Just skimmed through it, but this looks like a great intro for non-technical folk. I'll be saving it for when people ask me for resources into getting into frontend dev.
I'd suggest to send them a more boring but traditional approach first to DOM/CSS/JS. That way they will understand way better what problems React solve.
CRA is one way to get a very opinionated starter kit, but like all boilerplates and toolkits, they are very tailored to one particular use case, and you never learn what is possible with the library outside of the toolkit. Breaking from the happy path of the toolkit yields an even more frustrating experience than if you had set it all up by yourself. (Ejecting anything above a medium-complexity SPA from CRA is painful)
In practice though, unless you have some very specific needs (and the people I have met who thought that they did, well,... didn't :) ), you should still "just use CRA".
There are folks who like to live on the bleeding edge, and for those using something else (or ejecting) might even make sense... maybe. But for any production app you should just use CRA, otherwise you will find yourself explaining to your new hire all the obscure choices you made a year or two ago. Believe me, I've been on the receiving end of these explanations and it sucks.
I've been on the other end of that story, where entire dev organizations freak out because of a concern with webpack, babel, or some other piece of the stack... and nobody knows how to fix it.
CRA has its place, certainly. But it is a black box, and somebody in your org should know the tools well enough to make good decisions to build up a product from scratch without CRA... and then you may still choose to use CRA, but it is an educated choice, not a default answer because you do not know any other options.
I agree with it being important to know how to do this stuff from scratch (with Google, let's be realistic), but the black box problem is solved by ejecting.
My excuse for longing for something non-CRA is updating an existing frontend to React piece by piece. To integrate it with the existing Django app’s asset pipeline, I kind of had to eject and now my Webpack configuration and its dependencies are completely out of control. I am considering starting over with another tool chain, copying the existing components to the new structure. Replacing the whole thing with a new SPA would not have been feasible.
I don't think CRA is particularly opinionated, at least for the common scenario of "I want to make a react website". It doesnt force you down many (if any) routes, or prevent you from using too many popular technologies.
Yes, 100%, if you have more exotic requirements from a bundler or build toolchain then you'll need to look elsewhere and probably have to start learning tools like Webpack in more detail. I try and avoid those requirements.
Have you ever ejected a CRA? Your problems are just beginning once you've opened that can of worms. I used CRA exactly up until the point when I ejected it the first time. Never again. The sheer amount of code behind CRA is... remarkable.
Now I have a package/webpack/tsconfig files that I just re-use (and update as needed) between projects. I've never encountered a problem I couldn't solve. Sure now I need to manage the configuration of each project, but, I kid you not, my webpack.config.js file is 100 LoC total. This includes everything most projects probably need: Dev server setup and proxying, JS minification, JS bundling/code splitting, and SCSS/CSS transformation and purging.
I'm sure other projects have other needs, but it's really not that hard to understand these technologies.
And don't give me this "But all of that code is there to help you!" lecture. I've been deploying reasonably complex React apps since its inception, and have yet to encounter the kinds of edge cases to which the above sentiment is likely referring. Hey, maybe I'm just lucky...
The comment I was replying to was "React has too much configuration", which I disagree with because CRA and other low-effort build tooling exists.
I like CRA, it's my default go-to because i want to avoid maintaining a webpack configuration. If you have a solution that works for you, that's good too!
Sorry, the impetus of my comment above was that CRA is introducing FAR MORE configuration/dependency/complexity than maintaining a webpack.config.js file!
The build process of a modern React application has a certain amount of necessary complexity. Hiding it behind a "low-effort" build tool like CRA doesn't change the above and, frankly, is really a disservice to anyone who wants to understand the tools they are working with.
Go ahead, eject a CRA sometime. See how "low-effort" it really is...
I've splunked through CRA webpack config and submitted patches to the project. I've ejected and then years later un-ejected because I didnt want to maintain a webpack configuration.
I'm curious about this. I have been using the same webpack.config.js file (save modifying paths) for nearly 3 years. I kid you not, yesterday, I finally decided to upgrade to the latest version of webpack because I am about to embark on a new project[0] for the next 6-8 months. It took me roughly 20 minutes to modify the file according to the latest configuration conventions and have everything up and running exactly the same. I find it unfathomable that maintaining a short config file is "too hard".
I decided to try my hand at using CRA for the first (and last) time to build a small app at work because it had recently hit the scene, and appeared to be fast-becoming the idiomatic way of engaging with the library and ecosystem. I don't even remember why at this point anymore, but I had some issue that required me (as in the docs at the time said so) to eject the app. My jaw literally dropped after I saw what the project had become. It was... thousands of LoC. And spread across so many files!
Clearly we have different definitions of "too hard", but, to me, the task of understanding all of that was "too hard". I am simply not wired in a way such that I can use a tool without understanding how it works (obviously within reason). I have to imagine that when you say you "didn't want to maintain a webpack configuration" that you mustn't really understand what that entails, and are using the output from an ejected CRA as a proxy for what that configuration must look like. I assure you, it's rather simple. I've spent 20 minutes in the last 3 years doing so.
[0] I would estimate the kinds of apps that I build are far more complex than the vast majority of use-cases (think fantasy sports draft/league management software).
The traditional approach stopped working. It becomes chaotic and inefficient to always directly talk to Domo.
No.
The traditional approach was web 1.0, which was abandoned due to UX issues, not complexity.
Later on, the chaos of direct DOM manipulation by multiple javascript entry points became too much and was formalized into the SPA frameworks we see today.
An alternative solution is to go back to the true traditional approach & address the interactivity issues within that architecture (REST/HATEOAS).
Yes! You 100% dont need a front end framework like React to achieve dynamic UI effects. I’d argue they’ve degraded the user experience over time, complicated development process, and slowed down the web experience for most people.
The fact remains client side JS frameworks did not grow organically from the open source community. They had to be pushed into the dev mindspace by the mega-caps tech cos to offload processing power to the client. For the vast majority of companies (all but a handful), front end frameworks hold an org back.
I’ve had this unpopular opinion for several years, and have yet to meet/work with a startup who didn’t regret choosing Angular/React/etc.
SPAs designed to mirror state on the server have a distributed data problem, there are lots of problems there in terms of fetching, updating, ensuring the users are traversing from action, loading, success/failure etc
Then there's the problem that the page could have changed since the user started filling out that form, what happens when those form values now conflict etc etc
The difference between serving a dead fish of a HTML page, and a SPA application is vast because you're essentially creating 2 independent systems, server and client instead of just server and then adding one of the hardest thing in computing which is consensus between disparate systems
I'm quite excited about React Server Components because it means for the majority of your web app you can return to the simplicity of shipping HTML it doesn't solve everything but at the moment client side applications have a lot of boilerplate to do with just keeping the server in sync that would have been historically "for free" in a server context
Yes. This exactly. You're basically writing the business logic in the app twice. It's an anti-pattern in my opinion that adds all kinds of tech debt.
I'm loving it that the trend is starting to go back to rendering HTML from the server, then sprinkling on dynamic elements when desired. It's so much more efficient whether you're talking compute, developer time, or the ability to stay agile and change/add features as you learn about the market.
That clients exist to do work so that a company's hardware doesn't have to is cynical, a "client bad [if it's built with JS]" cargo cult, and it suggests that you can't think of any upside to doing things on the user's powerful device instead of a phone-home network request to a server.
You've never met anyone who didn't regret React? According to the Stack Overflow Developer Survey, 68.9% love React. I feel like you haven't talked to enough people.
The idea that client side JS was pushed to offload processing power is a bit ridiculous. Do you have any evidence for that claim? Many React sites these days do SSR anyway (running the client-side code on the server) so it doesn't seem like they would save money doing that.
"Why should only <a> and <form> be able to make HTTP requests?"
Because of accessibility tools, especially screen readers.
This looks like yet another DSL that has to be learned, and does not appear to do anything to solve the UX issues of Web 1.0 that jQuery didn't. (I recall plenty of attempts to build frameworks on jQuery that relied on automagically parsing commands out of data-x attributes).
Additionally, you now need to know your server language's DSL, whereas the bigger tools all offer server side rendering via JS if that is your thing.
I am not saying it is bad, only that I don't think it is an answer for this thread.
htmx is different in that it stays within the original REST/HATEOAS model of the web, it pushes HTML as a hypertext. All interactions are via HTML, so you are truly using Hypertext as the Engine of Application State.
Since htmx tries to fold in alongside the regular HTML concepts (which you need to know anyway) you need to know less, and your back end can be in whatever language you prefer. No javascript on the front end, no pressure to adopt it on the back end.
Accessibility is a concern, but, like everything else, has to be traded off against other concerns.
> Accessibility is a concern, but, like everything else, has to be traded off against other concerns
No, it really doesn't. It is mandated by law for at least some categories of websites, and opting to ignore it entirely (as the demo of HTMX apparently does) is extremely user hostile.
> All interactions are via HTML
HTMX is still javascript. Turn JS off, and you end up with a button that does nothing.
AJAX is also a DOM and JavaScript concept, not an HTML one. You need to account for error and loading states, or your users will have a bad time. That means embedding content in the document that isn't actually relevant to the state of the document.
It sounds more like a leaky abstraction that tries to pretend REST/HATEOAS is an HTML concept, when it is orthogonal... About as accurate to say that it is an XML or JSON concept.
is another example that can degrade gracefully in the absence of javascript: wrap the input in a form and do the normal post-back for non-JS enabled clients.
With respect to REST & HATEOAS, note the first term in HATEOAS: Hypermedia as the Engine of Application State. HTML is the hypermedia that Fielding was describing in his dissertation. (XML and JSON are not hypermedias, so I'm not sure what you are getting at with that as a comparisong)
htmx tries to use HTML (a hypermedia) as the data interchange, thereby respecting the uniform interface of the original web model. No side state, no interpretation, no special knowledge: just exchanging hypermedia with a server. This is in keeping with the network model Fielding was describing in a way that a React client, for example, is not.
htmx tries to extend and complete HTML along the lines it was already going, before it stalled. Yes, it uses the tools available to do so, which are javascript, unfortunately.
So I can't discern if React is a loved or hated technology (also it doesn't have to be binary). At the company I was working at the front end devs brought in React and were super excited about it, but reading a couple comments in here it seems like people have some reservations.
I haven't invested the time into as I don't have a use case but I keep hearing about and now get the sense it isn't necessarily worth looking at until i have a needed case.
My personal professional view is that I found web frontend development quite disgusting between the days of static HTML and React. The frontend apps built by my colleagues using jQuery or Angular seemed to have no structure and seemed quite fragile. Of course, one could use any tool well, but in my world it was not happening.
From my point of view, React and JavaScript improvements in later versions have made frontend development more tolerable and even interesting.
I think HN's comments of front end type topics tends towards 'back end focused folks talking about front end'.
I love HN, but I would really be wary of taking too much front end type commentary seriously as it comes from HN comments.
Now sometimes the comments are GREAT, that's not to say it is all bad, but other times the comments on front end topics on HN is like walking into a meeting with a bunch of managers and non front end focused folks who got together to list their gripes ;) In those cases I often don't say anything because the ranting is on and nobody really cares.
Edit: This was longer but I decided I didn't want to go that far down the meta rabbit hole.
It always reminds me of the Simpsons quote: "Am I out of touch? No, it's the children who are wrong.". I've seen many people here more willing to believe that all front-end devs are clueless than admit they might not understand modern web-dev.
You can tell how lopsided the discussion is here by how many people here think it's some sort of badge of honor that they're a "back-end guy" who barely even touches the client instead of feeling sheepish how far removed they are from the user experience and thus the concerns of how hard it is to build a good client and the tools that improve it.
A good example of this is how many "back-end guys" here think it's Javascript and web tech that are hard/annoying instead of all client tech due to the nature of building user-facing software that has to run on a 1,000,000 devices instead of sysops-facing software that runs on one server.
Be wary of anyone who just peddles downsides without acknowledging trade-offs. They don't have much experience (You can have 20+ years of dev experience while inexplicably avoiding this sort of realization). Right now there's someone in the top thread saying they literally don't know a single company that didn't regret using Angular/React. Oh bother. This sort of person just has to ask, but they don't because they prefer to cling on to their little sneering world view.
If someone seriously can't say why anyone could prefer React (or any other tech, like JS or PHP or jQuery) without a cynical disparaging trait like these people are just idiots, simply write this person off and seek more even-keeled opinions about the world.
People are more likely to chime in if they hate it.
I think most people are happy or content with React - but honestly, it doesn't matter. Nearly every job listing I've seen or applied to asked for React experience (if the position asked for frontend skills). It's so ubiquitous in the coastal US tech industry that if you want to be a frontend dev, you're limiting your career choices by refusing to learn it.
I did web dev from 2012-2015, until I moved into doing security engineering. I started doing some React tutorials on the side in December and now have a small project at work that uses it. I do not consider myself a web dev, so I will take any actual web dev's opinions over mine, but React seems nice!
At first it seemed a bit complicated, but looking back at the stack I left behind in 2015 (LAMP, numerous JS libraries, Bootstrap, some Ruby was starting to creep in), it actually is a little more consolidated.
I guess I should bookmark my comment and check back in a year from now in case I am still using React and see how my thoughts change by then!
If your project requires high interactivity, with lots of moving pieces, you'll love it. Particularly unidirectional data flow is a breeze to work with. If you need a static/basic CRUD site with few popups, you may prefer plain HTML/JS.
~~People don't complain about things they have not used.~~ People complain about things they have used so, if you have heard complains, it means a lot of people are using it, and using it despite those complains.
So, you should consider that there is some benefit which outweighs the complains
UPDATE: original line came out wrong. and was flat out incorrect
My impression is that developers love it because it makes things easier to develop, but users not so much because it makes interacting with web pages even slower than it already is.
Also, it makes webpages a pain to scrape, consumes more RAM and CPU, and recursive module dependencies can become a huge attack surface.
When I'm pressed to oversimplify, I usually respond with "A React component is basically a function that takes a set of parameters and spits out HTML, and can react to changes in those parameters and update said HTML. The rest is implementation detail."
I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach.
I don't have experience with all of these technologies but have been using React since its inception, and let me tell you, there is no amount of (reasonable) money that would make me want to go back to the times when jQuery the big new thing. It was awful! Procedurally manipulating the DOM! I mean, c'mon guys. Talk about a mess... Where are all of the FP evangelists when you need them?
And I know someone out there is bound to downvote me and respond with something like, "B b b but that one site where it downloaded 300kB of JS for a landing page! It's such a bad user experience!". Sure. That's precisely what I'm talking about /s.
The reality is that libraries like React are so popular because they make front-end web development not suck. You can actually reason about the behavior of your UI without first committing to memory a whole of bunch of procedural, ad-hoc `let el = document.getElementById('i-hate-myself')` nonsense.
I get it. It makes web pages a bit slower, and sometimes (maybe more often than that) get abused. That isn't fun for anyone. But level the critique at the idiots downloading a MB of JS to power a single dropdown, not the tool managing that dropdown's state.
I mentioned in another comment that I think HN's comments on front end type topics tends towards 'back end focused folks talking about front end'.
That doesn't make them wrong when they say "hey this super simple site doesn't need to be in react" but at the same time it also misses the use case(s) for react and other frameworks when they rant on the topic more generally.
I totally agree. Using react is a breadth of fresh air for building web applications.
If all you need is a static site landing page that changes once a year, sure use something else, plain ol html, css, and JS will do wonders. But when you want to build an entire application and experienece for consumers, React is exceptional.
Web applications always have state and side effects, there's no escaping it. If you squint and tilt your head, ReactJS is like a pure function given the environment. React lets you model your view around your state and takes statefulness as a given and doesn't try to obfuscate it away.
As you say, its far easier to leverage FP ideas in a react application. Most react components can be pure. State can be modeled with all the fun FP tools and ideas. At the end of the day, React clearly delineates the stateful from the stateless and lets you easily model both relative to each other in a ergonomic manner.
The mental model of UI = f(state) is really beautiful. And I got it explained to me that its best to use an SPA when you have 'interrelated, dynamically updated state' from Tom MacWright and I very much agree.
The issue I had with React is that it forced a lot of mental models and API's on you to achieve UI = f(state) but after finding Svelte and spending 20 mins on the tutorial [0] I feel like I can say I 'get it' when it comes to building web apps.
Though the things you throw away when you decide to go all in on the SPA approach for your site is crazy, I hate not having access to my freaking database while building a page and having to create a ton of unnecessary code just to express a page that pulls in bits of data from my database. I do not want to complex myself with GraphQL. I much prefer the approach of dhh were we should only be paying that interactivity cost on the pages we need high fidelity on (which is probably going to be one or two pages you have for 80% of apps).
I think Hotwire looks promising where you mostly have logical split up sections of html that you want to be independently rendered across the page or on a click. When it comes to communicating and weaving state between those I'd be thinking about Svelte if it starts getting too complex.
> The reality is that libraries like React are so popular because they make front-end web development not suck. You can actually reason about the behavior of your UI without first committing to memory a whole of bunch of procedural, ad-hoc `let el = document.getElementById('i-hate-myself')` nonsense.
I think it’s a bit different - they are so popular mostly because of the massive crowds of front end devs cargo culting static websites into SPAs.
And then maybe because of the many cases where they’re applied to replace jquery or a few js sprinkles with unnecessarily complicated SPAs. This is where stimulusjs + turbo or similar could solve the problem with 10% of the effort and complexity.
Then, maybe in third place or further, because there are more cases for SPAs than 10 or so years ago.
I agree that the cargo cult is real and abuse of the "SPA" paradigm has never been higher! But that is orthogonal to the tool.
React does make front-end web dev not suck. It may not always be the right tool for end-users, but as a developer? C'mon. It's never been so ergonomic (and plain simple) to build a complex UI.
I googled stimulusjs[0] and you know what? From a development perspective it looks like it sucks compared to React. I'd rather just write vanilla JS than that hot garbage. Is the bundle smaller? Didn't bother to look, probably. Is it faster? Didn't bother to look, hopefully.
I get it! "Our job is to deliver value to the customer blah blah...". Engineering has costs as well. From training to velocity to, yeah I'll say it, developer happiness, you can't just ignore these costs. Working in a shitty, homegrown codebase using these niche libraries is a recipe for turnover.
On the other hand, if you are just whipping a some simple pages here and there that probably don't need to be looked at ever again... go for it! Your future self will cringe a little bit when you open up the source to change something simple years down the line (I know I have!), but at least those interactions are fleeting.
[0] I apologize for my crassness if you are somehow involved in the project.
> On the other hand, if you are just whipping a some simple pages here and there that probably don't need to be looked at ever again... go for it!
Most interactions on the web are simple.
Tools like Gatsby use react to generate static websites. I’m sorry but that’s just insane.
The problem I’m speaking of is having a great slick well balanced hammer (react) which is a pleasure to work with and using it to put nails into (SPA-ize) everything in sight.
I’m not involved with stimulusjs or Hotwire apart from using them to create SPA-like experiences without much time, effort, or agony.
Basecamp use Hotwire for their cross platform hey email client - maybe take a look, it’s a pretty nice app.
You should have included the very next sentence in my quote.
There is a difference between using React and "SPA-izing" everything in sight. React is a library. It doesn't mandate an SPA as its use-case, and, frankly, I've had great success sprinkling React[0] into single pages that need that extra sparkle. Once you move beyond filtering a list or showing/hiding things, the pros quickly start to outweigh the cons.
Could some of those pages be made a bit more efficient or have a smaller download? Probably. But nobody notices and I am able to iterate on them quickly because they follow the same general structure as the bigger applications I've built.
To be clear, I'm not suggesting everyone use React for simple pages but criticizing the tool is a non-sequitur. You are kind of making my point above that all of this "modern JS is ruining the internet" criticism is being levied towards the wrong thing. Like you said, blame the bootcamps for churning out developers that know nothing else about how to develop a web page. Then blame industry for not training them the basics of their craft.
[0] Or preact (https://preactjs.com/). Which is way smaller (3kb)! At this size, it's crazy to use anything else. How big is jQuery again? 20 times that size?
I think we’re on the same page here and it’s a simple page with minimum added functionality via p/react or Vue or stimulusjs or even vanillajs and not an SPA which loads blog pages on top of each other.
> I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach.
I've got plenty of React & front-end experience and vastly prefer a thin library on top of the DOM than something like React, also for large applications. React is ok if all goes well, but when you have to debug or profile something, all the complexity behind the scenes occludes what you are looking for. Most of the time, people want JSX so you need a transpiler. Also keeping up with changes in new React releases seems like a lot of lost time.
I've been building [1] without a transpiler and just a 600 lines template library (see [2]), and it has been such a breath of fresh air. The fact that there is so little code between you and the browser makes it very easy to see what is going on. Call stacks of max around 15 frames.
It sounds like you are comparing React to jquery code without components, and I justed wanted to highlight that DOM APIs have evolved since those days, and that you don't need a library like React to structure your code.
React has popularized good ideas in front-end development, like components, but I think the complexity cost of a virtual DOM is often underestimated.
I see this sentiment often, that React is too complex, and I just don't understand that criticism. Is there some bloat? I'm sure. But the problems that React solves aren't trivial either.
The signature of a React application (and each component thereof) is simply `f(state) => HTML`. That isn't hard to understand, and the complexity behind the scenes is the complexity necessary to distill and optimize an application to the above. And to your point about JSX, yes, I do want that. I find it silly to write HTML using some other DSL. I have yet to find one that is anywhere near as transparent or ergonomic. How could there be?
I suppose I can agree profiling for the cause of undesired cycles could be easier, but, frankly, I rarely need to do so because I can simply reason about why a function/component is being invoked. The "flow" of a React application is well-defined (and rather simple). To your last point about structuring your code, you are probably right. Things have come quite far since jQuery in many respects, and I am sure that, if I were to try my had at it again, I would find it to be much more sane than 5-6 years ago. I just don't see why anyone would subject themselves to that though...
Kudos on your project! It looks great, and I'm sure provides the faculties important to you and your platform. I would be careful though. Given enough time and energy you may find, in the end, you have simply reinvented React!
Have you tried developing a doctors appointment website with React (or any SPA frameworks) say Django or Flask? It's a pain in the ass. Usually, you throwaway all the cool things about Django and turn it into a stupid JSON API and then you build a bunch of cruddy shit with npm tooling and cry yourself to javascript dependency hell. Then you need another server to serve up this bundle.js and a barebones index.html file. Great if you're building a Google Docs competitor. 99.999% of the people aren't.
I think VueJS is excellent and surprising to see React's popularity. Vue can be used just like jQuery without any nodejs tooling. Just like every discussion about this topic, React fanboys will respond with "But, technically, you can do that with React too" [1], yeah... It sucks at doing that. Without JSX, you can't interweave for example Jinja2 templates + React. Nor can you interweave JSX + Jinja2. With VueJS? It's just HTML with a few v- attributes. Even if React worked well with direct script tags in HTML, it still sucks at it because it's mainly designed for SPAs in mind. There is a lot of existing discussion on this topic [1].
I absolutely abhor the tooling/npm/babel/nodejs/webpack all this nonsense that Javascript frameworks need. They should be sort of like jQuery - no prebuilding steps - just drop and play. A doctors appointment website doesn't need to be an SPA. VueJS is the only framework that allows you to progressively enhance something like a Flask based website in the most natural jQuery-like way.
Oh btw, Svelte is yet another one - of course its SPA framework (Good luck trying to make it work on an MPA website). I am completely underwhelmed by Svelte, and ofcourse the JS peeps are flocking to it. :|
> Usually, you throwaway all the cool things about Django and turn it into a stupid JSON API and then you build a bunch of cruddy shit with npm tooling and cry yourself to javascript dependency hell
Or you could just shift your backend expectations and adapt to the different needs. If you're doing an SPA because you want an app-like experience and very decisively not a website-like experience, your backend should be as simple and stupid as possible and not force you into a model like MVC; you shift much of the complexity to the frontend when you go from website to SPA. You know, like it would if you're writing a desktop app or a mobile app that uses an API. Because it's an application, not a website.
You could pull the 99.999% number out of wherever, but the truth is that many things we used to do as websites are better off as apps. My bank's website is better off as an app, the social networks I use work better as apps. Hacker news doesn't. Blogs don't. Online newspapers don't. It all depends on the amount of interactiveness needed and how much better the experience is with access to real-time information streaming and quick UI responses based on things other than data loads.
And as dreadful as Javascript dependency hell is, it's objectively better than Python dependency hell since it's had a passable package manager for much longer than Python (and even then, most Python devs still don't use or even know of Poetry) so the ecosystem is better aligned to modern software development expectations. You're just used to one variation of hell, and don't want to learn a new one.
Try to understand modern frontend needs before assuming newer frameworks are shit at everything and that everything related to it sucks. They might be shit at the specific thing you're doing, and some lessons seem to have been forgotten when things were redesigned.
What hasn't changed however, is how most software development sucks, and the fashionable things that were done under terrible standards (devs and/or management) have changed, but are still done by the same terrible standards so you still have shit results.
> VueJS is the only framework that allows you to progressively enhance something like a Flask based website in the most natural jQuery-like way.
No. You're just allergic to build tools because you have not enough knowledge of them. Probably because, from what I've been led to believe from your comment, most of your experience seems to be with Python. All your described problems ultimately stem from there.
I’m allergic to build tools because I want zero JS in the backend.
Thanks for the counter, I have made previous attempts at App-like websites but have left me high and dry. There is something to be said about clarity and separation in MVC frameworks. I love MVC. I love boring tech.
Python dephell is no more after poetry. Have you used it?
I have! Poetry is definitely amazing. A while ago I had the misfortune of having to adapt an old Python 2 project with specific system dependencies, a mess of a C compilation pipeline and an annoying set of requirements.txt which made it pretty much impossible to convert (at the time at least), so I would say hell's not over for Python since it's simply been around too long with packaging being in a terrible shape and Poetry can't hope to solve all of it; but I'm sure this is not a problem if you're able to stick to current stuff in a greenfield project or if your brownfield codebase followed some semblance of good practices.
Then again, I would say the same for Node. Modern npm is much better than it used to, yarn 1 is even better (better DX between its CLI design and handling of vendored yarn's), and yarn 2 was magical in the smaller examples where I tried it, eliminating the need for node_modules.
Back on the topic for the SPA problem, I would suggest you take a look at Elm, at least for the learning experience. The Elm compiler ships all the tools you really need to be productive, it's performant, the Elm language gets across the usefulness of its state management model extremely well (unlike React, which is a terrible teacher) and as a bonus it will ruin you forever if you haven't seen functional programming actually being useful before.
Someone in this thread just posted Alpine.js. Literally made my day! This is what I want and would ever want in the kind of apps we build.
Node: I am not sure but so often do I come across a package that only works on a previous node version (say v10). How come Node is not backwards compatible? Node v14 should be able to run anything that runs on Node v10. This is a runtime, not some library. Also, I discovered recently about LTS and non-LTS versions of node. Who knew. The whole ecosystem is rickety and not up to standards IMO.
Nope, they absolutely don't! And Reddit's SPA is a good example that is markedly worse than their old website. I was thinking of Facebook.
Twitter (and things like Instagram and TikTok) in particular is something where an SPA makes it easier to handle the different sections like the main feed, DMs, lists while keeping it responsive, but for those cases tools like LiveWire and Hotwire help make the gap between sites and SPAs much smaller and are an asset for avoiding having to rewrite websites into SPAs just for those smaller things.
But then you have cases like YouTube, where you could've argued that the initial case was a perfect fit for a website, and then as it has incorporated features like notifications, livestreaming with live chat, live donations with payment flows on top of the video and smaller things like the mini-player... you would end up with a huge amount of imperative JS sprinkled around your templates and carefully managed around your LiveView-equivalent's state updates; or you could just go with an SPA, vastly simplify your backend to be concerned on handling your data efficiently, and just having a frontend that makes managing complex state updates not-as-horrible.
Agreed, but I think an SPA feels like optimizing way too early because of how far it seems you can get now with Hotwire etc.
Also with the pace of SPA's at the moment its a risky bet 2015 React code is nothing like 2021 React code with hooks and functional components etc. And Svelte is a new challenger which I really like but I'd try to avoid a lot of the SPA's as much as possible but when you have a page which clearly needs it you can drop it in. I hope we can somehow find a way to collapse the barriers a little more of SPA/SSR only and have 'sprinkles' of SPA when you need it for certain pages like large booking calendars or such. Maybe that's a silly and complex idea though.
But as you say if you were making a true 'appy app' today then that's an obvious SPA choice.
Instagram I'm very iffy on if that needs to truly be a SPA too, sounds like some Hotwire turbo-frames around some things could do the trick but I'm being arrogant here as I'm unsure.
> Vue can be used just like jQuery without any nodejs tooling
You can, but you probably shouldn’t (outside of prototyping). It requires you to both ship the template compiler to the client, and to perform the template compilation on the client, on every single page load (vs serving a cached, pre-compiled JS file).
If you want to sprinkle JS onto an otherwise server rendered page, you’re better off with something like Alpine.js [1]
82 comments
[ 3.9 ms ] story [ 154 ms ] threadInstall Node, run `npx create-react-app my-site` and you're all configured.
For example, on the reactjs.docs, https://reactjs.org/docs/create-a-new-react-app.html, create-react-app is simply one of four toolkits recommended, along with countless others in open source land.
There are folks who like to live on the bleeding edge, and for those using something else (or ejecting) might even make sense... maybe. But for any production app you should just use CRA, otherwise you will find yourself explaining to your new hire all the obscure choices you made a year or two ago. Believe me, I've been on the receiving end of these explanations and it sucks.
CRA has its place, certainly. But it is a black box, and somebody in your org should know the tools well enough to make good decisions to build up a product from scratch without CRA... and then you may still choose to use CRA, but it is an educated choice, not a default answer because you do not know any other options.
What is that one use case? What are the others that don't fit?
Yes, 100%, if you have more exotic requirements from a bundler or build toolchain then you'll need to look elsewhere and probably have to start learning tools like Webpack in more detail. I try and avoid those requirements.
Now I have a package/webpack/tsconfig files that I just re-use (and update as needed) between projects. I've never encountered a problem I couldn't solve. Sure now I need to manage the configuration of each project, but, I kid you not, my webpack.config.js file is 100 LoC total. This includes everything most projects probably need: Dev server setup and proxying, JS minification, JS bundling/code splitting, and SCSS/CSS transformation and purging.
I'm sure other projects have other needs, but it's really not that hard to understand these technologies.
And don't give me this "But all of that code is there to help you!" lecture. I've been deploying reasonably complex React apps since its inception, and have yet to encounter the kinds of edge cases to which the above sentiment is likely referring. Hey, maybe I'm just lucky...
I like CRA, it's my default go-to because i want to avoid maintaining a webpack configuration. If you have a solution that works for you, that's good too!
The build process of a modern React application has a certain amount of necessary complexity. Hiding it behind a "low-effort" build tool like CRA doesn't change the above and, frankly, is really a disservice to anyone who wants to understand the tools they are working with.
Go ahead, eject a CRA sometime. See how "low-effort" it really is...
I decided to try my hand at using CRA for the first (and last) time to build a small app at work because it had recently hit the scene, and appeared to be fast-becoming the idiomatic way of engaging with the library and ecosystem. I don't even remember why at this point anymore, but I had some issue that required me (as in the docs at the time said so) to eject the app. My jaw literally dropped after I saw what the project had become. It was... thousands of LoC. And spread across so many files!
Clearly we have different definitions of "too hard", but, to me, the task of understanding all of that was "too hard". I am simply not wired in a way such that I can use a tool without understanding how it works (obviously within reason). I have to imagine that when you say you "didn't want to maintain a webpack configuration" that you mustn't really understand what that entails, and are using the output from an ejected CRA as a proxy for what that configuration must look like. I assure you, it's rather simple. I've spent 20 minutes in the last 3 years doing so.
[0] I would estimate the kinds of apps that I build are far more complex than the vast majority of use-cases (think fantasy sports draft/league management software).
No.
The traditional approach was web 1.0, which was abandoned due to UX issues, not complexity.
Later on, the chaos of direct DOM manipulation by multiple javascript entry points became too much and was formalized into the SPA frameworks we see today.
An alternative solution is to go back to the true traditional approach & address the interactivity issues within that architecture (REST/HATEOAS).
The fact remains client side JS frameworks did not grow organically from the open source community. They had to be pushed into the dev mindspace by the mega-caps tech cos to offload processing power to the client. For the vast majority of companies (all but a handful), front end frameworks hold an org back.
I’ve had this unpopular opinion for several years, and have yet to meet/work with a startup who didn’t regret choosing Angular/React/etc.
Then there's the problem that the page could have changed since the user started filling out that form, what happens when those form values now conflict etc etc
The difference between serving a dead fish of a HTML page, and a SPA application is vast because you're essentially creating 2 independent systems, server and client instead of just server and then adding one of the hardest thing in computing which is consensus between disparate systems
I'm quite excited about React Server Components because it means for the majority of your web app you can return to the simplicity of shipping HTML it doesn't solve everything but at the moment client side applications have a lot of boilerplate to do with just keeping the server in sync that would have been historically "for free" in a server context
I'm loving it that the trend is starting to go back to rendering HTML from the server, then sprinkling on dynamic elements when desired. It's so much more efficient whether you're talking compute, developer time, or the ability to stay agile and change/add features as you learn about the market.
The idea that client side JS was pushed to offload processing power is a bit ridiculous. Do you have any evidence for that claim? Many React sites these days do SSR anyway (running the client-side code on the server) so it doesn't seem like they would save money doing that.
https://htmx.org
"Why should only <a> and <form> be able to make HTTP requests?"
Because of accessibility tools, especially screen readers.
This looks like yet another DSL that has to be learned, and does not appear to do anything to solve the UX issues of Web 1.0 that jQuery didn't. (I recall plenty of attempts to build frameworks on jQuery that relied on automagically parsing commands out of data-x attributes).
Additionally, you now need to know your server language's DSL, whereas the bigger tools all offer server side rendering via JS if that is your thing.
I am not saying it is bad, only that I don't think it is an answer for this thread.
Since htmx tries to fold in alongside the regular HTML concepts (which you need to know anyway) you need to know less, and your back end can be in whatever language you prefer. No javascript on the front end, no pressure to adopt it on the back end.
Accessibility is a concern, but, like everything else, has to be traded off against other concerns.
No, it really doesn't. It is mandated by law for at least some categories of websites, and opting to ignore it entirely (as the demo of HTMX apparently does) is extremely user hostile.
> All interactions are via HTML
HTMX is still javascript. Turn JS off, and you end up with a button that does nothing.
AJAX is also a DOM and JavaScript concept, not an HTML one. You need to account for error and loading states, or your users will have a bad time. That means embedding content in the document that isn't actually relevant to the state of the document.
It sounds more like a leaky abstraction that tries to pretend REST/HATEOAS is an HTML concept, when it is orthogonal... About as accurate to say that it is an XML or JSON concept.
The active search demo:
https://htmx.org/examples/active-search/
is another example that can degrade gracefully in the absence of javascript: wrap the input in a form and do the normal post-back for non-JS enabled clients.
With respect to REST & HATEOAS, note the first term in HATEOAS: Hypermedia as the Engine of Application State. HTML is the hypermedia that Fielding was describing in his dissertation. (XML and JSON are not hypermedias, so I'm not sure what you are getting at with that as a comparisong)
htmx tries to use HTML (a hypermedia) as the data interchange, thereby respecting the uniform interface of the original web model. No side state, no interpretation, no special knowledge: just exchanging hypermedia with a server. This is in keeping with the network model Fielding was describing in a way that a React client, for example, is not.
htmx tries to extend and complete HTML along the lines it was already going, before it stalled. Yes, it uses the tools available to do so, which are javascript, unfortunately.
https://htmx.org
I haven't invested the time into as I don't have a use case but I keep hearing about and now get the sense it isn't necessarily worth looking at until i have a needed case.
From my point of view, React and JavaScript improvements in later versions have made frontend development more tolerable and even interesting.
I love HN, but I would really be wary of taking too much front end type commentary seriously as it comes from HN comments.
Now sometimes the comments are GREAT, that's not to say it is all bad, but other times the comments on front end topics on HN is like walking into a meeting with a bunch of managers and non front end focused folks who got together to list their gripes ;) In those cases I often don't say anything because the ranting is on and nobody really cares.
Edit: This was longer but I decided I didn't want to go that far down the meta rabbit hole.
A good example of this is how many "back-end guys" here think it's Javascript and web tech that are hard/annoying instead of all client tech due to the nature of building user-facing software that has to run on a 1,000,000 devices instead of sysops-facing software that runs on one server.
Be wary of anyone who just peddles downsides without acknowledging trade-offs. They don't have much experience (You can have 20+ years of dev experience while inexplicably avoiding this sort of realization). Right now there's someone in the top thread saying they literally don't know a single company that didn't regret using Angular/React. Oh bother. This sort of person just has to ask, but they don't because they prefer to cling on to their little sneering world view.
If someone seriously can't say why anyone could prefer React (or any other tech, like JS or PHP or jQuery) without a cynical disparaging trait like these people are just idiots, simply write this person off and seek more even-keeled opinions about the world.
I think most people are happy or content with React - but honestly, it doesn't matter. Nearly every job listing I've seen or applied to asked for React experience (if the position asked for frontend skills). It's so ubiquitous in the coastal US tech industry that if you want to be a frontend dev, you're limiting your career choices by refusing to learn it.
Or if they love it.
The silent majority will just see it as a tool fit for certain jobs and not for others and wonder what all the fuss is about.
At first it seemed a bit complicated, but looking back at the stack I left behind in 2015 (LAMP, numerous JS libraries, Bootstrap, some Ruby was starting to creep in), it actually is a little more consolidated.
I guess I should bookmark my comment and check back in a year from now in case I am still using React and see how my thoughts change by then!
So, you should consider that there is some benefit which outweighs the complains
UPDATE: original line came out wrong. and was flat out incorrect
Whew can I get on the version of the internet you're on? Sounds nice.
Also, it makes webpages a pain to scrape, consumes more RAM and CPU, and recursive module dependencies can become a huge attack surface.
I don't have experience with all of these technologies but have been using React since its inception, and let me tell you, there is no amount of (reasonable) money that would make me want to go back to the times when jQuery the big new thing. It was awful! Procedurally manipulating the DOM! I mean, c'mon guys. Talk about a mess... Where are all of the FP evangelists when you need them?
And I know someone out there is bound to downvote me and respond with something like, "B b b but that one site where it downloaded 300kB of JS for a landing page! It's such a bad user experience!". Sure. That's precisely what I'm talking about /s.
The reality is that libraries like React are so popular because they make front-end web development not suck. You can actually reason about the behavior of your UI without first committing to memory a whole of bunch of procedural, ad-hoc `let el = document.getElementById('i-hate-myself')` nonsense.
I get it. It makes web pages a bit slower, and sometimes (maybe more often than that) get abused. That isn't fun for anyone. But level the critique at the idiots downloading a MB of JS to power a single dropdown, not the tool managing that dropdown's state.
That doesn't make them wrong when they say "hey this super simple site doesn't need to be in react" but at the same time it also misses the use case(s) for react and other frameworks when they rant on the topic more generally.
If all you need is a static site landing page that changes once a year, sure use something else, plain ol html, css, and JS will do wonders. But when you want to build an entire application and experienece for consumers, React is exceptional.
Web applications always have state and side effects, there's no escaping it. If you squint and tilt your head, ReactJS is like a pure function given the environment. React lets you model your view around your state and takes statefulness as a given and doesn't try to obfuscate it away.
As you say, its far easier to leverage FP ideas in a react application. Most react components can be pure. State can be modeled with all the fun FP tools and ideas. At the end of the day, React clearly delineates the stateful from the stateless and lets you easily model both relative to each other in a ergonomic manner.
The issue I had with React is that it forced a lot of mental models and API's on you to achieve UI = f(state) but after finding Svelte and spending 20 mins on the tutorial [0] I feel like I can say I 'get it' when it comes to building web apps.
Though the things you throw away when you decide to go all in on the SPA approach for your site is crazy, I hate not having access to my freaking database while building a page and having to create a ton of unnecessary code just to express a page that pulls in bits of data from my database. I do not want to complex myself with GraphQL. I much prefer the approach of dhh were we should only be paying that interactivity cost on the pages we need high fidelity on (which is probably going to be one or two pages you have for 80% of apps).
I think Hotwire looks promising where you mostly have logical split up sections of html that you want to be independently rendered across the page or on a click. When it comes to communicating and weaving state between those I'd be thinking about Svelte if it starts getting too complex.
Some examples of Hotwire I've seen so far https://twitter.com/tonysmdev/status/1355996616361205760 https://twitter.com/tonysmdev/status/1356460628819533824
[0] https://svelte.dev/tutorial/basics
I think it’s a bit different - they are so popular mostly because of the massive crowds of front end devs cargo culting static websites into SPAs.
And then maybe because of the many cases where they’re applied to replace jquery or a few js sprinkles with unnecessarily complicated SPAs. This is where stimulusjs + turbo or similar could solve the problem with 10% of the effort and complexity.
Then, maybe in third place or further, because there are more cases for SPAs than 10 or so years ago.
React does make front-end web dev not suck. It may not always be the right tool for end-users, but as a developer? C'mon. It's never been so ergonomic (and plain simple) to build a complex UI.
I googled stimulusjs[0] and you know what? From a development perspective it looks like it sucks compared to React. I'd rather just write vanilla JS than that hot garbage. Is the bundle smaller? Didn't bother to look, probably. Is it faster? Didn't bother to look, hopefully.
I get it! "Our job is to deliver value to the customer blah blah...". Engineering has costs as well. From training to velocity to, yeah I'll say it, developer happiness, you can't just ignore these costs. Working in a shitty, homegrown codebase using these niche libraries is a recipe for turnover.
On the other hand, if you are just whipping a some simple pages here and there that probably don't need to be looked at ever again... go for it! Your future self will cringe a little bit when you open up the source to change something simple years down the line (I know I have!), but at least those interactions are fleeting.
[0] I apologize for my crassness if you are somehow involved in the project.
Most interactions on the web are simple.
Tools like Gatsby use react to generate static websites. I’m sorry but that’s just insane.
The problem I’m speaking of is having a great slick well balanced hammer (react) which is a pleasure to work with and using it to put nails into (SPA-ize) everything in sight.
I’m not involved with stimulusjs or Hotwire apart from using them to create SPA-like experiences without much time, effort, or agony.
Basecamp use Hotwire for their cross platform hey email client - maybe take a look, it’s a pretty nice app.
There is a difference between using React and "SPA-izing" everything in sight. React is a library. It doesn't mandate an SPA as its use-case, and, frankly, I've had great success sprinkling React[0] into single pages that need that extra sparkle. Once you move beyond filtering a list or showing/hiding things, the pros quickly start to outweigh the cons.
Could some of those pages be made a bit more efficient or have a smaller download? Probably. But nobody notices and I am able to iterate on them quickly because they follow the same general structure as the bigger applications I've built.
To be clear, I'm not suggesting everyone use React for simple pages but criticizing the tool is a non-sequitur. You are kind of making my point above that all of this "modern JS is ruining the internet" criticism is being levied towards the wrong thing. Like you said, blame the bootcamps for churning out developers that know nothing else about how to develop a web page. Then blame industry for not training them the basics of their craft.
[0] Or preact (https://preactjs.com/). Which is way smaller (3kb)! At this size, it's crazy to use anything else. How big is jQuery again? 20 times that size?
I've got plenty of React & front-end experience and vastly prefer a thin library on top of the DOM than something like React, also for large applications. React is ok if all goes well, but when you have to debug or profile something, all the complexity behind the scenes occludes what you are looking for. Most of the time, people want JSX so you need a transpiler. Also keeping up with changes in new React releases seems like a lot of lost time.
I've been building [1] without a transpiler and just a 600 lines template library (see [2]), and it has been such a breath of fresh air. The fact that there is so little code between you and the browser makes it very easy to see what is going on. Call stacks of max around 15 frames.
It sounds like you are comparing React to jquery code without components, and I justed wanted to highlight that DOM APIs have evolved since those days, and that you don't need a library like React to structure your code.
React has popularized good ideas in front-end development, like components, but I think the complexity cost of a virtual DOM is often underestimated.
1: https://github.com/vector-im/hydrogen-web/ 2: https://github.com/vector-im/hydrogen-web/blob/master/src/pl...
The signature of a React application (and each component thereof) is simply `f(state) => HTML`. That isn't hard to understand, and the complexity behind the scenes is the complexity necessary to distill and optimize an application to the above. And to your point about JSX, yes, I do want that. I find it silly to write HTML using some other DSL. I have yet to find one that is anywhere near as transparent or ergonomic. How could there be?
I suppose I can agree profiling for the cause of undesired cycles could be easier, but, frankly, I rarely need to do so because I can simply reason about why a function/component is being invoked. The "flow" of a React application is well-defined (and rather simple). To your last point about structuring your code, you are probably right. Things have come quite far since jQuery in many respects, and I am sure that, if I were to try my had at it again, I would find it to be much more sane than 5-6 years ago. I just don't see why anyone would subject themselves to that though...
Kudos on your project! It looks great, and I'm sure provides the faculties important to you and your platform. I would be careful though. Given enough time and energy you may find, in the end, you have simply reinvented React!
I think VueJS is excellent and surprising to see React's popularity. Vue can be used just like jQuery without any nodejs tooling. Just like every discussion about this topic, React fanboys will respond with "But, technically, you can do that with React too" [1], yeah... It sucks at doing that. Without JSX, you can't interweave for example Jinja2 templates + React. Nor can you interweave JSX + Jinja2. With VueJS? It's just HTML with a few v- attributes. Even if React worked well with direct script tags in HTML, it still sucks at it because it's mainly designed for SPAs in mind. There is a lot of existing discussion on this topic [1].
I absolutely abhor the tooling/npm/babel/nodejs/webpack all this nonsense that Javascript frameworks need. They should be sort of like jQuery - no prebuilding steps - just drop and play. A doctors appointment website doesn't need to be an SPA. VueJS is the only framework that allows you to progressively enhance something like a Flask based website in the most natural jQuery-like way.
Oh btw, Svelte is yet another one - of course its SPA framework (Good luck trying to make it work on an MPA website). I am completely underwhelmed by Svelte, and ofcourse the JS peeps are flocking to it. :|
[1] https://news.ycombinator.com/item?id=24520116
Sorry if this doesnt make sense. I am mostly backend/servers.
Dude! I am, like, humble-bragging here. I did some react UI, and i had to painfully adjust to jsx to import some components.
My question is, since i have to oversee a new interactive trading front-end thingy, should i push for jsx or plain html?
Thank for the reply!
Edit: grammar
If you're using React, and you're not using JSX you're gonna have a bad time. There is no option to work with plain html.
Or you could just shift your backend expectations and adapt to the different needs. If you're doing an SPA because you want an app-like experience and very decisively not a website-like experience, your backend should be as simple and stupid as possible and not force you into a model like MVC; you shift much of the complexity to the frontend when you go from website to SPA. You know, like it would if you're writing a desktop app or a mobile app that uses an API. Because it's an application, not a website.
You could pull the 99.999% number out of wherever, but the truth is that many things we used to do as websites are better off as apps. My bank's website is better off as an app, the social networks I use work better as apps. Hacker news doesn't. Blogs don't. Online newspapers don't. It all depends on the amount of interactiveness needed and how much better the experience is with access to real-time information streaming and quick UI responses based on things other than data loads.
And as dreadful as Javascript dependency hell is, it's objectively better than Python dependency hell since it's had a passable package manager for much longer than Python (and even then, most Python devs still don't use or even know of Poetry) so the ecosystem is better aligned to modern software development expectations. You're just used to one variation of hell, and don't want to learn a new one.
Try to understand modern frontend needs before assuming newer frameworks are shit at everything and that everything related to it sucks. They might be shit at the specific thing you're doing, and some lessons seem to have been forgotten when things were redesigned.
What hasn't changed however, is how most software development sucks, and the fashionable things that were done under terrible standards (devs and/or management) have changed, but are still done by the same terrible standards so you still have shit results.
> VueJS is the only framework that allows you to progressively enhance something like a Flask based website in the most natural jQuery-like way.
No. You're just allergic to build tools because you have not enough knowledge of them. Probably because, from what I've been led to believe from your comment, most of your experience seems to be with Python. All your described problems ultimately stem from there.
Thanks for the counter, I have made previous attempts at App-like websites but have left me high and dry. There is something to be said about clarity and separation in MVC frameworks. I love MVC. I love boring tech.
Python dephell is no more after poetry. Have you used it?
Then again, I would say the same for Node. Modern npm is much better than it used to, yarn 1 is even better (better DX between its CLI design and handling of vendored yarn's), and yarn 2 was magical in the smaller examples where I tried it, eliminating the need for node_modules.
Back on the topic for the SPA problem, I would suggest you take a look at Elm, at least for the learning experience. The Elm compiler ships all the tools you really need to be productive, it's performant, the Elm language gets across the usefulness of its state management model extremely well (unlike React, which is a terrible teacher) and as a bonus it will ruin you forever if you haven't seen functional programming actually being useful before.
Node: I am not sure but so often do I come across a package that only works on a previous node version (say v10). How come Node is not backwards compatible? Node v14 should be able to run anything that runs on Node v10. This is a runtime, not some library. Also, I discovered recently about LTS and non-LTS versions of node. Who knew. The whole ecosystem is rickety and not up to standards IMO.
Do Reddit really need the UI = f(state) paradigm? Is there much of any complex cross component state sharing that an SPA would be valuable there?
Here is an example of Hotwire with Twitter https://twitter.com/tonysmdev/status/1355996616361205760
Twitter (and things like Instagram and TikTok) in particular is something where an SPA makes it easier to handle the different sections like the main feed, DMs, lists while keeping it responsive, but for those cases tools like LiveWire and Hotwire help make the gap between sites and SPAs much smaller and are an asset for avoiding having to rewrite websites into SPAs just for those smaller things.
But then you have cases like YouTube, where you could've argued that the initial case was a perfect fit for a website, and then as it has incorporated features like notifications, livestreaming with live chat, live donations with payment flows on top of the video and smaller things like the mini-player... you would end up with a huge amount of imperative JS sprinkled around your templates and carefully managed around your LiveView-equivalent's state updates; or you could just go with an SPA, vastly simplify your backend to be concerned on handling your data efficiently, and just having a frontend that makes managing complex state updates not-as-horrible.
It's trade-offs all the way down.
Also with the pace of SPA's at the moment its a risky bet 2015 React code is nothing like 2021 React code with hooks and functional components etc. And Svelte is a new challenger which I really like but I'd try to avoid a lot of the SPA's as much as possible but when you have a page which clearly needs it you can drop it in. I hope we can somehow find a way to collapse the barriers a little more of SPA/SSR only and have 'sprinkles' of SPA when you need it for certain pages like large booking calendars or such. Maybe that's a silly and complex idea though.
But as you say if you were making a true 'appy app' today then that's an obvious SPA choice.
Instagram I'm very iffy on if that needs to truly be a SPA too, sounds like some Hotwire turbo-frames around some things could do the trick but I'm being arrogant here as I'm unsure.
Trade offs everywhere.
You can, but you probably shouldn’t (outside of prototyping). It requires you to both ship the template compiler to the client, and to perform the template compilation on the client, on every single page load (vs serving a cached, pre-compiled JS file).
If you want to sprinkle JS onto an otherwise server rendered page, you’re better off with something like Alpine.js [1]
[1] https://github.com/alpinejs/alpine
https://imgur.com/9Pi1rBa