[HN Gopher] Remix web framework aquired by Shopify
___________________________________________________________________
Remix web framework aquired by Shopify
Author : betageek
Score : 436 points
Date : 2022-10-31 14:16 UTC (8 hours ago)
(HTM) web link (remix.run)
(TXT) w3m dump (remix.run)
| pearjuice wrote:
| Any ideas about acquisition cost? How do you value a FOSS
| project?
| wahnfrieden wrote:
| talent hires + brand trademark
| tbeseda wrote:
| GitHub star count /s
| Zealotux wrote:
| Congratulations! I was keeping an eye on this project for
| production use, and this news is boosting my confidence.
| interstice wrote:
| Having built a number of headless Shopify sites in Next JS this
| is slightly concerning, I was imagining a port over to Hydrogen
| at some later date with minimal changes rather than a total
| replatform.
|
| Of course a replatform wouldn't be necessary if Shopify would
| help out by - for example - not force logging out (and otherwise
| breaking checkout) for users that came from a headless store.
| wizwit999 wrote:
| Everyone raised seed funding recently, I wonder what was even
| their idea of monetization.
| dyeje wrote:
| Is Shopify shifting away from Rails?
| kylehotchkiss wrote:
| Shopify has a nice GraphQL API that can be used to build JS
| frontends:
| https://github.com/Shopify/quilt/tree/main/packages/react-gr...
|
| I imagine that paired with Remix it'd be easy and fun to build
| shops. It doesn't have to replace rails in that regard.
| tekbog wrote:
| This is something I'd like to know as well and nobody is
| talking about it, weird.
| Existenceblinks wrote:
| Remember the whining people don't take action .. but the guys
| who have been silent all along quit .. suddenly shocking
| everyone? They will keep saying everything is going great!
| fuzzygroup wrote:
| Amen!
| ecshafer wrote:
| We use a lot of React at Shopify on top of Rails, along with Go
| and Rust for critical performance systems on the backend.
| tinglymintyfrsh wrote:
| Makes sense. Ruby dev over at Meta who uses Vue, TS, Rust
| WASM, and Rust backend at home. No Go (anymore) or Rails, but
| I love Rails, DRY-rb, trailblazer, haml for their
| expressiveness and software engineering.
| theklr wrote:
| Probably not, but going where the market is in terms of
| business. Majority of their headless support is for react so
| investing in the stack allows them to expand and dictate that
| future. (Ancedata: did headless Shopify with ember and was
| aggravated in how piss poor their js support was in relation to
| React until their dev team told the data).
| airstrike wrote:
| This is likely a better link: https://shopify.engineering/remix-
| joins-shopify
| alberth wrote:
| Why acquire something that is MIT licensed?
|
| Is this really just a talent acquisition?
|
| https://github.com/remix-run/remix
| marstall wrote:
| that was my thought. an acqhire glammed up. from what I can
| tell remix isn't generating much heat.
| mdasen wrote:
| I wouldn't really call it a talent acquisition. It's more the
| same reason that any company pays people to work on open source
| projects. For example, Google pays people to make Flutter and
| Dart. Are those employees a "talent acquisition"? Clearly no
| because they started the project within Google. So then why is
| Google paying people to work on some MIT licensed thing? Well,
| it gives them a high-quality bit of code to build the things
| that are actually their business and it gives them a certain
| amount of control over the direction and priorities of the
| project.
|
| Let's say that I make a library X that your company uses. You
| can use X for free so why acquire X? Well, if X is a project of
| your company, that can give your company positive reputational
| benefits by association. You can set the priorities and roadmap
| of X. I'd be working at your company so I'd be there to help
| other developers. I'd see the friction you had in your
| environment and want to remove that friction.
|
| I'm not saying that the owner of an MIT licensed project can do
| anything they want. There's always the possibility of forks.
| However, there is still a certain amount of control. For
| example, Google's control of Go basically meant that they
| controlled the decision to go with a non-copying garbage
| collector because that was what would be best for Google and
| its codebase (and most people wouldn't care about the trade-
| offs that much).
|
| I think it's more than just "here are some smart people we can
| acquihire." I think it gives them influence over a project they
| might see as important.
| whalesalad wrote:
| we buyin frameworks now
| super256 wrote:
| Anyone remembers that upon Remix' initial release, one had to
| buy a licence for 250 USD?
|
| https://web.archive.org/web/20201204025307/https://remix.run...
| esprehn wrote:
| Michael and Ryan have always been about trying to make money
| from their React expertise. They literally created a company
| called React Training: https://reacttraining.com/team and
| have had a fairly lucrative business doing workshops for
| years.
|
| No harm in trying to get folks to pay for a framework. It
| doesn't seem it worked, but I can't fault them for trying!
| jholman wrote:
| Apropos of which, it always baffled me how bad the React
| Router documentation was, given that the company name was
| react-training. It was like an anti-ad.
| esprehn wrote:
| Some could argue the just okay docs were driving
| consulting business. Even the TFA mentions they started
| conversations with them because they were using react
| router! :p
| zwily wrote:
| React Training worked really well, was very profitable till
| Covid shut it down. Obviously not a scalable startup type
| thing but still a nice little business.
| PKop wrote:
| So what? This is akin to crowdfunding, or patronage. Many
| people were happy to have early access while supporting the
| project.
| super256 wrote:
| I just wanted to post this here because I think it's an
| interesting piece of trivia.
| adoxyz wrote:
| Congrats to the Remix team.
|
| I'm not entirely sure how you acquire a web framework or what the
| end-goal is, but I'm sure smarter people than I have the done
| maths.
| PhoenixReborn wrote:
| Acquihire - you're not looking to buy the framework itself,
| you're looking to get the people who built it to work for you
| instead.
| ComputerGuru wrote:
| remix feels like the react version of htmx. I'd just use the
| latter, tbh.
| exogen wrote:
| I suspect you are confused about what Remix is, unless I vastly
| misunderstand htmx.
|
| By example, a request comes into my app's web server at
| `/posts/123`: how would htmx be involved at all in (1)
| understanding the request, and (2) generating the response?
| Remix isn't just client-side, it's also a server with routing
| and SSR.
| ComputerGuru wrote:
| Yes, the routing part isn't covered by stock htmx but it can
| be shimmed server-side or client-side. The more "fundamental"
| bit as I understand it is that each logical/visible component
| is served by the server-side in a remix app as a separate,
| fully-rendered html component, instead of needing to render
| the entirety of the response to effectively obtain just a
| part of the view. Htmx provides that bit of the puzzle
| lending the remix-like aspect to a traditional server-side
| app.
| EduardoBautista wrote:
| I don't understand what is the business case for acquiring an
| open-source framework?
|
| Can someone explain why couldn't they just contribute or fork the
| project?
| tmorton wrote:
| It's an aquihire - they get the core team on staff. They can
| influence the open-source project roadmap, and get priority
| support for their integrations.
| sgallant wrote:
| Offering a great developer experience (DX) when building
| e-commerce sites is core to their strategy. DX was a key reason
| why they beat Squarespace in the early e-commerce days:
| developers preferred building Shopify sites over Squarespace
| sites.
|
| It's in Shopify's best interest to maintain that developer love
| and Remix can help with that. Here are two hypothetical
| situations to highlight that point:
|
| 1. If someone else, say, Swell [1], had better DX than Shopify,
| we would see Shopify start to lose market share to Swell for
| the segment of the market where developers can influence the
| tooling decision (i.e. agencies).
|
| 2. If in two years from now, everyone is using Next.js to build
| e-commerce sites, that would put Vercel (the company behind
| Next.js) in a good position to promote/partner with other
| e-commerce providers or build their own e-commerce solution and
| compete with Shopify.
|
| The developer market segment is important and DX is key there.
|
| [1] https://www.swell.is/
| SeanAnderson wrote:
| It's pretty decent, passive marketing, too. One could argue a
| similar effect would be achieved by a fork, but I don't think
| it would ring as true to SWEs.
|
| I think about Google a lot more due to how prolific Material
| Design is throughout my web experience, I think about Meta a
| lot more due to how prolific React is throughout my web
| experience, etc.
| nilsbunger wrote:
| Rewinding earlier, what is the case for VC investment in an
| open source framework? Usually it's some variation of
| proprietary extensions ("open core"), enterprise support,
| and/or hosting. Docker, Red Hat, MongoDB are prominent
| examples.
|
| So that could also be the rationale for Shopify acquiring it.
| Alternatively, they could've just wanted to acquihire an
| excellent team.
| jspash wrote:
| There seems to be a disconnect between what Shopify do internally
| and what they ask of their users. With Hydrogen and now Remix you
| would think they have their sh*t together. But when the official
| docs recommend that you inline jquery click handlers for a simple
| adjustment to their shop, I just don't know what to think.
|
| All in all the Shopify dev experience for me is on par with
| Wordpress. I hold my nose and cash the cheques. Then hurriedly
| leave the premises in a long trench coat with my hat pulled down
| to avoid being recognised.
| dmix wrote:
| There's often a disconnect between the technical staff who
| write customer-facing documentation vs the backend engineering
| teams.
|
| Often the technical writers will be working closely with real
| customers. The customers will come to them 90% of the time with
| hacky custom jQuery stores + the support staff won't be highly
| skilled Front-end engineers (usually a junior-dev grasp of
| JS/web dev).
| leviathant wrote:
| Shopify likes to brag about having 4,000 developers. Given
| the output of the company - that comes across to me as bloat.
| dewey wrote:
| Judging the visible output as a metric for how many
| developers a company needs is very naive.
|
| Think about the teams that don't directly interact with the
| outside like infrastructure, business intelligence, hiring
| (onboarding tools), internal tooling, all the work they do
| on Ruby (https://shopify.engineering/shopify-ruby-at-scale-
| research-i...).
| rhaway84773 wrote:
| Shopify probably employs many devs whose job is likely to
| pretty much operate as consultants for some of their
| larger customers.
| dubcanada wrote:
| Why do you feel that way?
|
| What is wrong with a quick inline jquery click handler? What
| part of web development requires webpack + react + tailwindcss
| + a bunch of random packages that provide 1 function? Sometimes
| people just want to get stuff done, and doing a simple
| $('.cart').on('click', () => {}); does the job.
|
| If you want to get fancy as another user posted, use the full
| API suite and do it all yourself. It's robust and rather
| friendly to integrate with.
| enumjorge wrote:
| If the argument is for minimalism, why use jQuery when
| vanilla JS suffices?
| dirkg wrote:
| because JQ is already loaded, and it IS minimal. You could
| do querySelector(...).addEventListener etc but why would
| you?
| cobertos wrote:
| Because you don't need another library to do it? Why load
| jQuery at all in 2022?
| mritchie712 wrote:
| It's legacy. A lot of people know jquery from when the
| things it does were verbose in vanilla JS. New devs
| rarely learn jquery, so it will die.
| good8675309 wrote:
| I get the purist push for Vanilla JS but for me it's
| still way too verbose. W3C has had decades to fix it and
| while it's improved it's still verbose as heck. Just
| implement the jQuery API into Vanilla JS and people would
| stop using jQuery.
| AprilArcus wrote:
| "just"
| good8675309 wrote:
| I mean the W3C has an annual revenue of $5.7M so it's not
| like they don't have the resources to start setting some
| vision and goals towards this.
| dmitriid wrote:
| Look at who makes up W3C. Then look at how much it costs
| to be a member.
|
| They could afford _anything_ if they cared to. Most of
| the time they don 't and so the small players like Chrome
| get away with anything.
| bcrosby95 wrote:
| I'm really surprised they don't get more shit for it.
|
| People love to make fun of Java for being verbose but
| then go all googoo eyes over Vanilla JS. As a Java
| developer for 20 years now, using it makes me think a
| Java developer from the '90s designed it.
|
| But, you know, it's JS so it gets a pass.
| c-smile wrote:
| That's what I did in Sciter:
|
| 1. Added element.$("selector") and element.$$("selector")
| functions. Later one allows to work with JQ sets:
| for(let el of parent.$$(".child")) ...
|
| 2. Added element.on("eventname" [,"selector"], handler)
| and element.off()
|
| These two allow to reduce need for JQuery to almost zero.
|
| Also added JSX as a built-in feature to JS/runtime. So,
| function Child(props) { return <p>Generated
| child {props.index}</p>; }
| function Main() { const list = [1,2,3];
| return <main> { list.map( el => <Child
| index={el} /> ) } </main> }
| // add the list to the DOM:
| document.body.append(<Main />);
|
| These three simple things, together with
| elment.patch(...JSX...) eliminate need for as JQuery as
| ReactJS almost completely.
| rhaway84773 wrote:
| A significant chunk of Shopify's user base is gonna be
| copying/pasting snippets they've found online.
|
| You're much more likely to find a snippet using jQuery that
| was created over the last 10 years or so that's consistent
| and works correctly than you are vanillaJS.
|
| VanillaJS queries would be all over the place with multiple
| if/else's for IE, Chrome, WebKit, Mozilla, etc.
| rhaway84773 wrote:
| What does VanillaJS get you over jQuery? The only practical
| argument I can think of is the performance improvement of
| not loading another library and loading all the extra KBs.
|
| But nearly every Shopify website's hero image itself would
| completely dwarf any bandwidth concerns jQuery might cause.
|
| In the meanwhile, jQuery is a much better known API among
| developers, there's far more and higher quality
| documentation and snippets available in it on the internet,
| and there are fewer foot guns.
|
| jQuery easily seems the superior choice over VanillaJS,
| with very few downsides given Shopify's use case.
| melony wrote:
| Nothing wrong with it but it doesn't make for coherent
| documentation. For a plugin-centric company like Shopify
| where third party integrations are crucial to its business
| model, you would expect more hand holding and better quality
| in its documentation. Their docs for common use cases like
| jquery and react/vue/svelte should be clearly laid out.
|
| Shopify seems to be an incoherent mess right now with poor
| engineering management. The stories that I am hearing are
| that a third of their engineering workforce consist of
| interns and the other third consist of juniors. They have
| very few engineering seniors and staffs, relative to most
| companies of their scale and market cap.
| mkl95 wrote:
| Most places that employ rockstar frontend guys are like that.
| Management let them build their design systems and other cool
| stuff, but most of their backlog consists of new spaghetti on
| top of old spaghetti plus bug fixes. The cool stuff is used on
| greenfield projects.
| [deleted]
| theturtletalks wrote:
| They have a perfectly good Storefront API that allows you to
| build any storefront. We use Shopify with Next.js and if we
| ever wanted to switch platforms, we would just change the API
| calls and keep the same frontend.
| Existenceblinks wrote:
| I wouldn't be surprised if they swap out liquid and its json
| based layout config .. despite they keep saying everything is
| doing great. New gen developer probably got gaslit by React
| vibe and demands change (admittedly I made this shit up)
| btown wrote:
| This acquisition is very much in the context of
| https://hydrogen.shopify.dev/roadmap/#first-quarter and
| https://github.com/Shopify/hydrogen - Shopify very much wants
| to move to the modern era.
|
| And to address your point, it's not gaslighting to say that
| React enables interactions that would be essentially
| impossible if restricted to server-side templating. But
| there's certainly some degree to which trendiness and a
| desire to attract developers into their ecosystem is driving
| this as well.
| Existenceblinks wrote:
| Remix approach which is Shopify is going with is having
| data loader code separated from client side code. So it
| could be .. Solid.js or vanilla.js that enables the
| interaction part. It's always has been this way, this time
| it's just writing html renderer in js.
| BryanBeshore wrote:
| FWIW: Tobi mentioned that if he had to do it all over again,
| he would still build the admin and business logic of Shopify
| in Ruby on Rails, but would probably build their liquid
| rendering in Rust or something like it
|
| https://twitter.com/tobi/status/1585459224506671104?s=20&t=0.
| ..
| cultofmetatron wrote:
| elixir/phoenix gives you a lot of the same productivity as
| rails with vastly higher performance. the big benefit to
| rails these days is the massive ecosystem of drop in gems.
| reducesuffering wrote:
| Probably only because that's what he's familiar with. Rails
| has the most ubiquitous scale problems that large co's keep
| migrating away from, and new devs are trending away from
| it. Shopify investing into the JS/TS backend world is just
| another domino falling of Ruby/Rails descending into Perl-
| like prevalence.
| weatherlite wrote:
| They are spending tens of millions building a ruby JIT so
| I am not sure you are painting an accurate picture
| here...
| reducesuffering wrote:
| So they recognize they're having problems with speed.
| Dropbox also spent years trying to JIT Python faster with
| Pyston, and were unsuccessful. They now are leveraging
| Rust and Go instead.
| skinnymuch wrote:
| how do you keep up with developments like this? I
| suddenly see how interested I am in what stacks companies
| are using and more so what are they going to be using in
| the near to mid term future.
| ativzzz wrote:
| I imagine following the tech blogs of certain companies -
| you can read about dropbox's engine rewrite here -
| https://dropbox.tech/infrastructure/rewriting-the-heart-
| of-o...
| reducesuffering wrote:
| For trends:
|
| StackOverflow Trends: https://insights.stackoverflow.com/
| trends?tags=ruby%2Ctypesc...
|
| GitHub Star History: https://star-history.com/
|
| NPM trends: https://npmtrends.com/
|
| For specific co tech stacks:
|
| Tech Co migrations: https://github.com/kokizzu/list-of-
| tech-migrations
|
| https://stackshare.io/wikipedia/wikipedia
|
| https://builtwith.com/
|
| Company GitHub page
|
| And HN in general, like surfacing this Shopify
| acquisition.
| dheera wrote:
| How do you acquire a framework? Why not just use it?
|
| It's not like there are physicists trying to acquire Dirac
| notation.
| Existenceblinks wrote:
| I have strange feeling about these nodejs server based and the
| direction of the web and the chaotic of Big|VC-backed corps
| playing chess. And that also causes effect on web job market. ..
| what's your retirement plan?
| colinramsay wrote:
| I'm not sure how to feel about this, but my main wish for Remix
| is a public roadmap and full development in the open. There is
| overlap but also healthy competition between it and NextJS, and
| I'm really interested to see where Remix goes next.
| PKop wrote:
| .
| nathancahill wrote:
| I read the opposite. There currently isn't, so it will be
| Ryan's #1 focus.
| [deleted]
| lloydatkinson wrote:
| Wow. With the recent remix drama this is an interesting
| development.
| rs_rs_rs_rs_rs wrote:
| Which one more specifically? :)
| thangngoc89 wrote:
| I don't follow discord or their github's repo, just reading
| release notices so could you please elaborate?
| lloydatkinson wrote:
| One of the main authors tweeted a bunch of crap about
| numerous other frameworks and then delete it a few hours
| later
| tasubotadas wrote:
| How does remix compare to nextjs?
| krtscrum wrote:
| https://remix.run/blog/remix-vs-next
| megaman821 wrote:
| Remix looks like a standard server rendered web framework (like
| Rails or Django) except that is use React for its template
| language, and React has the advantage of running interactively
| on the client-side.
|
| NextJS pre-generates (or generates on a trigger) most its
| pages. Like Remix it also uses React as its template language
| and client-side interactivity.
| kkielhofner wrote:
| Interesting development. If I were to guess who would acquire
| (acquihire?) Remix I would have said Cloudflare.
| youngtaff wrote:
| Cloudflare acquihired the Linc team a while back
| gabrielizaias wrote:
| Interesting move by Shopify, given that they have Hydrogen [0]. I
| was half expecting Hydrogen to become its own all-purpose
| framework, but alas, they seem to plan for both to co-exist.
|
| > While Hydrogen is focused on commerce, Remix is focused lower
| in the stack, and will continue to be a general web solution that
| scales from content through commerce and all the way to apps.
| Shopify will use Remix across many projects where it makes sense,
| and you can expect to see more of our developer platform with
| first-class Remix support over time.
|
| [0] https://hydrogen.shopify.dev
| jplhomer wrote:
| We're working on a new version of Hydrogen which is powered by
| Remix: https://hydrogen.shopify.dev/roadmap/
|
| It's nice to not have to build two meta-frameworks (along with
| docs and support) so Hydrogen can focus on commerce things.
| matthewcford wrote:
| Will there be beta releases before Feb? I'm looking to kick
| off some headless shopify projects soon - and ideally I don't
| have to rewrite them in a few months time.
| jdelman wrote:
| Congratulations to the Remix team. Though neither Remix's nor
| Shopify's blog posts make it clear, I'm guessing Michael and Ryan
| will continue to lead Remix development while hopefully having a
| team of focused engineers working with them. Since Shopify really
| believes in and wants to use the tech, it's great that they'll be
| able to pay engineers to continue to develop it in the open. I
| believe Remix also was VC funded so Shopify probably also made
| their investors whole?
| swyx wrote:
| happy noises from JJ who led their seed
| https://twitter.com/josephjacks_/status/1587136935981481984?...
| warent wrote:
| Nice little chunk of change for him!
|
| Wow and their (OSS Capital) first exit since founding in
| 2018. Talk about patience, but well worth it I'm sure!
| emptysea wrote:
| I'm curious if remix will remain general purpose or if it will
| gradually drift into just being used for Shopify things.
| lairv wrote:
| Aren't Remix and Hydrogen supposed to fill the same role ?
| Despite what Remix's creators try to argue, for me Remix is great
| for low interactivity website like e-commerce website, even doing
| a simple client-side request without refresh is a pain in Remix
| jplhomer wrote:
| We'll be redesigning Hydrogen to be powered by Remix:
| https://hydrogen.shopify.dev/roadmap/
| jacquesc wrote:
| Anyone currently using Remix in a production app? Read through
| the docs and it seems pretty interesting. Can't really get a
| sense for how stable it is though.
|
| I know from prior use of React Router, the maintainers love the
| big rewrites between major version numbers.
| Existenceblinks wrote:
| Mix feeling of this Correlation:
|
| React Router -> Remix
|
| Redux -> RSC
|
| Snowpack -> Astro
|
| "This time, we will make it right" kind of feeling.
| rozenmd wrote:
| I built a status page service
| (https://hackernews.onlineornot.com/) on Remix, I find the data
| fetching patterns (and SEO) make a hell of a lot more sense
| than Next.js
| roci89 wrote:
| Yeah we use it. It has been fantastic. Having a mutation story
| is an absolute game changer for productivity
| colinramsay wrote:
| Yes. The use of loaders and actions blurs the lines between
| client and server. It's really productive. There are a few gaps
| that need filling, one that comes to mind is
| internationalisation [1]
|
| I am very surprised that NextJS has left it so long to consider
| mutations - they're apparently coming up with an RFC on that
| but it seems to be somewhat behind closed doors.
|
| [1] https://github.com/remix-run/remix/discussions/2877
| jacquesc wrote:
| I agree, the API on remix seems awesome
| orliesaurus wrote:
| I never used Remix, why is it worth it investing in Remix?
| vosper wrote:
| Having used both, if you already know NextJS well then I
| wouldn't bother switching to Remix. If you want some of the
| Remixy API-niceness in NextJS land then you can use tRPC (for
| example, there are probably other options).
|
| Nothing against Remix, I do like it, it just isn't
| differentiated enough from NextJS to both switching for me -
| yet, at least.
| Scarbutt wrote:
| It's just an optimization to make your react pages load faster.
| emadabdulrahim wrote:
| This is huge. Remix is my favorite React framework at the moment.
| It is by far the best abstraction I've seen of client/server
| model. Their API abstraction layer is just right, working with
| native browser and nodejs APIs, not obscure them. Typescript
| support is amazing.
|
| I'd bet my money on Remix model and direction vs Nextjs
| pokpokpok wrote:
| could you characterize the difference you see between them? (to
| someone more familiar with nextjs?)
| emadabdulrahim wrote:
| High-level summary of Remix data
| model:https://remix.run/blog/remix-data-flow
|
| See also https://remix.run/blog/remix-vs-next
| tpmx wrote:
| > This is huge. Remix is my favorite React framework _at the
| moment_.
|
| I suppose this means it's temporarily huge.
| ornornor wrote:
| Wait what? We have frameworks for frameworks now? What?? How
| did we get there :(
| carlhjerpe wrote:
| Have a library never depended on another or just wrapped it
| up nicer with helpers and stuff? You don't write ASM or C a
| lot anymore either right?
|
| Many of these examples can make it easier to do things right,
| increasing performance by doing less things (better defaults
| etc) so I don't think something like this should be frowned
| upon.
| didip wrote:
| Everyone told me that Javascript ecosystem is maturing and
| slowing down.
|
| Everyone told me to just consider either React or Vue.
|
| But that doesn't seem to be the case.
| reducesuffering wrote:
| For 7-8 years now you've been able to use just React, even
| not learning functional components. You don't need to add
| Next, Remix, or learn Vue, and your career would be safe
| for the next decade with how many React codebases there
| are.
| Traubenfuchs wrote:
| Java has the same in the form of the Spring framework that,
| afaik, forces you to write your own entry point controller
| and take care of providing the servlet container yourself.
| There is the Spring Boot framework which sets all of this up
| for you in about 10 lines of code.
|
| People also made fun of this "framework for a framework"
| paradigm. But, if it works, so be it.
| tr1ll10nb1ll wrote:
| There's nothing wrong about that. Your existing options
| remain and WILL remain. The new options just feel more
| productive (but that's subjective too).
|
| If you prefer writing separate backend code:
|
| - You can use any backend with Next.js/Remix if you want to.
| (https://remix.run/docs/en/v1/guides/bff)
|
| - You don't have to use either of those for your front-end in
| the first place. You can just use React with Vite.
|
| Thinking about SSR/SSG? You can use the Vite SSR plugin (does
| serverless SSR really well too)
|
| If you prefer having your server and client coupled and want
| to go in with the new options (using React as your library):
|
| - Use Next.js/Remix for everything. You can then choose parts
| of your architecture individually (for instance Prisma as
| ORM, TRPC/Blitz's RPC model as your API model (or Remix's
| action-loader pattern), etc.)
|
| These are just two options and probably all you'll need to
| know to be productive unless you WANT to know more in which
| case you'll inevitably do your own research.
| savanaly wrote:
| I think React is better described as a library than a
| framework. Frameworks for libraries sounds entirely
| reasonable to me.
| super256 wrote:
| React does indeed describe itself as a library.
| eurasiantiger wrote:
| It is closer to Twig than Symfony.
| davnicwil wrote:
| not only reasonable but an inevitable conclusion I'd argue.
|
| I've been waiting for the current crop of React frameworks
| (of which Remix is my current favourite but they all bring
| cool thing to the table) to appear since the early days of
| using it - it was only a matter of time.
|
| First the library, then the patterns, then the ecosystem of
| add ons implementing those patterns, then the projects that
| scaffold sensible sets of those together for you along with
| a build setup etc, and finally... the all in one framework
| that does it all out the box.
| Traubenfuchs wrote:
| > the all in one framework that does it all out the box
|
| Wouldn't Angular and Vue count as cohesive "batteries
| included" frameworks?
|
| Having to work on your own build setup feels very inane.
| klysm wrote:
| Not 100% sure this is a positive thing for the Remix framework
| long term.
| evtothedev wrote:
| > I'd bet my money on Remix model and direction vs Nextjs
|
| With Nextjs 13, the patterns are actually kind of converge. See
| this whole thread from Ryan at Remix with his thoughts on it:
| https://twitter.com/ryanflorence/status/1586820806625046529
| psychoslave wrote:
| Wait, isn't React a js framework? Is Remix a framework over a
| framework?
| ajgrover wrote:
| People are using the term "metaframework" these days to
| describe things like Remix and Next that build on top of
| React as the view layer and provide many of the other bits
| you might need to get a fully-fledged web app up and running.
| Including but not limited to routing, performance
| optimizations for images and fonts, data fetching, SSR/static
| generation & regeneration
| underwater wrote:
| A meta framework on top of a Meta library?
| pier25 wrote:
| React is a library. Remix is a framework.
| dntrkv wrote:
| React is a framework though.
|
| The main differentiator between the two is Inversion of
| Control.
|
| React developers write their code to be called by the React
| application. You aren't choosing to include React or not
| (what you would do with a library), your whole frontend
| application is built within the context of the React
| environment in which it will run.
| reducesuffering wrote:
| Dan Abramov, React lead, says this:
|
| "i like to think of React as two things. React is a
| library. it is _also_ an architecture (which frameworks
| may implement) "
|
| https://twitter.com/dan_abramov/status/158508871644361523
| 4
| vlunkr wrote:
| It's technically a UI library. Though the line there is
| fuzzy.
| vosper wrote:
| If we're calling both "framework" (though as another
| commenter mentioned, the React package is pretty much just a
| UI library) then you can think of React as a UI framework and
| Remix as an application framework. You use the React UI
| framework in the Remix (or NextJS) application framework.
| jahewson wrote:
| Vercel already ate Remix's lunch.
| theklr wrote:
| While it may seem that way there's still plenty of market
| share on the table. Add vercel's increasing coupling to its
| deployment system for best features, others will always
| welcome more agnostic approaches.
| mr90210 wrote:
| By far.
| kylehotchkiss wrote:
| I was surprised how calm the remix developers reactions to
| the next 13 announcement were given how similar some of the
| new next features are. But now it makes sense! Upcoming
| acquisition on the horizon.
| jackbravo wrote:
| Very related:
| https://twitter.com/ryanflorence/status/1587096603822673920
|
| > Seeing that Next.js 13 preview before this acquisition
| would have put me in major defensive mode "HEY THATS OUR
| API" but now I'm just super chill and can work on Remix
| instead of my mental health
| asadlionpk wrote:
| Because they cashed out, don't care anymore $_$. Looks
| like Shopify's diligence team should be blamed here.
| lostcolony wrote:
| Should they be though? I'm not at all familiar with the
| specifics at play here, but from a company perspective, a
| player they can then fully shepherd to prioritize their
| own needs/desires for, is still a win against an
| alternative that would be more expensive to acquire, and
| which if they don't they can't own priorities for.
|
| Obviously there would need to be a balance between
| determining roadmap for your own needs, and building
| something to more broadly appeal to use in the outside
| world, but getting to influence that without creating a
| fork is still huge.
|
| And that's without the other considerations of the
| acquihire aspect.
| andrewingram wrote:
| They already did some very public complaining about it
| several months ago when the Layouts RFC was first
| published.
| kylehotchkiss wrote:
| I was expecting a lot more on release day!
| tfsh wrote:
| the https://remix.run website is beautifully fun. I know lots of
| people will berate it for being OTT, but scrolling I wouldn't say
| is a critical path given the docs/get-started call to actions.
|
| I'd be interested to see what Shopify do with remix, are they
| more interested in the core team, maintaining remix.run as they
| plan to/do(?) use it internally. I assume they want to offer this
| framework as a baked in enhancement of Hydrogen[1] to try and
| help clients build more robust sites.
|
| 1: https://hydrogen.shopify.dev
| yen223 wrote:
| I really like the website. I think it did a great job at
| telling us why we should care about Remix the framework, what
| problem it was designed to solve. A lot of websites for other
| OSS projects struggle with this.
| robertlagrant wrote:
| It is fun! The Windows crash screen made me laugh.
| asim wrote:
| Didn't Remix raise funding? Trying to read between the lines
| here. No appetite to raise further funding? Too much competition?
| Just curious.
| PhoenixReborn wrote:
| They did raise funding. It's unclear to me what their business
| model would have been (compete with Vercel?), and maybe the
| struggle to find one was why they decided to go for an
| acquisition.
| zebnyc wrote:
| I remember they had a really expensive subscription model
| (even for solo developers). They were looking to get traction
| based on the reputation of the founders and other tech
| influencers (like Kent C Dodds) in the react community.
|
| Personally I felt that they were not very clear on who their
| target audience was and what was the niche that they were
| trying to address to transition from good to great dev
| experience.
| bredren wrote:
| >They were looking to get traction based on the reputation
| of the founders and other tech influencers (like Kent C
| Dodds) in the react community.
|
| This had the opposite effect for me.
|
| I bought Dodds' Epic React course and it seemed to have
| been kicked to the curb in favor of joining and boosting
| Remix.
|
| I remember some important course updates were pending, and
| seemed to come to a standstill while his entire blog was
| re-written in Remix.
|
| Then a month or so later he joined that team. I really
| liked his prior educational content, in this it seemed like
| paid promotion for a particular framework.
|
| The VC raise and bringing Dodds on seemed like peak
| (hopefully!) hypecycle for frontend JS stuff.
| SevenNation wrote:
| This post is puzzling:
|
| 1. Michael Jackson tags himself as "Co-founder, CEO."
|
| 2. Remix website gives no indication that it's a company or that
| there is a company called "Remix."
|
| What's going on here? What exactly what "acquired?"
| rglover wrote:
| I'm always accepting refugees [1].
|
| [1] https://github.com/cheatcode/joystick
| Toine wrote:
| I'll stick to NextJS. Remix seemed fishy from the very start.
| kylehotchkiss wrote:
| To me, Remix seemed like a very lightweight reimagining of what
| Next excelled at (server side react with nice frontend
| integration). It was exciting to see how quickly it handled
| dynamic renders when running from a Cloudflare worker. But now
| that Next 13 has layouts/server components, I prefer Next.js'
| approach due to all the other performance work they've done
| with images, fonts, css, etc.
|
| One thing about Remix that always confused me was the very
| close ties to react router. It seemed like a distinct and
| unrelated concept to me, and the continued association seemed
| like a distraction from Remix's potential to be a stronger
| competitor to NextJS in the long run
| yilugurlu wrote:
| Ryan, the co-founder of Remix said this [1]
|
| > Remix is really just React Router + SSR.
|
| [1]
| https://twitter.com/ryanflorence/status/1586835847583653889
| Aeolun wrote:
| I share your feeling, but I don't think it's reasonable.
|
| I've used both now and it's just fine as a framework. Maybe
| it's in the way they present themselves.
| phgn wrote:
| Definitely it's how Remix presents itself. Their landing page
| reads like a marketing pitch by some crazy startup looking to
| raise money, not like a stable library to build a product on.
| You have to scroll quite far to get any factual information
| on what differentiates it from Next.js. I quote:
|
| > Focused on web standards and modern web app UX, you're
| simply going to build better websites
| DangitBobby wrote:
| Remix has some very clear second system advantages that become
| more apparent with usage. Next.js is trying to address many of
| their relative shortcomings in the 13 release. I would still
| advocate strongly for anyone to give Remix a try. Both are fine
| frameworks, at the end of the day.
| nell wrote:
| ~No they aren't rebuilding Hydrogen in Remix.~ Edit: Spoke too
| soon on the above, sorry.
|
| Remix raised funding. Ran out of money with no scope to self
| sustain or raise money. They downsized (see Kent Dodds. Perhaps
| there are others). Strong engineers that built the platform got
| acquihired.
| eatonphil wrote:
| > No they aren't rebuilding Hydrogen in Remix.
|
| Looks like they are.
|
| https://news.ycombinator.com/item?id=33407274
___________________________________________________________________
(page generated 2022-10-31 23:00 UTC)