Remix – A framework focused on web fundamentals and modern UX(remix.run)
remix.run
Remix – A framework focused on web fundamentals and modern UX
https://remix.run/
306 comments
I disagree wholeheartedly. This site breaks every UI/UX rule in the book, and in the worst ways. Instead of just letting people read the information at their own pace, they've decided to limit the information to one partial sentence at a time, and more than half of those sentences are just irrelevant jokes.
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.
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.
Think of it as a video but you scroll through it.
It’s really not that novel a concept.
It’s really not that novel a concept.
I never said it was a novel concept or that the functionality is confusing. I just said that it's terrible, which it absolutely is, and your video comparison actually reinforces my point.
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.
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.
That's just your opinion. I think it's awesome and if it really "breaks every UI/UX rule in the book" it's a great example of how breaking the rules can be a good thing.
I'd love to hear exactly why you think it's "awesome" and "a good thing" to force users to scroll an entire window height in order to read part of one sentence.
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.
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.
Sounds like you just can't accept the fact that people like it.
I could say the same thing about your commentary -- sounds like you just can't accept the fact that people don't like it -- which ought to tell you just how obnoxious you're acting right now.
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.
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.
I've said nothing of the sort. I do however have a problem with you aggressively arguing that there's an objective truth [1] and patronizing every explanation you get for why people like it [2]. No-one has said you can't have an opinion. Good try though.
[1] https://news.ycombinator.com/item?id=29315836
[2] https://news.ycombinator.com/item?id=29316485
[1] https://news.ycombinator.com/item?id=29315836
[2] https://news.ycombinator.com/item?id=29316485
> I've said nothing of the sort. [...] No-one has said you can't have an opinion.
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.
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.
Sounds like you can't respond to a simple question and prefer Ad hominem. "It's awesome" has never been a proper justification.
No, I don't need to justify anything here. There's no argument to be had. The point is that bryans is claiming the landing page is objectively bad and doesn't seem to accept that we obviously like it. A lot of people have told him why they do but he keeps arguing. No idea why you want to defend such a toxic person.
> The point is that bryans is claiming the landing page is objectively bad and doesn't seem to accept that we obviously like it.
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.
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.
The concepts presented , If the reader is not already well versed in the domain, seem hard to digest in under 30s if in video form . I’m from a backend world and frontend sometimes seems wild how fast it moves/changes… have you ever read a book and savored a single sentence ? Reflecting on what it says and the implications ? I find this site to be amazing at doing this or at least offering a great opportunity to do so. If I watch a 30s video, I would more easily “indigest”
The concepts because they would be presented so fast then be lost after seconds, as the video moves onto the next topic.
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 ?
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 ?
As I mentioned already, videos have pause buttons. If you were struggling to grok a particular portion of a video, you have every opportunity to pause and analyze, but you'd also be able to continue watching a portion without any interaction if you already understood it.
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.
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.
If breaking the rules means alienating people who like Reader Mode, PgUp/PgDn buttons, disabling JS, printing or exporting as a PDF, or reading on a constrained device: maybe the "rules" exist to protect underrepresented ways to read webpages.
I prefer this presentation over a PDF or a video. It works and I like it. You don't, then move on.
Counting "scrolls" (whatever that means) can't be a healthy way to engage with something you don't enjoy.
Counting "scrolls" (whatever that means) can't be a healthy way to engage with something you don't enjoy.
> I prefer this presentation over a PDF or a video. It works and I like it. You don't, then move on.
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 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.
Analyzing usability metrics is not in the purview of a developer typically, especially not for random tech tools.
What a ridiculously untrue and narrow-minded statement. If you've only worked at companies where you're one tiny cog amidst ten thousand employees, sure, you may have a designer or psychologist who specializes in UI/UX analysis. However, that does not describe the VAST MAJORITY of tech teams, and frankly, any frontend developer who isn't analyzing their output or at least taking a moment to think "hey, maybe 39 scrolls is too much for this task," doesn't really care about or understand what they're doing.
I specialize in working with startups and small development teams getting their tech stack up and running or fixing growing pains. I must have worked with hundreds of teams at this point, and not once has it been standard fair. You are MASSIVELY conflating noticing a UI inconsistency with analyzing usability metrics, the two things aren't even in the same arena, and the fact that you would compare the two gives me the idea that you may be on the more junior side.
This post is terrible.
like a video of text, one sentence at a time, that you have to advance manually.
Well, on a first page without any scroll you have action buttons which leads you to the pages where you can read at your own pace. For people who don't want that they've put small bits of information on each scroll. Every information is carefully chosen, so you keep scrolling and reading. After that you go to the doc to read more. 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.
This is is how UI/UX should be done. Bravo!
> Well, on a first page without any scroll you have action buttons which leads you to the pages where you can read at your own pace. For people who don't want that they've put small bits of information on each scroll.
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.
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 really glad I'm not working with UI/UX and project managers that you think would do that. Everything you stated is just your opinion (phrases like "anti-pattern" or "bad UX", "style over substance"), and that's fine. I don't find this homepage annoying. It's the opposite. I find it very informative. I'll for sure get involved with remix thanks to the great presentation and first impression they had on me.
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.
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.
If this is "the page that the title links to", it literally just gave me a headache. I am not sure why, something with how things moved in unexpected ways to me trying to scroll, I think.
If that is Great UX, I think I prefer bad UX.
If that is Great UX, I think I prefer bad UX.
> I'm really glad I'm not working with UI/UX and project managers that you think would do that.
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."
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."
You have chosen a strange hill to die on. Just accept the fact that we like this (I love it!) and move on. You won't convince anyone with your lousy attitude and obnoxious arguments.
> You won't convince anyone with your lousy attitude and obnoxious arguments.
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?
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. Some people like it, some people don't but it's all subjective no matter how hard you try to prove otherwise.
You keep trying to assert that nobody should ever have a discussion about subjective topics, but there's a reason why standardization exists, and those standards are born out of discussions where people disagree.
> 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.
> 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.
Why are you so obsessed with this "tech bro" construct?
If you are the kind of person that interprets everything as cliché, then you are liable to become one.
If you are the kind of person that interprets everything as cliché, then you are liable to become one.
Amidst many paragraphs across several comments, I twice (and passingly) described the author's jokes as being reminiscent of the "tech bro" character that everyone on this site is familiar with, because that is exactly how they sound. Can't imagine how you interpreted that as an obsession, or why you thought it was ammunition to "take me down a peg." Your trolling needs some work.
I can see how it scores poorly on the number of scrolls per paragraph of information, maximum words read per unit of time, etc, but clearly that is intended with the choice of spacing and font size which is different in the docs (typically optimized for providing information, similar to what your metrics seem to try to measure).
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 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
[deleted]
I suspect the reason it's not as daunting as it usually can be is cause it doesn't feel like it's scroll-jacking you, in a sense. When you're scrolling, it still feels like you're going "downwards". You stop scrolling, animation stops in its tracks pretty quickly.
More importantly for me, it doesn't screw with me if I don't want to do it at their rythm and scroll fast anyway. So many site with their accelerate / decelerate / transitions end up being horrible to use if you're a quick reader, theirs doesn't.
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 !
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 !
I love the little part with the fake Windows BSOD. The QR code is supposed to link to the documentation page on error boundaries, but sadly it's broken
So, after looking over the docs, here's my comparison list between Remix (which I haven't used) and other things that I've used.
- 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.
- 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.
There is https://github.com/smeijer/next-runtime if you want `getServerSideProps` to be able to handle post request and return a json
This looks great! Definitely brings Next and Remix to a pretty close level in this regard.
From Ryan:
"It's so fun to see people's takes on what Remix is. Especially the "this isn't any different than [x]" and I'm screaming from my office "open the network tab, slow down your network, click the button really fast, click back/forward really fast! then you'll see the difference!"
https://twitter.com/ryanflorence/status/1463241922168774658
https://twitter.com/ryanflorence/status/1463241922168774658
Next does technically support POST endpoints, in that API endpoints support any HTTP method and receive which one it is as part of the incoming request. Definitely less nice than the way Remix handles it though.
It does, but the convention with forms is that you POST to the path you're on, rather than a different one. This is so that if there are any form validation errors you can easily re-render the current page with the errors added. To get this behaviour in Next, you'd have to hijack getServerSideProps (which is what the lib in one of your sibling comments does).
Ah that's useful context, thankyou! I didn't realise there was anything special going on with the path, I thought they were just doing a redirect back to that path from the server route if there were errors. What they're doing is much more clever and sophisticated than I realised, I definitely need to dive into it a bit more.
I think in an SPA, traditional form posts and server redirects are a terrible idea.
This might work for q blog post example, but imagine doing a full reload just because you liked a post or a comment.
This might work for q blog post example, but imagine doing a full reload just because you liked a post or a comment.
To be clear, I don't think Remix does this: the built-in `Form` component automatically handles converting the form submit into a fetch call and routing it directly to the appropriate component without doing a full page refresh, unless the component explicitly calls for an explicit refresh afterwards (e.g. redirect).
> 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
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.
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.
It "wouldn't work" on next because your getServerSideProps receives a node http.IncomingMessage, and you would have to parse all of the form data yourself, or install a dependency to do it. Then you would have to write a second endpoint in a second file to be able to respond to a JS-enabled (fetch) request. Plus you get to implement all of the progressive enhancement yourself (state tracking, preparing that fetch request, etc).
I mean, I suppose if your baseline is writing server endpoints in assembler, all of this probably does seem pretty superficial.
I mean, I suppose if your baseline is writing server endpoints in assembler, all of this probably does seem pretty superficial.
> Then you would have to write a second endpoint in a second file to be able to respond to a JS-enabled (fetch) request
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.
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.
It actually seems that Remix just wraps the form element with its Form element that prevents "the way html works" from happening and instead provides a loading/submission state to the UI while performing the form submission via fetch in the background. At least that's what the demo suggests.
I watched the demo and the guy kept saying if this was `form` (meaning lowercase), it would still work, which is misleading.
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.
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.
Off topic: this is the best landing page I've ever seen on a mobile device. Keep scrolling down for some surprises!
Which device did you view it on? I tried to view it in mobile Chrome on a Samsung Galaxy S7, and apart from the page not fitting the screen, there were quite a few visual bugs. If I hadn't viewed this page on a laptop before, I would have been discouraged.
Android Chrome on Galaxy Note 10+.
Interesting. I thought it was a terrible landing page. I guess I tend to prefer "static" pages, literally like a physical page. Phone screen is just a mask. I also hold a controversial opinion that most websites that are animated presentations should just be replaced by a PDF file. I get everything completely "static".
wow, i have a radically different opinion from yours. for me it is the perfect example of some bad trend in webdesign. It feels like a powerpoint. And just to be clear: powerpoint is useful in some cases, but not on the web. On the web, it sucks.
It's mindbogglingly bloated and terrible.
It's mindbogglingly bloated and terrible.
It wouldn't be great if the web transformed into this format, but experiencing one or two like this periodically feels like a breath of fresh air.
What's wrong with using a familiar presentation style for what is essentially a presentation?
it's not the right format for the medium. slides are ok in class, or during a meeting - the web is different.
You're watching a presentation about a framework. What makes slides such a bad fit for it?
Slides are presented to you, web content is something you read. Slides can have more graphical elements and animations because they don't carry the full information load - most of that is spoken. You wouldn't do a presentation by giving out flash drives with the slide deck and then leaving.
and in this instance the slides on the website are also not the full informational load, the docs are.
You got me to keep trying to scroll at the bottom of the page like an idiot hoping for easter eggs.
I thought the part with the loading icons and clap emojis surprising. Sorry about that :)
Oh it was. It's just I'd already scrolled through the whole page before reading your comment. I took "Keep scrolling down" quite literally and went back to the page to try to scroll a bunch of times at the bottom of the page... lol.
Amazing on the iphone - it felt that the scroll effects fit the content really well
It’s really buggy on my iphone se 2.
It would be great if it let me scroll it! Elements suddenly becoming sticky and covering 60% of my screen and the scroll just...not working for 7 or so swipes there in the middle is a horrible UX. I'd be more forgiving on a 27" desktop monitor, but on a 5" mobile screen, this is borderline unusable.
It would be great if it let me scroll it! Elements suddenly becoming sticky and covering 60% of my screen and the scroll just...not working for 7 or so swipes there in the middle is a horrible UX. I'd be more forgiving on a 27" desktop monitor, but on a 6" mobile screen, this is borderline unusable.
I think this is the first time ever these type of Page Scrolling dont heat up my MacBook Pro 2015 at home. And it is fairly smooth.
On my iPhone it is even better.
On my iPhone it is even better.
Scroll up and lose context for a second.
Really incredible experience.
You can't even guess there is something below those 2 buttons.
It's created using React.js. ;)
It truly is one of the best mobile-optimized product explanation pages I’ve ever visited. Good callout.
I wonder how Remix ranks next to Blitz.js[1] or Redwood.js[2].
They seem like they're all trying to do similar things.
[1] https://blitzjs.com/ [2] https://redwoodjs.com/
[1] https://blitzjs.com/ [2] https://redwoodjs.com/
Yes, definitely different takes on the same problem! We could make a comprehensive list of all the differences, but the end result is that you can use all three (four if you include Next.js) to build any web app imaginable.
At the end of the day, you must try them each for yourself and find which one resonates most with you and your team.
At the end of the day, you must try them each for yourself and find which one resonates most with you and your team.
That's what I'm most interested in. What's the difference between remix and blitz.js? I can't find a detailed comparison anywhere
The one-line answer would be: Blitz is an additional abstraction layer on top of Next.js that offers a Rails-style set of conveniences like feature generation, plus a "compile-away" RPC abstraction that hides all data fetching. Remix is a from-scratch framework built around React Router that tries to adopt existing web APIs to minimize the amount of data-related code being written in the first place.
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 find this "everything old is new again" such a tiring take. Sure, you can do things you could already do in Rails, but without giving up on the things people adopted React for. Like client-side updates without full page refreshes.
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.)
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.)
I don't disagree, but saying that people adopted React because of things like "client-side updates without full page refreshes" kinda walks right into the GP's trap: doing it it was already possible with Rails several years before React, with PJAX and then Turbolinks.
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.
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.
I was already having doubts about adding an example because I was afraid it would derail the discussion by focusing on the particulars of the example rather than the actual point. So I'll leave it at: sure, but that's irrelevant to the point.
My point was that the point of Rails vs React isn't about features but rather about architecture. I agree with you, I'm just trying to strengthen your argument.
Ah you mean DHTML, right.
Watch the demo, they're not full circle yet. They're intermingling business and presentation logic all over the place. Their data models depend on createPost(), getPost(), and getPosts() style boilerplate methods. It'll be a couple years yet before the JS community reinvents MVC and ORMs (under a really slick name of course), then we'll be full circle.
The broader way to see it is that people are trying to bake reactivity into these old school paradigms that have a lot of good things about them in terms of separation of concerns and working with data, but suck at reactivity.
Intermingling business and presentation logic is fine - even preferred - when they are tightly coupled. Lots of “business logic” is actually just presentation logic anyway.
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.
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.
Presentation logic isn't business logic, and mixing both will create severe headaches later on.
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.
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.
Yeah, this is basically Vaadin and Spring for young hipsters.
More than madness, this seems like evolution, learning, and standing on the shoulders of giants.
Also as much as rails seems so popular, I REALLY don't like rails so this seems to take what's good about it and removes some of the nonsensical opinionated crap. I'm not too much of a fan of node either but it's easier to work with IMO
If you're not picking registers for your instructions are you really programming /s
This evoked a long ago memory of writing programs on a PDP-8/i in jr high (aka middle school) - and while the PDP-8 only had an accumulator (registers, plural - luxury :-) ), you did have to worry about fitting you code & data in 12 bit pages.
Genuine thanks for that memory.
It's hilarious isn't it. That being said, as we all know cobbling Rails + Angular or Rails + Whatever other client side library was always a hack that just used Rails as a JSON REST pump. At that point why not just use Node/Express? And so we come full circle.
I just ran through the tutorial. As someone who also still uses Rails and from reading the comments in this thread, it seems like Remix could be a good improvement over React, but not so much over Rails. (if Rails is your cup of tea)
During the last 20 years I kept using Java and .NET, with occasional dives into C++ when needed, while watching all those caravans pass through my porch ridding into the mountains, it appears there is some gold over there.
There is a lot of overlap between Rails and React, and you probably could use both to make 90% of the apps out there or more, but what really matters is the 5% that you can only make on Rails and the 5% you can only make on React. Plus the different productivity gains you can get on either for different requirements.
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.
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.
And here I am, a react developer just starting out with rails.
You can consider yourself a recovered person then.
I haven't used any modern framework yet (still rails).
Might consider Vue.js for writing new very interactive components...
Might consider Vue.js for writing new very interactive components...
Be sure you try stimulus and turbo first - you might find it is much better that way. Vue and react both have the same problem - it forces you to move your html into the JS. At that point you have no other choice but to move everything to js the database (vuex), validations, routing, internationalization, etc.
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.
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.
Thanks
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 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
Maybe the next great new thing is react code that gets converted into ruby.
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
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
Not full circle...this is more like an 8 shaped thing, and with this we're right at the wrong extreme right now in my opinion.
And someone once told me Rails is still only 90% of WebObject.
Guess what, enhancing the experience with JavaScript will not result in Ruby+JavaScript ;)
I've been hearing about Remix since they were sponsorware, but I don't really get the appeal. They don't seem to show how it'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 /api folder for any backend apis you want to set up.
They just did a demo with a simple form and looking at it seemed so obvious.
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...
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...
> There was no useState per form element, form data was trivially validated on the server, errors were trivially sent down to the server
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.
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.
> If you look at this example[0] you'll see there's not a single useState, useEffect, etc.
Sorry to point it out, but there is useRef, useEffect and a useUserData on lines 48, 53, and 47 respectively.
Sorry to point it out, but there is useRef, useEffect and a useUserData on lines 48, 53, and 47 respectively.
Ah i missed those cause this is different from the demo they showed. But the point still stands. There’s not a useDtate per form field which is how react normally handles forms
Hmm, you can easily use a normal form submit to pull field information from. We always want to do fancy things where we need the info while it is being changed though.
Forms are one of those things that are so much easier to manage in Vue (and no extra dependencies)
https://v3.vuejs.org/guide/forms.html
https://v3.vuejs.org/guide/forms.html
Two-way bindings could seem like a great idea at first, but then you start building on top of it.
let me clarify it with the specific complication I've always encountered. You always need a function to parse raw input, a dictionary of strings, to the typed model object, or fail, then there should be a function to serialize the model back to the input attributes. You owing these 2 functions make 2 ways binding useless.
If you're looking for some of the benefits of co-located components and "loaders", I would recommend checking out: https://github.com/smeijer/next-runtime . That was the main thing that intrigued me about Remix, but you can get a lot of the same benefits using this
They just did (maybe still going) Q&A session where they did a demo and answered question.
Remix seems to be more like PHP or Ruby On Rails, it handles both server side functionality (calls to db, third-party APIs...) as well as the frontend code in a single file.
That can be done on NextJS as well using getInitialProps, getServerSideProps, or getStaticProps
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
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
It doesn't really promote its use, but it's exceedingly easy to use cache headers with Next.js if you're using getInitialProps or getServerSideProps.
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.
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.
While it is easy to use cache headers with NextJS -- as you said -- you have to know what you're doing.
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.
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.
NextJS ships with both the built-in fs router AND a traditional imperative router.
Also, there's a lot more to caching with NextJS than SSG.
Also, there's a lot more to caching with NextJS than SSG.
Yes, NextJS does ship with an imperative router, but you cannot construct a custom route on the client-side without adhering to the core concept of building your routes based on the pages directory.
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.
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.
> "you cannot construct a custom route on the client-side without adhering to the core concept of building your routes based on the pages directory."
Actually, that's not true. You can opt out of the fs-based routing altogether.
Actually, that's not true. You can opt out of the fs-based routing altogether.
I'm not aware of said functionality on the client-side. Out of curiosity, do you mind linking me to said documentation or article on how to circumvent routing on the client-side without using fs-based routing?
https://nextjs.org/docs/advanced-features/custom-server#disa...
> "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...
> "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...
That is through using a custom server -- which is a whole other topic. I'm comparing apples-to-apples between NextJS's built-in router and Remix's usage of React Router as far as client-side routing is concerned.
> it handles both server side functionality (calls to db, third-party APIs...) as well as the frontend code in a single file.
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.
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.
Any chance you could share an example in a codesandbox? I realize that might be asking a lot, so no worries, but I'm super curious to see it.
Remix might be a few years too late to be honest.
After watching the session, there does not appear to be any significant differences from Next.
After watching the session, there does not appear to be any significant differences from Next.
the team behind remix probably has the biggest following in the react scene, so even without having any major differentiation (though I happen to think they do have) it's going to gain popularity.
I'm sure outside of my personal bubble this won't be an issue, but I've found the buzz generated from this announcement to be kind of off-putting. The sheer amount of promotion leading up to this announcement has been in my face now for weeks and kind of driving me nuts.
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.
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 get what you mean, the frontend dev community on Twitter seem childish and unnatural, spamming self gratification (don't know if it's the good term, basically trying to spread fake positivity all the time, trying to over talk about the inclusivity and woke social trends ) stuff and overusing using emojis.
I rarely check twitter but yesteday's Kent Dodds message section about a tweet announcing Remix's launch made me cringe.
I rarely check twitter but yesteday's Kent Dodds message section about a tweet announcing Remix's launch made me cringe.
I'm sure many of the frontend dev Twitter influencers are genuine, but I do get a similar vibe. Some of the conversations just don't feel real at all, very similar to _some_ church circles.
I'd never heard of Remix before today. To contrast, I heard about Next 3-4 years ago, despite not using it at work until a few months ago
Well Remix just released today, so it's not surprising you haven't heard about it. You'd have to follow Ryan, Michael and Kent, the people behind remix.
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)
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)
> and Kent, the people behind remix
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.
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.
Yes, but just because marketing.
Next.js has an /api folder that does that, is it similar?
Take what I say with a grain of salt since I haven't used either. The API folder in Next.js simply exposes API routes that you can use in the frontend code of your Next.js app, or not use it if you don't want to.
Remix does support this behavior, but it also supports exporting a data loader function and/or an action function for forms that can only consumed by by the page you're working on. All of that runs on the backend. Again, very similar to how things are done in PHP where data is loaded from a DB and then consumed all within the same file.
Their form demo is definitely worth checking out. You could build the same thing with a Next API route. You’d need to write some code to do the validation that they do, but it should largely look something like their hook does. Hopefully Next will build something like it because this is a much more sane way to write forms than the controlled inputs and state way.
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.
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.
So as a 56yo "old school" 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?
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)
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)
As a 47yo UI Designer and UX/User Centered Design Pioneer (CEO, PM, Business Owner, etc.), I have one rule of thumb towards "Cool JS/CSS/New tech":
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 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.
About the same age, I just apply it to every "New tech" not only web, other than that, 100% on point.
Yeah, there will be dragons in this like any other framework, and I'll let other people slay them for free. There is little incentive financially or career wise to get ahead on these things - so I only do it for tech I find genuinely interesting.
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!
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!
using PHP 5 and xhtml is also a valid strategy imho
I think this new wave of server-enabled React is enabling codebases that are better organized than old MVC stacks.
The MVC way was:
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.
This is what Facebook's Bigpipe was doing in 2010.
https://engineering.fb.com/2010/06/04/web/bigpipe-pipelining...
https://engineering.fb.com/2010/06/04/web/bigpipe-pipelining...
>> load and render each component individually
you can do that with Suspense. React doc calls that render-as-you-fetch pattern https://reactjs.org/docs/concurrent-mode-suspense.html#appro...
you can do that with Suspense. React doc calls that render-as-you-fetch pattern https://reactjs.org/docs/concurrent-mode-suspense.html#appro...
[deleted]
Frameworks are designed for the following (this is obviously an incomplete list):
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.
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.
> 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.
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.
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.
Sure, that's one way to look at 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.
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.
> 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.
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.
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.
I believe you are arguing that high level languages shouldn't exist. :)
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:
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! :)
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! :)
If the code was buggy, fix the bugs. If the code was truly redundant, you could delete it. I suspect you meant more that it was repeated in several places, in which case, of course refactor it to be more DRY. If you can write an abstraction that provides a consistent mental model and relieves programmer burden, then do it. None of that is in dispute.
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.
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.
Is this really new though? MVVM .NET apps similarly use getters & setters in this manner, except with XAML.
I've never seen .NET code that has magic properties hiding expensive operations, though my .NET experience is admittedly limited. Is that idiomatic?
Maybe so; it's pretty normal to expect a property setter to perform additional operations, as it's necessary for making data binding more manageable among other things. But using Go to Definition takes me directly to the getter/setter, so imo it's not exactly hidden.
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 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.
Check out Laravel Livewire: https://laravel-livewire.com/ — this is based on a similar concept. (If course, you do need to be using Laravel in the first place!)
[deleted]
[deleted]
Coming across "new stuff" I always ask myself: Where did the complexity go? It definitely didn't go away, so what is it that the glossy page is not showing?
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'm wondering why this decision was made?
They used to openly albeit implicitly mock open source software projects taking big VC money, by saying things along the lines of “we have a radical business model where we just charge people to use our product.” Noble, perhaps, and probably a good way to kickstart community good will, but the VC money is undoubtedly a much faster way to scale the fiscal size of the company!
> saying things along the lines of “we have a radical business model where we just charge people to use our product.”
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.
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.
That's what we call hypocrisy to summarize
Is the idea that if you build the framework you can build the ideal platform for the framework with a nice warm customer base and collect that sweet recurring revenue. Way more upside than selling licenses.
Sounds like timescale, metabase, and posthog.
Sounds like timescale, metabase, and posthog.
because this sort of company can be big
Remix, like other such attempts, will need to get into the hosting business. Give out a good framework to ensure lock-in, then sell the infrastructure/runtime to deliver the app built on your framework. Then sell add-ons like $5/mo for authentication, $10/mo for I18N, etc.
Yes this is what they discussed in their live stream this week. The blueprint is clear, execution is no guarantee, but seems like a no-brainer if they want to work on this full time and really want it to be a widely used javascript framework, and if someone is going to give them money to try. Personally I think it brings a lot to the table and I loved the programming model (SSR, loading data on server, common platform primitives etc) compared to Next.js prioritizing SSG. I think they have a good team and a good shot at gaining market share.
The execution challenge for Remix is how to navigate the tension where FOSS and commercial forces pull them in opposite directions. So far, they've been stressing "interoperability", "no lock-in", "run it anywhere", etc. To live up to this goal, they'll need to maximize how portable Remix is, which will minimize the value of their specialized runtime service. Meanwhile, players like Vercel always positioned their products+services as a natural pairing, where the best stuff is inside the walled garden.
If this sort of company is vercel, sure. But right now remix has no obvious monetization strategy. It seems obvious they'll announce a SaaS solution eventually but it's not clear what the value add will be.
Yes and Michael, one of the co-founders, already mentioned doing this in his introductory live stream this week. I did mean can be, and certainly this is why they went this route, but no it isn't a guarantee. But even as simply a "javascript framework", selling licenses and being closed source was a good way to bootstrap, but open source and taking money that someone wants to give you is probably the only way to be viable longer term and get traction and commitment from users.
Haven't looked at the specifics of the actual framework (yet), I came here to say that this landing page is simply amazing. It's fun, it tells a story, it gets you engaged, and it's fast and snappy and well-designed -- a pleasure to use! Kudos to whoever did the thinking & the work!
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...
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...
Nice. Defining multiple zones, each with their data and error boundaries, at little to no cost is a nice approach.
Though as silly as it might sound, Remix’ publicity work has put me off it. Will read the docs anyway.
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'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.
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.
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.
You might be interested in inertiajs: https://inertiajs.com/
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.
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.
I'd say that framework are like, mmm, rails. (RoR was a genius and very candid name.) They allow you move fast and safely as long as you move in the direction the creators if the framework had in mind. Their keyword is cohesion, and their drink is kool-aid.
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.
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've done some "fat app servers" that consume GraphQL APIs. You could build a Phoenix + Absinthe app, then consume it from something like Remix.
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.
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.
It’s definitely possible. I have a project that does the same thing with Python and React but you could switch out the backend to anything that outputs html. The cool thing is your front end is just super modular components and your backend does all the heavy lifting, can talk directly to your DB and you don’t have to write a single API. Was thinking of putting something open source together, let me know if that might be of interest
Yes, it would be if interest to me. I've been looking for something similar lately. One thing that I found is https://github.com/ChrisKnott/Eel but it's more geared towards making desktop apps
Can I contact you? My email address is in my profile
We're in the same boat. Wouldn't give up Phoenix on the backend for anything. We are gradually adopting LiveView with great support for components. Have you tried it?
Agree Remix looks good though!
Agree Remix looks good though!
There's no strong requirement to use Node for your backend...your Remix codebase can fetch() data from anywhere in the `loader` function:
https://remix.run/docs/en/v1/guides/api-routes#api-routes
https://remix.run/docs/en/v1/guides/api-routes#api-routes
I get that I can run this as a SPA, but then don't I lose out on the prerendered HTML fetched from the server? That's what I mean by isometric with Node.
Well you could run it as a sort of rendering layer in front of your backend, and talk to your phoenix app on an internal API or local socket. May not be worth it though. Unlike next, I don‘t think you can even run this as SPA only.
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.
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.
Why don’t you just return JSON from the server?
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 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?
From their contributing page:
https://remix.run/docs/en/dev/contributing
> "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?
https://en.wikipedia.org/wiki/Contributor_License_Agreement
> "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?
https://en.wikipedia.org/wiki/Contributor_License_Agreement
It's common for open source libraries that use split licencing. By assigning copywrite ownership to the project, they are able to licence your contribution however they like.
Without a CLA, any licence change, sub-licencing or commercial terms would need to be negotated with every individual that has contributed code to the project
This seems interesting but the rendering bugs on the website don’t give me much confidence.
https://ibb.co/DfNw2GV https://ibb.co/FgW3jQb
https://ibb.co/DfNw2GV https://ibb.co/FgW3jQb
Also the docs don’t have scroll restoration when you use the browser back button. You’d think a framework that prides itself on using the web platform would have that working automatically.
Like it works when nobody broke scrolling through custom JS.
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'm already so impressed by Remix after watching the demo today. Looking forward to Kent Dodd's demo tomorrow and to play around with the framework.
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 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.
Maybe it'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't put it as a "welcome" 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.
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.
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.
[deleted]
Made me think of Ethereum's remix, an amazing IDE all-in experience to write smart contracts: https://remix.ethereum.org/
Java/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?
I must not understand the question, because the answer is "the obvious way". You just run the V8 process once in each container and scale up your containers. There's nothing special to it.
What are you concerned about breaking?
What are you concerned about breaking?
> I must not understand the question, because the answer is "the obvious way". You just run the V8 process once in each container and scale up your containers. There's nothing special to it.
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).
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).
With something like Cloudflare Workers, your CDN actually becomes geographically distributed server instances. Since the work involved in actually serving the frontend code is never the bottleneck, it ends up working out pretty well.
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.
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.
Seems like Svelte Kit too
They lost me at:
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.
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.
No, I didn't downvote you because I'm "suffering from a lack of imagination". I downvoted you because those "web fundamentals" are the web fundamentals. Putting another abstraction layer over it to obscure it does jack shit other than make your code more complicated. As long as I need to render a h1 or a div to draw anything on a web page, then I want control over the h1s and the divs. If there was a way to get away from that then sure, I'd be all for it.
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.
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.
>I didn't downvote you because I'm "suffering from a lack of imagination"
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.
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.
I don't mind vouching for this comment because it does further the discussion.
It's a lot more interesting that the "let's should be lets" comments.
It's a lot more interesting that the "let's should be lets" comments.
Hey, I appreciate that.
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.
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.
Given that the entire Remix team has spent the last several years doing training teaching people how to use React, and building one of the core libraries in the React ecosystem, this seems like a rather off-tangent train of thought and unrealistic expectation for what Remix might have been.
>this seems like a rather off-tangent train of thought
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.
[0] https://news.ycombinator.com/item?id=29313460
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.
[0] https://news.ycombinator.com/item?id=29313460
Perhaps it would help if you could clarify what you envision a "truly paradigm shifting approach to web dev" might look like? I'm legitimately asking. There's been a near-infinite variety of options tried thus far, both with and without "HTML code mashing". I'm not saying it's entirely impossible for anything truly new to be invented at this point, but given the constraints of what a browser is, I'm really not sure what exactly you envision being suddenly invented at this point that would be radically different. (Or, tbh, why you feel a team that is knee-deep in React would suddenly turn around and go a completely different direction.)
>Perhaps it would help if you could clarify what you envision a "truly paradigm shifting approach to web dev
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.
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.
It seems like you're conflating a few different concerns here:
- 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?
[0] https://www.youtube.com/watch?v=x7cQ3mrcKaY
- 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?
[0] https://www.youtube.com/watch?v=x7cQ3mrcKaY
First, thanks for the thoughtful reply.
>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.
>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.
Okay, so what I _think_ you're saying here is that we should no longer be thinking about divs and spans and such as the raw materials we use to write a page, nor should we be writing HTML itself, but rather VB6-style "I want to drag a widget onto the layout screen"?
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.
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.
>Okay, so what I _think_ you're saying here is that we should no longer be thinking about divs and spans and such as the raw materials we use to write a page, nor should we be writing HTML itself,
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.
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.
This comment is at least 5 years late. JSX has been a thing for so long now and it works.
>This comment is at least 5 years late.
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.
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.
Maybe I will be giggling at my former statements. Most likely, actually.
But of all the things that need improving in the UI world, the templating itself is quite low down on my list of priorities.
But of all the things that need improving in the UI world, the templating itself is quite low down on my list of priorities.
Well, it's not just about templating (awful as that is). But, I hear you.
This is just React.
Try ClojureScript + Re-frame
I guess nostalgia is a powerful force in JS world.
How can this be integrated with react-query and react-location?
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).
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).
I think the goal here is to avoid needing something like react query. The loader functions you write execute on the server and pull data that is needed by the component.
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.
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.
Off-topic, but I disagree about React-query being a must-have. Putting the fetching responsibility into the components makes a lot of sense in a some projects, but not always. There have been many times where I wish I just went with RxJS to orchestrate the data flow instead.
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 "rethinking" trending opinion or what?
Looks like another contender for transitional apps[1], all for it!
[1] https://www.youtube.com/watch?v=860d8usGC0o
[1] https://www.youtube.com/watch?v=860d8usGC0o
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.
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.
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.
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.
I would bet on that, given that Kent C. Dodds has been almost annoyingly speaking about Remix in the past few months (he's been hired last week) and that he is obsessed with testing.
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.
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)
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't tell me anything at all, it looks like 100% marketing.
Is there a comparison between this and Next.js, Gatsby or any other framework?
Is there a comparison between this and Next.js, Gatsby or any other framework?
So far it's hard for me to differentiate this from Nuxt.js (Vue-based server-side rendered + client side rendered version of Next.js).
I'm digging into the demo vid to look for the selling points of this over Nuxt.
I'm digging into the demo vid to look for the selling points of this over Nuxt.
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'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?
It's not a UI library, so it has no more opinion about what UIs look like than React itself does. You can make it look however you want.
Just stop making websites (especially documentation) dark mode only, that's a pain. At least when it's the other way around you can easily use an extension to get dark mode, here you're stuck with sometimes unreadable text unless you manually tweak the CSS.
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.
Seems like they have a bit more going on with progressive enhancement and interaction support, but nested routes are the headline for me.
Seems like they have a bit more going on with progressive enhancement and interaction support, but nested routes are the headline for me.
I like to think of like this:
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.
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.
I'm curious what do you think is missing from Next.js that would make it better at connecting to databases and backend APIs?
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
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
1. Vendor-lock
2. Iffy folder structure. Some stuff both front-end & back-end will live under /pages.
3. Suboptimal experience when you have to use middleware. Disclaimer, haven't tried the latest updates, but I assume it's vercel only.
Yeah, other than the nested route thing, there doesn’t seem to be that much difference between Next and Remix when it comes to talking to a database.
Next.js has had nested routes since version 6. Not sure I see the difference in what Remix is offering?
https://nextjs.org/docs/routing/introduction#nested-routes
https://nextjs.org/docs/routing/introduction#nested-routes
I don't think the nested routes mean the same thing on the NextJS page. To my knowledge, NextJS doesn't support nested routers which is really what many are after. Like in the Remix demo, there are various content areas with nested content, which would be controlled by the URL. You can create url parameters manually like /account/:tab/:id but it's kinda hacky as you have to use router.params['param-here'] to get the parameter and the handle the rendering yourself. You'd really want an account router to handle each tab in the account area, and then each tab in that area has its own nested router than can display the relevant content (based on the ID of the invoice for example).
I think what you're looking for is nested routes _and_ layouts. It's possible in Next but IMO it's not the prettiest.
https://nextjs.org/docs/basic-features/layouts#per-page-layo...
https://nextjs.org/docs/basic-features/layouts#per-page-layo...
Remix have just been released and you're already jumping to conclusions ? What's missing from NextJS to connect your own backend framework like django rails express or whatever ? Or even using their api routes + something like Prisma and a SQl/NoSQL database ? Basically nothing.
We can call it the Gatsby-Next-Remix continuum.
I’ve only run through it on a surface level, but isn’t it the same as what JSF did a decade ago?
It rarely gets any praise, but to me it was the most productive web FE framework to date.
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?
To be honest what this does and how the code looks is like any random PHP CMS back than fifteen years ago.
I'm truly baffled.
I'm truly baffled.
Something new here? Because this is not new and gets posted semi-regularly every few months for a few years
Perhaps it was the v1 announcement that got it across your radar
posted a few hours ago:
https://news.ycombinator.com/item?id=29312063
posted a few hours ago:
https://news.ycombinator.com/item?id=29312063
I like this website. It's one of the few I've seen do "scroll = animation" well.
the example boosts with a technology that requires making 4 requests to show the UI?
if you think that's a lot, you haven't checked your network tab for any considerable production site lately.
What's the rundown on how this compares to the obvious competitors (Next, etc)?
[deleted]
Yay! Another JS framework, just what we needed!
Maybe i'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' attention constantly split instead of being guided.
Also it does that thing where it hijacks scrolling and uses your scrolls to control an animation speed. Which probably felt really clever to invent, but it is just super annoying and distracting. Like who are the people scrolling back up to replay bits of these silly little animations?
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.
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.
> Like who are the people scrolling back up to replay bits of these silly little animations?
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.
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.
Yep. Some of us still use the PgUp/PgDn keys, even! I don't ever remember encountering a scrolling animation that handled them sensibly.
I like it, looks nice. I know Apple does it as well and it's always impressive to me when they launch a new product and make a new webpage for it. That being said, those are just marketing pages, for critical behavior like buying a new product, those are all static pages with no animation.
I found it incredibly annoying to read/parse personally. Huge fonts, stuttering animations interrupting my scrolling, and way too many colour/formatting changes to be able to smoothly read it. It's all very distracting and over-designed.
Exactly my thoughts. Impressive yet annoying. But I can understand their desire to do some magic show at the front page because it is an appropriate place to catch your eyes. More plain, traditional documentation could be found elsewhere.
It's almost an exact copy of reactrouter.com, which is also (IMO) hard to parse. I'm not actually sure what the difference is between this and RR, given the websites are so similar. It seems like the fundamental pitch of Remix is RR6, judging by the site.
I would have made this be /about or something like that and had the landing page be something more traditional. I don't think repeat visitors are going to want to scroll through a presentation like that all of the time. But that could be what they ultimately do, I wouldn't be surprised if they moved it.
I see no mention of Typescript support. Anyone know?
The create npx command has a typescript option, the entire framework seems to be typed nicely, the demo was all typescript. I’d be surprised if they didn’t write the whole thing in it.
seems like the code in the docs [0] is typescript
[0] https://remix.run/docs/en/v1/tutorials/blog
[0] https://remix.run/docs/en/v1/tutorials/blog
It supports typescript completely
I know this is low-value, but it always stuns me to see basic typos on a product’s landing page (lets —> let’s). Have the creators shown it to anyone else? Has nobody close to them told them about it?
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 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.
You're not the only one who has that kind of reaction. Proofread copy should be important everywhere, not just on the landing page, but this is literally in the first sentence after the initial headline.
Sure but on the other hand you have copy that has gone through five levels of managers OK-stamping it but only after fixing the errors and sanding down all sharp edges, your text churned into corporate yogurt that no one in their right mind would ever believe because it resembles FAANG speak too much.
I kind of like the odd error here and there. Makes me feel safe to at least try out their product.
I kind of like the odd error here and there. Makes me feel safe to at least try out their product.
Is that not what's happened to this site anyway? Looks an awful lot like corporate yogurt to me.
While I do agree a typo in the very first sentence is not the perfect way to start, there’s still the fact that English is not everybody’s native language and this sort of typos can be very hard to spot for non-english natives.
Not an excuse for having typos in the product’s website, but a very common explanation for it.
Not an excuse for having typos in the product’s website, but a very common explanation for it.
[deleted]
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.