Remix – A framework focused on web fundamentals and modern UX

I usually have deep hatred towards scroll-jacking but this was actually quite well done.<p>Not because of the pizzazz but because it essentially put only one thing to learn on the screen at once. It was like a &quot;getting started&quot; section that might be slower to go through but feels like it&#x27;s faster to understand.

So, after looking over the docs, here&#x27;s my comparison list between Remix (which I haven&#x27;t used) and other things that I&#x27;ve used.<p>- Forms seem better in Remix. Remix seems focused on progressive enhancement here, rather than fetch. Imagine if Next supported POST endpoints, and the idiomatic way of making your site was to use that instead of API endpoints. I hope that we soon see a Remix-compatible form validation library (e.g. something that takes a zod schema, validates it on the server, and handles client-side validation and state tracking).<p>- The nested routes feature sounds interesting, but the docs for it are completely devoid of actual code, so I have no idea how ergonomic it will feel compared to something like Relay (requires complete buy-in to the ecosystem) or Suspense (extremely ergonomic black magic).<p>- The error boundary feature is a very nice touch. I guess it depends on their nested routes feature to function. I haven&#x27;t explored React&#x27;s own error boundaries, so I can&#x27;t comment on how ergonomic it is to add these to other components (in Next or in Remix).<p>- I don&#x27;t see anything in Remix about exporting the site statically, so it looks like you&#x27;ll want to stick with Next if you are actually building a static web site.<p>- CSS modules are not supported. It appears to be possible to add support to esbuild for CSS modules via a plugin, but there&#x27;s no escape hatch to be able to do this in Remix.<p>- There doesn&#x27;t seem to be an easy way to create auxiliary server-side scripts in Remix. Looks like you could hack it by manually setting up a separate TypeScript build step to emit your auxiliary script, but it would be nice to see this built into Remix properly. I accomplish this in Next by using the webpack escape hatch to add a custom server-side entry point that handles my auxiliary scripts.

Off topic: this is the best landing page I&#x27;ve ever seen on a mobile device. Keep scrolling down for some surprises!

I wonder how Remix ranks next to Blitz.js[1] or Redwood.js[2]. They seem like they&#x27;re all trying to do similar things.<p>[1] <a href="https:&#x2F;&#x2F;blitzjs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blitzjs.com&#x2F;</a> [2] <a href="https:&#x2F;&#x2F;redwoodjs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;redwoodjs.com&#x2F;</a>

So the web dev madness has come full circle - the react people just built rails in react. In the mean time I just keep using rails...

I&#x27;ve been hearing about Remix since they were sponsorware, but I don&#x27;t really get the appeal. They don&#x27;t seem to show how it&#x27;s different from e.g. Next.js, especially version 12 which seems to have a similar feature set of server-side plus static rendering, as well as React server components, and then a separate &#x2F;api folder for any backend apis you want to set up.

So as a 56yo &quot;old school&quot; LAMP-stack monkey, could someone please give me a quick rundown exactly what benefits would investing the mental energy (a non-trivial amount) and time (less an issue) give to someone in my ancient yet comfortable canvas Cons?<p>For sure next.js is an interesting framework and of course I use plenty of typescript in my projects to keep the UXs from feeling stale, but I have yet to see the overwhelming benefits that going all-in with something like this framework would give me overall, besides just the obvious one that I&#x27;m &quot;keeping up with the cool kids&quot;...<p>One think I do really like here is the way Remix is keeping things on the backend...I&#x27;ll admit coming from the 1980s I&#x27;m much more comfortable working with backend paradigms, so this particular stack has caught my attention more than others and why I am particularly interested in hearing about its direct benefits (besides the obvious ones like &quot;its not PHP&quot; of course)

I remember the team had the idea of charging for the software but now I am seeing that they raised VC money. There is no question that this sort of company can be big (See Vercel) but I&#x27;m wondering why this decision was made?

Haven&#x27;t looked at the specifics of the actual framework (yet), I came here to say that this landing page is simply amazing. It&#x27;s fun, it tells a story, it gets you engaged, and it&#x27;s fast and snappy and well-designed -- a pleasure to use! Kudos to whoever did the thinking &amp; the work!<p>EDIT: Finished scrolling to the end, and... now I feel kind of silly for having praised the landing page, because my mind is like... &quot;c&#x27;mon, it&#x27;s super simple, it&#x27;s still just text (albeit well-written), with some nicely done scrolling transitions etc&quot; -- BUT... it&#x27;s still really good! Yes, the elements and effects and everything on the page is stuff we&#x27;ve all seen already, it&#x27;s not really something new, but I feel like it&#x27;s just put together super well, and it is so frickin&#x27; smooth, I didn&#x27;t notice a single hitch anywhere...

Nice. Defining multiple zones, each with their data and error boundaries, at little to no cost is a nice approach.<p>Though as silly as it might sound, Remix’ publicity work has put me off it. Will read the docs anyway.

You should explain why it&#x27;s better than other full-stack SSR apps. Lots of people will come to Remix already knowing about SSR, they want to know about the advantages (like idk if other apps do constrained errors, how the speed compares, how live reload works vs others, etc.)

I really wish there were frameworks that developed ways to plug in with your already favorite backend kit instead of solely isometric with Node.<p>You couldn&#x27;t pay me to give up Phoenix in Elixir for backend work but it does lock off a healthy amount of the neat things being done to make data loading on the frontend more optimal. Phoenix has LiveView + AlpineJS but I really don&#x27;t want to give up React which still feels more productive to me.<p>This looks neat but just like NextJS and Sapper it will not nicely play with my stack.

From their contributing page: <a href="https:&#x2F;&#x2F;remix.run&#x2F;docs&#x2F;en&#x2F;dev&#x2F;contributing" rel="nofollow">https:&#x2F;&#x2F;remix.run&#x2F;docs&#x2F;en&#x2F;dev&#x2F;contributing</a><p>&gt; &quot;We need you to &quot;sign&quot; a contributor license agreement (CLA) first that assigns us ownership so we are able to include it in this software. We don&#x27;t yet have a CLA, but we are working on it and we will be able to accept your contributions as soon as we do.&quot;<p>Apparently, requiring a CLA isn&#x27;t as uncommon as I initially thought, but I&#x27;m still curious why some projects require this but others do not. What about their business model &#x2F; licensing choices necessitate a CLA?<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Contributor_License_Agreement" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Contributor_License_Agreement</a>

This seems interesting but the rendering bugs on the website don’t give me much confidence.<p><a href="https:&#x2F;&#x2F;ibb.co&#x2F;DfNw2GV" rel="nofollow">https:&#x2F;&#x2F;ibb.co&#x2F;DfNw2GV</a> <a href="https:&#x2F;&#x2F;ibb.co&#x2F;FgW3jQb" rel="nofollow">https:&#x2F;&#x2F;ibb.co&#x2F;FgW3jQb</a>

The best part of this is that someone took the time to explain how remix is different and why that can be good. I wish more projects would do something like this. There are plenty of tools I never learn about because no one bothers to explain them.

I&#x27;m already so impressed by Remix after watching the demo today. Looking forward to Kent Dodd&#x27;s demo tomorrow and to play around with the framework.<p>It has a great balance between client and server code. Just as React brought the mental model of writing integrated HTML&#x2F;CSS&#x2F;JS for an isolated component, Remix seems to bring the mental model of writing client and server code that are associated to one another together in an isolated way.<p>There&#x27;s so much power this brings and the benefit is easily seen in how much less client side JS is really needed to build websites with support for lots of user interaction.<p>It&#x27;s a push to go back to running code on the server that can, instead of shoveling everything into the client.<p>This is only the beginning of Remix, I&#x27;m excited to see what the team will bring.

Maybe it&#x27;s just me but the code at the top of the homepage is a bit confusing at first sight. I can kinda guess the conventions that hook stuff together but I wouldn&#x27;t put it as a &quot;welcome&quot; message without some comments at a minimum.

I have played with the generator app and some basic APIs. It seems to be a more opinionated NextJS.<p>It has a way to load data, submit forms, load styles... All good if you buy-in the philosophy of the framework, and I guess it could reduce js-fatigue.

Made me think of Ethereum&#x27;s remix, an amazing IDE all-in experience to write smart contracts: <a href="https:&#x2F;&#x2F;remix.ethereum.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;remix.ethereum.org&#x2F;</a>

&quot;let&#x27;s&quot; should be &quot;lets&quot;

Java&#x2F;React dev here. This seems great for a small app. But could someone help me understand how this would work in a large scale app? It looks like the some pieces of the JS make up the server side API of this and it runs in a V8 process. How would you deploy a production version on AWS and scale those à la ECS Fargate containers against RDS?

Seems like Svelte Kit too

They lost me at:<p><pre><code> return ( &lt;div&gt; {projects.map((project) =&gt; ( &lt;Link to={project.slug}&gt; {project.title} &lt;&#x2F;Link&gt; ))} &lt;Form method=&quot;post&quot;&gt; . . . &lt;&#x2F;div&gt; </code></pre> I don&#x27;t know why we need another framework that smashes together code and HTML&#x2F;directive-based templates like this and, generally, keeps us bound so tightly to web idioms.<p>Would be nice to have a framework that <i>obscures these kinds</i> of &quot;web fundamentals&quot;, so we no longer have to wrangle such low-level primitives to build complex apps.<p>EDIT: The people downvoting this are suffering from a failure of imagination. Sure, Remix may be an improvement over some current frameworks&#x27; failings, but there&#x27;s no reason improvements need to be so incremental or debt-bound.

How can this be integrated with react-query and react-location?<p>Seems that it&#x27;s tightly coupled to their variants (SWR and react-router).<p>React Query is IMO a must-have on any project that already warrants using React (and that isn&#x27;t an offline-only app of course).

The person writing the doc seems to go out of their way to use let everywhere instead of const when appropriate. Where I work there is also a guy like that, curious is this some new &quot;rethinking&quot; trending opinion or what?

Looks like another contender for transitional apps[1], all for it!<p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=860d8usGC0o" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=860d8usGC0o</a>

Not sure the holy grail exactly, but several of these new frameworks are probably on the right track. Particularly those that prescribe workflows and coding conventions that are just intuitive and easy to be expressive, instead of big frameworks with new languages and apis to learn.<p>My theory is, you can afford one big abstraction (React) on top of platform (HTML&#x2F;JS&#x2F;CSS&#x2F;Browser). Try to abstract beyond that, and things get unnecessary, bloated, and difficult to reason about.

The biggest complain for me about nextjs is the testing part. Did you ever tried to create a Monorepo which includes nextjs and want to run integration tests like any other react app with react-testing-library? Good luck. The integrated routing solution makes it really hard. There is a Community solution to named „next-page-tester“, but nothing official. That’s much better with gatsby and it’s built-in usage of reach-router. I hope it’s the same with remix.

One part of me likes this, it’s a framework built with many concepts I already use on my React apps on a DIY fashion. On the other hand I always have a bad feeling when there is too much magic under the hood… when magic don’t work in your favor you must turn to voodoo and that’s something I prefer to avoid in 2021.<p>Anyway I’ll give it a try on some side project, looks nice if you need something simple built fast (maybe with supabase or some of those new kids on the block)

This doesn&#x27;t tell me anything at all, it looks like 100% marketing.<p>Is there a comparison between this and Next.js, Gatsby or any other framework?

Feels like this is kinda doing some of the same thing as first-class React primitives like suspense and server components.

I was reading through the documentation and the only thing I think is really lacking is the fact that there&#x27;s no screenshots or examples of what the UI winds up looking like after the code has been written... is there any examples of what any of this looks like from the user perspective from the web browser side?

Just stop making websites (especially documentation) dark mode only, that&#x27;s a pain. At least when it&#x27;s the other way around you can easily use an extension to get dark mode, here you&#x27;re stuck with sometimes unreadable text unless you manually tweak the CSS.

I guess now one can have markup, css, client side js, and server side js all in one file...

This seems like a really neat web framework but I wonder if tangling some of the model and binding logic with react components might make it more confusing to extend the web app to say a native mobile client.

If this is just Next.js with nested routes, it‘s already worth it.<p>Seems like they have a bit more going on with progressive enhancement and interaction support, but nested routes are the headline for me.

I’ve only run through it on a surface level, but isn’t it the same as what JSF did a decade ago?<p>It rarely gets any praise, but to me it was the most productive web FE framework to date.

So this is Vaadin but in JavaScript and therefore cool?

The text are overlapping at a bigger text size.

To be honest what this does and how the code looks is like any random PHP CMS back than fifteen years ago.<p>I&#x27;m truly baffled.

Something new here? Because this is not new and gets posted semi-regularly every few months for a few years

I like this website. It&#x27;s one of the few I&#x27;ve seen do &quot;scroll = animation&quot; well.

the example boosts with a technology that requires making 4 requests to show the UI?

What&#x27;s the rundown on how this compares to the obvious competitors (Next, etc)?

Yay! Another JS framework, just what we needed!

Maybe i&#x27;m dumb, but i fail to see the advantages of doing 4 requests simultaneously instead of one single request to load an initial state.

truly something to get excited about in the frontend world. will use this to replace traditional server rendered pages from rails, django etc. props to the authors of this fine library.

This website is impressive somehow, but also crazy to parse. Always at least two things going on at same time, the viewers&#x27; attention constantly split instead of being guided.

I see no mention of Typescript support. Anyone know?

I know this is low-value, but it always stuns me to see basic typos on a product’s landing page (lets —&gt; let’s). Have the creators shown it to anyone else? Has nobody close to them told them about it?<p>I don’t blame anyone for making a mistake - everyone does it, and I’m certainly no exception. But typos like this make a product feel much less professional and by extension less trustworthy. To me, good copy feels important enough to be a top priority, at least on your landing page…<p>If a friend shared their new site with me and I saw a typo like this one, I would flag it to them every time.