I usually have deep hatred towards scroll-jacking but this was actually quite well done.
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.
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.
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 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.
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!"
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.
> 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.
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.
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 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.
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.
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.)
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.
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)
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.
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)
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?
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...
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.
> "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?
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.
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.
[+] [-] danr4|4 years ago|reply
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.
[+] [-] bryans|4 years ago|reply
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.
[+] [-] folkrav|4 years ago|reply
[+] [-] nolok|4 years ago|reply
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 !
[+] [-] empyrical|4 years ago|reply
[+] [-] CGamesPlay|4 years ago|reply
- 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.
[+] [-] apiep|4 years ago|reply
[+] [-] pacomerh|4 years ago|reply
https://twitter.com/ryanflorence/status/1463241922168774658
[+] [-] mcintyre1994|4 years ago|reply
[+] [-] midrus|4 years ago|reply
This might work for q blog post example, but imagine doing a full reload just because you liked a post or a comment.
[+] [-] nsonha|4 years ago|reply
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.
[+] [-] haolez|4 years ago|reply
[+] [-] azangru|4 years ago|reply
[+] [-] systemvoltage|4 years ago|reply
[+] [-] kome|4 years ago|reply
It's mindbogglingly bloated and terrible.
[+] [-] elwell|4 years ago|reply
[+] [-] foogazi|4 years ago|reply
[+] [-] d--b|4 years ago|reply
[+] [-] franga2000|4 years ago|reply
[+] [-] franga2000|4 years ago|reply
[+] [-] ksec|4 years ago|reply
On my iPhone it is even better.
[+] [-] aiibe|4 years ago|reply
[+] [-] diordiderot|4 years ago|reply
[+] [-] archeroe|4 years ago|reply
[+] [-] Bellamy|4 years ago|reply
[+] [-] chairmanwow1|4 years ago|reply
[+] [-] aarpmcgee|4 years ago|reply
[1] https://blitzjs.com/ [2] https://redwoodjs.com/
[+] [-] flybayer|4 years ago|reply
At the end of the day, you must try them each for yourself and find which one resonates most with you and your team.
[+] [-] jtsiskin|4 years ago|reply
[+] [-] jacobsenscott|4 years ago|reply
[+] [-] Vinnl|4 years ago|reply
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.)
[+] [-] dreyfan|4 years ago|reply
[+] [-] magicink81|4 years ago|reply
[+] [-] proxyon|4 years ago|reply
[+] [-] cmelbye|4 years ago|reply
[+] [-] cercatrova|4 years ago|reply
[+] [-] cubano|4 years ago|reply
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)
[+] [-] msoad|4 years ago|reply
[+] [-] seeekr|4 years ago|reply
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...
[+] [-] gherkinnn|4 years ago|reply
Though as silly as it might sound, Remix’ publicity work has put me off it. Will read the docs anyway.
[+] [-] armchairhacker|4 years ago|reply
[+] [-] ianbutler|4 years ago|reply
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.
[+] [-] doesnotexist|4 years ago|reply
> "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
[+] [-] tambourine_man|4 years ago|reply
https://ibb.co/DfNw2GV https://ibb.co/FgW3jQb
[+] [-] cout|4 years ago|reply
[+] [-] bern4444|4 years ago|reply
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.
[+] [-] Guillaume86|4 years ago|reply
[+] [-] Raed667|4 years ago|reply
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.
[+] [-] baby|4 years ago|reply
[+] [-] blueprint|4 years ago|reply