I think this is not the problem with React (well, apart from point 5), but with modern webdev in general. React is a good tool for single-page applications (so is Vue or Angular) but in many cases you simply don't need and should not have a SPA in the first place.
NodeJS isn't actually all the great. It's certainly a step up from PHP/Ruby/Java/Python, but nowadays there are better options. Rust Lang is like a million times better
Many reasons: the safety guarantees are absolutely astonishing and this not only gives you confidence in the correctness of your work, but also enables rapid iterating where you can use the compiler as a pair programmer (for example, revealing everything affected by a breaking change); from a performance / resource utilization perspective its actually capable of besting C/C++; the use of zero cost abstractions makes code very succinct and makes powerful behavior very accessible (for example, see rayon parallel iterators); the trait system allows for combining behaviors in a really succinct fashion; implementing generically over traits is extremely powerful; it’s superbly expressive; the build system and formatting just work; it can be used just about anywhere; it makes multithreading concurrent programming easy; it’s fun to work with; the language teaches you to be a better engineer; the abstractions make things vastly more readable and generally once you understand the language it’s fairly easy to read code and to know what’s going on; Rust doesn’t have spaghetti code; Rust is so freaking reliable that runtime issues are basically nonexistent; Rust has libraries like Diesel that make it impossible to do invalid SQL queries and that guide you towards optimal design pattens; GraphQL API development on Rust is way easier than on other languages due to the trait system (see async GraphQL); Rust enables APIs that cannot be implemented incorrectly by design; Rust enables system level programming to be accessible; Rust removes the need for garbage collection; Rust can already do 100% of JS web APIs; Rust can generate Node modules via WASM bindgen; Rust WASM doesn’t need to be interpreted and hence runs instantly in web env thus vastly reducing time to first render; Rust is enabling a new generation of decentralized technologies....
I’m not really sure there is an end to this list. Rust is the most significant leap forward in language design ever. It is truly mind blowing.
Does not necessarily mean "javascript on the backend". It means you'll have nodeJS serving your pages, but it could be as lightweight as just accessing your APIs pulling the data and serving them, in some cases not even at runtime.
Your more heavyweight backend, REST API, microservices, etc. could still be developed as separated services, with Rust or anything else you like. If you are already looking at something like Rust for performance you are probably already going towards that kind of architecture anyways
Well, you still have to use React, which is Facebook porting the PHP bad practices into JavaScript.
I don't like to say "X is better than Y" because it's usually very subjective but let's put it that way. The only people I've ever seen like React are comparing it to jQuery in their heads while the people I see using Vue/Nuxt often had a severe JS fatigue and take pleasure again in doing front-end.
I started programming in 1995 with Microsoft BASIC on MS-DOS from a book I found in my father's library, and I slowly (having no real mentors) learned other programming languages by myself.
Doesn't matter. With Next or Nuxt you get a fast first render with SSR, and then if you use their Link component, that requests all links from the page in the background and caches them in the client side router so that when you click something else, navigation is instant. And anyway, you can't get away from the client-server model and network lag, so why is everyone here expecting INSTANT f'ing load times? That's just ludicrous!
Jeremy Keith outlines that hydration is no substitute for progressive enhancement.
The goal is keep the amount of JavaScript that is critical for interactivity to an absolute minimum (and load anything else separately, preferably on demand or to be cached for later use).
Matching the performance of static pages with dynamic pages is unrealistic but web site/app owners have a wide range of approaches available to them for improving performance on the server side. But they have no control over:
the quality of connection to the client device
the compute power on the client device
In light of these limitations the prudent defensive strategy is to deliver payloads that are small (the minimum for the necessary capabilities) and require relatively little compute.
Modern web development within the current JavaScript ecosystem doesn't follow these kind of practices.
The approach to move as much work away from client run time to site build time (e.g. Sapper/Svelte) is a step in the right direction.
I started programming in 1995 with Microsoft BASIC on MS-DOS from a book I found in my father's library, and I slowly (having no real mentors) learned other programming languages by myself.
... or not? To me, it looks like we're trying to build around JavaScript's shortcomings instead of focusing on the real problem: the inefficient runtime (and arguably the programming language as well). And then there's one "progressive" feature that almost no-one talks about: JavaScript's backwards compatibility. It's a clunky language, with so many user agents, so many code paths and so many different optimizations that have to be built-in in so many different runtimes...
I don't think the current expectations match the state, power and limitations of the tools currently used to build web applications. Arguing about the right way to do this or that is ... almost pointless because it's fruitless, unless something is done about the language and the runtimes that can't keep with the pace of innovation and at this point are only being added upon, continuously, making them heavier and slower.
Why should the platform dictate how much code I can ship? Why do I have to target sub-standard UI+UX just so my app can load in a small enough frigging time that it doesn't look like it's dead to my users? I shouldn't have to worry about this. The platform should take care of this for me. Stream my code... do something!
Sorry for ranting. I didn't mean to. Imagine I was ironic and sarcastic the entire time. :)
Front-enders work with an unknown number of radically different environments.
Familiar approaches for the backend or desktop simply don't apply to a situation where you have no control over the capabilities of the client device and the quality of the connection to it.
I started programming in 1995 with Microsoft BASIC on MS-DOS from a book I found in my father's library, and I slowly (having no real mentors) learned other programming languages by myself.
Well, one of the things I wanted to say is that this is the issue with the web platform: it lacks proper standardization and leadership. OK, so it's a varied collection of web platforms... does it have to be!? Especially if they are all doing the same thing basically?
Not really. Web standards define how browsers ought to behave on any platform and for the past years Google and Mozilla have been driving the standards process forward (with anyone else who might be willing to donate their effort).
For the time being Mozilla's future role is in question but "survival of the Web" is in Google's best interest which is why they keep pushing Chromium/Chrome forward (and are snarky about Apple/Safari (especially iOS)).
Granted it's not from an act of selflessness but for the time being the side product of the browser as an "Ad projector and Analytics gather" still enables the open and wide reach of the web (e.g. IndieWeb) (it's been my observation that Google's browser people on average tend to be more pragmatic than the framework people).
The post jQuery era gave rise to opinionated frameworks which use a boatload of JavaScript to promote their own design time vision (standard?)
without too much regard for the (client) runtime consequences. That was OK in the days of fat core desktops (the framework is restricted to a single thread) with solid, wired connections but is a bit presumptive with small core smart devices over flaky data networks. JavaScript was largely designed to script the browser (Python's success is partially based on popular libraries being implemented in C/C++ - and those don't have to squeeze through the network connection all of the time). The browser is the runtime - not the framework. Work should always be offloaded to the browser whenever possible - it's written in C/C++/Rust and the browser can offload some (non-JS) work to other threads.
Only recently some frameworks started to align more with the way browsers work in order to get away with less JavaScript - i.e. ship exactly as much JavaScript needed to accomplish the task, no less, no more.
... does it have to be!?
Using the web is about its reach. The reason it has that reach is because it makes minimal assumptions about connection quality and client capability (single thread performance, available memory, screen size (responsive/mobile first design), etc.). Making minimal assumptions means anticipating a range of capabilities. Unpredictable connection quality requires that the web is resilient - and it's that particular flavour of fault tolerance that defines the architecture of browsers and how the web works.
Many people see UI frameworks as being at the core of "web apps". Frankly I think that Service Worker is much more important. Right now they are relegated to cache managers. However they can play a much larger role in making a site more "app-like". For a more involved example see:
Also current frameworks are still single/fat core centric. The UI framework belongs on the main thread but in order to leverage today's multi (small) core devices (e.g. Android) web apps need to use Web Workers more for non-UI work so that the UI can stay responsive. Then there is at least a chance that the web app's load can be distributed over multiple cores (The Free Lunch is Over (2004)).
Especially if they are all doing the same thing basically?
They aren't.
Just look at Rendering on the Web - i.e. the range of rendering options. There is a continuous spectrum of architectures between a static web site and a web app. Web development covers a wide range of solutions. The issue is that people are always gravitating towards their golden hammer. They stick to the tools they are familiar with often applying them where they are less than ideal.
I started programming in 1995 with Microsoft BASIC on MS-DOS from a book I found in my father's library, and I slowly (having no real mentors) learned other programming languages by myself.
Thank you for your very informative answer and for shedding light on a complex topic.
Maybe I should reformulate my opinion. It's not that there's no standards or body to control the evolution of the web... I guess that's not what I meant. I know there are standards and the W3C, etc.
It's just that there's no clear solution to everyone's vision of what the web should be and should be able to do, and the sad part is that the only way the problem can be fixed is, if the web can find the perfect solution in order to become this one and only universal platform everyone wants it to be.
Otherwise we will always continue to hear these complaints about the tools and technologies we use and how they suck, when in fact they are NOT the problem, but only solutions to the real problems!
Maybe the web needs re-architecting from the ground up?
I believe the main issue is with the way we write and run code on the web. For example, having just one programming language and one code runtime is a huge detriment to the web platform. Let's hope WASM and WASI can fix that. And CSS... can't we do better than that? CSS shouldn't be a separate language IMO.
It's just that there's no clear solution to everyone's vision of what the web should be and should be able to do
That is one of the problems.
There are lots of opinions of what people want the web to be for their own personal benefit. At the same time there seems to be very little willingness to accept what the web actually is and to understand why it got to be that way.
if the web can find the perfect solution
Perfect with reference to what?
If anything the web is an exercise of "the best we can do with the constraints we are currently operating under". That's what made it successful in the past and that is why it is still around after 31 years (1989).
one and only universal platform everyone wants it to be.
Universal doesn't imply one or even a unified platform. The web succeeded so far because it was willing to compromise in the face of constraints set by technology and physics.
the real problems!
Real solutions accomodate all existing constraints. Solutions that ignore real constraints create problems.
Maybe the web needs re-architecting from the ground up?
Let's say that it was possible to come up with "the perfect" alternative (which is unlikely) - how would it be adopted in the current climate?
The web browser was transitioned onto smart/mobile devices because most customers want access to the web. If Apple removed Safari from iOS today likely a lot of people would be upset - perhaps enough to switch to a platform with web support.
However a new architecture would have very little content initially to generate consumer demand and if there is no opportunity for platform holders to directly profit from it, it's in their interest to not support it.
The web established itself during a unique window of opportunity. Something like it would have a lot more difficulties today. If the web made itself irrelevant we'd likely be back to multiple disparate platforms and walled gardens. The problem is that with mobile the web has to operate in an environment that is even more unreliable and hostile than the one it established itself in. The influx of less expensive devices into the market means that the average device is becoming less performant - even as flagship devices are still becoming more performant.
The web could quickly become irrelevant if the majority of web sites (and apps) indulge in technologies that focus on serving flagship devices with fast and clean network connections while neglecting service/user experience for mid to low-spec devices with less than perfect connections. If the majority of users have to rely on native apps even for casual engagement the reach and therefore appeal of the web is lost. And having to go through the app store for an app download is already beyond "casual".
Also in the past there have been efforts to "improve the web":
Java Applets
Active X
Flash
Silverlight
HTML, CSS and JavaScript on the other hand are still around today.
I believe the main issue is with the way we write and run code on the web.
I think this has more to do with the expectations that are grounded in the experience of developing applications for desktop, device native and the back end which aren't constrained in the same way that developing for the web is. I think this is similar to the mindset that is addressed in Convenience over Correctness (2008) - developers wanting to treat a remote procedure call no different than a local function call - it's an unrealistic expectation given that there is so much more that can go wrong with a remote procedure call.
For example, having just one programming language and one code runtime is a huge detriment to the web platform.
Earlier you wanted standardization. Now that you don't like the standard, you want choice (i.e. variation which can lead to fragmentation)?
Let's hope WASM and WASI can fix that.
While WASM is an important development I think people are overestimating its impact - again because they hope that it will bring web development closer to "traditional software development" - but WASM doesn't change the constraints that the web has to operate under. The most likely languages for WASM development will be C/C++/Rust, i.e. systems languages because they only need a skimpy "runtime".
Anything higher level than that will require a significantly larger runtime for download - e.g. Blazor has the .NET CLR (or a variation thereof) albatross around its neck. And multi-language development could require multiple runtimes. I suppose each execution context (page, worker) would require its own copy of the runtime, further increasing memory requirements for a client device. I'm not saying that this won't have interesting niche applications but I don't see these type of solutions having the same kind of reach as lean HTML/CSS/JS solutions with less demanding runtime requirements.
And CSS... can't we do better than that? CSS shouldn't be a separate language IMO.
Why not?
HTML initially included visual design. But in the end it was decided that HTML's job was to structure content - not layout and styling. Windowing systems use programmatic layout managers. For browsers it was decided to go with a declarative language instead.
I started programming in 1995 with Microsoft BASIC on MS-DOS from a book I found in my father's library, and I slowly (having no real mentors) learned other programming languages by myself.
I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
I was going to title this "Stop Using Modern JavaScript" but decided to call it "Stop Using React". I can't agree with you more, the problem is SPAs in general. I would like someone to explain to me why SPAs need to exist actually. (Preact is an okay framework for speed, but I would still prefer writing HTML...)
I think SPAs are mostly useful for companies who need to organize their code...right? I don't get it.
HTML already has modularity and templating built in, if copy and pasting is what grinds people's gears.
Comment hidden by post author - thread only visible in this permalink
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
SPAs fit into the Progressive Web App movement which is about bringing native experience to web. So websites feel like mobile apps that have instant load time.
It can also involve service workers to fetch data in the background and also cache it esp like a feed of posts or photos.
What I like about a SPA is it can be served as a static site on GH Pages or Netlify (if you use a CI build step). So no speed and hosting and security issues that go with having a Node Express app. Just fast static assets served.
I recently moved a project from templating with Mustache to templating with Vue and the move meant I didn't have to think about low level DOM operations to find values on form elements and push the results to an output section. I get to focus on the variables as they are bound to HTML elements.
I do agree with your sentiment. Don't make a web app into a desktop app and don't break if JS can't run.
JS was designed for a philosophy of progressive enhancements. I have a JS book I read which emphasises this at the start. Yet many sites are blank with a warning to enable JS. And sometimes just a blank page! The obsession with JS means sites are unusable if you have an older browser or the developer used only the newest syntax and didn't use babel to get output that works pre-ES2016/ES6
I like using Jekyll for templating in general to avoid JS on the page. Or to just add JS to add sort or filter on say a table.
The main reason I guess I like JS whether SPA or not SPA is that there is no page load when you submit a form or like a photo etc. There is white screen flicker.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
For interest, I added Vue to my jquery mustache site using frontend code only. So adding a script tag loading vue.js and then using a script tag on my HTML page.
This was light as there was no build step and the site was not a SPA yet, just HTML pages with JS added on top. And I could have using jekyll to add consistency so I have Vue load in the head of each page.
And I could have broken my JS into standalone JS files so I can run tests and linting against them.
The thing about the SPA style is that it means you manage your JS deps using a package file and you then import that in each of your scripts. You treat them like modules like in a server side app like an API or CLI. The problem with the browser approach is there aren't imports, just script tags loaded in a certain order.
Having said that there is a newer syntax where a script tag is imported as a module and you can use import x as * from 'jquery' in a JS file and then use it on the frontend! I am have just not tried it yet. But it means better server side feel of development with the frontend usage without making it a SPA.
Instead, we should concentrate on the unique web selling points: its reach, which, more or less by definition, encompasses all native platforms, URLs, which are fantastically useful and don’t work in a native environment, and its hassle-free quality.
The problem with the browser approach is there aren't imports,
Besides type="module" bundlers were introduced to enable "modular JavaScript" - not to support SPA's. If you are using React/Vue your choice (webpack) is essentially made for you - but for anything else I find rollup.js a lot saner especially as it is built around ES2015 modules (esbuild is faster).
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
The part about not using Vue template on the frontend might make sense in certain cases like if you are making tables or you have SSR. But vue supports it and it means you can have a touch of vue to your site without rebuilding it as a SPA so it might still be worth it. Same goes for React and Preact especially. A SPA structure comes with safety but it also has a cost which is the point of the post.
What I meant by the module syntax is that I can use that to get the experience of writing JS tests and imports like in a SPA but without actually structuring as a SPA.
I have heard of Eleventy and Gatsby and others but haven't really tried them
But vue supports it and it means you can have a touch of vue to your site without rebuilding it as a SPA so it might still be worth it.
When using DOM HTML as a template you have to ship and execute runtime + compiler (93kB) rather than just the runtime (65kB) on the client.
When you use a build step to compile the template into a bundle you only need to ship the vue runtime to the client - this isn't the same as building an SPA. At the core of the original article is the notion that it should be a goal to ship and execute less JavaScript on the client.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
I it was pointed out earlier in this thread but there is a major misconception that SPAs are PWAs. A SPA can technically be a PWA, but honestly there is no justification for SPAs in the context of a well written PWA.
The service worker can eliminate the network latency, which means you can ditch the fat, out of shape, slow JavaScript that are popular fast food frameworks. love2dev.com/blog/pwa-spa/
SPAs are actually useful. It is justified when you trade a longer loading time for faster interactions in the future. Think a webmail client, like GMail. Sure, you can load a lo-fi version and keep reloading on every click, but the experience of having email load super-fast and be able to answer them fast is just nice. You usually spend a couple of minutes browsing them and then the time consumed on initial load is saved.
Other areas where SPAs are good are live applications, such as betting ones. You always want to see the current stakes, so you need the data pusher from the server to update what you see in the frontend. No one would probably bet on a static site (unless those are bet for something static too, for example "which year a human will land on Mars").
And of course, SPAs are a must in web applications imitating interaction from regular desktop applications, such as Google Docs.
Pity they are also used in blogs (!), contact forms (!!) or just informative website about the small business.
My opinion is that React should be a last-resort option considering all the negatives, and even then, should be used with adaptive loading and every web performance optimization possible. Right now it seems like React is the default for every app and no one considers the negatives.
I also know that Facebook, who developed React, is aware of these negatives and serves a different version of Facebook to users on feature phones (a version of Facebook with less JavaScript to download) than the version they serve to users on iPhones. The developers of React know that React is flawed.
Complex apps that actually require JavaScript intensive SPAs usually have adaptive loading in place (Gmail has the basic HTML version for slow connections) but the average developer doesn't think about any of this.
Comment hidden by post author - thread only visible in this permalink
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
It depends on many factors but you generalize a problem for everyone. We've different analytic tools so we know our customers devices, resolutions and so. Why I must take care about 2G connection guys when the slowest connection we get is with 3G or 20Mb ADSL and on a <5%?
You need to know your market before choosing technology, isn't it?
If my customers are using high speed internet connections I MUST NOT care about those who are with 2G, because you put extra-efforts and engineering for it to run as nice as possible, even building a different version (check the cost of that in time and money) instead on giving the best experience to YOUR customers.
I see all that post and most comments some kinda romantic programming where things are idealized like "welcome all 2G users, welcome 56Kb modem users, let's push accessibility" but on the real world companies do what their customers need and no more for obvious reasons. And if you are a programmer you either will work on a company or being the boss of one so you need to take this in mind (the third option is being so bad you've no job).
If you already thank on that, you probably are on a country with very bad internet speeds then ok, change the title and say "Stop using react if your business market is on [country_name]" and will be zero misunderstanding.
This sounds like you really believed that most of decisions about using technology X are preceded by careful market evaluation, not just jumping on a hip technology bandwagon. I feel that software development is plagued by this kind of thinking:
Most of my users are on a fast internet, so I don't care about the bundle size
Most of my users are not blind, so I don't care about accessibility
Most of my users have names longer than three characters so it's okay if I put the validation like that in my registration form
The thing is, if you think about it from day one, you probably won't spend huge resources on adjusting the project for people who are not a majority of your market. But if you did not think about it, sure, you have to spend time on coming up in post-factum justifications like that ;)
Of course, there are some cases when using SPA is fully justified (see my previous comments) - but let's be honest, in most cases it's not.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
I must be biased about business side thinking but that's what you're taught at college, doing before thinking makes you redo several times so it's inefficient 🤷
When you open up a new project to a market there must be a previous analisis, not doing that and complain about the results is something dumb, don't you think?
SPAs fit well on tones of applications while does not fit on tones of others, that's right, the same for microservices architecture vs services or vs monolithic.
That's just the point, there's a big nonsense on recommend to stop using something "as is", your needs will depend on what do you need to achieve (requirements), knowledge about your market, seek the pros and cons for each option and decide which one fits better for your product, that's all
Well put. Some people keep saying "stop using Laravel" but if you don't have crazy concurrent requests, Laravel can solve almost all of the problems you would typically need & can get a lot done using this framework in a limited amount of time. So the context is important. 2G,3G,4G these are relative to the business of the website is catering. Remember we had to support that shitty IE ? Now we don't because the market cap is insignificant for the older versions of IE. There's always a tradeoff according to your customer base.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think this is not the problem with React (well, apart from point 5), but with modern webdev in general. React is a good tool for single-page applications (so is Vue or Angular) but in many cases you simply don't need and should not have a SPA in the first place.
Why not use sth like NextJs? That’ll create a server side rendered page using React. No SPA here.
Because that means JavaScript on the backend.
NodeJS is amazing why not.
NodeJS isn't actually all the great. It's certainly a step up from PHP/Ruby/Java/Python, but nowadays there are better options. Rust Lang is like a million times better
What makes Rust so much better?
Many reasons: the safety guarantees are absolutely astonishing and this not only gives you confidence in the correctness of your work, but also enables rapid iterating where you can use the compiler as a pair programmer (for example, revealing everything affected by a breaking change); from a performance / resource utilization perspective its actually capable of besting C/C++; the use of zero cost abstractions makes code very succinct and makes powerful behavior very accessible (for example, see rayon parallel iterators); the trait system allows for combining behaviors in a really succinct fashion; implementing generically over traits is extremely powerful; it’s superbly expressive; the build system and formatting just work; it can be used just about anywhere; it makes multithreading concurrent programming easy; it’s fun to work with; the language teaches you to be a better engineer; the abstractions make things vastly more readable and generally once you understand the language it’s fairly easy to read code and to know what’s going on; Rust doesn’t have spaghetti code; Rust is so freaking reliable that runtime issues are basically nonexistent; Rust has libraries like Diesel that make it impossible to do invalid SQL queries and that guide you towards optimal design pattens; GraphQL API development on Rust is way easier than on other languages due to the trait system (see async GraphQL); Rust enables APIs that cannot be implemented incorrectly by design; Rust enables system level programming to be accessible; Rust removes the need for garbage collection; Rust can already do 100% of JS web APIs; Rust can generate Node modules via WASM bindgen; Rust WASM doesn’t need to be interpreted and hence runs instantly in web env thus vastly reducing time to first render; Rust is enabling a new generation of decentralized technologies....
I’m not really sure there is an end to this list. Rust is the most significant leap forward in language design ever. It is truly mind blowing.
Does not necessarily mean "javascript on the backend". It means you'll have nodeJS serving your pages, but it could be as lightweight as just accessing your APIs pulling the data and serving them, in some cases not even at runtime.
Your more heavyweight backend, REST API, microservices, etc. could still be developed as separated services, with Rust or anything else you like. If you are already looking at something like Rust for performance you are probably already going towards that kind of architecture anyways
Well, you still have to use React, which is Facebook porting the PHP bad practices into JavaScript.
I don't like to say "X is better than Y" because it's usually very subjective but let's put it that way. The only people I've ever seen like React are comparing it to jQuery in their heads while the people I see using Vue/Nuxt often had a severe JS fatigue and take pleasure again in doing front-end.
SSR introduces component rehydration overhead on the client (compared to plain server rendering) which increases Time to Interactive (TTI).
Hydration
Even static websites generated with Gatsby rehydrate (by default).
Doesn't matter. With Next or Nuxt you get a fast first render with SSR, and then if you use their Link component, that requests all links from the page in the background and caches them in the client side router so that when you click something else, navigation is instant. And anyway, you can't get away from the client-server model and network lag, so why is everyone here expecting INSTANT f'ing load times? That's just ludicrous!
Because the gold standard is set by the speed of static pages.
Starting with The Cost of JavaScript 2018 Addy Osmani identified "hydration" as a potential cause for
in reference to
2013: Progressive Enhancement: Zed’s Dead, Baby
Despite progressive enhancement repeatedly being declared dead, in 2016 Jake Archibald stated
This illustrates that PWAs got their name from progressive enhancement:
Jeremy Keith outlines that hydration is no substitute for progressive enhancement.
The goal is keep the amount of JavaScript that is critical for interactivity to an absolute minimum (and load anything else separately, preferably on demand or to be cached for later use).
Matching the performance of static pages with dynamic pages is unrealistic but web site/app owners have a wide range of approaches available to them for improving performance on the server side. But they have no control over:
In light of these limitations the prudent defensive strategy is to deliver payloads that are small (the minimum for the necessary capabilities) and require relatively little compute.
Modern web development within the current JavaScript ecosystem doesn't follow these kind of practices.
The approach to move as much work away from client run time to site build time (e.g. Sapper/Svelte) is a step in the right direction.
... or not? To me, it looks like we're trying to build around JavaScript's shortcomings instead of focusing on the real problem: the inefficient runtime (and arguably the programming language as well). And then there's one "progressive" feature that almost no-one talks about: JavaScript's backwards compatibility. It's a clunky language, with so many user agents, so many code paths and so many different optimizations that have to be built-in in so many different runtimes...
I don't think the current expectations match the state, power and limitations of the tools currently used to build web applications. Arguing about the right way to do this or that is ... almost pointless because it's fruitless, unless something is done about the language and the runtimes that can't keep with the pace of innovation and at this point are only being added upon, continuously, making them heavier and slower.
Why should the platform dictate how much code I can ship? Why do I have to target sub-standard UI+UX just so my app can load in a small enough frigging time that it doesn't look like it's dead to my users? I shouldn't have to worry about this. The platform should take care of this for me. Stream my code... do something!
Sorry for ranting. I didn't mean to. Imagine I was ironic and sarcastic the entire time. :)
At the core of the problem is that React doesn't play to the strengths of the platforms on the web.
Something like Sapper/Svelte does - though there still is room for improvement.
There is no one platform and there never will be - that is simply the nature of the web.
Tools don’t solve the web’s problems, they ARE the problem (2015):
Front end and back end (2015)
Familiar approaches for the backend or desktop simply don't apply to a situation where you have no control over the capabilities of the client device and the quality of the connection to it.
Well, one of the things I wanted to say is that this is the issue with the web platform: it lacks proper standardization and leadership. OK, so it's a varied collection of web platforms... does it have to be!? Especially if they are all doing the same thing basically?
This article needs more traffic: Where Web UI Libraries are Heading
Not really. Web standards define how browsers ought to behave on any platform and for the past years Google and Mozilla have been driving the standards process forward (with anyone else who might be willing to donate their effort).
For the time being Mozilla's future role is in question but "survival of the Web" is in Google's best interest which is why they keep pushing Chromium/Chrome forward (and are snarky about Apple/Safari (especially iOS)).
Granted it's not from an act of selflessness but for the time being the side product of the browser as an "Ad projector and Analytics gather" still enables the open and wide reach of the web (e.g. IndieWeb) (it's been my observation that Google's browser people on average tend to be more pragmatic than the framework people).
The post jQuery era gave rise to opinionated frameworks which use a boatload of JavaScript to promote their own design time vision (standard?)
without too much regard for the (client) runtime consequences. That was OK in the days of fat core desktops (the framework is restricted to a single thread) with solid, wired connections but is a bit presumptive with small core smart devices over flaky data networks. JavaScript was largely designed to script the browser (Python's success is partially based on popular libraries being implemented in C/C++ - and those don't have to squeeze through the network connection all of the time). The browser is the runtime - not the framework. Work should always be offloaded to the browser whenever possible - it's written in C/C++/Rust and the browser can offload some (non-JS) work to other threads.
Only recently some frameworks started to align more with the way browsers work in order to get away with less JavaScript - i.e. ship exactly as much JavaScript needed to accomplish the task, no less, no more.
Using the web is about its reach. The reason it has that reach is because it makes minimal assumptions about connection quality and client capability (single thread performance, available memory, screen size (responsive/mobile first design), etc.). Making minimal assumptions means anticipating a range of capabilities. Unpredictable connection quality requires that the web is resilient - and it's that particular flavour of fault tolerance that defines the architecture of browsers and how the web works.
Many people see UI frameworks as being at the core of "web apps". Frankly I think that Service Worker is much more important. Right now they are relegated to cache managers. However they can play a much larger role in making a site more "app-like". For a more involved example see:
Also current frameworks are still single/fat core centric. The UI framework belongs on the main thread but in order to leverage today's multi (small) core devices (e.g. Android) web apps need to use Web Workers more for non-UI work so that the UI can stay responsive. Then there is at least a chance that the web app's load can be distributed over multiple cores (The Free Lunch is Over (2004)).
They aren't.
Just look at Rendering on the Web - i.e. the range of rendering options. There is a continuous spectrum of architectures between a static web site and a web app. Web development covers a wide range of solutions. The issue is that people are always gravitating towards their golden hammer. They stick to the tools they are familiar with often applying them where they are less than ideal.
Thank you for your very informative answer and for shedding light on a complex topic.
Maybe I should reformulate my opinion. It's not that there's no standards or body to control the evolution of the web... I guess that's not what I meant. I know there are standards and the W3C, etc.
It's just that there's no clear solution to everyone's vision of what the web should be and should be able to do, and the sad part is that the only way the problem can be fixed is, if the web can find the perfect solution in order to become this one and only universal platform everyone wants it to be.
Otherwise we will always continue to hear these complaints about the tools and technologies we use and how they suck, when in fact they are NOT the problem, but only solutions to the real problems!
Maybe the web needs re-architecting from the ground up?
I believe the main issue is with the way we write and run code on the web. For example, having just one programming language and one code runtime is a huge detriment to the web platform. Let's hope WASM and WASI can fix that. And CSS... can't we do better than that? CSS shouldn't be a separate language IMO.
That is one of the problems.
There are lots of opinions of what people want the web to be for their own personal benefit. At the same time there seems to be very little willingness to accept what the web actually is and to understand why it got to be that way.
Perfect with reference to what?
If anything the web is an exercise of "the best we can do with the constraints we are currently operating under". That's what made it successful in the past and that is why it is still around after 31 years (1989).
Universal doesn't imply one or even a unified platform. The web succeeded so far because it was willing to compromise in the face of constraints set by technology and physics.
Real solutions accomodate all existing constraints. Solutions that ignore real constraints create problems.
Let's say that it was possible to come up with "the perfect" alternative (which is unlikely) - how would it be adopted in the current climate?
The web browser was transitioned onto smart/mobile devices because most customers want access to the web. If Apple removed Safari from iOS today likely a lot of people would be upset - perhaps enough to switch to a platform with web support.
However a new architecture would have very little content initially to generate consumer demand and if there is no opportunity for platform holders to directly profit from it, it's in their interest to not support it.
The web established itself during a unique window of opportunity. Something like it would have a lot more difficulties today. If the web made itself irrelevant we'd likely be back to multiple disparate platforms and walled gardens. The problem is that with mobile the web has to operate in an environment that is even more unreliable and hostile than the one it established itself in. The influx of less expensive devices into the market means that the average device is becoming less performant - even as flagship devices are still becoming more performant.
The web could quickly become irrelevant if the majority of web sites (and apps) indulge in technologies that focus on serving flagship devices with fast and clean network connections while neglecting service/user experience for mid to low-spec devices with less than perfect connections. If the majority of users have to rely on native apps even for casual engagement the reach and therefore appeal of the web is lost. And having to go through the app store for an app download is already beyond "casual".
Also in the past there have been efforts to "improve the web":
HTML, CSS and JavaScript on the other hand are still around today.
I think this has more to do with the expectations that are grounded in the experience of developing applications for desktop, device native and the back end which aren't constrained in the same way that developing for the web is. I think this is similar to the mindset that is addressed in Convenience over Correctness (2008) - developers wanting to treat a remote procedure call no different than a local function call - it's an unrealistic expectation given that there is so much more that can go wrong with a remote procedure call.
Earlier you wanted standardization. Now that you don't like the standard, you want choice (i.e. variation which can lead to fragmentation)?
While WASM is an important development I think people are overestimating its impact - again because they hope that it will bring web development closer to "traditional software development" - but WASM doesn't change the constraints that the web has to operate under. The most likely languages for WASM development will be C/C++/Rust, i.e. systems languages because they only need a skimpy "runtime".
Anything higher level than that will require a significantly larger runtime for download - e.g. Blazor has the .NET CLR (or a variation thereof) albatross around its neck. And multi-language development could require multiple runtimes. I suppose each execution context (page, worker) would require its own copy of the runtime, further increasing memory requirements for a client device. I'm not saying that this won't have interesting niche applications but I don't see these type of solutions having the same kind of reach as lean HTML/CSS/JS solutions with less demanding runtime requirements.
Why not?
HTML initially included visual design. But in the end it was decided that HTML's job was to structure content - not layout and styling. Windowing systems use programmatic layout managers. For browsers it was decided to go with a declarative language instead.
Granted experience with imperative programming doesn't prepare you for the demands of CSS. It was never meant to make sense to programmers but it seems to make sense to designers (You'd be better at css if you knew how it worked (2019), Don’t QWOP Your Way Through CSS (2017)).
And CSS can be managed on its own terms (ITCSS, BEMIT, CUBE CSS), it just requires a different approach than what most programmers are accustomed to.
Interesting arguments. I'll have to sit on them for a while. Thanks.
I'm curious to know if there's any other tool to make complex websites, other than these SPA frameworks and jquery
I found this to be a great guide from @_developit , jasonformat.com/application-holotypes, when deciding on how to architect your application.
I was going to title this "Stop Using Modern JavaScript" but decided to call it "Stop Using React". I can't agree with you more, the problem is SPAs in general. I would like someone to explain to me why SPAs need to exist actually. (Preact is an okay framework for speed, but I would still prefer writing HTML...)
I think SPAs are mostly useful for companies who need to organize their code...right? I don't get it.
HTML already has modularity and templating built in, if copy and pasting is what grinds people's gears.
This confuses me greatly.
Are you referring to
<template>element?SPAs fit into the Progressive Web App movement which is about bringing native experience to web. So websites feel like mobile apps that have instant load time.
It can also involve service workers to fetch data in the background and also cache it esp like a feed of posts or photos.
What I like about a SPA is it can be served as a static site on GH Pages or Netlify (if you use a CI build step). So no speed and hosting and security issues that go with having a Node Express app. Just fast static assets served.
I recently moved a project from templating with Mustache to templating with Vue and the move meant I didn't have to think about low level DOM operations to find values on form elements and push the results to an output section. I get to focus on the variables as they are bound to HTML elements.
I do agree with your sentiment. Don't make a web app into a desktop app and don't break if JS can't run.
JS was designed for a philosophy of progressive enhancements. I have a JS book I read which emphasises this at the start. Yet many sites are blank with a warning to enable JS. And sometimes just a blank page! The obsession with JS means sites are unusable if you have an older browser or the developer used only the newest syntax and didn't use babel to get output that works pre-ES2016/ES6
I like using Jekyll for templating in general to avoid JS on the page. Or to just add JS to add sort or filter on say a table.
The main reason I guess I like JS whether SPA or not SPA is that there is no page load when you submit a form or like a photo etc. There is white screen flicker.
Progressive Web Apps are great!
For interest, I added Vue to my jquery mustache site using frontend code only. So adding a script tag loading vue.js and then using a script tag on my HTML page.
This was light as there was no build step and the site was not a SPA yet, just HTML pages with JS added on top. And I could have using jekyll to add consistency so I have Vue load in the head of each page.
And I could have broken my JS into standalone JS files so I can run tests and linting against them.
The thing about the SPA style is that it means you manage your JS deps using a package file and you then import that in each of your scripts. You treat them like modules like in a server side app like an API or CLI. The problem with the browser approach is there aren't imports, just script tags loaded in a certain order.
Having said that there is a newer syntax where a script tag is imported as a module and you can use
import x as * from 'jquery'in a JS file and then use it on the frontend! I am have just not tried it yet. But it means better server side feel of development with the frontend usage without making it a SPA.That is a misconception that dates back to the App Shell Model.
The core technology for PWAs is ServiceWorker using the Cache to retain the essential parts of an (possibly MPA) web site for offline usage.
Developing Progressive Web Apps (PWAs) Course.
"bringing native experience to the web" is a fools errand.
Web vs. native: let’s concede defeat (2015)
Why Progressive Web Applications Are Not Single Page Applications
FYI: Eleventy was inspired by Jekyll but uses JS instead of Ruby.
That approach isn't recommended:
Why You Should Avoid Vue.js DOM Templates
Besides type="module" bundlers were introduced to enable "modular JavaScript" - not to support SPA's. If you are using React/Vue your choice (webpack) is essentially made for you - but for anything else I find rollup.js a lot saner especially as it is built around ES2015 modules (esbuild is faster).
I don't really understand. The website just tells good solutions, but not really against it.
Thanks for the links.
The part about not using Vue template on the frontend might make sense in certain cases like if you are making tables or you have SSR. But vue supports it and it means you can have a touch of vue to your site without rebuilding it as a SPA so it might still be worth it. Same goes for React and Preact especially. A SPA structure comes with safety but it also has a cost which is the point of the post.
What I meant by the module syntax is that I can use that to get the experience of writing JS tests and imports like in a SPA but without actually structuring as a SPA.
I have heard of Eleventy and Gatsby and others but haven't really tried them
When using DOM HTML as a template you have to ship and execute runtime + compiler (93kB) rather than just the runtime (65kB) on the client.
When you use a build step to compile the template into a bundle you only need to ship the vue runtime to the client - this isn't the same as building an SPA. At the core of the original article is the notion that it should be a goal to ship and execute less JavaScript on the client.
The "Developer Experience" Bait-and-Switch
Any opportunity to complete work at build time that reduces the amount of code needed at runtime should always be taken.
Time and time again Rich Hickey's observation proves to be accurate: Programmers know the benefit of everything and the tradeoffs of nothing.
Many tools are adopted to enhance the "developer experience" while the potential negative consequences downstream are either ignored or downplayed.
I see the solution as quite easy.
Use
*.vuefile, with Parcel. It will internally usevue-template-compiler.Do not put
<template>tag inside Jekyll.I actually followed an approach without a template element so could have skipped the compiler.
I just added v-model etc. to plain html and setup
new Vue(...)at the bottom.Here was the work in progress before moving to SPA
github.com/MichaelCurrin/badge-gen...
I did use vue-markdown tag though which I guess needs the compilation.
Thanks for sharing. I liked the video a lot.
I it was pointed out earlier in this thread but there is a major misconception that SPAs are PWAs. A SPA can technically be a PWA, but honestly there is no justification for SPAs in the context of a well written PWA.
The service worker can eliminate the network latency, which means you can ditch the fat, out of shape, slow JavaScript that are popular fast food frameworks.
love2dev.com/blog/pwa-spa/
SPAs are actually useful. It is justified when you trade a longer loading time for faster interactions in the future. Think a webmail client, like GMail. Sure, you can load a lo-fi version and keep reloading on every click, but the experience of having email load super-fast and be able to answer them fast is just nice. You usually spend a couple of minutes browsing them and then the time consumed on initial load is saved.
Other areas where SPAs are good are live applications, such as betting ones. You always want to see the current stakes, so you need the data pusher from the server to update what you see in the frontend. No one would probably bet on a static site (unless those are bet for something static too, for example "which year a human will land on Mars").
And of course, SPAs are a must in web applications imitating interaction from regular desktop applications, such as Google Docs.
Pity they are also used in blogs (!), contact forms (!!) or just informative website about the small business.
Thanks for the explanation!
My opinion is that React should be a last-resort option considering all the negatives, and even then, should be used with adaptive loading and every web performance optimization possible. Right now it seems like React is the default for every app and no one considers the negatives.
I also know that Facebook, who developed React, is aware of these negatives and serves a different version of Facebook to users on feature phones (a version of Facebook with less JavaScript to download) than the version they serve to users on iPhones. The developers of React know that React is flawed.
Complex apps that actually require JavaScript intensive SPAs usually have adaptive loading in place (Gmail has the basic HTML version for slow connections) but the average developer doesn't think about any of this.
It depends on many factors but you generalize a problem for everyone. We've different analytic tools so we know our customers devices, resolutions and so. Why I must take care about 2G connection guys when the slowest connection we get is with 3G or 20Mb ADSL and on a <5%?
You need to know your market before choosing technology, isn't it?
If my customers are using high speed internet connections I MUST NOT care about those who are with 2G, because you put extra-efforts and engineering for it to run as nice as possible, even building a different version (check the cost of that in time and money) instead on giving the best experience to YOUR customers.
I see all that post and most comments some kinda romantic programming where things are idealized like "welcome all 2G users, welcome 56Kb modem users, let's push accessibility" but on the real world companies do what their customers need and no more for obvious reasons. And if you are a programmer you either will work on a company or being the boss of one so you need to take this in mind (the third option is being so bad you've no job).
If you already thank on that, you probably are on a country with very bad internet speeds then ok, change the title and say "Stop using react if your business market is on [country_name]" and will be zero misunderstanding.
This sounds like you really believed that most of decisions about using technology X are preceded by careful market evaluation, not just jumping on a hip technology bandwagon. I feel that software development is plagued by this kind of thinking:
The thing is, if you think about it from day one, you probably won't spend huge resources on adjusting the project for people who are not a majority of your market. But if you did not think about it, sure, you have to spend time on coming up in post-factum justifications like that ;)
Of course, there are some cases when using SPA is fully justified (see my previous comments) - but let's be honest, in most cases it's not.
I must be biased about business side thinking but that's what you're taught at college, doing before thinking makes you redo several times so it's inefficient 🤷
When you open up a new project to a market there must be a previous analisis, not doing that and complain about the results is something dumb, don't you think?
SPAs fit well on tones of applications while does not fit on tones of others, that's right, the same for microservices architecture vs services or vs monolithic.
That's just the point, there's a big nonsense on recommend to stop using something "as is", your needs will depend on what do you need to achieve (requirements), knowledge about your market, seek the pros and cons for each option and decide which one fits better for your product, that's all
Well put. Some people keep saying "stop using Laravel" but if you don't have crazy concurrent requests, Laravel can solve almost all of the problems you would typically need & can get a lot done using this framework in a limited amount of time. So the context is important. 2G,3G,4G these are relative to the business of the website is catering. Remember we had to support that shitty IE ? Now we don't because the market cap is insignificant for the older versions of IE. There's always a tradeoff according to your customer base.