Remix – A framework focused on web fundamentals and modern UX
remix.run
remix.run
Not because of the pizzazz but because it essentially put only one thing to learn on the screen at once. It was like a "getting started" section that might be slower to go through but feels like it's faster to understand.
Possibly even worse is the lack of snapping to the sentence, which means the user has to guess how far they need to scroll to fit the text in the available space. The text is even so large that some sentences don't fit in that space. It becomes a seemingly endless loop of reading 6 words, scrolling, reading 8 words, scrolling too far and then scrolling up, reading a 5 word joke, scrolling not far enough, etc.
In fact, it's 39 mouse wheel scrolls to get to the bottom of the page, all to read one paragraph of actual information -- and that information is mostly a bunch of boisterous posturing, in order to make a pitch that amounts to a couple of prescribed patterns.
You're reversing the series of events. A user visiting a page (especially a homepage) expects it to offer relevant information in an easily consumable way. It is impossible for a user to automagically intuit that they can get more easily consumable information on a separate page, just because a link to that page exists.
So, what you're suggesting is that it's good UX to make the homepage so annoying that multiple pages are required to provide the same information. That's called an anti-pattern, and really makes that nearly 1MB page load (and 80kB loading gif) a complete waste of time and electricity.
Even worse is that the feature information doesn't actually exist outside of the homepage, so you're making an incorrect assertion that people who don't want to scroll can instead just click a button.
> Every information is carefully chosen, so you keep scrolling and reading. After that you go to the doc to read more.
In this case especially, the information is the exact opposite of carefully chosen. It is chock full of jokes and irrelevant "aren't we cool" posturing, which comes across as pure "tech bro" and does a terrible job of convincing someone why they should use and trust this framework as a foundation for their product.
> I've never seen better UI/UX that hook me in so quickly. If it was just regular page I would think "ah, just another framework" and close the tab.
A bizarre statement. You're admitting to be willingly manipulated by style over substance, and that you have a premeditation for not actually reading a site's content unless they've met some arbitrary level of flashiness. If a project manager asked you to research frameworks, and your response was to supply them with a list of homepages that you thought "looked the coolest," you'd be fired on the spot.
I'm doing web development and UI/UX for some time, same as people who build this (I didn't even know who built this until now). And it checks every mark in my UI/UX book. Shared with my peers (devs, PO and designers), all think the same. Great UX.
And I'm glad that I don't work with your project managers, who apparently think that choosing frameworks based on a homepage's arbitrarily "cool" presentation is appropriate methodology.
> Everything you stated is just your opinion (phrases like "anti-pattern" or "bad UX", "style over substance"), and that's fine.
Yes, when somebody says something, it's their opinion -- not sure what point you're even trying to make here, honestly. However, I provided you with specific reasons for those opinions based on decades of published research by countless developers and psychologists. Intentionally slowing down information consumption IS an anti-pattern. Making people scroll dozens of times to read one total paragraph IS bad UX. Limiting information in favor of animations IS style over substance.
Whereas your entire argument is based around the presentation "looking cool," which is an opinion not even shared by the vast majority of commenters in this thread.
> I'm doing web development and UI/UX for some time, same as people who build this (I didn't even know who built this until now). And it checks every mark in my UI/UX book.
You appear to be asserting that "you know better" because you're a web developer. However, I've been a web developer for 25 years, so your attempted posturing doesn't win you any points here. Also, there are literal books on UI/UX -- tons of them, actually -- and they all disagree with your imaginary book.
> Shared with my peers (devs, PO and designers), all think the same. Great UX.
To show you how silly that argument is, I just shared this page with some folks -- three developers and two designers, all of whom have been in the industry for a minimum of a decade -- and asked them to give me a quick <5 word impression of the site. These are their responses:
"Page loads already scrolled to the bottom. Is that what it's supposed to do?"
"some shitty designers wet dream from 10 years ago"
"LOL - this is bad."
"stopped reading at: (What the heck does event.preventDefault do anyway?)"
"Garbage."
Well, except for the 50+ people who upvoted my comments and the dozens of people who made similar commentary about the website -- but I guess they don't count as real people because they don't agree with you?
> You didn't convince anyone. They already agreed with you.
You're right, I should have assumed that you know everyone on the site and surveyed them after my comments to determine that, in fact, zero people found any of my arguments convincing.
If that is Great UX, I think I prefer bad UX.
If you are the kind of person that interprets everything as cliché, then you are liable to become one.
It’s really not that novel a concept.
They could have made this presentation into a 30 second video, which would have extremely simplified the access to information, while also only requiring one click, and still providing the ability to pause the flow of information when necessary. Instead, the page takes 39 manual scrolls to read through a bunch of tech bro jokes.
The reality is that they could have produced this same concept in a way that doesn't force such extreme interaction to consume very minimal content, resulting in the same "awesomeness" without wasting the user's time or energy.
Perhaps you are coming at the interpretation from an “experts” viewpoint? (With all the bonuses/hindrances that can come along with it)
Off topic Have you ever done psychedelics ?
And as the GP pointed out, the layout and content is essentially already in video form. They just chopped that video up into a website that forces the user to consume that tiny amount of content in an extremely specific way, which also requires a bunch of extra effort and massively wastes time -- for example, 3 full scrolls just to get past an animation full of loading icons and a single completely irrelevant sentence.
You keep mentioning this "we" as if you speak for the entire world. In reality, there are far more commenters speaking negatively about the site than there are positively.
> A lot of people have told him why they do but he keeps arguing.
You're again suggesting that I shouldn't be allowed to respond to people who replied to me, which is antithetical to how forums work. And, in fact, almost no one has actually articulated why they like it -- they've just said that they like it, while refusing to acknowledge any negative aspects.
> No idea why you want to defend such a toxic person.
The irony here is very rich -- you calling other people toxic, when all you've done so far is tell me that I shouldn't be allowed to express my opinions, all because you don't personally agree with those opinions.
Unless you have something new to add to the conversation, it's beyond trollish to repeatedly assert that I shouldn't be allowed to speak my mind (or even respond to people who replied to me) just because I don't agree with you.
You've told me to "accept it and move on" at least three times, which is an assertion that I shouldn't comment or express my opinion. So yes, you said exactly something of the sort, multiple times. That you're trying to convince me otherwise is some extreme gaslighting.
> I do however have a problem with you aggressively arguing
You're greatly exaggerating any perceived aggression. You try to make it sound like I'm some troll resorting to name-calling, when all I've actually done is provide detailed arguments based on actual experience. You're welcome to interpret them as aggressive or patronizing or whatever you like, but that's entirely subjective, ironically.
If anything, I'd say repeatedly replying to all of my comments and telling me to "move on" is far more aggressive than anything I've said.
> that there's an objective truth
Again, you're pretending that neither standardization nor subject matter experts exist.
Counting "scrolls" (whatever that means) can't be a healthy way to engage with something you don't enjoy.
I could say the same thing to you -- if you like it, then move on. Nobody is forcing you to read my comments, and it is antithetical to the concept of a public forum to assert that I shouldn't be allowed to comment just because you don't agree with me.
> Counting "scrolls" (whatever that means) can't be a healthy way to engage with something you don't enjoy.
As a web developer, half of my job is analyzing metrics which describe how effective and usable a website is. This particular thread is a discussion about site usability, and I'm using decades of experience and actual site data to show how bad the usability is, which very relevantly includes counting how many times they are forcing someone to scroll to read a single paragraph of text.
I think it is more usefully analyzed as a landing page, with a lot of emphasis on how it looks, at the deliberate tradeoff of the text being harder to access.
On the practical side, personally I'd expect to find docs, getting started, and source repo which I found immediately.
Some surprises though: I didn't notice the scroll until after looking at links (intended?). The way some elements disappeared if you scrolled just slightly past them entering the page. I didn't find the scroll jacking surprising after first seeing it, I read it as "not a normal text document" shortly after.
Of course you might in the end not care for the visual side, or not expect it to come at such a great expense in terms of scroll # or similar metrics. I think that's a risk they take with this kind of page.
edit: typo
I don't quite like the low information density it uses, but at least it doesn't take away my control. I prefer that a site doesn't do it at all, but if they do they should at least do it this way !
- 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).
- 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).
- The error boundary feature is a very nice touch. I guess it depends on their nested routes feature to function. I haven't explored React's own error boundaries, so I can't comment on how ergonomic it is to add these to other components (in Next or in Remix).
- I don't see anything in Remix about exporting the site statically, so it looks like you'll want to stick with Next if you are actually building a static web site.
- CSS modules are not supported. It appears to be possible to add support to esbuild for CSS modules via a plugin, but there's no escape hatch to be able to do this in Remix.
- There doesn'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.
Remix does nothing to make this happen, it's just the way html works. I dont see how it would not work on next. The difference is api is in a separarate directory and remix have them in the same file. Superficial.
I mean, I suppose if your baseline is writing server endpoints in assembler, all of this probably does seem pretty superficial.
This is only annoying if you prefer Remix's structure of putting the endpoint and the UI in the same route. To me I have no interest in making cookie cutter CRUD apps that map pages directly to API endpoints so this is useless.
Honestly I don't see anything exciting about "supporting" form method because that's such a broken and limited way of doing UI. The assumption that every time you submit a form, it results in a request, or that the request is exactly what you put in the form, is false. Just because something exists in html does not mean it's the right way to do thing.
This might work for q blog post example, but imagine doing a full reload just because you liked a post or a comment.
It's mindbogglingly bloated and terrible.
On my iPhone it is even better.
At the end of the day, you must try them each for yourself and find which one resonates most with you and your team.
Might consider Vue.js for writing new very interactive components...
In theory you can just decorate your server side html with vue tags, but in reality that only works for simple hello world demos. Vue wasn't really built for that.
I have stimulus in my scope too
We have some JS code works similar to it but still considering the testing and transition method.
Before that I got some dependencies need to be updated first
I don’t think the JS community is going to make the same mistakes Rails did. I for one am glad the days of highly mutative, untyped MVC are coming to an end.
The point is more, most apps just don't have any business logic at all! It's very often just some CRUD on some data entities, and the rendering of those entities. CRUD isn't business logic.
In serious though I really hope that Hotwire can become mature and intuitive enough to completely negate any need for a js framework on top of a rails backend
If you fool yourself into thinking that a few similarities to what you're used to means that there's nothing new to learn, you're missing out.
(To be clear, I'm not saying that everything new is automatically better, or that even Remix is. I'm saying that it's foolish to dismiss something without trying to understand what it brings to the table that you've not experienced yet.)
The reason people adopted React etc was not because of a few specific features, but rather because it was a completely different architecture with different pros and cons.
In practice you can do anything React does 100% on a server by sending a video feed to the client + some thin APIs, but it will have different issues and will solve different problems.
If you think there's a "better" solution that will supersede the other for every case, then you probably haven't seen or worked on all kinds of app that benefit from both co-existing.
I do think it’s nice having it in the same file as the form itself, but it’s not clear how well that’ll scale in a more complex page with many forms. So I think Next could get most of the way there with a few helpers to make a form submit to an API route with similar DX.
Blitz JS does this to an extent, by magicking away the API and letting you right your queries in your front-end code. It actually works really well, and it's quite a nice dev experience once you get used to it. My favourite bit is writing my zod schemas and having them validate (with feedback in the form) on the frontend, and also on the backend.
Some of the notable differences between NextJS and Remix are the following:
- While both support file-based routing, Remix is baked with React Router -- giving developers the capability to declare custom routes without sticking to file structure conventions
- NextJS banks on its static site generation to generate "cache-able" websites whereas Remix utilizes cache headers for its server-rendered pages
- NextJS has no baked-in support for handling session and cookies; Remix has
My issue with Next.js (alongside lack of nested routes) is that it has a handful of weird light abstractions which make things marginally easier for developers for the most common cases, but completely tie the hands of people who know what they're doing. To that end, Remix is a little more appealing.
It still boils down to use case, implementation, and quite possibly preference.
Personally, I'd still pick NextJS any time for any enterprise-level projects. Remix would be a fun little new framework to toy with for personal projects.
Does it? You can still do traditional SSR in Next
Also, there's a lot more to caching with NextJS than SSG.
I also agree that there's more to caching and SSG with NextJS. I'm simply stating some notable differences between NextJS and Remix, answering the top-most parent comment.
Actually, that's not true. You can opt out of the fs-based routing altogether.
> "You may also wish to configure the client-side router to disallow client-side redirects to filename routes; for that refer to router.beforePopState."
https://nextjs.org/docs/api-reference/next/router#routerbefo...
After watching the session, there does not appear to be any significant differences from Next.
That being said I see no reason to not welcome another competitor in this space... and it's free. I'm sure you are right and this will gain popularity, though the competition is stiff.
I rarely check twitter but yesteday's Kent Dodds message section about a tweet announcing Remix's launch made me cringe.
Guillermo Rauch (main dude behind Next and Vercel) was well known in the scene before next which also helped it gain the initial traction to build upon.
Feels like a similar case. IIRC remix wasn't suppose to be open source, but feels like nowadays it's a better choice for them to go the Next route and build services around their framework.
My bet is they'll build a Cloudflare Edge Suite abstraction (or even get bought by CF for their edge offerings)
Is Kent also a person behind remix now? It used to be just Michael and Ryan, best known in the react space for react-router, and in the frontend ecosystem more generally for unpkg (Michael).
UPDATED: oh, I just found his tweet about him joining the Remix team.
There was no useState per form element, form data was trivially validated on the server, errors were trivially sent down to the server. If you look at this example[0] you'll see there's not a single useState, useEffect, etc.
Fundamentally, Remix is about using native browser behavior to build websites. The imported `Form` component is replaceable with the HTML `form` element and it all still works.
I think Remix is going to be even better than NextJS. This isn't a rivalry though, just an alternative solution. Clearly NextJS and React frameworks broadly are valuable, Remix is now another option.
I really like that Remix's architecture means you end up writing code that would execute on your server and not the client. It feels like a much nicer balance rather than doing everything on the client.
[0] https://github.com/remix-run/remix/blob/a56bdfd7f7e7fa9d8a3b...
Sorry to point it out, but there is useRef, useEffect and a useUserData on lines 48, 53, and 47 respectively.
you can always do this, regardless of react or not, people did not do it because they want to do client side validation/feedback. Not to mention forms have nothing to do with endpoints. Mirroring your UI after some endpoints is a shitty way of making UI, or API. Sometimes you just have dialogs or wizards to build up the state of the payload and the submission happens much later.
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'm "keeping up with the cool kids"...
One think I do really like here is the way Remix is keeping things on the backend...I'll admit coming from the 1980s I'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 "its not PHP" of course)
The MVC way was:
1. Look at the route
2. Recognize that this route has, e.g. A Header, A Sidebar, and Content
3. Load the data for the Header, Sidebar, and Content
4. Pass the data to the templating engine
5. Use the templating engine to render the route, which likely fans the data for the Header, Sidebar, and Content into individual template files.
https://engineering.fb.com/2010/06/04/web/bigpipe-pipelining...
you can do that with Suspense. React doc calls that render-as-you-fetch pattern https://reactjs.org/docs/concurrent-mode-suspense.html#appro...
1. large teams (not just one webmaster, circa 1999)
2. tooling like syntax checking, style enforcement, minification, and transpiling
3. component-based development & reuse; forces smaller files which are easier to lint and test
4. separation of concerns. in the old days there was one Apache www folder and everyone took a big shit in it. javascript was in html files that also contained php, it was snarled mess. frameworks separate that to a large extent (one could argue angular/vue etc went backwards)
5. regression, aka CI/CD: there are actual testing flows today, unlike the 2000s
6. if you've been out for a really long time: reactivity. JavaScript allows getter/setter methods that can update the DOM when a value changes; this includes before/after and around-like methods that can integrate AJAX calls in a VARAIBLE name. e.g., you access the variable and an AJAX call fires and updates your DOM when the data returns with you doing ZERO coding. This is a big step over PHP where you sprinkle magic server commands everywhere, and big step up over Jquery, where you have to target each DOM class/ID, which is tedious.
That being said I maintain a LAMP site, a pure-NodeJS site (get() verbs send back pug templates), and a NuxtJS website. I prefer developing the NuxtJS website (hot loading is sweet), but I can hack the LAMP site in a snap without touching literally everything; the NodeJS website is more aesthetically appealing in terms of architecture, but adding content to it is laborious.
EDIT: I'd go even further and say there is way more of a diaspora today. In the old days you could approach any website and basically understand what was going on in the frontened. Today there are layers upon layers of compiling/transpiling/parsing etc, that creates dozens of bespoke syntaxes. It is maddening, but I chalk it up to the fact that companies hire for the "hot new thing," damn the consequences, because their PMs are youngins too. There's a enormous lack of engineering discipline everywhere you turn. You will find many, many, MANY of the tools fail to even succeed at their own how-to guides because they have no real deep thought behind them.
Maybe I'm old but that sounds TERRIBLE. When my code is doing something expensive like a network call, I want to know about it.
Another way to look at it is you just removed 300 lines of buggy redundant code into one line that does exactly the same thing but without all the fuss. And now that your code is so small you can understand it better, and test it.
Also, there's this "new" thing called async/await: javascript is built on deferred execution, so you don't block on expensive calls. PHP is a dinosaur.
Reactivity is mostly used for managing the DOM in a natural, non-intrusive way, and my AJAX example is maybe extreme, but a good illustration. I'd say that concept in the frontend is biggest invention since 2010.
Maybe I'm missing something critical here, but the code doesn't go away, does it? You still have to have the AJAX implementation, it's just that instead of the intention-revealing interface of a call to something like fetch you have an intention-obscuring interface of magic properties.
The code still has to live somewhere, even if you've swept it under the rug. But now when you walk across that rug it's real easy to trip.
Did you write the driver that you call when you do HTTP request through a TCP/IP stack? No? You just swept it under the rug!
I kid, but I honestly don't understand your resistance. You don't seem to want to let go of some kind of anchor, referring to it as "magic properties." While I argue you already are letting go at so many other levels.
It is easier to read code that says:
div
p The current stock price is {{ stockPrice }}.
computed: { async stockPrice(): { return await axios.get('/stock?TSLA'); }}
Every time the DOM is redrawn this updates, and it is 100% non blocking, easy to read, and trivial to maintain. (I didn't bother with a catch, but you should have an error handler elsewhere for non-transactional dynamics; also didn't index the data object since Axios returns JSON, but that depends on your endpoint that you wrote.)
The HTML (well, Pug, because who writes HTML?) is clean and easy to read; I didn't need to $('domObject').innerHtml() with jQuery; I didn't need to implement a wrapper around 'new XMLHttpRequest();' and I didn't need to block execution -or- write a big messy Promise<> because async/await. 80% of this benefit is a framework (20% is ES5).
Is that really so awful?
And: If you want to be skeptical of frameworks, I thoroughly encourage that because they need more critical eyes on them! Seriously, they need some restraint. There are some deep rabbit holes that devs go down which really turn a great idea into crap.
EDIT: I have to add that if we were working on a project you'd be looking at me funny, because I gripe about frameworks and tooling non-stop. I feel like I'm forced to waste time on so many hacks to utilize the truly brilliant ideas in frameworks. So I take no responsibility if you fall into the framework hole with the rest of us! :)
My point is rather one of interface design. This is about communication with other developers. Help them out! Give them affordances to make their lives easier. Leave clues so they know what's going on.
A developer coming up to your template that just says {{ stockPrice }} has zero chance of knowing that this is going to secretly issue a network request. If it looks like a field reference, people are going to assume it has roughly the same characteristics as a normal field reference. That's an eminently reasonable assumption -- don't violate it.
Everyone would be surprised to see that take several orders of magnitude longer because it needs to touch the network. Everyone would be surprised to find out that they can't include that field in a template that might possibly be rendered when the user has no network connection. When things do something different from what they look like they're doing, it's surprising.
Don't surprise people. Make life easy for them.
I think it becomes problematic (or more magical) when these network/database/expensive calls are made willy nilly throughout an application, without a dedicated class or layer to aggregate these kinds of operations. If you have things architected correctly, it's not a big deal to trace these kinds of things throughout your app.
I wait for the tech to become "Unavoidable" in Implementation practices.
Aside of "mental load", every new paradigm shift is measured in education/expenses/support time. So waiting for "market validation" is the only valuable option for me. This approach has saved a tons of money for my clients and thousands of hours in support/maintenance.
"Keeping up with the cool kids" is not valuable business decision, you can invest in systemic design knowledge and "proven technology" optimization.
I think this sort of thing will be interesting to many, but not me. Seen enough view frameworks (ok this probably is something else, even working out what it is and what problem it solves is a weekends work). Thanks!
Sounds like timescale, metabase, and posthog.
In the world of web frameworks (or maybe software libraries in general, especially those that deal with the web), I don't think it's wrong to call charging the users radical, while not totally unseen.
EDIT: Finished scrolling to the end, and... now I feel kind of silly for having praised the landing page, because my mind is like... "c'mon, it's super simple, it's still just text (albeit well-written), with some nicely done scrolling transitions etc" -- BUT... it's still really good! Yes, the elements and effects and everything on the page is stuff we've all seen already, it's not really something new, but I feel like it's just put together super well, and it is so frickin' smooth, I didn't notice a single hitch anywhere...
Though as silly as it might sound, Remix’ publicity work has put me off it. Will read the docs anyway.
You couldn'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't want to give up React which still feels more productive to me.
This looks neat but just like NextJS and Sapper it will not nicely play with my stack.
The real problem is switching languages. I sure get slow when I change from Elixir to JavaScript. There's not a bright line between backend/frontend in a fullstack app, so I've been much happier minimizing how often I have to switch languages.
Agree Remix looks good though!
I agree with you in the sense that I don’t want to write server code in Node since I like batteries-included frameworks (Django)…
I guess you’re talking about features like form validation and whatnot?
I think for remix to be able to do what it does, it kind of needs to run as a JS (not node!) backend, because a big part of it is running react on the server. Also, you are literally writing the server and client code in the same file. Closure and Reason which have strong react ports/bindings might be able to do it, but otherwise I don‘t see how.
What other backends need is probably a totally different framework, that wraps up a react server renderer with native language bindings. Might be neat, but totally different.
It only technically is built for Rails and Laravel but reading the “spec” and the code I got it to work pretty quickly with a Rust backend.
It would be nice for more of these frontend niceties to be built around an API contract rather than a particular JS on the server implementation.
When you need to move in a slightly or severely different direction, you're better of with a set of libraries. They allow you to build a contraption that matches your unique problem space. They require much more time and thought to achieve the first results. Their keyword is composability, and their drink is a cocktail.
At the start, or if you are a contractor, you want something really fast, so a framework is usually inevitable, unless you're overqualified.
Down the road you keep needing to move across the rails, so you slowly switch to using more libraries.
> "We need you to "sign" a contributor license agreement (CLA) first that assigns us ownership so we are able to include it in this software. We don'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."
Apparently, requiring a CLA isn't as uncommon as I initially thought, but I'm still curious why some projects require this but others do not. What about their business model / licensing choices necessitate a CLA?
It has a great balance between client and server code. Just as React brought the mental model of writing integrated HTML/CSS/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.
There'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.
It's a push to go back to running code on the server that can, instead of shoveling everything into the client.
This is only the beginning of Remix, I'm excited to see what the team will bring.
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.
What are you concerned about breaking?
Interesting. So the idea is that the you scale identical instances of your app to increase both frontend and backend throughout? Sorry for the stupid questions. I am used to using a CDN for serving the front end and just scaling the backend resources (instead of adding more containers that are running Express of whatever web server within).
Next allows you to compile the "static assets" and put them on a "dumb" CDN like say a typical Rails application. I don't think Remix supports this pattern at this time, but again, it does work with a perfectly reasonable alternative.
return (
<div>
{projects.map((project) => (
<Link to={project.slug}>
{project.title}
</Link>
))}
<Form method="post">
.
.
.
</div>
Would be nice to have a framework that obscures these kinds of "web fundamentals", so we no longer have to wrangle such low-level primitives to build complex apps.
EDIT: The people downvoting this are suffering from a failure of imagination. Sure, Remix may be an improvement over some current frameworks' failings, but there's no reason improvements need to be so incremental or debt-bound.
It's a lot more interesting that the "let's should be lets" comments.
I noticed in another of your comments you mentioned it seemed similar to Nuxt.js and you were digging in further to look for differentiation.
That's kind of what I'm getting at here: things in this space are moving needlessly incrementally at this point, creating so many permutations on largely the same underlying themes and staying pinned to original Web semantics. Why do we accept HTML as an app UI "language"? Is that what we would choose if spec'ing for that use case today? So, why do we introduce all of these new layers, complete with webpacking, transpiling, etc. only to continue surfacing such ill-suited low-level constructs in our code?
That's not to say the Remix team aren't good people or haven't made real improvements here. Reading further, I see where they're creating value, and the testimonials seem to be inspired.
So, it seems successful for what it is, but that's all relative. What I'm suggesting is that it's time for a paradigm shift in Web development.
Would really be interested to see what that same team could have created had they broken out of the React/SSR/etc. box.
It's funny to hear someone complain about tangents on an HN thread. And, right on cue, as of this writing the top comment [0] literally starts with the phrase ”Off topic:" and has 7 replies.
Irony aside, my point is very much on topic, as I am asking exactly the question, "what if teams like Remix had instead invested their considerable talents and years-long efforts in building a truly paradigm shifting approach to webdev?"
What I'm suggesting here is that it's time to advance the state of the art in Web development. But, I could certainly be wrong. It might instead be time for another incremental improvement in the React/Vue/Angular-ish, HTML/code-mashing, shadow DOM-rendering, SSR-driven, reactive framework universe.
Really? You can't imagine even a single alternative approach?
Get inspired by Swing or even VB—really any ground-up app-building environment. The point is that we keep stuffing things back down to "web fundamentals" when what we're really building is apps, not web pages.
>but given the constraints of what a browser is, I'm really not sure what exactly you envision being suddenly invented
That's the problem--this idea of browser constraints. Again, free your mind of the browser and "web fundamentals". We're willing to transpile, Webpack, etc. but somehow still stop at coding to and thinking in HTML/DOM/etc.?
We can do anything and we're already effectively building on VMs. Why do this?
>why you feel a team that is knee-deep in React would suddenly turn around and go a completely different direction.
Man, I'm really not stuck on the idea that the Remix team should've done this. It was just a hypothetical when I said "Would really be interested to see what that same team could have created had they broken out of the React/SSR/etc. box." My point there is that a lot of talent/time is going into these incremental improvements.
So, I get that they're just giving the people what they want. I just think it's time for the people to want something entirely new.
- JSX as a paradigm for defining component display output
- Drag and drop capability for UI design
- How web apps are built tooling-wise
- The actual display layer being used (HTML, canvas, etc, or at least that's what I think I'm reading)
- Whether the browser is where these apps run at all (?)
Those are all entirely different questions and concerns. Which of these are you actually asking about?
JSX has been argued about since React was first introduced [0]. It exists because React tries to stay "just JS" and use JS logic for flow control, rather than having a completely separate templating layer. Some people love that, some people hate it.
Drag and drop for laying out an app exists - there's multiple projects out there that allow a very VB-like GUI design experience for React components.
Modern JS build tooling exists to solve the multiple problems I listed earlier: insufficient standard library, building full-size apps with tens of thousands of SLOC and large teams, and optimizing deployment bundle and asset sizes.
HTML and CSS are the native language of browsers. You can certainly use canvas/WebGL to draw pixels on screen (and that's what "compile-native-desktop-to-WASM" demos do), but you lose all the built-in accessibility of HTML, and still have to reinvent all the widgets from scratch.
As for "breaking free of browser constraints and web fundamentals"... well, we _are_ talking about still delivering code to run in a browser, so what other options are there?
I'm genuinely not understanding what you're trying to envision or describe here. You seem to have a particular vision or set of ideas - can you describe what you're picturing more specifically?
>It seems like you're conflating a few different concerns here:
>Those are all entirely different questions and concerns.
What you're picking up on is that I'm talking about all of it, as my call is for a completely new paradigm, which necessarily upends everything. As such, these are not "entirely different concerns". They are tightly coupled concerns.
So, to your points, respectively:
1. Yes. JSX is flawed (for a different reason)*.
2. Yes. We should be building graphically
3. Yes. The tooling should reflect the paradigm
4. N/A. We shouldn't care about the underlying display layer (perhaps the most meaningful point)
5. Yes. It makes sense to run in the browser because ubiquity and standards. But a lightweight "VM" that translates from a more idiomatically suitable mental model/coding approach to raw web standards can be used to insulate us from thinking in HTML.
*JSX is flawed not by its design, but by the problem it's trying to address. That problem is emblematic of outdated, low-level thinking. I'm trying to push the discussion up a layer or two: that is, there is no need for a webdev to ever type an angled bracket.
Anyone who has ever worked in an app-building environment that's purpose-built for creating apps should look at that return statement in my comment at the top of this subthread and think "What the?".
So, again, if you're not seeing it, then one approach is to think Java Swing or similar for building web apps. And, it doesn't just end at a GUI builder. From event processing to component bindings, we should be dealing with higher level concepts, not web stuff like HTML-ish templates (irrespective of whether we rename them to **X because they're mixed with code and delivered via return statements).
Sure, there'll be times when you need an escape hatch to target lower-level constructs. But these should be rare and, even then, the available API should allow us to target these with clean idioms, not:
x = '<div>'
If you're still not seeing it, I can guarantee you that in a couple of years we're going to have something much more akin to what I'm talking about. Maybe it'll be delivered via one of the low-code platforms or similar. JSX and the React-ish frameworks will soon-after be dead, or perhaps these environments will generate something akin to it on our behalf. I really don't care if React, et. al. get a second-life as compiler output. And, that's the point.
That does exist in some form today, between "low-code" tools and React-based drag-and-drop tools.
But then again, this also treads awfully close to the argument that "devs shouldn't be writing 'code' any more anyway, we can just hook together a bunch of boxes with arrows on screen and it all works". Thus far, those approaches still haven't taken over devs from writing code despite years and years of promises.
Yes. It seems you grasped that some time ago, as you refuted it.
>this also treads awfully close to the argument that "devs shouldn't be writing 'code' any more anyway
Is Java Swing 'code'? WinUI? Was VB?
I don't think what I'm suggesting here is really that difficult to grok. But, hey I believe this thread has run its course. Appreciate the discussion.
And "smashing together" code and templates is the best thing to ever happen to web development. Template languages suck ass, they rely on thousands of lines of build time magic to work. JSX is a line for line transform (which is as simple as the build time logic can get while still enabling any sort of templating whatsoever), that conceptually maps back to a simple call to add an element to the DOM some time in the future.
As soon as you get over the "ew, code and "html" together" reaction, you realise that "everything as code" is the easiest way to just completely avoid hidden complexity and surprises.
The problem with suffering from a lack of imagination is you don't know you suffer from a lack of imagination.
The entirety of your comment is devoted to the current and past state of things. JSX is better because "template languages suck ass". You need to "render a h1 or div" to "draw...on a web page" or "add an element to the DOM", etc.
So, you're championing one approach because you think it's better than everything else that already exists. That's the definition of a lack of imagination.
>Putting another abstraction layer over it to obscure it does jack shit other than make your code more complicated.
I doubt you appreciate how many layers of abstraction already exist. But, per your logic we should all be writing assembly code.
You have it exactly backwards. There's no reason HTML has to be the target simply because that's what the browser currently consumes. If, tomorrow, browsers "natively" consumed something that was less document-oriented and more idiomatically app-appropriate, then will you understand? Would you be comfortable with coding to that abstraction level? Because everything you touch is essentially running in a VM. These frameworks could easily provide that layer versus the one they provide.
So try to get HTML and other "web fundamentals" unstuck from your brain. Imagine languages and platforms for building non-Web (e.g. native) applications and perhaps that will help open your mind a bit.
Imagine.
In any case, thanks for the comment versus just a silent downvote. FWIW, I upvoted you for that, even though your comment was poorly considered.
More like a few years early. Bookmark this. If you think JSX and screwing around with HTML-in-code is as good as it gets, you'll be laughing at your comment in a few years.
BTW, I've been saying this since encountering the then-loved awfulness that was Angular 2.
>JSX has been a thing for so long now and it works.
That's a pretty spectacular statement — sort of a rallying cry template for never innovating on anything again. Just substitute anything you prefer for JSX.
I think I dramatically understated the situation when I said there was a lack of imagination.
But of all the things that need improving in the UI world, the templating itself is quite low down on my list of priorities.
Seems that it's tightly coupled to their variants (SWR and react-router).
React Query is IMO a must-have on any project that already warrants using React (and that isn't an offline-only app of course).
You can of course still use react query/swr/redux tool kit etc if you want. Remix doesn't limit what you can do and still fully supports any of these and other client side tools.
Remix just encourages to make better use of server side code instead of shoveling everything into the client.
My theory is, you can afford one big abstraction (React) on top of platform (HTML/JS/CSS/Browser). Try to abstract beyond that, and things get unnecessary, bloated, and difficult to reason about.
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)
Is there a comparison between this and Next.js, Gatsby or any other framework?
I'm digging into the demo vid to look for the selling points of this over Nuxt.
Seems like they have a bit more going on with progressive enhancement and interaction support, but nested routes are the headline for me.
I use Next.js for my marketing site.
I use Remix for my web app.
Next is good if you just need to get some HTML on the page. Remix is good if you need a connect to a database or backend API.
There is a bit of evidence that people are building heavily used web apps with Next.js that connect to databases, backend APIs, and expose APIs of their own, for example: https://nextjs.org/showcase
https://nextjs.org/docs/basic-features/layouts#per-page-layo...
It rarely gets any praise, but to me it was the most productive web FE framework to date.
I'm truly baffled.
posted a few hours ago:
What is the point? I think they put them in there as little speedbumps to catch the attention of people who are flicking boredly through the site on a tablet or phone or whatever. They should be more confident in their ability to keep their users' attention.
There are people like that. I did it a couple of times. I'm more annoyed when the scroll is hijacked but it won't let you replay an animation.
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…
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.
I kind of like the odd error here and there. Makes me feel safe to at least try out their product.
Not an excuse for having typos in the product’s website, but a very common explanation for it.