I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.
It's true that they are largely more complex than O.G. web technologies, and it worries me that they create a sort of gatekeeping effect on the industry, but I think it's disingenuous to outright claim React & co. are bad from a development perspective. I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
I've done lots of native development on Desktop and Mobile and I can sort of see how you get there if that's your point of reference, but if you work on web apps daily it's clear why the popular technologies are popular, and it's not hype.
For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the solutions don’t work very well means they’re constantly being reinvented, which means if you do the work to keep up with it all you’re rewarded by being regarded as an expert, which is nice.
Lastly, I wouldn’t underestimate how this has built up slowly over time, and therefore how many people just don’t know any better.
Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing react libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done.
At the end of that session this developer said to me, “wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.”
This is a good, very productive, very fast-learning developer I’m talking about. He literally had never tried to use the DOM api, and didn’t realize it was, you know, useful.
I think there’s a lot of that in front end world today.
This is what I meant by gatekeeping; there is common misconception that you have to go looking for a library to solve a problem. And it makes it seem like there's a higher barrier to entry than there is.
But the reality is that React is plain HTML and Javascript, in a less error-prone and maintainable package.
Everything you can do with vanilla JS you can do in React, but with React you benefit from being forced to separate the state of the DOM from manipulating it.
I don't buy the hipster-centric logic, for me it comes down to productivity. The bugs of yesteryear, tracking down which procedural code path led to modifying a variable, are mostly gone with React. And if you don't use it (or something like it), you end up implementing a subset of it anyway because it's a foundational part of coordinating UI with business logic. /shrug
As a sibling comment notes, and as I noted in a reply to the OP, I agree with you that working with components is a nice approach and very useful. Using React as you describe is perfectly fine. The SPA craze where everything has to be done via React components is where we've jumped the shark IMO.
That's fair. I have an app that is rendered server side (Node.js/Express) and the frontend is built with jQuery. Made sense at the time. But I ended up adding two very interactive modules and decided React was best for them and added it in piecemeal, and I was right. But now trying to integrate the new features with the older ones, I wish I started with React for everything. This happens more frequently than I'd like and it's why I'm skeptical of saying SPA's are bad. To me they make my life easier and are very flexible.
Currently the site I'm building is a pretty static site of about 30-50 pages that is just brochureware for a non-profit scientific organization, on one hand I feel sort of embarrassed because it feels like I'm back in 2004 and I have a hard time justifying my salary for something like this, on the other hand I'm really super embarrassed at making the wrong solution because a React SPA with a service worker has been ordained as the way to make this thing.
Gatsby (static-site generator powered by React) was a massive timesaver for me. Sure, you spend a bit longer setting up some basic components, but the trivial ability to share those components between pages more than makes up for it...
Yes of course I want Gatsby, but that is one of the things I'm not being allowed to do. I think I may have gotten overly sensitive these years to not getting my way on architecture.
Doing things with react is mutually exclusive with SPAs. You could even do a purely server-rendered website using react on the server if you wanted to, and all the benefits of functional component design can still be utilized.
You probably meant "orthogonal" (a smarter-sounding way of saying "perpendicular", in the sense of "linearly independent"). A framework made and used primarily for doing SPAs can't be "mutually exclusive" with doing SPAs.
But setting the wrong state is someting that happens far less and is much more traceable, because the encapsulation of state changes into a single place massively reduces the side effects (and global state) that were the cause of 90% of those bugs in the bad old days.
A lot things can be easier if you do things the "wrong way". App development can be faster if you don't use Typescript, liberally use the "any" type, or just avoid. Most of recent javascript tech like React, Redux, Typescript, et all, came to reign in the multi-paradigm language that is Javascript so that larger organizations can actually make maintainable error free code from a language and ecosystem that is very easy to shoot yourself in the foot in from junior developers.
Sure, you just do some javascript and HTML to get your thing working quickly, but that hasn't even been recommended since the days of Jquery (where it was recommended over just doing vanilla JS in order to maintain cross-browser compatibility).
It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable, and that's before even considering things like browser compatibility, accessibility concerns, localization/internationalization, etc. A simple app or product does not mean the internals are necessarily simple.
> A lot things can be easier if you do things the "wrong way".
> It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable...
I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to full-on SPA.
When presented with most spectrums of choice like this, it's expected that most people will weigh in requirements first and choose the solution based on the requirements (if they are an engineer, or pretending to be one.) In terms of expertise, they might love to write SPAs, but they realize that the other options on the spectrum exist for reasons other than being in, or out of fashion.
The problem is that some folks overemphasize what's in fashion. There are many reasons for this, and it's something that happens across other disciplines, not just programming. That said, we have a unique situation with programming in that someone can be quite an expert while only understanding one end of the spectrum. It's very easy for these folks to hold sway.
When it comes to the "wrong way", I agree with you, but I'd go further. If the requirements demand a SPA then you need to go all in and use the best modern tools. There are a lot of things created as we moved out of the full page render ages which don't result in good SPA development (for users or devs.) Embrace Typescript, React, etc because these solutions have evolved from that in-between stage.
Using "browser compatibility, accessibility concerns, localization/internationalization" isn't a great argument here. These are often orthogonal requirement. It's easy to argue that full page rendering, or static HTML meets all these more easily. These apps can't compete if you need particular interactive experiences.
I did address that it depends on your requirements. But my point is that it is highly unlikely that any requirements would be better served by vanilla JS + html than say writing your code with ES Next or React, unless you truly have some sort of limited use one-off thing.
Tools like webpack, babel, and react are also orthogonal to whether or not you're doing an SPA. These new tools aren't just to make your app a SPA, but are meant to decouple the maintainability of your code from the implementation details. React itself isn't even a framework but a paradigm which just happens to have a specific implementation that requires their runtime. The most recent shift is to turn your components into pure functions, and this is less about the framework and more about decoupling your app rendering logic from the react implementation. There's no objective argument that writing vanilla JS is better than writing modern ES next code. These language improvements are done to improve the failings of the javascript language after all.
You can totally use React to purely statically render your website. This is what most SSR implementations do, and the only reason JS is still activated is most modern apps require interactivity.
If you start doing vanilla JS and HTML you're doing a direct implementation. That's almost always the wrong way just because of browser differences between operating systems, mobile vs desktop, and all the other features that aren't really bells and whistles but more and more necessary as technology serves a bigger role. Perhaps in 1990 it's fine that a website can be made for a specific user for a specific purpose.
I have been working with various SPA frameworks for about 5 years now, from the bad old days of AngularJS to mostly React nowadays.
Your comment about 1990 seriously rubs me the wrong way because it seems to imply React et al. actually does something to address the points you make. It does not, at all. You still need to test your code on every viewport you support. And now you have to deal with an insane build process that rivals some C++ projects while doing it.
And there is absolutely an objective argument that staying close to the web platform is preferable than 200 layers of leaky abstraction and a 10MB uncompressed bundle of transpiled JS. The language itself is pretty okay in 2020, certainly not worse than anything else from the TIOBE top 10. I would definitely say writing a bunch of plain JavaScript is all that’s needed for most applications out there. If you can’t manage that without a frontend framework, the problem is certainly not with the platform or language.
Yes you still have to test your app on different platforms and browsers, but the point of the build process is that they make them work on those various platforms, whereas before you would have to manually fix those failed tests and hack in fixes for obscure conditions. That's what frameworks and libraries are for. They've abstracted away things so you can focus on higher level things. Tests are always going to be required, even if your framework and libraries are perfect.
We don't need to stay close to the platform because abstractions allow for more advanced applications. That's why most web apps don't use C, and should never use C, because 99% of the coding work is higher level tasks that don't need the bare-metal performance optimizations.
> Tools like webpack, babel [...] but are meant to decouple the maintainability of your code from the implementation details.
Let's be real, the only reason we really need WebPack and Babel at this point is for IE11 compatibility and JSX.
Currently >90% of the browsers (that depends on the country) are evergreen, and have support for most ES6 features, including ES6 modules. As soon as we're able to drop IE11 (when will Google remove IE11 support from Youtube?), the only reason to keep those tools will be JSX, which is frankly a minor convenience compared to the rest of React, and there are multiple alternatives to it that are not that terrible. [2]
Apart from that, WebPack and Babel are extremely hit-and-miss and terrible slow for anything but small-ish projects.
If you're doing SaaS or enterprise, chances are most of your customer-base is already 99.9% on Chrome or, in the worst case, in enterprise Windows-centric companies, Edge and that 0.01% is just waiting for something to tip them off.
I really can't wait to get rid of those two shitshows. Or maybe replace them with something actually useful, like Typescript compiled directly to modules.
Babel is there so you can write your code with the latest Javascript features and separate your written code from what is actually deployed. JSX and IE11 are a subset of problems that this type of abstraction can solve.
This is miles better than the previous alternative: manually importing shims or adding in css prefixes. Babel and webpack also enable macros and static code analysis tools so you can write code in "inefficient" ways that's more readable, and automatically generate more performant code automatically.
Browsers are still split, even if considering only desktop users. If you add in mobile users then all those iOS people are using Safari, not Chrome.
And because of this fragmentation you can't expect the latest ES features to be usable on day one. So you'll always want Babel so you can write the code the way you want, and have platform targeting be a separate concern.
It sounds like you believe that we should be writing very platform specific code for the web, which is a bad practice in general. Nobody should write platform specific code. Leave that to the compiler.
Nope. You're the one advocating targeting a specific platform, and it's called Babel.
What I'm advocating is targeting evergreen browsers whenever possible: Chrome, Safari, Firefox, Edge, and their forks. They already have most ES6 features. Even Safari has great ES6 support. iOS is known for being very up to date. Fragmentation in Javascript is a thing of the past, as long as you only use features available for +90% of the people on caniuse.com.
If you're targeting evergreen browsers you can already write the latest Javascript, and would only need Babel for something like JSX. All those browsers have async/await, ES6 modules (aka import), arrow functions, and destructuring.
To separate your written code from what is actually deployed is much more of a con than a pro. I'd rather not need a compilation step if possible. My time is valuable. Babel and Webpack are slow as a dog for non-toy projects.
Manually importing shims are a thing of the past when you're targeting evergreen browsers. You can use something like Polyfill.io for edge cases, and it will cover the small number of
CSS prefixes have nothing to do with Babel or Webpack, they're normally handled by tools like PostCSS. Nothing to do with Javascript. Static Analysis is normally handled by tools like ESLint that can use Babel but can be completely decoupled from the compilation step. Or Typescript, which actually brings a lot to the table compared to Babel.
Again, this might be hard: maybe you need to handle customers with IE11. But to not need Babel is something we should aim for.
I honestly can't wait for Babel to be 100% unnecessary and to die. It is valuable in a world where Internet Explorer exists, but there is zero advantage in using it when it's unnecessary.
> than say writing your code with ES Next or React
Say again? One is a framework, the other is an updated version of the language that can be transpiled to ES3 for (non-mathematically) provably identical results.
React isn't a framework. It's a library for writing functional components which can, at the moment, target native mobile components and HTML components so that you are not writing the components manually in a platform specific way.
Having done some old Skool desktop dev recently I can't shake the feeling that modern web development is mostly just trying to reinvent wheels that have mostly been sorted for 20+ years.
I guess it's understandable though, the web was never really designed with its current use-case in mind.
People do so love forcing square pegs into round holes though.
>If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most
I see this everywhere in programming, not just frontend. I think this silent peer pressure influences us all to some degree. Whether through not wanting to look outdated or foolish, to just being tired of the uphill battle involved constantly fighting against the unstoppable momentum of the cargo cult.
What a great anecdote. It aligns with my big worry here: we are raising a cohort of front-end developers who don't know how to use plain HTML and forms!
> That's what the C devs said about all the people learning Java.
That's not a great argument here. Web development is much more of a continuous spectrum. Programming platforms are designed to hide the the layers beneath to a large degree. I'm not saying there aren't leaky abstractions!
We use the term "full stack" for web developers, but people visualize this with layers, but for me it's a really wide list of items and not a very tall stack.
> but for me it's a really wide list of items and not a very tall stack.
That is fair. You need a bit of many technologies to launch a website. I always interpreted full-stack to mean that you could launch a site on your own, from the database to the buttons and thus do not require a dedicated frontend, backend, or dba.
Coming back to C++ after a decade of Python I realised I had largely forgotten about how memory management works and that felt bad. I felt stupid, because not thinking about that wasn't necessarily a good thing.
I meant to constrain my comment to the web development sphere. Niche cases mean some scenarios where bandwidth limitations prevent the use of React or something.
Although you can use React for mobile (Native) and desktop (Electron)
I want to hear a war story of someone starting from a React bug report, reducing it to pure JS, fighting through the Chrome build process, isolating the v8 JIT bug, producing a patch, and going on to a successful compiler career.
Heh, I could almost tell that story. We had a bug in a React app that started when a new Chrome release came out. I boiled it down to a small piece of JS that V8 was clearly misinterpreting and which looked like it might be memory corruption in the JITed code. Yep, I got a Chrome build going and was tracing through to see what was going on ...
... but I'd also submitted the JS fragment to Chrome, of course. They ended up flagging it as a high security bug and, not surprisingly, beat me to a fix.
So I never got as far as making a patch, which I guess is why I still don't have a successful compiler career.
I did get a $1k security bounty from Google, though, so that was cool.
And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.
It literally doesn't. You can build a fully normal HTML form in react. The only reason to do any of it yourself is because you need something regular forms can't provide and even then you can still use as little or as much custom parts yourself.
It literally does, unless you have the form POST or GET to an API directly + a redirect from the API.
You have to override the submit functionality which is built-in by the browser. You have to maintain state of what the user inputs, which the browser handles for you. You have to reset inputs, which the browser handles for you (button type=reset). And a ton of people forget to actually validate on the server because they validate on the client.
You do have to override the submit functionality if you don't want to load a new page, sure, but that was always the case with plain Javascript or jQuery or whatever.
You don't have to maintain the state of what the user inputs if you leave the inputs as uncontrolled (https://reactjs.org/docs/uncontrolled-components.html) and access their value via a ref. You could even give them IDs and access their value directly via that if you wanted to, just like you would pre-React. But there are clearly advantages to making the inputs controlled by React, otherwise there'd be no reason to bother doing so (not saying that there aren't probaly a lot of cases where you could keep it simpler but people have been led to believe they need to put their form data in Redux so use some elaborate solution which doesn't scale, or whatever).
Also if you are doing forms in React, check out formik, it's the nicest library I've found so far. Granted it's not as "easy" as a straight HTML form that POSTs to a new page, of course, but modern web experiences often demand richer functionality than "the old way" allows.
Also, per the form libraries question: Formik and React Final Form are the two standard packages I suggest folks look at. React Hook Form seems to be gaining some popularity. Also, I recently ran across https://github.com/wsmd/react-use-form-state and tried it in one of my own projects, and was pretty impressed with it as a lightweight option.
It's sad how convoluted something as simple as form submission has become with "modern" Javascript frameworks. I'm not sure if it is React's fault, or the way most people use it, but it does seem to degrade into a mess of over-complexity. (I've been working on web sites since CGI scripts were a thing.)
Its as simple or as complex as you make it, you can use react to render a perfectly plain html form or you can manage it totally in react. And honestly, once you have everything set up and some previous examples, managing and submitting forms in react is trivial as well.
> And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.
Show me the HTML standard that supports SPA submissions that don't reload the page.
It seems that your problem is about SPAs, not React.
That was a thing even before AJAX came along, eg via forms targetting an iframe.
A long time ago, I wrote a single-page chat application that continuously updated through chunked transfers, with submission via a plain old HTML form that received a 204 response.
IMO, it's kinda hard not to end up learning those things even if you are in react all day.
At one point or another things don't work and it's because of simple HTML... and not react.
Maybe that's not the right path to learn it but we've reached a point where if you want a job, plain HTML and JavaScript isn't it.... plenty of folks who had the benefit of developing their skills from HTML + JS all the way up will bemoan this situation.... but if they're hiring people they're not hiring anyone who just knows HTML and JavaScript without any exposure to anything else.
> If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most.
It sounds like you're reinforcing this divide by classifying people who have a different opinion to you as "hipsters."
They label your technology choice as outdated, and you label them as hipsters. You become the thing you fight.
The problem with using some shiny new library/software/app/technology is, that it might dissapear in a year. The developers will move on to new companies, and work with some new shiny tech, and all your codebase will be useless due to a unmaintained library and no new people (developers) who know how to use it.
I wanted to make an example that it was like starting work at a company, and seeing that they're still using phpBB (but with a 1 year old library)... but it seems phpBB is still being developed...
>“wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.”
Wow. These two sentences completely capture modern day Web Development, Javascript as assembly.
>I think there’s a lot of that in front end world today.
In modern Web development, ( and in possibly all area of software development ), instead of making things simpler ( not easier ), it seems we have been building premature abstraction after abstraction.
> Also the fact that the solutions don’t work very well means they’re constantly being reinvented, which means if you do the work to keep up with it all you’re rewarded by being regarded as an expert, which is nice.
This is a huge assumption. For example, I don't think any web dev enjoys wrangling with CSS positioning or workarounds because they want to be "rewarded by keeping up".
> Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing React libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done.
I don't know what your feature is. But any decent web dev today has to think of multiple angles that are not present in non-frontend development
- Responsiveness
- Browser support
- Accessibility
- Internationalization
That is in addition to testing, error logging, analytics, etc. We haven't even gone to the business logic yet.
Many people underestimate how much work a good web app entails
The senior engineer could have just as easily wrote worse code.
Just some weird obscure Javascript floating around editing the DOM directly causing untraceable errors in the future.
React helps with lots of things;
- Testability
- Readability
- Less side effects
- Documentation
- Rendering
- Error Protection
I could rattle on forever, might be time to write a blog post, gets a bit tiring reading the HN users who think we've just made the frontend complex for fun.
Frontend development is HARD, factors include;
- Plethora of device models/sizes
- Latency / Async / Fetching (data)
- Rendering speeds based off how you coded it
- State Management / Cache Freshness / LocalStorage
- Server Side Rendering
- Code Bundling (js and css)
- Design / Transitions / UX / UI
etc
Now why is all this important? Because to be a competitive app, it simply has to be sexy and slick.
If I could do that with one style tag and one script tag, I would.
1) CSS works great, and while it continues to incrementally improve, has been fairly stable since its introduction. What I meant about "solutions" that don't work well are things like React state which has gone from "not a thing" to "redux" to "redux is an antipattern" to "redux is moot because now graphql" which oh BTW means you now need a whole new API? Ok. That framework churn is because those problems are actually difficult, and to date there's no "one true way" that is pretty straightforward and covers 90% of cases pretty well. By contrast, things like "how to set up a webserver that handles HTTP requests" are easier and already well-solved in every serious language, and thus not so subject to the same degree of churn.
2) All those concerns were present in the project I worked with said developer on, and were easy to handle with the basic tools of the browser.
> I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting.
Yes. And its important to remember that React is heavily marketed to developers by Facebook, just as MS does with Typescript, and Google does with Angular. The point of this marketing is to create a feeling that these technologies are "safe" and "standard". Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising.
That said, there are a few major functionality gaps in native JS that leave the door open for front end libs. The biggest one is some kind of sane support for templating, and the second big one is that async is too complicated (people who actually understand callbacks and Promises often dont realize how many devs dont understand them). Facebook, via React, provides solutions to these problems, and leverages them to get users to buy into the React ecosystem.
If somebody could show how to make a component in JS that could be included in a page as an HTML tag, and could talk to other components on the page then the need for React would just evaporate.
> Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising.
Of course. Most devshops don't have the manpower that FB/Google/MS have. You don't really have months to tinker around and create some new framework and then another 2x months to fix bugs and add new features to cover some edge cases. So you pick whatever is backed by a lot of manpower as it has the highest chance of being usable even 3 years from now.
WASM is entirely different from Svelte/React. WASM is a compilation target for native-code languages, and can't interact with the DOM except through JS shims.
About your junior dev it might also be the way he was taught React.
I'm also a junior and the way I was introduced to React was by teaching me enough JS that I could theoretically write React (with a bunch of research).
One of the things I've noticed among other junior engineers (including myself) is tutorial driven development. Through a mixture of inexperience, laziness, and self doubt it can be easier to find someone else who's implemented something and just use theirs. Rather then thinking about a complex problem and naively coding up a solution finding someone else's hopefully battle tested code.
An example of this is how I used to make JS based games. I essentially used an array to toggle classes on a grid of divs divs in the style of an LCD screen. I hadn't heard of html's canvas element. My solution worked but I don't think anyone would think it's a particularly good one. If I had found someone's snake game and saw they used canvas I could have saved myself some headache.
I remember when jQuery was the React of its day. Then browsers copied most of its stuff. And now we have moved in to Angular and React.
Frankly, web components can do most of the stuff React does - and even the JSX can be done with eval and concatenating some backticks to strings. As long as you are SURE the strings are coming from templates, they can be assigned at runtime similar to how React assigns at compile time. Not that you should do any of that crap!
Still, React and Angular are insane. React makes you use Babel for JSX and a bunch of esoteric rules that they then make workarounds for, such as “hooks”. And Angular is even more complex, with its digest cycles and mocks and bindings etc. It totally sucks you in.
If you want to use a framework that’s much more lightweight, use Vue. Or use the one that we built ;-) It treats CSS, HTML and JS — and the rest of the Web - exactly as it was meant to be, and doesn’t try to reinvent the well. Well, it does use Handlebars for templating, but can support any other one also.
to me, though, javascript development has always felt like a chaotic tangle of duct tape, until I started working in React. somehow React feels like _writing software_ - building things in small pieces with well-defined inputs and outputs.
And JSX feels like the programming style that I didn’t know I was I’ve been missing since the 1990s - like it’s the logical conclusion for working in HTML, when everything else was either doing sloppy string manipulation or really indirect object-graph walking.
I don’t love babel, but we have a hot-reload script that auto-compiles while I’m working and even swaps in components to my webpage without a reload! It’s actually _less_ friction than vanilla javascript. I cannot imagine going back.
I hope eventually some of these technologies get pushed into the browser, but honestly it doesn’t matter much - javascript is fast, we can afford to use it as a compile target
IMHO the framework makes way more sense than React in that it is a lot simpler to reason about, and it also treats HTML CSS and JS sensibly. React is a bit esoteric... but it has the backing of a large company so everyone uses it. It’s a bit like Wordpress is used by everyone despite its codebase being from 2004. Like it’s OK, I get it, you have to buy into the ecosystem. But I think one day it will be replaced by something cleaner.
At work, I've been forced to use angular. It's just awfully complicated, breaks subtly, changes (not improves) constantly and has sucked in hundreds of developer hours that could have been better utilized.
I was appalled at the state of things in front end development till I realized my current project uses kubernetes (implies docker, helm), spring for implementing REST endpoints and ansible for deployments on the back end.
I disagree. Do you remember the days when J2EE was the hot stuff? Popularity comes and goes and is not necessarily correlated with whether something is a good idea or not.
Over the last 15-20 years or so as a web development shop we've gone through Prototype, Jquery, Backbone, Angular, Vue and now React for JS frameworks. We've mostly settled on React lately. Our experience is however that it is wildly overused where it is not needed and adds significant time to development. Features that should take a week to build now suddenly have complex client side state management requirements (to name one issue) and take several weeks. We've seen this in several projects while working alongside experienced developers.
We do use React extensively and we find the sweet spot is in smaller components on a page, or highly interactive sections, things without lots of shared state, but it often seems like web developers have one hammer and it is not the right one.
> Features that should take a week to build now suddenly have complex client side state management requirements (to name one issue)
This sounds like bad system design rather than a problem of React.
In general, I find React hate massively overblown. The problem seems mostly to be that everyone is using it, and "everyone" in the case of frontend devs is all over the place in terms of how they got there, what they know to do, and what they know not to do. If you're not careful, all of the JS ecosystem can give you a lot of rope to hang yourself with. The relative accessibility of webdev is a blessing and a curse.
This sounds a lot like the days in web dev before Ruby on Rails came along.
When they (and django) took the web dev world by storm they were prescriptive and told developers how to do something, not just giving them a bunch of tools where you had to build your own app lifecycle, usually massively over-engineered. A whole load of mental overhead disappeared.
Just before Rails, etc. everyone was going on about Factories and the Gang of Four and people were building crazy startup patterns on their webapps using Singletons.
I really like Svelte because of what you are describing. It feels almost like writing normal JS/CSS/Html but you get access to some QoL features that make writing JS easier
It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.
As a user and developer myself, that's the sort of selfish attitude that really really angers your users.
I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
I've worked on "complex"[1] websites in PHP, all static/server-side rendered; zero need of JS, near instant load times, ultra low bandwidth and server CPU utilisation, and don't even need to think about "browser support" because it'll be usable with anything from the past two decades.
[1] complexity in terms of features and usefulness, not in terms of how much code and resources it needs. Unfortunately a lot of developers seem to think complexity as in the latter is a good thing.
XHR was invented because without it, Microsoft couldn't make a web-based email client that behaved the way users expected an email client to behave. 20 years ago. I'm not sure you can reasonably claim this stuff is not also strongly driven by the expectations of users and and the desire to meet those expectations.
I'd like to know which users desired a web-based e-mail client 20 years ago. It is my impression that this kind of software is very much push, not pull - i.e. the idea comes from the vendor, not from customers expressing a demand. Which is not a bad thing in itself (a big part of progress is speculative creation); I just don't like the unspoken assumption that companies do things because customers want them to, it's not always true (almost never in B2C).
Many of us only used it because it was free/available for everyone and we were students or stuck in another situation were it was the only option. If there was both a webmail interface and imap we chose imap.
Some of us still to this day prefer imap/jmap/exchange if the server support it in a meaningful way.
those crazy users, not wanting to install, configure and update software, download their emails and make sure their backups work, and just get on with actually reading their emails on whatever computer they wanted
Those crazy users who then cry, "what do you mean I've lost 10 years of e-mails forever, becuase my daugher commented with an emoji on a YouTube livestream, and Google decided to go nuclear everything associated with that account?".
Cloud services aren't more reliable than owning your data. They're just unreliable in a different way. You need backups anyway.
I'm of course referring to the Markiplier drama of last year, where a streamer asked people to vote on his stream by typing in red/green emojis. This resulted in hundreds of people losing their Google accounts due to an oversensitive spam filter. The matter fortunately got sorted out (somewhat, not all accounts were unbanned), but essentially only because it involved a fairly well-known youtuber.
And random automated bans (which happen on all big social networks) are only one fairly common failure mode of cloud services. Smaller services shut down or get acquired, taking your data with them, or they just shutter the products you depended on (and even if you can export data, there often isn't anything you can import that data back into). Governments may randomly make whole populations lose access to service (c.f. Adobe's Creative Suite and trade sanctions on Venezuela, earlier this year). And, of course, no Internet access = no access to service = no access to data.
In general, owning your data makes you vulnerable to physical world problems - floods, fires, etc. Using cloud services makes you vulnerable to relationships between you and third parties, as well as between these third parties themselves.
Server side email has the failure mode of the company going broke or banning you. Client side email has failure modes like destruction of device (house fire, flood, other accidents) or even just obsoleting of OS/app. Neither is inherently superior to the other.
In the particular case of the emoji ban, the problem is that the FTC should never have allowed one company to control search AND email AND school document sharing AND maps/reviews AND video AND mobile phones, etc. If you don't use Google for your email, there's no danger of Google banning you from it. :-) More seriously, Google (and Amazon and Facebook and Microsoft+Github) needs to be broken up to protect consumers from one company having a chokehold on their digital lives.
Perhaps the SPA pattern, for all the justifications from developers (and yes, of course there are genuine cases where it's a good fit) is really an outcome of Conway's Law[1] in action. In a large enough organization, you corral your dev teams into isolated, specialist "backend" and "frontend" groups which end up communicating largely through decoupled APIs. As with microservices, it's not really about whether this is the most efficient and user-friendly approach to delivering useful apps to the end users, but how much this architecture mirrors your company's org chart.
As others said, user != customer. A big chunk of software (perhaps the majority) is bought by someone other than the end-user. Think workplace, or all the OEM garbage that ships with your phone.
On top of that, on the mass market, customers don't have a meanigful choice. They can't signal desires in the entirety of concept space; they choose out of what's available on the market. Which means the choice really lies with the vendors.
And they do, even if it's not a conscious decision. Most large scale experiments see bounce rate increase and revenue decrease with page load time. More load time because "it's easier to develop this way and it saves developer time, which is expensive" means more bounces and less sales.
Of course, that only matters at scale. If your site never takes off, optimizing for user experience (instead of developer experience) wouldn't have paid off. On the other hand, maybe putting your users second lowers the chance of it being well received.
This (and related phenomenon with subscriptions) is arguably a big drive for the software becoming increasingly infantilized; shiny toys instead of useful tools.
I don't agree. A classic PHP-as-it-was-used-15-years-ago site either loads or fails for every user request. That isn't good enough any more. An SPA either loads or fails for the first request, but then they do a lot of things that can mitigate a patchy internet connection - prefetching content, offline mode, bundling things to reduce the number requests, etc. A server-side rendered app doesn't take advantage of those optimisations, although things like rel="prefetch" are starting to get used more which helps a lot.
Like the article suggests, there's definitely some middle ground where enough of the site is loaded on the first request for it to work, and then more things can happen in the background to make subsequent interactions faster and more reliable. That isn't a pure SPA and it isn't a pure SSR site either.
Very few SPAs give proper user feedback. There could be any number of silent errors in the background.
It's even evident for relatively basic things such as infinite scroll. Users on sketchy connections won't even see all the items in a web store if their mobile connection is sketchy enough, and they will never even know it.
There are some real costs here. Had anyone seriously A/B tested these things they wouldn't be so widespread.
Very few SPAs give proper user feedback. There could be any number of silent errors in the background.
Badly built apps that ignore errors and don't work well for users are certainly not limited to SPAs, and blaming SPA tech for that seems a bit unreasonable.
For "classical" websites, it was not possible to screw it up. The feeback was always there - clear, unmistakable, universal across sites. Boom, "No Internet", site's gone. Press "back" to get the previous state and click again/resubmit later. And it was nice that you could actually do that - use the "back" button to revert to the last correct state even without an Internet connection. Can't do that with almost any SPA these days.
I suppose it just boils down to the fact that with more freedom comes more freedom to fuck things up. But when you see an industry systematically fucking things up, and being driven by economic incentives that encourage fucking things up, one has to wonder whether some of those freedoms should be taken away.
The feeback was always there - clear, unmistakable, universal across sites.
It wasn't clear for lots of users. There were common stories of people getting a connection error and refreshing a page only to find their order on an ecommerce site had been taken twice, or that a comment they'd made had been submitted a second time, or that a request to delete something had actually worked but the second request threw up an error because it couldn't be deleted again so it looked like it had failed. These aren't so much of an issue today because browsers warn about form resubmission, but let's not forget that server-side rendered websites in the past were absolutely riddled with UX problems and bugs.
That's not a defence of SPAs, far too many still get the basics wrong, but if you believe it was better when devs made "classical" sites I think there's some decidedly rose-tinted nostalgia going on.
> I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
I have a 20 year history of building websites, and a recent three year stint of building front-end applications professionally using mostly React, which I'm now proficient in. I also normally use a strict whitelisting policy for Javascript using NoScript. If it's not a tool that depends on it that I really want to use, or if I find no obvious reason for it to be using Javascript, websites don't get added to the whitelist.
Javascript, as far as I'm concerned, is a wide open vector for an ongoing large scale attack on my privacy. Not only that, but I also have to pay for it in battery life and memory. The occasional blog built in React without a static fallback will usually go unread on my end, and no one is losing sleep over it.
I also think that you are fundamentally missing the point of the article if you your experiences building native applications vs building web applications is supposed to offer a counterargument. It's a false dichotomy in this case; the blog was never a native desktop app. The marketing site was never a native desktop app. They're collections of documents and I have no idea how anyone could come to believe that arranging that using a framework designed to facilitate reactive web applications is easier than just delivering the documents using technology designed to do so.
If you mean to equate wearing tinfoil hats with employing a blacklist-by-default Javascript policy I'd gladly hear your reasoning. I'm sure it would help others not confuse your point with vapid shitposting, as well.
Yes, that's what I'm equating it with. I think it's a fair analogy. Disabling Javascript isn't enough to 'protect your privacy', and even if it was, I haven't heard of any tangible impact that would have on anyone's life.
Okay, taking Facebook as an example. Let's say you visit a random website and get tracked by a Facebook Pixel (which happens to be an image, not JavaScript), what happens then? You see behaviourally-targeted advertisements on Facebook and partner destinations, instead of generically-targeted advertisements. I don't agree with the assertion that this has a materially negative impact on anyone's privacy or life as a whole.
I understand that this is an unpopular opinion, but it's what I believe.
> I don't agree with the assertion that this has a materially negative impact on anyone's privacy or life as a whole.
I haven't asserted that it has any negative impact. To say that it has no tangible impact (as you have) is decidedly wrong. Either the manipulation is working at a grand scale (which is scary in its own right), or people that invest that much money in targeted ads are idiots buying snake oil. Regardless, Facebook and Google now command huge social and political influence, and they're entirely in the business of using my private information to sell ads.
I guess wanting to be the constant target of increasingly direct attempts at manipulation is a matter of personal preference, but the fact that it has an obvious material impact on the world is not.
I spent several months with JS off by default. I relented after one too many broken sites. Since then, I've suffered from sites with HTML popups, autoplaying videos, and not one, but two "subscribe to my newsletter" prompts which trigger when you move your mouse to the address bar.
Disabling JS by default severely reduces the ability of websites to pull user-hostile tricks (though it breaks web apps). No website (presenting static information to be consumed) should ever break with JS off, and any site that does is defective. I won't extend this to web apps (interactive dynamic functionality like Google Docs) though.
> I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
So, this is the kind of thing I make for my employer. But guess what? I can still do things the way I did them back when I learned Rails over a decade ago: HTML templates and a very small amount of JS to tell the server to re-render them when the user needs it.
What many of us really need is not fully dynamic SPA-type things, we just need some dynamic forms and some page elements that dynamically respond to user input. This is all stuff that you can also do without JS, if you design your site to handle that use case! Rails still makes it easy to make this kind of site with plain JS (or a lightweight framework like Stimulus, or jquery if you really want).
But all that's to say I fully realize why and how JS is useful... and that's actually why I disable most JS by default in uBlock Origin.
The problem isn't the existence of JS, it's the fact that massive tools like React become the hammer, and everything starts to look like a nail. There's no reason for the sites I am usually interested in visiting, which are either content hosting sites (no JS needed at all) or sites like my own (that could be enhanced with JS but still functional without it) to pull in so much code unrelated to the primary function of the site.
I always wondered if we take shortcuts because we have to re-write everything every 14 months or if we have to re-write everything every 14 months because of all the shortcuts we take.
I put food on the table, and I do more work in Django than I do in SPA's. In fact, one of the complaints I read about from management is that Django devs cost more than JS devs (don't know if that's true, just saying it's a management concern).
But I think the "React everywhere" error, is more or less the same as the "one language for everything" error, the "everything should be Windows" error, and many other cases of wanting to use only one technology and have it work for all cases.
I've been working in the tech industry for 20 years and from my experience rarely do "cheap developers" ever actually seem to work out costing less in anything other than the very short term.
The cheaper the developer, the shorter the period where they cost less.
I have been developing all sorts of native and Web applications for a couple of decades now, and SPAs is something I avoid as much as possible.
And yes, I also implemented interactive desktop like applications as Web applications.
Server side rendering frameworks, with support for components and just enough JavaScript go a very long way, and best of all, they are faster than SPAs in every kind of device that customers might have.
Server-side rendering + Turbolinks [1] + jQuery-or-equivalent gives you an SPA experience anyway, without the client-side bloat. With judicious use of markup, it can be massively more responsive.
for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time
The premise of the article is that they are not easier to work with and do not save time in most situations. I agree.
Most websites are fundamentally documents, even those that think of themselves as apps. You could even build gmail quite easily as a document based app with some limited use of fetch() or WebSockets to get the data you need, though it's one of the few applications where a less document based approach might help.
React and other js frameworks are a huge amount of overhead for very little gain if you see the web this way. Your about page is not improved by using react.
I gave an example of a prominent web app I don't think needs a js framework - most web apps don't IMO as the web correctly centres the experience on documents. Games would be the obvious exception where an immersive app experience is warranted and there are no documents as such, almost every other app works with data organised into stores of documents (i.e. in gmail every email is a document and deserves its own URL IMO).
> fortunately people don't use React for making About pages.
No, About pages are out of fashion and people don't do them in high numbers anymore. But they do use react to display news articles, web shops, and all kind of text.
This doesn't match my experience at all. I've seen many, many places where a bleeding-edge React stack was deployed to serve what was 100% static content.
> for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.
Our salaries are expensive because, presumably, we're being paid to make something that serves the users. So anything that benefits us at the expense of the people we're serving should be rejected. How self-centered can we be?
What about if you used a mature back end framework such a Rails, Django or Laravel for 95% of your app. And then vue or react for the 5% that rally needs it? Would this be more or less productive?
The author wasn't claiming that react and co are bad for development. Rather that they are great for particular use cases and inferior to other options for other use cases.
I think that's undeniably true.
You hinted at something that to me is a key point: A lot of web apps are built by teams at big organizations.
In that environment trends are compelling because they keep everyone on the same page. It's easier to onboard people, it's easier to hand things off, easier to maintain going forward.
That makes a strong case for using the latest frameworks even when they aren't the best solution for a particular problem but it doesn't make it right from an efficiency or user experience perspective. There are a lot of reasons why arbitrary complexity is expensive. One example: what happens when your page load times start to rise above the threshold where it starts hurting organic traffic? You probably don't scrap everything and start over, instead you hack solutions on top of what you already have. Now you've lost money in both free traffic, one time development costs and increased maintenance costs going forward.
Again it's not that react is bad, and either way people aren't going to stop using it for things it's not ideal for until another trend replaces or absorbs it. But I think there's value in seeing things for what they are, and having conversations about it.
> they're easier to work with and they save us time.
I have never seen evidence of this.
Its a lie developers frequently mention because it sounds so thrilling to say. Approximately how much time does it save you in estimated hours? Its like asking for a helicopter to take me to work, because supposedly its faster. I'm simply assuming its faster without looking at any numbers or finances.
I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more.
It's certainly faster to use jQuery to change a CSS attribute than it is to setup a React project but what's not considered in that calculation is maintaining the state of that attribute or making changes to the logic in the future. Especially on code you didn't write originally.
If all you have to do is validate a form, sure, use jQuery if that's your cup of tea. But I would still rather use something like React because I know I'm less likely to write buggy code or introduce a regression in the future. To each their own though.
I think the problem/frustration is simply this: there are a lot of web sites out there that are, well, web sites, not web applications. Looking back at the linked article, it goes out of its way to talk about many ways that React is "pretty great" and "for a particular scope of use cases it's the best tool you can find," but then goes on:
> There are a lot of problems for which I can't see any concrete benefit to using React. Those are things like blogs, shopping-cart websites, mostly-CRUD-and-forms websites.
And the thing is, this still comprises an awful lot of the web. If I can produce a web site with Lektor or Hugo or some other sophisticated static site builder, it's hard to see how React is going to bring anything to the table that either makes that web site easier for me to maintain or provides a better experience for that web site's users. If you introduce some dynamic elements to the web site -- well, just what are those elements? Ad banners? A simple image carousel?
And I think that's really the argument being made here -- use the right tool for the right job. If all you have is React, everything look likes like an SPA, but that doesn't mean that it is.
Your argument hinges on the assumption that the products have a final conclusion. I can start building a product in hugo, say - I’m just displaying information in charts and generating predefined reports. Time passes more users are added and now I need to identify each users reports. Now I need a server and at this stage I can get away with SSR. More time, more organizations, more complexity. All of this can still be handled by SSR. The real kicker happens when people start demanding the ability to generate their own reports by supplying their parameters. They want the ability to write their own queries. They want WYSIWYG building blocks. They want to define their own templates.
Very quickly we are in a territory well done with react than with Hugo.
Most products, especially if it’s a company, are like this. Products are constantly evolving. Whether products should be constantly evolving is a different discussion and tools are only a small part of that discussion.
I would say rather that my argument hinges on the assumption that the majority of web sites in the world are not the primary products of the companies that produce them. I would argue, in fact, that you're looking at web sites from a very particular lens. An absolutely valid lens, to be sure, but a particular one. nonetheless.
If you're an SaaS (or PaaS or whatever-aaS) company, then your web site is literally the core of your being. You're building an application that happens to run in the browser, so you want to build it like an applications! But a lot of companies aren't doing that. Hacker News, the web site we're on right now, doesn't need to be an SPA (and isn't). Does any CMS need to be designed like one? I'd never give a blanket "no," but I'd sure never give a blanket "yes." How about a company blog? A simple storefront? A customer-facing restaurant site?
Also, don't get hung up on my particular example of a static web site -- I wasn't arguing that all sites can be done with Hugo. :) But you could absolutely design a modern, maintainable CMS that lets internal customers generate their own reports, write their own queries, and define their own templates using Rails or Django or Laravel as the back end -- and that seemed to me to be what the original article was really trying to get at. We've gotten so hooked on "JavaScript is everything everywhere" that we may not always be considering whether a given project really fits that paradigm. "This project doesn't fit it now, but it might in the future" is nearly always a technically correct response -- but "what you're building couldn't possibly scale up to unicorn level" is nearly always a technically correct response, too.
For all the talk of "resume driven development" I think most developers - unless they are playing around with side projects and non-essential experimental stuff - prefer to do the simplest thing that will get the job done and keep the site maintainable, and the reason they resort to more complex and advanced frontend solutions is due to onerous requirements from stakeholders for more and more intricate and complex UI. It's another question entirely whether this more intricate and complex UI actually delivers business value or provides a better experience for the end users, but that question is above the developers' pay grade.
I suspect a little of both. Developers do like to play with cool new technologies, and product managers do like to see how spiffy they can make their products.
Having said that, though, I do not think it's a universal truth that all web sites must expand to fill all available functionality, which seems to be implicit in a lot of arguments here and in the highest-rated rebuttal to me.
The same way anyone would come up with a time estimate if asked how long it would take to mow the lawn with a pair of scissors or lawnmower -- experience and extrapolation.
Fair enough on the experience and extrapolation. But I would argue your analogy is a bit off. It's undeniable that a lawnmower is faster than scissors. I don't think that's the case between React and no React.
A closer analogy would be a comparison between different models of lawnmower or between a lawnmower and a different kind of mechanical grass cutting device. In which case, it seems you would need to log time to see if you've saved time using one over the other.
> I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more.
Its a lie so long as the number sounds completely invented. I suspect the number comes from somewhere, maybe a vague memory, or a grossly unqualified estimation, but it isn't based on anything. It is something superficial that primarily serves as self reassurance.
When you have never had to bill people for your time, or you have never been to a board meeting, or never briefed senior executives this kind of fantasy is perfectly fine. The moment there is money on the table you are expected to do more than invent fictional numbers, or you will be replaced by somebody who can.
I have worked as a consultant for 5 years where I billed people for my time, and paid at least $200k to other contractors in that period for help on projects; it's not made up and it is based on my experience tracking my own time and productivity, and that of my subcontractors.
I do think it's more abstract and harder to justify properly when someone is a well paid salaried employee for a FAANG. But that's not me.
For me the real subject would be "the death of templates in favor of decorator based objects", which could have been predicted by the GoF that recommended the decorator pattern for GUIs, and makes great sense for the tag-based language that HTML is.
Template languages often impose language limitations to make easier for HTML/CSS coders to work with, without breaking the backend code, isolating their codebase from the backend codebase.
These limitations make them less composable and reusable than functions or objects, and obviously show more drawbacks than advantages for one-man-development, and reuse across projects.
My wild guess is that if we replace templates by components on the server side, we will see less React & friends, for me they mainly demonstrate the clear win of component based patterns against template spagetti.
Seems we are going full circle: the Python ecosystem had component-based template languages such as ZPT (Zope Page Templates) and Genshi. The former I think is still used with the Pyramid framework, but mostly these approaches have been replaced by Django/Jinja2 text-based templates. So in Jinja2 or Django you would have something like:
If you squint hard enough this doesn't look a million miles different from React or Vue.
This approach largely fell out of favor, but I don't know whether that was just due to Django's popularity vs other Python frameworks or Django template language just being more flexible and approachable, especially for front-end developers (and you could use it for any kind of text based content, such as emails).
It was that the template engine got a Turing complete text declaration language, while the tag based one had to rely on hacks that didn't scale very well. Also, as you said, because the template engine were useful for any kind of data, while the tag one carries a lot of opinions about the resulting text.
More flexible and conceptually simpler tend to win over time, as people try to learn less things.
I’ve written one or two web applications to put food on the table. I’ve found that unless additional complexity comes with an orders of magnitude benefit, it’s usually not worth it.
Seems like the author had a few well articulated and valid concerns, and probably likes the taste of food too.
> I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
Anyone who cares about privacy allows minimal JS etc. Especially if they're using Tor. And given Tor's high latency and low bandwidth, sites that require lots of client-server dialogue, and/or push lots of data, are a pain to use.
And yes, I've never built complex websites. Just static HTML. Because mostly they've been Tor onion sites, and that's what works best for them.
You are contradicting yourself by opening with a claim of time savings and ease of use followed by admitting that the solution is largely more complex. More complex work does not save time in aggregate and is not easier to use.
> You are contradicting yourself by opening with a claim of time savings and ease of use followed by admitting that the solution is largely more complex
It's not a contradiction. C# is "largely more complex" than C, that doesn't mean C is inherently more productive than C#.
But that's a one-time cost. Spring Boot is stupid complicated, too, but once you know it you know it, and getting your next project spun up is a lot faster.
I'd rather maintain a React app because it will be at least somewhat familiar than try to fight my way through someone's home-grown rendering framework that can't even be Googled.
The solution is not more complex to the developer or user, it's more complex to the browser, which hardly ever complains when you make it work harder :-)
Users could complain when someone makes their browsers work harder. Looking around the net, they mostly don't. I don't know. The only time I developed a serious full SPA, I intended to use it myself on a $50 phone, so I actually kept complaining to myself until it started loading in reasonable time and working instantly after that.
It’s all about where the complexity lives. As long as your client code needs aren’t too complicated then you lose time by using React^. But once you cross a threshold you end up inventing some subset of React^^ and hope that it’s overall less effort to maintain than using React itself.
^ maybe not if your dev team is used to using React but nonetheless.
^^ React could be any of the popular frameworks. They all solve similar problems.
I wonder, when did this shift happen wrt the Web: we only care about how it is easy for the developers, not for the users. Despite all the talk about UX a lot of the momentum is still in the wrong direction.
I've been writing working with the web close to 25 years now. It is amusing to see it come the full circle. How hard it is to understand, that you don't need react for some blog, or anything which is not even remotely an app?
> when did this shift happen wrt the Web: we only care about how it is easy for the developers, not for the users
Are you talking about the same web that ditched XHTML because you had to validate your site before publishing? And had those "works better on Mozaic in a 420x340 resolution" warnings?
> I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
Does wondering that help you come to terms with the idea that you're creating things that range between "not the best user experience" to "thoroughly unpleasant to use"?
Personally I have been building websites (anything between sysadmin to backend and frontend) for 20 years, and my experience of the JS ecosystem is that it's utterly unpleasant to work with and in no-way better than other web technologies, but then maybe that's a delusion brought on by not eating enough.
> It outweighs all the end-user-facing cons by a lot
Well, I got so sick of crappy JS "websites" spinning my CPU fans that I installed the NoScript plugin, and now the web is a far nicer place to be. My browser is more stable and faster, uses less memory, and doesn't hog my CPU as much.
> client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.
As a developer that started off with client applications going on two decades, this is the attitude I despise most about the modern web, the frameworks that power it, and the developers building on it.
Developers serve the user. The user must always be the primary beneficiary. Forgetting that is why we have this bloat, terribly frustration UIs, inconsistent UX, poor accessibility, and everything else that plagues software development today.
> sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
I've been developing single page applications, mostly, for six years; and I generally don't enable JavaScript on a website unless it is otherwise broken and I actually care to use it. I'm developing a website right now that has some persistent elements (video call, interactive charts) that don't play well with server side rendering. For the elements that are fine without it I prefer to render them on the server when there are enough of them, but ultimately there are limits.
> client-side technologies like React have a pretty clear advantage... they're easier to work with and they save us time.
> it worries me that they create a sort of gatekeeping effect on the industry
Aren't these two quotes contradicting one another? If frontend frameworks make frontend developers' job easier, then how can they be regarded as contributing to gatekeeping? If it had not been for them, frontend development job would have been harder and would have required more expertise.
I’ve never used React, but I spent years fighting with Angular, and it seemed like all downside with no upside - I kept expecting the upside to become apparent eventually, but it never materialized... it just made site development take longer, crash more mysteriously, and run slower. Is React really “better” than Angular? That is, does it actually do anything?
Angular's model is based on "two-way data binding", which was also the paradigm used by Backbone and other popular JS frameworks of a ~decade ago. This means that any user interaction with your app directly causes some JavaScript value to change, potentially triggering side-effects. But you can also cause the same value to change in your business logic code, in response to some other event or change. Components maintain a lot of data internally, so your job as a developer is largely about making sure that these components stay in sync with each other, and with whatever non-component-oriented data you have.
This gets messy very quickly. Where is your data? What things can cause your data to change? What happens if you want to change a data schema, or introduce new fields, new components? Angular tries to solve this problem with a fairly complex architecture[1] which promises that all of this can be OK if you follow the rules.
The problem is that this architecture is so complex that most people can't follow it well: there are modules, components, views, directives, services, dependency injection containers, service metadata, bindings, a router, and events. That's ten concepts, and you can't build very much in Angular without knowing what those concepts are and how they relate to each other (and if you can build it without knowing these things, then you didn't need Angular).
React is much simpler: there is state, and there are views. State can be global or component-local, and I would suggest ignoring component-local state unless you can't avoid it. Views render whatever state is passed to them. State can be updated by events. This is the same basic loop that is recognisable in desktop apps, games, in fact most interactive software. There's no "two-way binding" because views render based on state, but can't modify it directly. This is a lot easier to understand and to debug.
React might be less "batteries included" than Angular, but Angular requires such an enormous battery pack because it is trying to solve problems in an insanely complicated way.
It sounds like excuses companies make when they pollute the or exploit their employees. Solution for them to stop is to level the playing field by law. I think that one day the same will happen with software, and we'll all be sorry.
You would be shocked to learn how many roads and buildings are actually built like this. Except that in the case of roads and houses, people die sometimes as a consequence.
I’m tempted to step back and evaluate this on another level. Our industry is very big, and any industry that gets that big will be able to house a lot of people just for the sake of it.
If you think we have a large amount of fresh frontend people, understand they are hired almost with a one to one correspondence with fresh product/business people.
Modern product development is essentially a polishing job on every component that Twitter Bootstrap or Jquery UI ever invented. Over and over, we dress up a modal, with a slider, with a ‘user flow’, with some tooltips, and so on, and allow the process to masquerade around as real design/engineering. There’s so much money in this industry that we can hire entire teams to basically take a Bootstrap component, and theme it. This gets passed on as product development, and from the developer side, it gets passed on as engineering.
If this is the level of masquerading occurring, why would a frontend developer ever go ‘what’s the right solution here?’.
Something similar is happening on the backend and infrastructure. It too will take on a mask behind devops and data science and start pumping out what are probably straight up SQL queries and cron jobs. This will get passed off as design and engineering as well.
> There’s so much money in this industry that we can hire entire teams to basically take a Bootstrap component, and theme it.
This feels a tad reductionist based on my experience. Sure, most apps are designed around an agreed-upon set of affordances and design principles that the community determines, but modeling application behavior for real-world scenarios involves way more than theming a bootstrap component. I think it’s a mistake to reduce a developer down to the code that they write, because the ultimate value of a developer is in the code that they choose not to write just as much as the code they do write.
I think you're bordering on a contentious idea that I will take a step further. I would argue that frontend, nearly in its entirety, is effectively one giant bike-shed operation. And like you're alluding to, it's an operation that exists mostly because there is money to burn. At best, frontend exists to save backend engineers the trouble of dealing with the tedium of HTML/CSS.
As an example, the article brought up Craigslist; renowned for its brutalism. Craigslist would only be hindered by any frontend changes: arbitrary and confusing interface changes, (necessarily) slower load times, and increased complexity.
That said, I agree with the article that HTML form UX often requires more advance strategies like React and Vue. The decision requires discretion, of course.
I'm actually more of the opinion that a lot of backend is bikeshedding! Branding and UI/UX design are very important for emotionally influencing a customer's opinion or improving their user experience with your product. On the backend, how often are the any different than some cross set of options from:
* synchronous CRUD
* async data flow
* bidirectional realtime messaging (message in the "data packet" sense)
* search
Most products are not serving traffic that is large enough or solving a computational problem that distinct enough to not be covered by some off the shelf combination of the above. We just haven't figured out how to make these different solutions composable on the backend. Over the next 10 years I think we're going to see more and more codeless SaaS services, like Webflow for the backend.
It seems that each generation of programmers at some point comes to this epiphany that a lot of things that they're doing are repetitive enough that they ought to be doable by non-programmers, if you just come up with a way to glue those common things together easily. That was the story behind "4th generation" programming languages, for example; and to some extent, behind RAD.
Every attempt so far produced many technologies that died very fast, and a few (e.g. SQL) that survived long enough to become a natural and useful part of the landscape - but even that part still requires programmers to tend to it. When non-programmers try to use that tooling, the result rarely works well; and in those few cases when it does, it's rarely maintainable anyway.
RAD died because it could only cover 98% of business needs and idiot managers thought they needed a language to deal with 100% and so threw away really great tools.
I could fully foresee VB making a comeback in the future.
RAD never really died, we just stopped calling it that.
But open Visual Studio today, and create a new Windows XAML app, then open the form designer. You can still drag a button from the toolbox, move it around, then double-click it to wire up an event handler - exactly like it was in VB6. In fact, it's quite possible to ignore all the modern stuff like data bindings entirely, and just manually read and update all widgets, as a typical VB/Delphi app did.
For WPF, data binding is idiomatic. It wasn't back in those days.
My point is basically that the tooling that we use for desktop UI development is still very much rooted in the RAD era - but as best practices around it changed, we dropped the "RAD" label. It was a gradual evolution, though.
>Over the next 10 years I think we're going to see more and more codeless SaaS services
Maybe it will finally happen, but some variation of this has been the holy grail for a lot of years now.
I read an article a while back that talked about how many times developers have implemented the same thing in different ways at different companies; for instance payment processing. And it's true. But, you have companies like Stripe and Braintree. Now, there's even a SaaS subscription management SaaS businesses that sit above these (I don't recall any names).
But these just become other things to which we have to integrate. Now the task has moved, but we still have to build the connections and implement all of the business rules that go around that. I guess my point is that with every business having different logic, processes, models, etc it becomes very difficult to have some generic tool that allows a codeless solution to all of these problems. It's not the individual components like those you listed that cause the complexity. It's the way they are wired together and the underlying rules. So, while it seems inefficient to keep building these things, I think it is reductionist to say "well, it's only another CRUD app" or whatever.
Sure, tools can make things easier, but they make things easier for everyone. So now the bar is raised in terms of what you must do over and above that baseline in order to win.
Maybe a good analogy is that back in the day everything was written in assembly. High level languages came along and made it easier to do more faster. But then the complexity of software and the demands on it also increased, so in a similar fashion it just moved the problem.
I suppose another way of looking at it, is more about what you've mentioned with Stripe, Braintree, etc. A lot of the things that a web business needs to run are getting built out as APIs. At some point, I predict non-tech companies that still need some tech components, they will:
* pick out the SaaS they need, and someone will write a tool to integrate the top different SaaS providers together
* they will differentiate themselves from their competitors based on their product offering and branding, less so on tech
So, I'm not saying that programmers in general will be able to plug and play backend infra like Legos, but that non-technical people will be able to mix and match the infra components they need without doing coding. For these kinds of people, what the computers are doing is not important, and the frontend is more important, IMO.
It might be possible that product development itself is the actual bike shedding, and all the frontend, backend and product devs help the product owner realize that ;) However, you can't know in advance, yet the process has a tendency to self correct over time - creative destruction and all that.
> the process has a tendency to self correct over time - creative destruction and all that
I wonder how long it takes for the correction to kick in, because for the last decade+, software seems to be getting worse and worse - slower, bloatier, less functional, and with more user-hostile business models.
Just look around your government systems. They have had decades to fix themselves but are they fixed yet? Are they faster, less bloatier, less user hostile and privacy invasive?
Software development?
Web development?
What used to be called "Application Development" back in the 1980s and early 1990s?
I'm asking because there's a lot of software developers/engineers whose jobs don't feature any of the keywords in your comment ("Frontend", "Backend", "SQL queries", "modal" etc. etc.)
If all one has been exposed is a development world of web-based consumer-facing front-ends (CFUI), it is hard to imagine that the majority of software lies elsewhere. Hard to imagine that anything else is important. It leads to a viewpoint that modern programming is mainly about UI interacting with a database.
I'd say you have to group business-facing front ends with consumer-facing front ends, as well as big chunk of mobile development, because all of these are done by the same people from the same programming culture, with the same technologies, patterns and ways of thinking.
And with that, I'd argue this is majority of software.
By what measure? Majority of individual 'products'? Majority of programmers? Majority of investment? Majority of revenue?
I think that at best what you're describing is a thin simple majority by some of those metrics. But there are so many developers working on factory automation, networking, gaming, small embedded systems (anything with a chip in it, from washing machines to cars), not to mention the huge frameworks that power am off the simple apps you are taking about - Linux, Windows, Chrome, Firefox, Android, iOS, the major SQL DBs, the major NoSQL DBs, the language tools for all of these, the web servers, the distribution frameworks at Google/Facebook/Microsoft/Amazon and so on.
While the number of core technologies is obviously easily dwarfed by the number of applications, the number of people working on each of these core technologies is so large that I can't believe your assumption.
Also, some of these industries, particularly gaming, and maybe networking as well, are so huge in terms of revenue, that I don't think CRUD apps could win on that side either.
I'd say majority of programmer-hours, because anything else is a metric that's too unreliable / easy to fudge. "Individual products" is an arbitrary marketing distinction (e.g. a company I worked for could create and sell new products by tweaking few lines in a config file; every customer would get their own mix and match of software pieces). And neither investments nor revenue are directly correlated with the amount of software you have.
Note also that out of the things you mentioned, "factory automation, networking, gaming, small embedded systems", perhaps only small embedded systems projects aren't partly done in web technologies. Gaming definitely is (in AAA games, all the UI that's not the part of core gameplay - e.g. launchers, lobby, marketplace - is likely to be done in Electron or some embeddable webview library). Factory automation, if two companies I worked with over the last decade are any indication, is slowly moving towards webapps for everything. So I imagine networking on the admin side.
It's basically too cheap to make a shit, bloated but somewhat pretty UI with JavaScript. Everyone's doing it, everyone keeps hiring for it.
Using web technologies is not the same as doing crud web apps. Games for example are a very different kind of programming. And even if network admin and factory automation apps have web front-ends, that's still a minuscule part of the code.
Games are very different programming. Code surrounding games - lobby, game server lists, marketpaces, IAP - this is pure CRUD, and it's entirely unrelated to the game code.
I think there's a strong overtone of that in many places, including in business and popular culture. Most peoples' interactions with software are phone apps and web fluff.
At this point, I am convinced the problem is not web frameworks but browsers. Someone needs to take all the legacy bloat away and put it in the side while starting from the scratch. Web doesn't need three different languages. It doesn't need freedom that costs accessibility. It doesn't need to be so primitive.
I agree, I feel like all the points both for and against SPAs and frontend frameworks in this thread are just circling around the idea that browsers make an awful platform for building software. But the delivery mechanism is so much more compelling than anything else available, and the momentum so great, that we're all willing to put up with it.
It will never happen, but I wish there was a second stack that browsers understood, totally separate from the DOM, purpose built for developing _applications_, rather than abusing the fact that this document creation tool allows us to put styled boxes in different places.
This is not really a failing of HTML, CSS, or JavaScript, but if your platform SDK's total feature set for building UIs amounted to some basic form inputs, incredibly inflexible tables, and a handful of ways to add semantics to otherwise featureless blocks of text and boxes, you'd be laughed out of the room. The fact that anything remotely feature rich must be built from scratch is part of the reason the ecosystem has such a bad rap for over reliance on packages, and for constantly reinventing the wheel.
The whole conversation ignores, for example, the reason that jQuery was invented: At a time when there were many competing browsers, all of which spoke different dialects of JavaScript (that's my punny way of saying that they had different bugs), HTML/CSS bugs that were all different across browsers... jQuery brought order to chaos.
And the problem is, that as browsers improved and got closer to general standards compliance (where we STILL ARE NOT today), they didn't remove the cruft and the past bad behavior - no, they continue to support code that implements that crappy API that was deprecated 15 years ago.
These problems continue today and as long as that is true - as long as fundamentally, the problem is the browser itself -- these frameworks will continue to have a place.
I'll take it a step further and say we shouldn't be using the Web paradigm at all.
We've tried a million different ways now to essentially generate HTML. So many frameworks. So many libraries. Front end. Back end. Etc.
But, we're still working within the paradigm of the stateless Web, designed to display documents and images. Trying to hammer an application in there (especially a SPA) really doesn't make sense.
So, why do we just keep forcing it? If leveraging the ubiquity of the Web is the objective, then there's nothing to say we couldn't have a VM running in a browser that itself uses web protocols/languages, but abstracts them away. That would leave us writing code a la Swing, an event-driven, component-based model that makes so much more sense for a GUI style application. No CSS, HTML, fighting back-buttons, state management, routing, etc. That's all handled in the VM.
Because hyperlinked documents are the whole ball game. Web technologies are a pain in the ass for developers but a boon for the advancement of human knowledge and connectedness.
The great islands and continents of web space float in the same aether. They interconnect, despite being built at different times, in different styles, on different technologies. It all just, for the most part, works. It’s fucking beautiful.
I'm personally curious how far we could go with using just canvas and wasm. If we focused on making a browser that was just incredibly efficient and focused at using wasm and webgl, and had no other concerns, a lot of the cruft could be cut. Then any given "page" would essentially just expose the canvas for wasm to draw to, and GUI frameworks like Qt (which already can compile to wasm I believe) could just target this. We could then have different UI toolkits targetting this model, and hopefully even have something akin to Flash without being the same security nightmare.
Keep the current browser stack for the things it still makes sense for - static content like articles and blogs, and forums too, but anything with greater complexity and reactivity would run faster and get better gains from just abandoning html/js completely, and browsers themselves could stem the unending march of feature creep.
I'm just spitballing here, I'm not sure I think this is actually a good idea - you'd be losing a lot of accessibility you get for free with HTML for example, but I'd like to see some experiments in this area to see how far this could go.
> I'm personally curious how far we could go with using just canvas and wasm
In a word: accessibility. HTML is inherently accessible - you can curl a webpage and read the contents of any (static) web page. If you curl an entirely <canvas> based web page, you'll walk away knowing only that the web page has a <canvas> element in it.
You mentioned Qt. I've never programmed a Qt app, but I went hunting for its accessibility features in the docs[1]. I'm encouraged that Qt takes accessibility and Assistive Technologies seriously. However, if you're coding a web page in canvas/wasm/Qt you're going to need to make sure all the content, links and additional accessibility/AT requirements get ported from the <canvas> into the surrounding DOM to make it accessible.
Yes, the Web should stay what it is for static documents. In fact, what I advocated would continue to be based on Web standards (HTML, CSS, Javascript, and newer constructs like canvases, etc).
So, you would have a JS-based VM that runs in the browser. No Flash or other binary. Just pure Web standards for executing the code, rendering, etc. However, as an app developer, you wouldn't touch HTML or Web standards. Instead, they'd all be abstracted away and you'd work within a component/event driven model that's provided by the VM.
Instead of CSS, you'd roll themes, allowing you to stylize components. They'd ultimately be applied via CSS, but ideally you'd have a GUI interface for creating these themes. CSS gives you ultimate flexibility, but why are we still fighting whitespace and these other
low-level document layout constructs when we are really working at a UI component/control level? It's like designing in assembly.
Instinctively, people won't want to give up this granular control. But that's only because we've been thinking about apps in Web terms for so long.
For me, that's the problem with a lot of these frameworks. They do a great job of helping you to wrangle the impedance mismatch between the web and apps. But, they are all predicated on deference to the Web, so they keep us immersed in this world, essentially fighting the Web's ill-fittedness to the task: HTML templates, DOM management, render functions with HTML strings, CSS styling embedded in "components", etc.
Why go so far to create a framework only to hamstring it with the very problems it aims to solve?
And yet, unlike newspapers with an in house advertising staff. All web adverts are 3rd party. That are easily blocked. Google laughs to the bank everyday it killed old advertising.
Since 2013 my work has generally consisted of applications that run in the browser, right now I'm working on the first normal website I've worked on in 7 years. And I agree this is a bunch of little polishing jobs.
I do say to myself what's the right solution here, but I know for business reasons I am not allowed to do the right solution.
Isn't this the same in almost any industry? For example, in engineering this kind of "reinventing the wheel ad infinitum" you are describing is incredibly common. How many times to you think engineers have separately designed and tested clips to hold capacitors in place in the ECU of a motor? Many thousands of times, while being paid competitive salaries. Maybe you should argue there should be some "book of capacitor clip designs" but actually this doesn't work in practise because every capacitor clip design needs to fulfil very slightly different requirements. Often it is just easier and faster to redesign from scratch.
Taking existing components and redesigning them in some small way to fit your specific requirements is common in almost every industry I can think of.
The alternative is just having premade components lazily glued together. It seems that the markets have decided that highly polished custom tools are worth the cost.
"Growth" != profit. I can sell $10 bills for $1 and grow rapidly too, doesn't mean I will ever become profitable.
Are these low/no-code providers actually making profits, or is it a temporary fad and eventually 1) the market will re-adjust and these no-code tools will become more expensive to sustain themselves, bringing up the cost of a no-code app and/or 2) users of these tools will realise their limitations and eventually word will get out that you end up spending twice as much with no-code than doing "code" to begin with?
Nice take. Yes design/frontend has rarely been about actual design. Backend web has rarely been about engineering either, I'd say. Just look at all the elastic search engines left open to the public internet as proof of unconscionable levels of ignorance.
Either you omit some interactive elements on load, or you try really hard to make sure that the JavaScript loads faster than users will click, or you make some elements not require JavaScript to work - like making them normal links or forms. Or some combination of those.
I realise I'm in the minority, but I use JS whitelisting, which means that any SPAs I come across in my web searches (a disturbingly large number, and unfortunately increasing) will quickly make me go back since I can often find what I'm looking for somewhere else, on a site which doesn't require running arbitrary code just to render what usually turns out to be static content anyway.
The state of web development has always seemed a bit odd to me, largely driven by fashion and a desire for developers to "outdo" one another in complexity. There's a ton of churn and ADHD as people jump around from one trend to the next; instead of settling down and focusing on getting the most out of a platform, they're eternally in search of the next one. Reinventing/reimplementing in JS what basic HTML and CSS can do is just one example of this behaviour. The massive overuse of the "modern" adjective is another, and quite frankly all this really irritates me, as someone who just wants to use the Web as a hypertext document system to find some information.
I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens.
You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least for me, I have to fight against every client, employer, and coworker to execute this approach.
Maybe web developers as a whole just got bored. They don't want to make webpages like they did in 2002.
Make a folder with some .HTML, .CSS, .JS files. Then sync it to a linux box. Wow, you're on the internet, a modern marvel. I see younger devs who don't even know this basic stuff. As if, this were all way more complicated than it actually is. It's not.
How do we get web devs back on track? Makers need to thoroughly understand their tools and materials, inside and out, for any industry. I'm just not seeing that as much anymore. It seems like an education problem, or maybe it's just human nature to go for new and shiny instead of practical and reliable.
I agree with the sentiment of what you're saying, but I don't agree with the premise that there are no use cases for single page apps. You can achieve a decent UX for some applications by using small amounts of vanilla JS, but it's simply not possible to avoid re-rendering the entire page without using XHR requests at some point. That is how the browser is designed, fundamentally. Because it wasn't designed as an application platform, it was designed as a document platform.
But some products are actually better as applications, not interconnected documents. For those applications, the browser fights you every step of the way, because that's not what it's designed for. You simply can't compare the UX of document-based web applications to native clients.
An SPA is just the web approximation of a native client. Your application truly runs in the client process continuously, so rendering transitions happen smoothly instead of blank pages and jumping transitions. Everyone would benefit from understanding more and using that to simplify all areas of the tech stack, but the experience that an SPA offers is simply not possible otherwise.
SPA is a poor approximation of a native client with a hugely bloated browser stuck in some level of the abstraction, bypassing native app libraries, design sensibilities, typography guidelines and accessibility by implementing some UI framework that was developed by people that are entirely unqualified for it. Have you looked it the guidelines for UI development, say for MacOS? Here you go: https://developer.apple.com/design/human-interface-guideline...
PWAs, browser apps - they bypass all this work from professionals and give it in the hands of an unequiped developer. Oh god.
A browser is a window, an area of the screen that is allowed to do whatever it wants in a sandbox mode. This is a terrible idea. It becomes complete wild-wild-west.
>it's simply not possible to avoid re-rendering the entire page without using XHR
Wrong on two separate levels.
First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever.
Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs.
The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity.
If you pay even a little attention to order of loading you can avoid FOUC entirely. If you pay a little attention to defining sizes of leading elements, you'll have constant layout of the top part of the page, and avoid flash of white background. If you use anchors here and there your user will be scrolled to the proper position.
Yes your page can easily look as if it got only updated with JS after doing a full load+render.
The technology is already in the browser; no need to approximate it with three layers of JS.
You can’t compare the UI of a web page built in this way to an SPA or a native client. Re-rendering an entire page on every interaction is strategically never going to get you the same experience. I understand wanting to be a browser purist, but web applications have had pretty laughable UX compared to native apps of even 20 years ago.
I mean look at an iOS app designed by Apple. I always reference the AppStore app itself. You simply can’t build that app as a web app, certainly not by using iframes as a “solution.”
You don't need an SPA to use XHR, and your description of the SPA experience for the end user is a fantasy - there's a reason pretty progress bars are popular in SPAs, and it's not because of fast state changes, quite the reverse.
It's funny, your example actually shows the primary benefit of an SPA, and doesn't do anything to show any downsides. A progress bar is a perfect example. You can't show a progress bar with HTML. You would have clicked something, and a new page would be rendered entirely. In the time it took to create the new page on the backend, the user would be staring at either a white screen or the current page. If they're looking at the current page, they probably think the application is malfunctioning, as no user feedback was given to their action.
Whereas, with an SPA, you can _instantly_ show a progress bar, at least indicating that something is going on. And, the very fact that you're showing a progress bar means that the client side rendering isn't the slow action, it's retrieving something from the server. So, the UI was as interactive as possible.
This is an amazing feature you simply don't need on the majority of web apps, because a) the browser has a loading indicator and b) most web apps are fast enough to not need to tell the user about it, they just load new pages in milliseconds instead.
An in-page progress bar is in most cases a failure of UX, not a success.
Please write more about this because I feel the exact same.
Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static. Why do you want things moving around and reacting? People of the internet - imagine if the internet protocols were given to us, but no browser existed. Would we develop this non-sense we have today?
What should have happened is the following:
- Develop web-to-native-UI mapper, call that thing a browser.
- Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig.
- Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.
The web went downhill the day `<input>` tag was allowed to be styled by CSS. We had a web-to-native-UI mapper!
I am forever a believer that democratically designed things generally suck unless there is a BDFL who can make shots. Dictatorship is a necessity of great products and services - Steve Jobs to Guido, democracy is good in politics, not in software development. Feature creep from the public will ruin whatever youre buidling. Designers will ravage through what worked well and replace it with "taste".
/Rant, I am getting old. Humans tried to make the web "pop", but instead it exploded with chaos.
Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static
Exactly. As a bonus, you automatically get the behaviour associated with a link that browsers already implement: people can bookmark a link for later use, open it in a new window, etc. All of which would need extra effort (and thus also easily break) if it was just a clickable element invoking some JS.
I've had some pretty annoying conversations with customer support and developers about things like this; almost always, the response is something like "we didn't think you would have a need to do that". They would not have needed to think about it at all, and it would work for me, if they had just used a regular link.
That said I'm not totally opposed to SPAs; highly interactive apps, e.g. realtime games and such, would definitely benefit as they wouldn't really make sense as a linked set of documents. But for everything else it feels like they not only reinvent the wheel, but make it square.
It's not even the ability to bookmark it. It's basic stuff like the ability to restart my computer (e.g. because Windows demands that for updates), and go back to the same exact spot I've been at. For desktop apps, this works. For web pages that are just web pages, it works. But with something like Facebook, if you close a tab in which you've been scrolling through the feed, that state is forever lost.
“Let the page refresh” translates to a terrible UX. It devalues the application. It’s equivalent to buying a physical product, say a car, but the car jerks up and down whenever you hit the gas, and you hit your head on the roof every time.
Yea, the web page _works_ but it’s ugly, and in poor taste. Users do not care about browser purity, they want an app that seems polished. You can’t get that experience by using semantic HTML at all.
I'm pretty sure blind people don't even notice this 'terrible UX' problem you describe, and that sighted folks aren't quite as jarred by it as you think.
This 'taste' issue probably matters more in some organizations than others. Hopefully they don't involve blind people in their business, because SPAs are notorious for being unusable to them. You can design an SPA with accessibility in mind (https://www.deque.com/blog/accessibility-tips-in-single-page...) but most devs either can't be bothered or aren't even aware of the issue.
Yes, people who don't have the ability to see won't care about flickering on the screen and the better user experience that a single page app affords to users who can see. Not even sure why you're making that point other than to try and imply that people who write single page apps automatically don't care about blind people, which is self-righteous and rude.
We have a single page app and we regularly run it through screen readers to see what the experience is like. Since an SPA is not some magical entity and it does produce a real DOM tree, we can achieve a great degree of accessibility (not perfect) by simply focusing on the markup that's produced. That doesn't help with things like loading screens, but again, since we actually check applications on screen readers, the experience for pages that take a long time to render is not much better with pure HTML either.
I read the link you posted and it's a good resource. The #1 takeaway I got from it is:
> Make sure that client-side view changes are known to screen reader users by announcing the change in page title, using ARIA live regions and/or focus management.
That's a good idea and one we'll incorporate into our application.
Some other comments in the article are not helpful, such as:
> Consider whether a single-page app is really necessary, and if you even need to use a JavaScript framework at all.
This is a moot point. Using a JavaScript framework to create an application is not only acceptable, but extremely popular. So instead of trying to politically smash the idea of building an application using JavaScript, we should be focusing on how to improve accessibility in that landscape. We can and should figure things out.
I'm glad there are people out there taking the accessibility issue seriously, what you said does make me more inclined to evaluate framework-based solutions. Nice to know at least parts of the most popular JS platforms are maturing enough for this to be easier for devs to implement.
Can't agree more. It's a very simple point but I am surprised that people couldn't realize it and even downvoted your view.
IMO, discussing this further will just yield a negative returns as I think there are some fundamental issues/gap between two parties in this thread.
No matter how much ppl kick and scream, the SPA is gonna make the web a much more user friendly place in general. When we fade away and the next generation of us come, they will take this as the new norm easily and happily.
They can, but it requires additional work on the part of the developers, which in my experience is almost never done. Also, that's kind of what the SPA acronym stands for, no?
> Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static.
To be completely honest, this is one of my least favorite things about HN. As I write this comment and click reply, if I wish to navigate “back” after I post this comment, the first back button click with take me to this still-filled comment form. (Will I fuck anything up by clicking “reply” once more? This is an easy trap for a user to fall into.) The second back will take me back to the post comments. Which is weird, because this is where I was taken after posting the comment. The third back will take me back to HN homepage. I expect to go back to the homepage on the first back click.
And this nav stack works as it does because HN uses plain HTML forms without any “overkill” JS. But the reality is that the default back behavior doesn’t really fit most user expectations, because most people don’t understand that clicking each of these buttons added more and more to the stack. Most people don’t know what a stack is! :) I think this is a great example of why the default document behavior of the web doesn’t really match most people’s user expectations, and the normal form behavior on the web makes it way to easy to do the wrong thing, like re-submit information.
> Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig.
> Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.
I'm not sure if this was supposed to be a case of 'how it once was' or 'how it should be', but this was never a reality, at least after the 90s. Native apps have always tried to style themselves just so (my company has a C# B2B GUI that has a little bit of assembly somewhere calling a Windows interrupt directly because they couldn't figure out another way to change the color of some window element). Even the earliest web pages were often trying to look as different as possible.
Just chiming in to say this is an absolutely viable approach. I just built a project, over about six weeks, using mostly vanilla js and some jquery (the heaviest widget I have is tinymce, which is a necessity unfortunately), and started selling it about two weeks in. I'm up to $650 mrr and the sky's the limit (really, the market is huge and desperately underserved), and not one person has complained about it acting like an old style website. People are just happy it works. And mobile testing was a breeze.
If I tried to build this on a "modern" stack I cannot imagine any benefit, only drawbacks.
So unfortunately the live project has no public-facing component; without going into too much detail it helps certain corporations and larger nonprofits with a kind of compliance. But, I can tell you that I based it very closely on the layouts provided by the ultra lightweight css framework, PureCSS. (This is also my favorite framework!)
One other remark: people are happy when they learn about this. That is now my #1 predictor of success. Everyone I've demoed to has adopted the product within a day (usually during the demo), and tech wise it's no different from what was possible with the web 15 years ago.
Because Rails, Symphony, Django, Phoenix or whatever does the job in the preferred language of the developer/team and often has more batteries or better tooling included.
I bet those are not a Front end's preferred language and you end up need JavaScript anyway if you need some extra client form handling. Now you use two language to do one thing and made it more difficult to be maintained.
I'm agreeing with you that the "modern web" is too complex, but the "make a folder and sync it to a Linux box" solution doesn't work very well for real-world use. It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime.
>It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime.
I was pushing to *nix hosts I didn't have to manage in early 2000. Actually, one of them I recently remembered and had paid a small lifetime membership for limited static hosting (<$100) and simple shell access and guess what--the pages I put together 20 years ago and supplemental files I had hosted are still there. Not only that, they still render as intended.
I've done absolutely nothing for 20 years at this specific host and it's working today. Yes, the content is fairly static and very simple (its 20 years old) but it's all there. It's a simple shared system and no it wouldn't scale out to support more than probably 10k simultaneous requests but its served its purpose over the years. No, there's no SLA. I'm not saying services like S3 haven't been able to improve on that older infrastructure but it goes to show what very simple systems are capable of.
I've not spent a second of time in 20 years worrying about security, someone else did for a very nominal fee. This isn't a new concept, now we have better scaling available for sure.
I've often said that web development has a big culture problem.
In any other field, 'modern' is the opposite of a selling point. People want tools that work, that are proven and have years of stability and momentum. But in web development, there is an obsession with the new and shiny. It's 100% about the developer's own experience in creating a program and 0% about the user's experience actually using the half baked and constantly changing web app.
On the backend, shiny technologies like Go have been exploding — Go modules only stabilized this year! Since React was released, we’ve gone through through at least two new ways of deploying a server — containers and serverless, replete with their own huge abstraction layers like Kubernetes — and we’ve moved from monoliths to microservices and back again. And in native land, the “Rewrite It in Rust” crew is doing their best to bring the new and shiny to systems programming.
I agree that frontend web developers are maybe a bit too enamored with new tools. But I don’t think that mindset is unique to them, at all; they just happen to be the most numerous and visible examples.
Is Go really "shiny"? I mean, it's probably the most conservative mainstream PL on the market today, rivaling Java in some respects. Many claim that this is in fact why it's so popular.
I have just recently been tasked on estimating how many people in our city would fit your standard job requirements if we applied them to Go... since the requirements are legally necessary, we had to ditch any plans of using the language.
I don't think "exploding" is the correct word, although it is growing.
On the backend, shiny technologies like Go have been exploding — Go modules only stabilized this year!
This is only true in shops where webdevs dabble in back end, same as node.js. In most places you will find recent versions of things that may be decades old - Python, Postgres, Apache, even Linux itself.
Go and Rust are both older than react. And I 100% agree that backend people overengineer with stuff like kubernetes. I think that's less about the new and shiny and more an obsession with scalability - even though the site could easily be hosted on a single Linux box.
> instead of settling down and focusing on getting the most out of a platform
How do you know when to settle? Should we have stopped at jQuery?
We are doing exactly what you are asking for, but not in the way you like. Web developers are getting the most of the web platform. The result is that new frameworks and libraries are keep popping up. Most will sink, a few will float and it's okay, this is how evolution should happen. I don't like all tech solutions that I encounter just because they are new. I simply just don't use them in my projects, simple as that.
I'm sorry, but the web not just a hypertext document system to find some information, it has outgrown this idea probably 20 years ago.
And most backend engineers don't go architecture astronaut Kafka, Cassandra, Kubernetes, et al into seemingly straightforward concepts?
The number of times I've seen Kubernetes as part of an on-prem install of enterprise software when there will only be one node was hilarious. That front-end devs get flak seems to largely be because their choices are visible, not because they are any different from the weird heaps people throw together behind them.
Oh no, that's terrible and idiotic behavior as well. A lot of dumb decisions are made on both the backend and the frontend at many companies; one does not preclude the other.
For the bulk of websites that are mostly static with a little sprinkle of fancy interactions here and there? Maybe.
There is a time and place for React. Shocking to some, that place is not actually everywhere on the web. The bulk of the web IS actually about finding information. Few sites are soundcloud style webapps.
For context, I like react a lot -- I love its clojurescript re-frame variant. It is what I reach for _when needed_. The rest of the time, give me boring forms, pages, and jQuery and let me get on with my day.
I have adhd. in my experience, commodifying the use of ADHD as anything other than a mental disorder makes it easier for people to make claims like "everyone is a little bit adhd" etc.
An ADHD diagnosis is not purely based off of exhibiting behaviors typically associated with it. While everyone is forgetful/distracted sometimes, ADHDers have a physical/chemical difference in their brain which make such behaviors impossible to avoid.
> Suggesting the whole world stop doing this is silly
Just wanted to say that I don't think this is a silly pursuit, and I'm sure plenty of other people reading feel the same way. I think this is a serious issue because the language we use is related to how we act and treat each other, and talking about the issue has a real effect.
Reminds me of the quote attributed to Margaret Mead, whom I actually don't know anything about besides the quote:
"Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has."
Too corny? Idk. I like it
Yea maybe save it for when speech is actually a real issue and not over policing and treating it like it's your personal servant. Grow up and get over it
We should create a better division in web standards between the "document web" and the "application web." I think there are valid use cases to both, and we shouldn't rule out either. Wikipedia has to be the greatest realization of the initial spirit of the web: an endless interconnected network of articles of varying topics. That's a real use case, but it's not the use case of _every_ application.
Some applications really want to make use of a richer UX, one that doesn't need to re-render the entire page from scratch on every button click. Maybe Gmail is the best example of using the SPA experience to drive a rich UX. The web browser was not meant to build such applications, that's something we don't acknowledge enough. The web browser was designed, since day one, to render and link between text documents. We've been trying to play UX catch-up for 20 years at this point, and it's finally converged with lots of support for treating the web as an application platform as well (React, Angular, etc.)
So we've taken years to arrive at SPA's, but I think they're completely justified. They absolutely have tradeoffs, but they're not pointless tradeoffs. That doesn't mean that all applications should be SPA's, but I also think it's completely wrong to say that all applications should be simple documents too.
> Maybe Gmail is the best example of using the SPA experience to drive a rich UX.
My experience is quite the opposite. I still use Gmail's "Basic HTML" UI, and it takes less time for me to click a link and load a new page on that UI than any interaction on the default UI.
That’s ok. You should have the option to use that UX.
I can tell you that any non-programmer on the planet would ever choose that UX over the “app-like” feel. I think we forget that most users are not programmers way too often.
> Maybe Gmail is the best example of using the SPA experience to drive a rich UX.
Gmail is is the perfect example of an app that loses more functionality than it gains by being an SPA. Middle click to open an email in a new window doesn't work, if it was a normal web page that would have come for free. This is more important functionality to me than saving a page refresh. Same goes for JIRA, middle click at least works but the the 30+ seconds to reload the SPA in it's own tab makes it unusable.
These are both document driven apps and the document viewer I'm using them in have some great features that they cripple.
> Middle click to open an email in a new window doesn't work, if it was a normal web page that would have come for free
The fact that things like middle click and right click can be overridden in javascript is pretty much one of the biggest failings of modern browsers in my opinion. It's developers giving the middle finger to standards, and browsers accomodating those whims without considering the end user whatsoever. If your grand design doesn't include basic functionality that browsers provide then great, feel free to create a native application that fits that design. Otherwise, please leave the functionality that I rely on every day, and works in 99% of other sites, alone.
> We should create a better division in web standards between the "document web" and the "application web."
Why are those the only two options? By those terms do mean "document web" as HTML without any JavaScript and "application web" as HTML with any JavaScript, or something else?
"Why stop at two" is an excellent question, but the first cleave is the heaviest lift.
I think the first seam should be network requests. Unwind AJAX: produce the "content web" and the "interactive web." The content web should be HTML with JavaScript that can respond to events, but cannot fetch new code. This sterilizes the malware aspect of the web: JS can no longer track you (it can in crafty ways but ad blockers are a match for these).
The second seam should be aimed at the other direction: empowering the web. Factor out the "app web." This provides a native-level API which can dispense with the anti-fingerprinting, second-guessing nonsense. But the app web has higher barriers: revocable certs, user reviews, potentially frictive installs.
Eventually a document web might become interactive. For example you start with something basic, now you want to show some animations. For example in geometry visualization.
Sometimes you just need something dynamic. I need it in 99pc of my websites. Why would I start with plain js, and then move to react. Plus I already have a base in react that can be shared with all websites. Much easier to maintain all in react than a mix
Your conclusion is hard to disagree with. I don't think anyone's saying all apps should be SPA's or no apps should be SPA's
I think what a lot of us are saying here is that SPA's in general are overused in our industry when simpler solutions are more appropriate. And that's having a negative effect on productivity and developer happiness.
> But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are optimizations to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.
I think this is at the root of it — most web devs today don't see that some plurality or small majority of web app use cases these days just don't require the tradeoffs of SPAs.
But there's a generation of devs who've come up exclusively on JS tooling (Node, Express, React/Redux or Angular) and the crowding effect has therefore made those the default choices, if only because the labor pool is big.
My honest belief is you can more quickly build most functionality needed for most businesses with a plain-old full stack framework like Rails or Django these days.
But the real value of those frameworks doesn't show in the initial speed to build (though it's there!) — it really shows up in how much common functionality (logins, file uploads, etc.) you get for free 6-12 months in, and how low your cost of change stays over time as a comparable SPA app becomes a pain in the butt to add new features to.
Speaking as a young(ish) dev, I think the issue with SPAs is that it's that its use has been conflated with separation of concerns and agnostic backend dev.
What I mean by that is that the way we learned is that the old/wrong way (php style templates) mix front end and backend development, and data with formatting. It's better to have data available through rest APIs and then consume it from something. Which is mostly true if you plan on being available in a reasonable way from smartphone apps, etc. but of course that means that your website should also be a client capable of working as similarly as possible to a mobile app - there you go, SPAs.
We need to find a way to keep those benefits without the bulk of current SPAs. But SPAs appeared for a reason, and it would be wrong to ignore why it happened. Being able to have front and backend devs working in parallel is a benefit, being able to server your content to several frontends is a benefit, etc.
(And if you're thinking "these people don't need apps anyway", the reality is that clients demand to have them - even if it's only so they can bother users with push notifications or collect data, they do ask for them).
I agree with this. In my experience, adding React or friends doubles the size and complexity of your application and in a lot of cases, the benefits accrued are not worth it. You essentially end up having two applications to maintain and therefore two places to manage state and make sure they sync correctly.
I commented below that I hope frameworks like Phoenix LiveView will be the future. Seems like the best of both worlds, the simplicity of server side html rendering with SPAlike interactivity. Of course not perfectly. There are tradeoffs no matter what decisions you make.
There's no thin line for this, CRUD-FORM can be really complex or really simple. A thoughtful design choice must be made here between server-side-rendered html with some JS and a SPA.
> There’s no category winner like React as an alternative
I'm really rooting for frameworks like Phoenix LiveView, Rails Turbolinks, Laravel Livewire to fill this void. SPA like interactivity by just rendering HTML templates and sending them to the client via Ajax or websockets sounds great to me.
I quite like Turbolinks too, but it can have some unintended interactions with other JS code. If you're looking to make your non-SPA site faster another way, you can try https://instant.page/ as well. It preloads pages as you hover over them, which makes links feel like they load instantaneously. It's a pretty cool trick! You can try it out on their project website or on https://www.snazz.xyz.
The Android turbolinks version 1 adapter is now deprecated but a version 2 is meant to be coming soon. I believe it's going to come out after Basecamp's new product named Hey is released shortly.
Dan Abramov put up a tweet thread agreeing with this piece, and talking about how the React team is now looking at trying to come up with some server integration capabilities to enable a hybrid model for the rest of the community:
"React is bad in your case, drop it." I know it's far out idea in tech, to flat out tell someone "you don't need this, you just save time and money and get a better result of you don't use what we made", but it shouldn't be.
React is fine per se, the problem is throwing these "simple, magic" solutions onto everything, without even caring what mountains of code end up running as a result. The minimum for a Discourse installation is 10 GB, for example, but PHP is the weird ecosystem, because reasons. I don't mean to pick on Discourse, but that's still crazy to me.
I personally liked how easy it was to install Discourse thanks to Dockerization, and don't care one whit about requiring 10GB of space (cheapest DigitalOcean droplet comes with 25GB).
Fine, but that kinda falls under "without even caring what mountains of code end up running as a result". You use 10 GB instead of a few MB, and get an easy installation vs. an easy installation.
It's like driving a huge truck everywhere, even to get the mail from our mailbox, because it starts up real fast and we don't have it far to the garage from our living rooms, and then later on because we haven't walked in so long, we don't even remember what it is. And especially with websites, people also tend to forget that their website isn't the only thing anyone ever runs on their machine, some have to share resources with dozens of tabs.
Discourse and software like it was not as easy to install. This was literally one-click. Installing wordpress and such in the past required installing PHP, MySQL, yada yada on your server to get everything running.
I've always felt like the vast majority of apps do not need to be on React. It's too low-level. Surely it makes more sense to just use a framework like Next or Ember, where you can focus on developing your product functionality (what sets you apart) rather than bikeshedding on routers, build configs, developer tooling, etc.
PHP is literally the reason I first used Kubernetes in anger because the sheer impossibility of getting sane deployment configuration without dockerization meant we had to get something that could manage them for us.
I think a lot of the problem is React's syntax and ecosystem is too complicated for the majority of sites out there. IMO using React to make static sites and regular CMS / document type sites is way overkill no matter how performance optimized it is.
I've been experimenting with Vue and I'm liking it more and more just for the simplicity.
Ract syntax is functions + jsx. Jsx has just a smal set of additional rules compared to ordinary html, so I would not call it complex. In Vue 2 you have directives and wierd object model where you store data, getteres, watchers, etc. Each library has its own set of things which needs to be learned, and for me both basic vue and react are easy.
Jsx is not complex but it adds additional cognitive load keeping in mind everything is still JS and the small differences between Html. Also the common libraries that people use in a React app tend to be overkill. Things like Flux/redux add way too much boilerplate for small-medium projects yet everyone uses it.
Hasn't this hybrid model used by many for a long time already? SSR react as most as you can(try to avoid client-side routing), then hydrate/enhance parts of the page and make it dynamic.
The problem with not using a JS framework is that eventually, the investors/business person/design team/frontend enjoying devs wants this highly animated site with all sorts of little toggles, confirmation boxes, popup models, toasts, etc.
It is far nicer doing that in React where you can just casually npm in some online component that does that rather than in vanilla JS or jQuery. React is basically a compromise between nice interactive websites and keeping it as programming.
Nothing stays simple and when it stops being simple, you want React.
Developers like simple sites like Hacker News. Nobody else does.
>Developers like simple sites like Hacker News. Nobody else does.
I'm not entirely sure about that. Pretty sure most people just want some program to accomplish the function they're using it for so they can move on with their day, not chase around an overly complex and forever changing UI they have to keep up with, ontop of their actual work.
> Developers like simple sites like Hacker News. Nobody else does.
People like Google.
I'm convinced that users don't care for most "design" and "clever layout". Site owners do, but users don't. Which is understandable, you want your site to stand out so you make it special. Users usually don't want special, they don't want to think, they don't want to figure out where they need to hover for functionality to reveal itself etc. I do believe that users would be much happier if layout/design possibilities would be much more restricted, like they are on mobile, because there's no constant re-learning there.
The problem is that designers and developers need to get site owners on board, so they are selling to site owners.
Well, when I am considered a developer AND a stakeholder I may be able to address that AND not be told that I'm going to implement the carousel because "market research" anyways.
The cases which should be simple, don't give anyone a chance to be impressive. This applies not only to the devs, but also to the managers (and designers, and etc).
I am impressed with simplicity, but most people aren't.
I expect it, and I demand it. We're in 2020, I don't want to click around on hyperlinks - I'm sorry. I grew up in a world of interactivity and the iPhone.
My bar is very high for consumer services. Animations and smooth transitions are table-stakes.
Surely you also grew up in a world of web browsers and hyperlinks. They haven't gone anywhere. There's just more applications on the web now in addition to traditional websites and hybrids. When I use the browser on my phone, I'm usually touching hyperlinks to go to different sites and pages, and often those hyperlinks are shared on different apps.
>Developers like simple sites like Hacker News. Nobody else does.
StackExchange ( Which is not only about developers ) Serve their Server Rendered HTML page in less than 20ms at 98th projectile with little to no caching.
They didn't even bother caching their most popular section or page.
Wikipedia has been taking some strides in this direction. For example, on the "mobile" site, if you follow a link from an expanded page section and then go back, the section is no longer expanded, and you lose your place. (Then it re-expands, but you're in a completely different place on the page now.)
This type of stuff is one of the reasons why I choose to support older browsers like Netscape, IE, and Lynx. I think that a website which would have been usable 25 years ago has a much better chance of being usable by some random person using an old device I've never heard of and a browser I've never tested with.
It turns out that aside from HTTPS, most older browsers can do quite well with HTML websites! If you do it right, all old browsers will be able to render it because it'll work in WorldWideWeb.app.
However, if you want universal html (no changing the html for individual browsers) and some half-decent web-app functionality and no-js compatibility and accessibility and for it to look pretty, be prepared to spend many hours tweaking it.
Here's a video of some testing I did recently. Here, I discover that IE doesn't play nice with being forwarded to a URL which has an anchor at the end.
Use the right tool for the job. Why is this so controversial?
Yes SPA frameworks are overused but a lot of modern web "apps" are actually real applications and can't be built on a reload-the-world on a mouse click paradigm of the old web.
What constitutes a real application? There is some obsession with preserving client-side state as if the user could not live without it, and yet in almost every case where significant engineering has been put in to (essentially) reimplementing a web browser within a web browser, the result is either on a par or slower, and almost always vastly more cumbersome than just shipping a brand new page.
There are so many things the majority of applications never even try to get right, like progressive loading or history management, that have been solved problems for browsers since the dawn of time.
Separately, avoidance of client JS eliminates multiple classes of potential bugs, because eliminating (or minimizing) active behaviour on the client prunes vast chunks of the overall application state space.
I hire contractors quite regularly, and the amount of time I waste almost weekly having to explain "no Javascript, rip it back out, you're making a mess", because so few people seem to understand this. Our market is somewhat unique, in that most clients are high latency low bandwidth, but even if that were not true I expect my direction would still be the same.
"The page content is smaller as JSON" .. "you introduced a round-trip, game over"
"We only need 200KB of JS what's the problem" .. "the page didn't even start to render until the last byte of JS was loaded"
"We can implement mixed rendering and fix this on the server" .. "or you could just send HTML and rip out the JS, which is what we're doing"
This is an overly broad statement. In the last year, for example, I've built an in-browser SVG vector drawing tool and a very detailed dashboard with a lot of nested charts and data visualizations. Neither of these would have been possible without a heavy client-side JS component.
My current project is an e-commerce app that's almost entirely server rendered. I avoid JS where it's not needed but also avoid irrational biases against it when it is needed.
Honestly, I think it's controversial because a lot of frontend developers lack critical thinking. There isn't a nuanced technical assessment, they just go "Oh React is the industry standard let's use that", with no regard for whether or not it fits their use case.
I also see this a lot within the React community with things like Hooks, you have Dan Abramov giving one presentation and a lot of the immediate reaction is "this is a panacea, the future of web development, it's perfect".
Joking aside, was thinking exactly the same while reading the article. This has been talk about for years, and today there is lots docs and resources for devs to be able to make a thoughtful decision of going SPA vs no-SPA.
It's controversial because it directly effects us. I wish I didn't have to develop in a JS framework but as a full stack developer almost every company I come across requires me to.
I've barely used Next.js, so take this with a grain of salt, but to me the whole "hybrid" approach where you statically-render-and-hydrate has always felt like one big heaping pile of hack. The amount of grotesque complexity that's required to achieve this "best of both worlds" solution, and the number of asterisks that have to be added to that title, have never sat right with me.
I'm a believer that you simply need to decide from the outset: "Is this a web app that people are going to dwell on? Are they going to stay here and use it or are they simply going to visit it?" And if yes, go all-in on treating it as a capital-a App whose "binary" consists of minified JavaScript, and if no, just stick with server-rendering. Most things fit neatly into one or the other. There's no need to shoot for the moon.
I do have to disagree with this part, though:
> The high performance parts aren’t React...The level of abstraction that React works on is too high
In my experience it's perfectly possible to write your complex, screaming-performance app in React or the like and spot-optimize it as needed. I've done that sort of thing myself. Now, something like Mapbox probably lives mostly in WebGL, which is not concerned with the DOM, so that portion isn't really relevant to React. And the question does get more complicated when it comes to shipping an embeddable widget. But at a base level, I think React and its abstractions are perfectly well-suited to high-performance apps.
The good thing about starting with just server rendering is that you can sprinkle in react if you just have one section with heavy interactivity and build from there, whereas it’s harder to go the other way around
What I dislike the most about the modern web and the unnecessary use of SPA technologies is how unreliable and error-prone it has made sites that really need to be simple and reliable. For example, banking websites, utility websites, government websites (like DMV, unemployment, and others), anything where failure or mistakes have a high cost.
These sites should stick to reliable, tried and true, pre-SPA technologies. But now that's "boring" and "not-modern" so they rebuild using React (or whatever is the popular SPA framework this month) and the result is often a huge degradation in site quality.
Because of the cargo culting, you see all sorts of Fortune 500 companies using this for fairly critical end-user tasks and failing at it. Air Canada did a redesign a while ago and I still can't book a flight on there. You look at the console and it's barfing all sorts of client-side errors and 500's. I would rather have a static, slow, reloading app that is reliable.
There are good uses for SPA's like ticket sites that have virtual queues and office applications. I just don't see the advantage SPA's give me for a lot of critical things I need to do in my life.
IMO React and it's ilk are amazing in some applications but the problem is trying to make 'everything' a React/Angular/Vue app without considering scaling or how it would benefit a user. I have been tasked with building complex UX'x which would've been far simpler and performant as a multi-page type app with some plain JS sugar.I agree with wrnr - I too am leaning more towards WebComponents where some dynamic functionality is required. It provides us the ability to not only keep the tech stack small and also avoid all the dependency and version pitfalls.
Reeks of obscurity engineering. Simple crud is being rewritten into react, things that could be done 300-400 lines are being written into 2 month long projects.
The vast majority of tooling, pages, functionality is so simple that I want to puke every time someone drops in node,react,Vue to replicate something that could be done in 100 lines of python or perl.
You guys should give Svelte a try. It's a breath of fresh air for modern JavaScript. Your codebase becomes much simpler. It's much faster and lighter than React.
It doesn't give you absolute flexibility like React + JSX does, but it solves your most common problems much more pragmatically.
Not all of them. Without the overhead of rendering everything to a virtual DOM and then doing a diff, performance can get pretty close to native javascript--the sweet spot the author mentions gets bigger. Plus since the framework is mostly just a compiler, the bundle issue is less of a big deal.
Virtual DOM actually has some efficiency benefits. So it is not as easy as no Vdom = better. Also React, Angular or Ember does not add a lots of code to the project. I am 100% sure real world app written in each of major frameworks including Svelte has almost exactly the same size. Svelte has the same problems like React or any othe framework.
>Virtual DOM actually has some efficiency benefits.
Please explain these efficiency benefits. VDOM architecture can't be faster than native javascript updating the DOM because at the end of the day you still have to to use native javascript to update the DOM.
> Also React, Angular or Ember does not add a lots of code to the project.
They do to small apps. I tend to embed small svelte apps inside of a larger multi page apps to handle more complex UIs. In that use case the much smaller overhead helps tremendously.
You don't need a VDOM to use a buffer to batch changes. A VDOM is a buffer that comes with a huge amount of overhead vs an ordinary sequential buffer of DOM manipulation commands.
VDOM is an optimization that allowed react to be fast enough to work, it can never be faster than direct dom manipulation.
VDOM isn't useless. It's basically an optimized immutability helper. React wouldn't have been feasible without it.
But mutating the data directly is always going to be faster.
If you want to operate at a level of abstraction where you can ignore mutability and say rerender an entire huge ul every-time a single li changes, then using a VDOM to calculate the diff so you can only replace the single li is going to be faster than replacing the entire ul directly in the DOM. In many cases this is fast enough and so you get to program at a that higher level of abstraction.
However, if you have code that just directly replaces the innerHTML in the single li that changed, the VDOM can never be faster than that. Because it has to do that as well as calculate the diff to find which li it should change.
In essence Svelte just runs more of its abstraction optimization techniques at compile time instead of at runtime.
Obviously Svelte can't do nothing about the misuse of Svelte (which is one the major points of the article) but:
> The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too high for any company to include it as part of an SDK.
Svelte is just a simple way for you to write vanilla instructions. There is no runtime and practically no framework.
Other than React he is criticising problems which have better solutions than the ones he is proposing.
For example the bundle splitting problem can be solved by a smart browser refresh at the appropriate time.
The SSR problems he mentions are non existent with Svelte as the JS needed for an SSRd page is probably less than 5kB and since those are so small you can preload all JS files on the first user visit. He also mentions authentication problems which are non existent if your SSR app talks to the database and uses some KV cache for sessions. It's also certainly possible to cache the HTML, not only in the server but in the browser too using service workers.
As for his critique of APIs I don't agree. He also states that "GraphQL application will suffer under the N+1 query problem" which is true on the most simplistic implementations. Hasura, Fauna DB, and other GraphQL servers don't suffer from this problem at all.
> There is no runtime and practically no framework
As a fan of Svelte, I really wish people would stop repeating this. There _is_ a runtime in the form of repeating patterns of code, which are objectively less ideal than the not-so-revolutionary approach of just having a runtime. Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and having best-in-class perf. On the other hand, the question of how the Svelte repetition scales as an app grows is a constant worry that drives away would-be newcomers.
> There _is_ a runtime in the form of repeating patterns of code
Obviously there has to be some running code at the end, and technically you are right, but I think you're splitting hairs and for a brief introduction it makes more sense to say that there is no runtime.
Also I think I implied your point with "Svelte is just a simple way for you to write vanilla instructions".
> Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and having best-in-class perf
I'm not sure about this point.
I do agree Solid is currently faster than Svelte, at least on synthetic benchmarks.
OTOH compilers can optimize hand written code which a runtime cannot do. We see this in assembly written by C compilers for example which have been optimized for decades and will beat the vast majority of hand written assembly. Svelte is very young and, while I could be wrong, I believe we will see performance improvements over the years. I also think this would be completely unnecessary.
> On the other hand, the question of how the Svelte repetition scales as an app grows is a constant worry that drives away would-be newcomers.
If you're doing a SPA this can be solved with code splitting which is trivial to implement [1]. If not then Svelte will ship comparatively less JS than any other framework that needs a runtime[2].
BTW, big fan of Mithril here, are you still working on it?
I'm mostly worried about the _optics_ of saying there's no runtime, because if people think "hey Svelte looks cool BUT I'm scared my bundle size will be humongous", then they won't convert. And Svelte sure could use some more adoption to get the adoption snowball going. That's all that it boils down to.
Svelte is a compiler, and yeah you have to structure your code to fit certain patterns, but there is no framework in the end result as you would expect from React/etc.
Real World application written in Svelte requires a lots more libraries and code to supplement parts Svelte does not provide. So in the end you still have a big chunk of data.
Svelte does not make the problem dissapear. Svelte does not provide a solution. Svelte has exactly the same problem like React.
> If Wikipedia were started today, it’d be React. Maybe?
No, I'm building a hard fork of wikipedia and I'm using Go to render the pages on the server side and a vanilla JS for a user friendly the rich text editor.
I don't know why not more people use WebComponents as a light weight alternative to React/Vue/Angular. It was natural choice in my case because it grew out of the desire to keep the tech stack small. For now I haven't find a reason to regret it, two way databinding is nice to have, but when the js is reloaded with every page, the global state is easier to reason about and less of a problem.
Probably because "more people" are not trained to "use WebComponents as a light weight alternative to React/Vue/Angular", let alone lead a team in that direction (and assume responsibility for a thing that has no market value on their resume... it's the situation 80% of tech workers find themselves in).
Momentum is a b#%~~ I mean, momentum is hard to ignore.
The sad reality is that trendy will always be driving behaviors for as long as recruiters attach value to buzz-words and -names.
Meanwhile, I guess a few will take the risk to do good engineering and damn the name of techs used, hopefully to rise to decision-making positions. Hopefully. Oh who am I kidding.
Both, its 2020 wikipedia should have had a WYSIWYG editor a long time ago. They keep making excuses why this can't/should't be the case, so I want to migrate over the content to a new system.
> But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites.
If "React" is used loosely here to mean a modern frontend framework, then at least one concrete benefit is the ease of splitting web pages into components, and the ease of co-locating CSS with these components.
I have tried Eleventy with nunjucks, but compared to the way React (Vue, Svelte, whatever) allow you to organize your code, it felt really awkward. Even Google dev rels, such as Jake Archibald, admit that they love the developer experience of something like Next.js [0]
This is pretty much it, tbh. Every time one of these types of threads pop up you get a bunch of people commenting about how broken the web is and how it sucks because front end devs aren't real devs or something, and it's immediately clear to me that none of them have done any serious work on a modern website.
The problem is a business/orgnanizational problem - it's not like developers are incapable of mimicking their own websites with pure html+css+js (especially with all the improvements to JS and the browser apis over the years), it's that doing that and then maintaining and growing it with a team of people is basically impossible at any useful scale.
Frameworks provide a common language for teams to build their site with. The fact that they also currently introduce a lot of extra complexity that require developers to handle previously "free" things (ex. performance, bundle splitting) isn't some fundamental flaw with the idea of frameworks, it's just a result of people still trying to figure out exactly how the hell you can provide a nice, interactive site with all the bells and whistles that'll make like 5 different groups of stake holders happy.
My subjective counter-take: "modern web" is fine and where it lacks it is improving over time. React/Vue/Angular/Webpack are clear improvements over what came before despite the learning curve, which is obviously much overblown considering all the hand-wringing over n00bs using React for their blog.
React is not to blame because someone used it to build a blog, but it's also ok not to make an SPA. It's also ok to filter JavaScript out of your job search so you never have to build an SPA ever again. Lastly, the best part about "the Modern Web" is that the 20 year old approach to building web pages still works just fine, fire up NotePad++ and have it.
This is an absolutely perfect take on what’s wrong with front-end web right now. I've been trying, and failing, to explain this at work for several years now. Indeed, swimming against the cultural tide is hard.
React is built on two fundamental ideas that are both extremely valuable. The first and most transformative is that the web is mostly made of _components_, and specifically that organizing the markup, javascript, and CSS makes many thing easier. The second idea is that _declarative programming_ is better than imperative.
The thing is, HTML and CSS are already declarative. So React is not inventing this, nor bringing it to the web, but rather providing a pretty solid idea for how to make Javascript (or more generally, complex interactivity in the browser) declarative as well.
Thus, as MacWright argues, there is a sweet spot for React (or similar libraries) where you have highly interactive, complex UI elements on the screen.
But the rest of the web really, really doesn't need it, and when you try to apply "React Everywhere" things get very bloated, slow, and complicated, very fast. This is _especially_ true if you didn't start from scratch with Next.js or create-react-app, but are incrementally converting an established application. It's just painful.
I think more and more people are realizing this, and the fact that Dan Abramov himself agrees is pretty indicative that the tide is going to turn. But the question is, what next?
One major problem that the author didn't go into is the special pain of bundling front-ends these days. The actual work of setting up and integrating a "modern" javascript asset pipeline with a server side framework is not trivial, and I've yet to see a framework nail this. In the ones I've used there's always some gotcha - if you don't roll your own web pack (and understand what every bit of it is doing), you will eventually run into some library you want to use that just won't play nice with the rest of your bundle, and then you have a problem. And on the JS side, even simplicity-focued tools like Parcel are SPA oriented, thus gluing them together with your server-rendered app is non-trivial.
I think that will remain an issue for a while. But it also means there's an opportunity for the "old school" frameworks to keep working at this and, if they really nail the bundling and server-rendered / reactive component handoff, to thrive in the next decade of web development.
It's my personal philosophy in many things, but I like to insist that it's far from being the end-all be-all of good engineering in general. Perhap so I don't fall prey to the usual weaknesses of a hacker.
I see this sentiment a lot, and sympathize with it because I value accessibility and access to content by people with less powerful devices and connections.
But full time I'm employed to build web apps that I can't conceive of building without Vue or React or some other AJAX tool at least. For example, a node management system, displaying up to twenty disparate nodes at once. Client expectations are that any edited node is immediately persisted to the server. If I refresh the page, I've got to rerender each of those elements. If I'm not using tech that has things like v-for, I'm building out 20n wonk ass custom event handlers from scratch... I'd love to find ways to build this vanilla, I do that for my personal projects, but I don't see a path.
SPAs are a product of the mobile app frenzy of the early 2010s. Web devs felt left out and tried to mimic the shiny UX of mobile apps. Also SPAs allowed the web app to be just another frontend client, like a third mobile OS, sharing the same server API that the mobile apps consume. Generally trends that are based on delusion (that the web is just another app platform) tend to run out of steam at some point. Use the right tool for the job. You're not Facebook or Twitter. I can finish a Django hello-blog while you're still trying to get WebPack to transpile TypeScript(TM).
React, Redux, Webpack, 90% line coverage testing requirements...
I understand intellectually, sort of, kind of, often not really..., why those things came to be... but for fuck's sake, they have really sucked the joy out of my web development.
It feels so much more free and fun to just sit down and hack some vanilla HTML/CSS/JS.
The modern web development stack has attained "bondage and discipline" levels rivaling those old Java enterprise edition stereotypes.
This discussion reminds me of Java and C/C++. In those days, we used to write messy programs in C. The language works well if you want to write some targeted libraries. It becomes really difficult to write complex software. I think Microsoft Windows has thousands of engineers to maintain their C codebase.
Java appeared on the market. It's a big change. It really brought out the goodness in Object Oriented paradigm. It made software engineering more rigorous. Most enterprise software made the switch to Java. They need the reusability of Java. Microsoft came out with C# to counter the rise of Java.
We have the same situation here with JavaScript and TypeScript/React. React brings structure to the messy world of JavaScript. But it also incurs the cost of traditional enterprise software engineering on the web development. I expect performant libraries to continue in plain JavaScript. Reusable web components will move to TypeScript/React. It's exciting to have better technologies to use for our projects. I don't think one will diminish the other. They'll both co-exist.
The first big project I had as a professional SWE was to rebuild a checkout page to use React. Seems like overkill for a single checkout page to be its own React app? It wasn’t. There was a lot of edge cases. It needed to handle different countries (some have states, some have zip codes, Brazil has a crazy tax scheme), different SKUs, different payment methods (including resellers), free trials, etc. The original template + jQuery rendered version was nearly impossible to work with. Any sort of change would take forever and would lead to bugs whose patch would only increase complexity.
React substantially simplified the page, and it actually looked and performed much better since there wasn’t any jankiness from HTML rendering before JS could correctly format the page. We were then able to experiment on the page to optimize the experience and drive conversions.
TL;DR, more often than you would expect, the tiny performance costs you face from using a SPA is more than made up for by being able to develop quickly and more confidently.
There was a recent article on having your website be entirely statically regenerated except for a select few components that require interactivity: shopping carts, comments, etc.
That way, your entire site is basically live just on a CDN, infinitely scalable. Even if your API server goes down, only the small subset actively engaging with interactive content would know! With client side persisting technology like service workers, you can pair down which interactive content matters for that.
Really seems like the direction I'd want for my next project. And, again, Svelte and Sapper support exporting static sites... Really I'm continually impressed by their position I'm supporting great patterns out of the box.
> But the cultural tides are strong. Building a company on Django in 2020 seems like the equivalent of driving a PT Cruiser and blasting Faith Hill’s “Breathe” on a CD while your friends are listening to The Weeknd in their Teslas. Swimming against this current isn’t easy, and not in a trendy contrarian way.
more like, your friends are listening to Weeknd on vinyl and gramophones because their friends do. The more i read about JS frameworks the more i want to start doing everything in Perl again, or C, because its the work that matters and not the tools.
React is a great example of YAGNI and premature optimization. I'm sure Facebook benefits from it, but most websites don't need it. JSX is an abstraction encouraging deeply nested components, which makes state handling hard, necessitating the invention of React Hooks. "Controlling complexity is the essence of computer programming" -- Brian Kernighan. I see a celebration of complexity in modern website development and it makes me sad (I'm retired, I don't get that sad about it.)
I'm not a React expert, but I wonder how do you interpret this by Dan Abramov? This is where I got my information about hooks before trying them out:
React doesn’t offer a way to “attach” reusable behavior to a component (for example, connecting it to a store). If you’ve worked with React for a while, you may be familiar with patterns like render props and higher-order components that try to solve this. But these patterns require you to restructure your components when you use them, which can be cumbersome and make code harder to follow. If you look at a typical React application in React DevTools, you will likely find a “wrapper hell” of components surrounded by layers of providers, consumers, higher-order components, render props, and other abstractions. While we could filter them out in DevTools, this points to a deeper underlying problem: React needs a better primitive for sharing stateful logic.
Right, it's not that managing state was hard it's that sharing the logic to manage it was hard. Hooks are additive in that way -- it's offering you the ability to re-use your stateful React logic in the same way you can re-use your declarative JSX.
I think one of the big reasons a lot of people are moving to SPA or SSR + hydration is latency of dynamic content (static content can be cached at the edge with little effort).
The problem with traditional PHP/Rails/Django apps is that those cannot easily run on multiple locations. Even if you somehow find an easy way to redirect the user to a server near them you still have to solve the problem of replicating the database. Big companies with cash and talent can solve all that but for small dev teams this is much harder to solve with a traditional web dev approach.
With an SPA your user will click and the UI will refresh instantly, even if it's just to show a spinner or some mock data, but that will be enough to distract the user for the time it will take for the API to respond.
With SSR you can run your html rendering code in serverless functions at the edge. Your latency will be sub 100ms, even sub 50ms when you hit the DB cache. I'm doing this with Cloudflare Workers and Workers KV as a cache and using Fauna DB which is also ditributed and running close to the edge. If it wasn't because the local dev experience of workers is still in alpha I'd say I've hit the jackpot of performance and DX.
Scaling is another matter but I don't think it's such a common problem for the vast majority of projects as latency which happens on every request.
> And then there’s the authentication story. If you do SSR on any pages that are custom to the user, then you need to forward any cookies or authentication-relevant information to your API backend and make sure that you never cache the server-rendered result.
Isn't this also a problem in conventional server-side-rendering (eg. PHP) websites? And Steam once had a caching bug and accidentally showed people others' profiles?
The only important question is whether this is a technology problem or a business problem. Fundamentally the problem is this:
Web developers don't know what they are doing and oversell their capabilities.
To be more clear though, this isn't a new problem, just that the symptoms of the problem have changed as the tools have evolved. I remember starting at Travelocity in 2007 and they sure as shit didn't know what they were doing either. All the JavaScript developers there, except for 1 (so about 6 of them) were spun off onto a special project that never made it to production. There was 1 guy left to write JavaScript for the rest of the site in a company who only real product was a website and employed 3500 people. All the other developers were Java people. Most of those guys were scared shitless of web technologies. There were a few Java developers who had a solid working knowledge of CSS and JavaScript but worked extraordinarily hard to keep that a secret.
That was a big WTF, but then I discovered it was also the same at both Expedia, Orbitz, and Southwest.
Now people really, and I am not being figurative, expect Angular and React to do their jobs for them from solving technical problems to telling them exact what products to build.
Worse still is when you point out the incompetence that so clear to everybody else the developers doing the work get angry. I mean hostile out to stab in you the back angry. The non-developers see the dysfunction and have absolutely no idea how to manage it or solve for it. Sometimes the dysfunction is so pronounced that it leads to inter-department warfare within the company, as was the case in one of those previously named travel companies (not Travelocity).
Here I am 13 years later working on the web that is now a 30 year old platform (20 years old if you count the modern standard web), and its still the same shit show. How have businesses allowed such cancer to prosper?
What you describe as "broken" is what I imagine to be the ideal situation.
I expect travel agencies and similar websites to have a rock-solid back-end, and I don't care at all for any Javascript fanciness. In fact I would expect their websites to work with JS disabled.
The fact they canned whatever special project the JS developers were working on might have been the right decision (and I just checked, Travelocity is still in business).
> I expect travel agencies and similar websites to have a rock-solid back-end
They had no such thing. Sometimes their shopping carts were so horribly incompetent it’s amazing we generated any revenue at all. Pretty bad since they had no idea just how broke it was until investing in something like Tealeaf.
I strongly support this sentiment. I’ve recently come to the conclusion (after building a non-trivial react app from scratch) that the optimal use case is in a rails/django/go/whatever app that only uses react to handle front end state for the hairy components while the lion’s share is handled by the server.
What would that look like in practice. Would you write 95% of the basic crud stuff as server side rendered then just have the React or Vue component for the really complex UI stuff?
Would there be downsides having the mix of languages (assuming your backend language is not JavaScript) ?
most of the page is server rendered. The hairy bits (eg. complex forms, super interactive components) are react and they maintain their own state. There might be downsides but they're probably not worse than writing a bunch of jQuery.
I get the SPA movement. I’m a big proponent of it. If a user is navigating between many similar pages or wants high interactivity without a page load then you want to cache the views as js scripts via cdn and only download the data via REST calls to an api. It works well with mobile apps too. Both web app and mobile app talk to the same api.
What I don’t get is the server hydration kungfu. If you’re rendering the template on the server then don’t do the same thing again with js and download the data twice. Just render html serverside and call it a day. Either app or a site.
A tiny bit of jquery like JS snippets for banners and image galleries make sense but that shouldn’t be render blocking nor be in megabytes.
I’m a big proponent of Preact over React. Same API but much smaller library. The difference is noticeable when browsing on 3G networks and low powered devices.
The core issue is that the web was intended as a document delivery platform, not an application delivery platform. That mismatch means one of two things: you either have to pervert your application to expose a document-centric UX, or you pervert the document platform to look like an application platform.
I would say in 95%+ of cases, perverting your application is the better choice: my core issues with the web now are surprising/malign UX patterns and terrible performance, not cross compatibility or lack of features offered by browser APIs.
That doesn't mean you should forgo JavaScript entirely, but the construction of the UI and UI interactivity should not be its primary responsibility.
I've found that using things like React, for things as mundane as a blog or marketing site, just makes me sad. If my pursuit was to spend my time thinking about tricky issues — which it is — I get sad when to output doesn't necessitate the complexity I navigated to get there. Whatever I end up doing next, I hope it's something more interesting than webpages re-invented. Even working on purely design is way more challenging and interesting, and necessarily so, than frontend web "engineering". Things that do fall outside of this reduction are fully interactive applications like Mapbox studio that really weren't feasible before.
In fact SPA in general are suppose to work around a single issue, sending a request will lose all your state and reload the whole page(If different content, downlaod whole html). Since most website have multiple routes this is an actual issue. You need to sync state with server for example. I think the solution will be able to say "all this route are the same site" to the browser and now browser can be able to allow delta update or store some variables. This will be perfect with html imports.
While I largely agree with most of the points made, I strongly disagree with the objections made about APIs. In general, that section seems to have been written with the assumption that the web application is the only client an API can have.
This ignores mobile applications, desktop applications, third party services, webhooks, SDKs and maybe even command line interfaces. The more standardized the API, the easier it is to create multiple clients for it; it's one of the principles of the clean architecture even.
ISTM you need to strike the right balance. The ideal is that you have a static site and fetch data using JS -- this is good because it's simple. Most pages don't have a lot of data, and if there is data and its dynamic, then JS is needed to make the app responsive. On the other hand, if you have content that you could be fetching using JS but it's desirable to have it rendered every time you land on the page, then yeah, you want to render it server-side.
Reading stuff like this gets me hopeful that https://github.com/obsidiansystems/obelisk/ (from where I work) will be able to reach a wider audience. The author is right that the React ecosystem doesn't deliver what it claims to, but I think is overly pessimistic that the use-cases he describes are too diverse to be solved by a single solution.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction."
Web development clearly has a problem. I don't know enough to say what we have to do about it but I look at the current state and my face curls up in disgust
> I can, for example, guarantee that this blog is faster than any Gatsby blog (and much love to the Gatsby team) because there is nothing that a React static site can do that will make it faster than a non-React static site.
Gatsby produces static HTML which I guess is the same with the authors' website.
How can we compare two static HTML websites and conclude on what's faster? Just by saying so is not the answer.
This raises good points. SPA are certainly not the right solution for all projects. Static pages (such as AMP) are great for document type projects where speed is important and vanilla is often needed for high performance apps. It's a great reminder not to jump into create-react-app without first considering the right approach.
I've been freelancing whilst working on some of my own projects, and have helped a devent number of clients get their front end approach cleaned up enough to work for their end-user and use case.
So when I read an article like this (which I like by the way), I make comment/response style notes to make me think through it; its long but I've dropped it in here in case anyone cares:
The issue with bundle splitting for SPA's that he mentions is a real thorn in many peoples side. A not amazing, but workable solution is to structure the site as follows:
* Split your "entry" bundle down to nothing, so it is only the map of other things that can load and a bootstrapper that looks at the URL and loads the right one.
* On the server generate html files for all your main endpoints (or hot routes for dynamic paths), ideally these are Server Side Rendered, but at a minimum they must include a script tag for both the normal entry bundle and the correct primary bundle for that page (ie, you eliminate the round trip for requesting the bundle).
The issue of running an "out of date" app is a present one. I can often restructure it to gracefully cache the state and refresh at an appropriate time without the user noticing, but it is often a far cry from simplicity.
His attack on SSR is largely correct for the way people currently deploy it, but there is nothing stopping you doing it a lot better. It is perfectly possible to generate correct HTML that works without needing to have a hydration step - its just most people aren't willing to, or knowledgeable enough to, do the work to make only the parts that need rehydration be hydrated (or, allow everything to be rehydrated but with no effect to the majority of the page). To be clear, you don't need to hydrate links, buttons, or even basic forms.
Of course, anything that genuinely requires your app js to be around to do anything reasonable needs to be there; but if you aren't looking for a drag/drop stay on page interaction you can normally just add a traditional route to allow it as well (more work of course).
He is right about API's. Though I'd hardly count it as a web or an SPA problem. Software is all about abstractions and how they are very leaky (likely "unfixably" so).
I was surprised about the data fetching comment. I've taken a look at the React docs and done some searches around the web, and he's right. Unless you know what terms to search to get the useful patterns its just a mess of amateur/broken Medium posts.
SPA's are built on top of browsers that are trying to predict where we are going and react to where we were yesterday at the same time. I'm with the author that most things don't need react, and that the things that do are mostly SPA's that have to be SPA's. I have worked with other frameworks before, but my hammer is a nodeJS & React stack I've cobbled together; thankfully its very good at SSR generating static sites, so most people don't know I'm using such a big hammer.
And we finish with a wishy washy maybe its right maybe its wrong, do we need this, maybe we do, maybe we don't.
Here is something concrete. I'm writing a small web application for my sisters business that I'm going to be doing all the legwork to see if it can grow into something. It isn't a SPA, it has some highly complex interactions, and it only uses React as a static site templating language because of my exisiting well-tooled stack (hammers make things nails).
I am not a web dev, but what exactly is an alternative to fat spa if you are building a truly interactive front end? How does server rendering work when you lose connection to the server?
- Browsers are a privacy mess. Users are left exposed to blatant fingerprinting, tracking across websites, etc.
- Instead of JavaScript as first class language, use WebAssembly or a similar language as a first class language. Developers may continue to use JavaScript if they prefer, but the code they deploy should be WebAssembly.
- Instead of HTML and CSS, browsers should use a binary representation of a document. Developers may continue to use HTML and CSS, but what they deploy is this new binary format, not HTML and CSS. That would make documents more compact and render faster. And, this makes it possible to replace HTML and CSS with something else.
A lot of the comments here are missing two key points:
1. Google and Facebook have created really high-standards for what's considered a usable web application
2. HTML is still a language highly optimized for creating static documents, not building the reactive applications most devs want to build
I think experienced developers might even deliberately ignore how much of a moat these two facts create for big companies (because it serves their interest as well).
Think about it: if styling/designing/building a web app like Google Docs was easy, do you really think Google would be able to maintain its lead in every vertical in that market for so long? Sure, maybe for some use cases it's the best solution — but what about lawyers or doctors: they could certainly use a custom version of a real-time document-editing app.
But, by keeping web development hard (i.e. split into a million different technologies that have trouble connecting with each other), Google and Facebook have enough breathing room to be able to create THE real-time work platform and THE social network, without worrying too much about competition sneaking up behind them.
And, if some small startup does manage to get off the ground despite the incredible engineering effort required, Google can just copy or acquire them with some of the billions they've made from their technology moat — and voila, as an extra bonus — all the devs who work at that acquired startup are already trained in the specific framework that Google and Facebook uses (oh yeah... that's why they open sourced it in the first place...).
By creating this huge moat between what's a "good enough" real-time web application in the eyes of most users (who expect instant updates, smooth transitions, collaborative features, and interoperability by default) and what most developers can pull off in a few months, these big companies can ensure they stay on top and not too many competitors arise.
And why don't developers fight back against this? Because this moat benefits us as well. It artificially inflates our salaries by making web development a super complex field. Not only do you have to know a lot of technologies and all of their secrets settings, you also need to know how everything fits together behind the scenes.
Can you imagine if web development was as simple as learning a single language? We'd all be making far less money by tomorrow.
All these moving pieces and arcane knowledge gives us pride in knowing something other people done, while making it extra hard to be a new developer. It also protects our employers from being disrupted every 2 weeks, giving some economic stability to the tech market at large.
Another benefit it provides to those already in power is an easy way to control who the next breakthrough success: if you're running a startup that's competing (even tangentially) with Google or Facebook or the thousands of other entrenched players, you'll need a million dollars just to catch up to them in terms of creating a usable product. People aren't going to be impressed with your photo sharing app if its interface isn't as sleek as Facebook's or Instagram's.
What's the solution to all this? The no-code movement? Perhaps low code?
Nah — those are patches in a sinking ship. The fundamental fact is: the web wasn't made for building dynamic web applications (and web components aren't actually simplifying the process).
Think about this: your browser doesn't even know what a "user" is or how to connect to a database or what a SPA is. And how long have we been building these things over and over again? It's absurd there aren't standard APIs for all of it...
But that would destroy the moat.
I think the true solution is a next gen version of HTML that abstracts away and standardizes everything difficult about building a web app.
Devs need to be able to focus on just building awesome products that serve a need — not configuring Webpack and getting a 5 year degree in CSS before even getting started.
It's too bad Google owns the most popular web browser (that could actually make a difference in this fight) and Facebook has convinced every developer I know that they've solved web development. It'll be their self-created competitive advantage until all developers simultaneously go crazy from having to re-implement the same damn architecture again for the thousandth time.
I think deep down people writing SPAs really just Flash apps or Applets would come back. They want to ignore everything about the web except the ability to deliver content over a network. I'd go so far as to say they hate the web as a concept.
Most problems stem from that disdain for the web. Many of those problems are then exacerbated by "opinionated" frameworks being en vogue. None of them are helped by the shit platform that is JavaScript.
I've seen the justification for SPAs front end JavaScript frameworks being a desire to separate data and presentation. A back end API serves data that's displayed by the app. We had that fifteen years ago with XSL!
There were these things called "browsers" and they could parse and display HTML and even XML. They supported stylesheets that could arbitrarily style those documents for display. They could even decide to use different styling depending on the display device! If they sound amazing they were.
I mentioned XML parsing. An XML document could be used to represent all kinds of arbitrary data. While a browser might consume XML, a native application or service could also consume it. But arbitrary XML in a browser wasn't super useful since a browser didn't have rules to display every different XML document that could be made.
The people that developed XML also came up with a way to transform data in XML to different formats. Browsers, being able to handle XML already, added support for this transforming. An XML document could include a link to this stylesheet and the browser could transform it into something (XHTML) that it did have rules for displaying, including CSS to further style elements and JavaScript to make everything terrible.
A native app or service consuming an XML doc could and often would ignore the stylesheet so to them it was just data. Even JavaScript asynchronously loading XML data would ignore stylesheets. Usually it was only browsers that cared about linked stylesheets.
But this let a single API serve browsers and native apps and even JavaScript. Presentation and data were separate concerns. Browsers would also cache all the display resources for a document so when a new document was viewed all of those resources would be cached locally.
But then for whatever dumb set of reasons web developers ignored these "browsers" and and their cool abilities. They insisted on ingesting XML to their JavaScript and then manipulating the DOM of an HTML page causing hundreds or thousands of repaints. Then they knew better still and replaced XML with JSON. By making the data serialization format require JavaScript they could obviate the browser even more. Now browsers are relegated JavaScript runtimes and even web servers are just load balancing proxies for JavaScript runtimes running on servers.
No reason to be bitter about XML having failed on the web; some important vocabularies, like SVG and MathML, have been incorporated into HTML, and some other parts of the XHTML effort, like XForms, really didn't work out. The web wasn't created on XML but on HTML which is an SGML not XML vocabulary, so there's no point in appealing to a glorious past that never existed (and yes, I actually developed <?xslt-stylesheet ...>-based sites in the early/mid 2000's).
If you like XML, maybe you like SGML, XML's big sister, as well. Since XML is per definition just a subset of SGML, everything that applies to XML equally applies to SGML as well. Only that SGML has additional concepts and much more power as an actual text authoring, document composition, and templating format, and, unlike XML, SGML can parse regular HTML, including HTML5.
I didn't like the promise of XML on the web because I fetishize markup languages. I felt it is/was a good solution for the separation of data and presentation on the web.
A website could simultaneously be a site for a browser and an API for native or web apps by serving the exact same documents to everyone. The server side could focus on data and the client would be responsible for the display or processing.
It did the things modern JavaScript monstrosities do but natively in the browser. XForms even proposed to handle a lot of the stupid validation and state management that requires megabytes of JavaScript to handle today.
Tons of resources are wasted every second parsing and running JavaScript to do the same thing browsers can do natively.
Just one thing. How do you reuse components on client and server side and at the same time keep the component encapsulated. For example I don't want my component to have a bit of php, a bit of JavaScript and then couple my JavaScript to the class that php gives me. This is a huge hack. If you have 2 states, they have to be both on JavaScript and php land... Not a waste?
HTML should never have grown into the mutated application runtime it is today. The presentational concerns for documents are different from application rendering. The javascript stack should have been something entirely separate.
I strongly feel we should create a lightweight HTML fork that is again document-centric and doesn't allow for all of this javascript nonsense. Something that doesn't allow for stupid custom UI or behavioural tracking. Just text, images, videos, and links. The painting algorithm would be dead simple, documents would load lightning fast, and we'd be confident there would be no ad malware.
I'm not so sure that the evolution of HTML could or should have been different. The second thing I ever did with images and text was link them to other pages and arrange them in the form of a menu. When I learned to use CGI, the first or second thing I did was write a script to generate pretty menus.
The web's UI is a document-as-app model... documents that use a small set of interactive elements to create a cohesive and useful experience. It beat many competitors that were applications for displaying documents. Document as app works really well. Users understand it. It costs less to develop than old UI guidelines defined desktop apps. And is portable to users on diverse systems... Web apps (and web pages) have succeeded where entire generations of cross-platform tech has failed... or succeeded mildly.
I strongly feel we should create a lightweight HTML fork that is again document-centric and doesn't allow for all of this javascript nonsense. Something that doesn't allow for stupid custom UI or behavioural tracking. Just text, images, videos, and links.
HTML already has such a mode. It's called "turn off JavaScript". Fortunately, there are still plenty of good sites in that style.
(You can still have ads with plain HTML; they just aren't as annoying nor intrusive.)
Where do you get your news and stuff without JavaScript? I think HackerNews is just about the only website I regularly use nowadays that works without JavaScript
We already know what happens when that system is created, though. Because it’s what the web used to be. And the result was that people hacked around it: rendering entire page structures as static, unresponsive images.
What you want is for web authors to follow progressive enhancement. No JS should be required to load the contents of the page. If JS is included it should be to replace what would otherwise require a full page reload.
Creating it is the easy part, IMO. The hard part is to get people to publish on it.
I fear that most authors (and most creators of images and links) are not knowledgeable enough to see the web's shortcomings and that it will be very hard to explain the shortcoming to them -- with the result that most authors will continue to consider their job to be done once they have put their writings (and images and links) on the web.
It already exists and it is called HTML. It is how JS is used to load page contents that can not be tolerated.
Follow progressive enhancement. No JS should be required to load the contents of a page. If JS is included it should be to replace what would otherwise require a full page reload.
If it is not possible to load the contents of a page without JS or the JS fails to complete, then the page should show its alternative contents. The page shall under no case be left blank. This is graceful degradation.
This is advice for a web site owner, and I don't see giving advice to web site owners to be an effective way to help internet users who are very annoyed with the web like I am. Web site owners are embedded in an ecosystem controlled by entities such as Google and Mozilla who either don't know or don't care about the dissatisfaction I and people like me have with the web. I have come to believe that the best way to help internet users who are sufficiently like me is not to try to improve or change the web, but rather to start a new internet service outside of the control of Google, Mozilla, etc. Great grandparent seems to have come to a similar conclusion.
Modern web browsers are designed to satisfy goals X, Y Z, U and W. You are pointing out that browsers can be used to do X. I (along with great grandparent IIUC) are replying, yes, it can, but a new service designed to do X alone will probably do it better with fewer bugs and glitches. And all the web site owners with goals Y, Z, U and W are really getting in our way when we pursue X; our moving to the new service would give us a way to separate ourselves a little from those site owners, saving us a lot of time and annoyance.
People use React not because because it's shiny (guess what, it's not, React was first launched 2013 - six years ago, and it's more aged than jQuery's age when React was born), nor because they want everything to be an SPA (contrary to common HN belief), the use it because it gives a battle-tested, excellent solution for components and reactivity. That's really the only reason why React is prospering, and why other libraries are trying to get inspired from React and tries to copy it's API surface. (Preact, Crank.js, etc...)
For the pages to not use React, we really only need one thing: Built in reactivity to web components (custom elements). That's really the only reason why React is used. If you want to see static pages without JS, you could also need a method to define custom elements declaratively (in HTML).
That two things is the solution to this problem. Not saying that web developers just want shiny things and everything is bloated.
It's true that they are largely more complex than O.G. web technologies, and it worries me that they create a sort of gatekeeping effect on the industry, but I think it's disingenuous to outright claim React & co. are bad from a development perspective. I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
I've done lots of native development on Desktop and Mobile and I can sort of see how you get there if that's your point of reference, but if you work on web apps daily it's clear why the popular technologies are popular, and it's not hype.