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