DEV Community

loading...
Cover image for Stop Using React

Stop Using React

ender minyard
💻➕📱
Updated on ・3 min read

I thought I simply didn't understand React. I taught myself React and I still wish I could go back in time and make it like React never existed. Here's why.

1. It's slow

mobile source: tim kadlec

53% of mobile users abandon websites that take longer than 3 seconds to load. For every additional second a page takes to load, 10 percent of users leave. Performance is user experience.

Also read this.

2. It's expensive

Put your React app into this testing tool: https://whatdoesmysitecost.com/.

Do you care about people who can't afford to pay for expensive websites on their data plan?

A lot of people have discussed how expensive JavaScript frameworks are, but it seems developers don't care about reaching all their potential users. I'm not the first person to make this point, but it seems like the message isn't getting through. Do you think some users are more important than others? Do you care about reaching all users or only the wealthy ones?

3. It's inaccessible

Hundreds of millions of users access the Internet from feature phones with a 2G connection. When you load all your JavaScript onto a feature phone, all the user sees is a spinning wheel.

There's so many articles, tools, and frameworks that help you develop for these users - but developers scorn them. Within the JavaScript subreddit, web workers are hated, even though they are one of the best tools we have for effectively developing apps on feature phones - scratch that, for all users!

If your app is fast on a feature phone, it will be blazing fast on an iPhone. When you develop with all users in mind, it improves the user experience for all users.

4. React goes against what the web was made for

Here's the general idea of React: you download all the JavaScript a website needs for like, seven seconds in a row without showing anything, but once you do that, you never have to download resources again, because you've made a single page application.

Is this how websites are supposed to be?

"The web is a streaming thing by default. You go to a page and it serves HTML. You'll start seeing it as it's downloaded. Same with images, video...You can do something with just a little bit of the response." - Jake Archibald

The Internet is a stream. React is not. I see it like this: React fights against the natural flow of the Internet.

Ditch React and become friends with the web. It's a web, interconnected, with resources coming from everywhere. Web apps are not like native apps that take 30 seconds to download before the user accesses the content. Stop treating webpages like native apps.

5. It's made by...those people

Just read this Wikipedia article. No, it's more than you expect.


Discussion (352)

Collapse
katafrakt profile image
Paweł Świątkowski

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.

Collapse
ender_minyard profile image
ender minyard Author • Edited

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.

Collapse
katafrakt profile image
Paweł Świątkowski

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.

Thread Thread
ender_minyard profile image
ender minyard Author • Edited

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.

Thread Thread
Collapse
michaelcurrin profile image
Michael

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.

Thread Thread
ender_minyard profile image
ender minyard Author

Progressive Web Apps are great!

Thread Thread
michaelcurrin profile image
Michael

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.

Thread Thread
peerreynders profile image
peerreynders • Edited

SPAs fit into the Progressive Web App movement which is about bringing native experience to web.

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)

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.

Why Progressive Web Applications Are Not Single Page Applications

I like using Jekyll for templating in general to avoid JS on the page.

FYI: Eleventy was inspired by Jekyll but uses JS instead of Ruby.

So adding a script tag loading vue.js and then using a script tag on my HTML page.

That approach isn't recommended:
Why You Should Avoid Vue.js DOM Templates

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).

Thread Thread
patarapolw profile image
Pacharapol Withayasakpunt

So adding a script tag loading vue.js and then using a script tag on my HTML page.

That approach isn't recommended:
Why You Should Avoid Vue.js DOM Templates

I don't really understand. The website just tells good solutions, but not really against it.

Thread Thread
michaelcurrin profile image
Michael

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

Thread Thread
peerreynders profile image
peerreynders • Edited

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.

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.

Thread Thread
patarapolw profile image
Pacharapol Withayasakpunt

I see the solution as quite easy.

Use *.vue file, with Parcel. It will internally use vue-template-compiler.

Do not put <template> tag inside Jekyll.

Thread Thread
michaelcurrin profile image
Michael • Edited

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.

michaelcurrin profile image
Michael

Thanks for sharing. I liked the video a lot.

Thread Thread
docluv profile image
Chris Love

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/

Collapse
timo_ernst profile image
Timo Ernst

Why not use sth like NextJs? That’ll create a server side rendered page using React. No SPA here.

Collapse
peerreynders profile image
peerreynders

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).

Thread Thread
brokenthorn profile image
Paul-Sebastian Manole

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!

Thread Thread
peerreynders profile image
peerreynders

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

An experience that can’t deliver on this will frustrate your users.

in reference to

For a page to be interactive, it must be capable of responding quickly to user input. A small JavaScript payload can ensure this happens fast.

2013: Progressive Enhancement: Zed’s Dead, Baby

Despite progressive enhancement repeatedly being declared dead, in 2016 Jake Archibald stated

So you should think of the network as a piece of progressive enhancement

This illustrates that PWAs got their name from progressive enhancement:

  1. Content is the foundation
  2. Markup is an enhancement
  3. Visual Design is an enhancement
  4. Interaction is an enhancement
  5. PLUS: The Network is an 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:

  • 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.

Thread Thread
brokenthorn profile image
Paul-Sebastian Manole

... 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. :)

Thread Thread
peerreynders profile image
peerreynders

the inefficient runtime

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.

Why should the platform dictate how much code I can ship?

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):

there is no web platform, there’s an immensely varied collection of web platforms

Front end and back end (2015)

Back-enders work with only one environment.

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.

Thread Thread
brokenthorn profile image
Paul-Sebastian Manole

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?

Thread Thread
peerreynders profile image
peerreynders • Edited

This article needs more traffic: Where Web UI Libraries are Heading

it lacks proper standardization and leadership.

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.

Thread Thread
brokenthorn profile image
Paul-Sebastian Manole

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.

Thread Thread
peerreynders profile image
peerreynders • Edited

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.

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.

Thread Thread
brokenthorn profile image
Paul-Sebastian Manole

Interesting arguments. I'll have to sit on them for a while. Thanks.

Collapse
katafrakt profile image
Paweł Świątkowski

Because that means JavaScript on the backend.

Thread Thread
ivanjeremic profile image
Ivan Jeremic • Edited

NodeJS is amazing why not.

Thread Thread
bajix profile image
Thomas Sieverding

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

Thread Thread
lesleyvdp profile image
Lesley van der Pol

What makes Rust so much better?

Thread Thread
bajix profile image
Thomas Sieverding

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.

Thread Thread
holdencaulfield profile image
JP Saraceno

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

Collapse
xowap profile image
Rémy 🤖

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.

Collapse
nickytonline profile image
Nick Taylor (he/him)

I found this to be a great guide from @_developit , jasonformat.com/application-holotypes, when deciding on how to architect your application.

Collapse
amanzx4 profile image
AmanZx4

I'm curious to know if there's any other tool to make complex websites, other than these SPA frameworks and jquery

Collapse
steveblue profile image
Steve Belovarich • Edited

These are all fair points. Web development is vastly different than five years ago when React was becoming wildly popular. Some people may take this personally because of how invested they are in the React ecosystem, but that doesn't mean the most popular JavaScript library doesn't deserve this kind of criticism.

I would like to extrapolate on #4 because this seems to be encoded in the DNA of Facebook. "Move fast and break things" is their famous motto. Facebook has almost singlehandedly destroyed any notion of egalitarianism on the internet. The internet was originally created in order to share things and I'm sure that didn't necessarily mean everything about our lives. The internet I grew up with in the 90s was a vastly different space. Anyone could learn html. The barrier to entry has become too great. jQuery simplified things while React made them way more complicated. The level of tooling needing to bootstrap a React application is way too much. The methods used to code React applications have changed dramatically over time. It's fitting the library distributed by Facebook is as disruptive to the web development community as the company is to everyone on Earth.

Is the disruption React caused really a good thing? Perhaps. What web engineers should be excited about in my opinion are other libraries that are a response, web standards that have evolved over time that essentially replace or outperform React.

I think it's fantastic how you framed #2. Web engineers should have more empathy for the end user.

React is just a tool, like any other. If you prefer React then go for it. Every JavaScript framework or library has advantages, teams using any tool find ways to create technical debt.

Collapse
ender_minyard profile image
ender minyard Author
It's fitting the library distributed by Facebook is as disruptive to the web development community as the company is to everyone on Earth.

👍

Collapse
eaich profile image
Eddie

Exactly my thoughts. Thanks for a great read.

Collapse
abdullahmiraz1 profile image
Abdullah Miraz

@steve
After reading all of these comments, I liked the one you have described. Others are just trying to win over other's opinions

Collapse
ishman profile image
ishman

I think you have forgotten another of the main points why react should not be the first option. I'm talking about one of the ugliest and most aberrant things that have been done related to the web lately. Of course I'm talking about JSX

Collapse
markohologram profile image
Marko A

To each their own, I really like JSX. Prefer it way more than HTML templating for sure.

Collapse
ishman profile image
ishman

Comparing the ugly spaghetti code that forces you to produce JSX with the clean, comfortable and easy template engine of frameworks like Angular, Vue or Svelte??. Analyzing one of the most basic examples:

// React ul loop syntax
const names = [‘John’, ‘Sarah’, ‘Kevin’, ‘Alice’];
const displayNewHires = (
  <ul>
    {names.map(name => <li>{name}</li> )}
  </ul>
);
ReactDOM.render(
  displayNewHires,
  document.getElementById(‘root’)
);
Enter fullscreen mode Exit fullscreen mode
// Same Vue Syntax
<ul>
  <li v-for=’name in listOfNames’>
    {{name}}
  </li>
</ul>
Enter fullscreen mode Exit fullscreen mode

I'm really trying to understand your position my friend, but I just can't ...

Thread Thread
markohologram profile image
Marko A

As I've said, to each their own. I might have been burned by AngularJS that I don't really like HTML template strings or whatever. JSX feels really good to me and tooling for it is phenomenal since it's "mostly JavaScript". Although I do admit it can get a bit complicated at times if you have lot of conditional rendering or stuff like that.

One small flaw with this example is that you show React component rendering, but for Vue you just show the syntax for that component so these examples cannot really be compared. If this example didn't have ReactDOM.render call, it would then be apples to apples comparison in this case.

Thread Thread
joshuaamaju profile image
Joshua

You can't decouple view from the logic in react, no matter how hard you try, so it's a perfect example

Thread Thread
nrutledge profile image
nrutledge

Completely contrived example. You are comparing apples to oranges by including extraneous stuff in the React section. Once you strip that away, you are left with just a few lines of what is essentially HTML + JS.

One can certainly argue that the mixing of HTML and JS in JSX is strange/unconventional. But I'd rather think in terms of JS logic that can spit out HTML than deal with some random template syntax. To each their own.

Thread Thread
ishman profile image
ishman • Edited

I have never said that it is not useful or powerful. I just think it's pretty ugly at the code level. In any case, HTML came before Javascript and although a tag language may not be very attractive for modern programmers, for a reason of hierarchy and how the web works, I see more sense to put JS in HTML than the opposite

Thread Thread
Collapse
patarapolw profile image
Pacharapol Withayasakpunt • Edited

Although I don't really like JSX in the past, I have changed my mind.

JSX is the best way for your template engine to be smart with IDE, being a mere JavaScript function, that is.

Spaghetti or not is something you have to learn to manage your code.

Collapse
pozda profile image
Ivan Pozderac

I found out that spaghetti code comes from either devs who are trying to learn/understand something new or from seasoned spaghetti dev who doesn't bother to stick to good practices and is often lazy to read the documentation/guides before actually using something.

That also determines if someone would like to work with you or not if you are that second kind of dev.

Thread Thread
lionelrowe profile image
lionel-rowe

Mmm seasoned spaghetti dev, my favorite 🤤🍝

Collapse
adarshhegde profile image
Adarsh Hegde

Garbage In, Garbage Out. Don't blame the tool.

Collapse
asadsaleh profile image
AsadSaleh

As a contrast, I really love JSX. I love how we use javascript's 'map' to render list. I don't know, maybe it's just me.

Collapse
phil_lgr profile image
Phil Léger

One thing I know... I don't want to maintain the templates that you wrote,

but you will find my typed JSX easy to maintain yourself

Collapse
sebbdk profile image
Collapse
vndre profile image
Andre • Edited

I love React, but I feel there are two kinds of developers: the ones who understand it and others who don't. The "standard" way of learning and doing React is wrong: bootstrapping an app with CRA and just building it to create a SPA is bad as OP pointed out.

I have been working with React for like 5 years and I can tell you I have created some fast and performant JAMstacks, just look how successful Gatsby.js and Next.js have become...

Collapse
lexiebkm profile image
Alexander B.K.

Without CRA, we have to handle webpack manually. Fortunately the webpack config which was created by CRA is still adequate for my project. However, learning webpack, will be needed eventually.

Collapse
sarahob profile image
Sarah 🦄

Interesting perspective. I think rather than being solely a React issue I think it’s a SPA issue. Single Page Apps are the reason the web doesn’t behave like the web anymore.

Another issue is using frameworks for the sake of using frameworks. The first thing that should be considered before starting any project is who are the users, where are they and what are we giving them. answering these questions help identify the correct stack.

You can write performant react. So again I think the issue is people not considering performance as a first class citizen and instead it’s become a “nice to have” and here is where users with poor connections or less powerful devices suffer most.

Collapse
pozda profile image
Ivan Pozderac

I agree, you can implement conditional bundle loading for separate parts of the app, lazy load data or load in background, same as gatsby loads on link hover so you have lazy loading and fast response.

It sadly often ends up with 'just ship it' mentality from management because numbers are important, not users. If you work in bad company that is.

Collapse
therise3107 profile image
Lalit Yadav

Very well said! We built and shipped a very very large React website. It takes 7 sec to print the front page in Google Lighthouse.
Well our team just didn't stop at just showing some html and css via js but we even parsed 10k-50k lines of markdown documentation on the browser itself, which wasn't so bad initial when the lines were just 500 but as the project grew so the documentation. One major issue I find is incapability of React developers to looks for other potential contenders or to say, including myself is the misconception of thinking that programming in JavaScript is the correct programing paradigm even when we have to drive our css and html from our javascript. I am not going to use React for everything, even for static websites I have decided not to use Gatsby when I can just drive most of my static content via proper file structuring and small javascript scripts.

I think React is good for dashboard(interactive) and for better code maintenance (component architecture) but that's just what developer cares for not the end user. Please correct me if I'm wrong, thanks for reading.

Collapse
peerreynders profile image
peerreynders

I'd like to understand why people enjoy using it.

If it's good enough for FB it must be good for us.
It's a perceived productivity cult.
It's an attempt to minimize cost of implementation at the expense of everything else.
There is the expectation that components are more "reusable" (how does this work out in practice?).
The component mindset is grounded in familiar OO while the view = fn(state) approach is easier to reason about at design time - imposing the runtime cost of loading and running the VDOM.

"Components are objects"

Interestingly the Elm community came to the conclusion that "components don't work" (in Elm). Packaging pieces of the Model, Update, and View into a "component" abstraction doesn't create a unit that composes particularly well. The constituent parts of the Model, Update, and View compose in very different ways. It's the types that flow through them that connect everything.

Elm Europe 2017 - Richard Feldman - Scaling Elm Apps

Some of the emerging React Patterns remind me of the old meme that many OO patterns exist to get around the shortcomings of OO (a bit of a slanderous claim - but there are some "I need a pattern for that?" moments).

Some older posts (i.e. this is not news, people have been warned):
React + Performance = ? (2015)
The DOM Is NOT Slow, Your Abstraction Is (2015)

At this point the horse has left the barn. There are lots of codebases that are heavily invested in the React ecosystem and developers to help them grow are in ready supply. So what's left? Pointing out that there are better performing alternatives (like Preact/Unistore) for many projects?

The other issue is that "current UI frameworks on the web are the centre of your universe".

Collapse
ender_minyard profile image
ender minyard Author • Edited
"If it's good enough for FB it must be good for us."

Do people actually think this way? That scares me a bit.

Pointing out that there are better performing alternatives (like Preact/Unistore) for many projects?

I've been a fan of Preact. Thanks for showing me Unistore.

Collapse
peerreynders profile image
peerreynders

Do people actually think this way?

The fact that it's backed and used by a mega-corp gives people a sense of stability and sustainability.

What doesn't enter into their thinking is that FB has the resources to deliver native applications to any platform they wish - FB has no problem with "walled gardens" so their web solution doesn't have to have the full reach of the "entire web" - just enough for first contact and to get somebody to download a native app for a "better experience" (and more access to their data).

Another thing I didn't mention is the lure of "reuse" via React native. Historically speaking cross-platform solutions don't serve any particular platform that well - it's always a compromise. In this case it's the VDOM that makes it possible to reuse React components on another rendering platform. There's already a varied collection of web platforms so trying to additionally accomodate other platforms which are even more different can only be severely limiting.

I've been a fan of Preact.

You may also enjoy this article: radEventListener: a Tale of Client-side Framework Performance

Thanks for showing me Unistore.

Jason Miller also created a JSX alternative HTM.

Thread Thread
ishman profile image
ishman

"The fact that it's backed and used by a mega-corp gives people a sense of stability and sustainability."

The fact that it's backed and used by a mega-CORRUPT-corp makes me discard it regardless of the stability and sustainability it may offer me. It's a matter of principles. I apply the same for the rest of the FB stuff. I love VR but I refuse to use their oculus glasses even though these are the best. Unfortunately whatsapp is the only thing I cannot get rid of because I would be left alone ...

Sorry telegram, I love you anyway ...

Collapse
huncyrus profile image
huncyrus

Very easy, why people like to use it:

  • It is designed by people with absolutely no knowledge for frontend
  • It is used by people who has zero-to-non knowledge for frontend
  • It is designed by people with absolutely no affinity for frontend, design, colours or in general nice things
  • It is used by people who has zero-to-non affinity for frontend, design, colours...
  • Designed by people who think factory pattern is the best way to automatize everything
  • Used by people who has zero chance to build something nice because of time budget or lack of management decision
  • Designed and used by people who absolutely don't have to work with SEO nor optimizing the code/site/snippet/component.
  • Once you learn it, quite fast to setup/use/build small things in it.
  • Don't have to think about how and what (DOM structure, elements, functions...)

This is my personal opinion. I do have couple of years of experience in frontend/UI/UX. And have more than a dozen years of experience in development.

Collapse
sheriffderek profile image
sheriffderek

Yep. It's about memorizing how a JS object looks - and not really about design or thinking.

Collapse
madiodio_gaye profile image
Madiodio ⚡️

Yeah of course this is your opinion like saying the planet is flat isn't gonna make it look factually less round any day like the very first point of your argument.

Collapse
sheriffderek profile image
sheriffderek • Edited

Yeah!

React is gross. But it's kinda cool that they made it - so that people could learn from it and borg it's best parts into things like Ember bright side?. But we don't use it - and don't plan on using it. Anyone who (doesn't teach React for a living) and uses it for a few years comes to the same conclusions. It's a learning process. React is just wrong.

It really sucks that all of new developers are already addicted to Netlify and Gatsby. They can't do anything without it. I tutor people all the time just out of a "React bootcamp" who can't write the HTML and CSS for a simple portfolio site. They learned JSX and non of the things that really matter about markup, styles, functionality, or MVC concepts etc. And now even WordPress's stupid Gutenberg blocks are written with React (and yeah - inaccessible ) even causing some notable people to quit their jobs at WP because it's so bad.

SPA's (apps) have their purposes. Google Docs isn't just a "webpage" - and so, you gotta know when to use what stuff... for what reason... but - not sure when React would ever be that choice.

Collapse
ender_minyard profile image
ender minyard Author

What's your opinion on Netlify?

Collapse
sheriffderek profile image
sheriffderek • Edited

It's fine. It does what it does well. But - it's a little bit of a black box. The whole JAMstack - is a marketing idea. It's nothing new. But - the problems we're seeing is that people go to boot camps / or learn in tutorials --- and then come to us thinking they are a 'pro' dev... and they can't write basic HTML. The idea of having pre-rendered pages and they hydrating parts of those pages with dynamic data is great! Great idea! So, why do we need to create a system all tangled up in command-line tools and React? People think that every website can be like Dev.to - and that it can just all be created with # markdown - and that I'll only be used by developers - and that's not true. I think that Netlify is doing some cool stuff. They've chosen the right spokespeople... but the way people are using it - seems to be stunting them - instead of helping them.

Collapse
mellen profile image
Matt Ellen

Point 5 is the main reason I've not tried react. I learnt angular, until i realised it was a Google project. I do use vue.js despite its Google roots, because it's not a Google product.

I'm not condemning anyone who does use react or angular, but it doesn't sit well with me.

Collapse
sebbdk profile image
Sebastian Vargr

That's too bad, React is bloated but it inspired Preact, which is awesome.

Some of the patterns Facebook introduced to the scene that Preact/React implements are solid, so are the state patterns that Flux/Redux introduced.

Don't you think that we miss out somewhat if we base our choices on branding rather than content/actual-code?

Collapse
mellen profile image
Matt Ellen

I realise there is no ethical consumption under capitalism, but what Facebook and Google do and have the power to do puts them in another league.

It has nothing to do with brands, and I don't condemn anyone who choses differently to me.

Using their libraries is implicit support for the companies. I can work adequately without them.

Thread Thread
sebbdk profile image
Sebastian Vargr • Edited

I’m not sure i can see how that support works, how it could be negative, or how it ties into capitalism for that matter.

The whole open source ecosystem seems very apart from the idea of using currency for trade, or trade even being a thing for that matter. :)

What do you think?

Thread Thread
mellen profile image
Matt Ellen

I think that using software created by a company is showing support for that company. If there's no other choice, then fine, but there is so much choice in OSS that choosing to align myself with a company I find abhorrent is illogical.

Collapse
patarapolw profile image
Pacharapol Withayasakpunt • Edited

OK, I have some anecdotal experiences as well.

  1. SPA may be slow for minority of users with slow bandwidths, but a complex WordPress site can be slow for MAJORITY of users with decently fast connections -- mainly because of lack of preloading.
  2. Although I don't know much SSR technologies, I would say that developer's experience matters. Breaking into fully contained components help with development.
    • I know there are templating engine, but I don't know how well it integrates with JavaScript (bundler)...
  3. I personally think that websites are usually either content-focused or functionality-focused.
    • Faster-than-whole-page-loading functionality-focused must be a valid use case for SPA's.
    • About content-focused, Static-site generators (like Jekyll, Hugo) might be faster than SSR (and security?), but I am not so sure. But what about when you need some minor interactivity? That's when JavaScript, and perhaps esbuild is needed.
Collapse
Sloan, the sloth mascot
Comment deleted
Collapse
steveblue profile image
Steve Belovarich

The definition of engineering isn't "solving problems with the tool you like". 🤷‍♂️

Collapse
mpixel profile image
Max Pixel

How about we just let people use the tools they like?

That's "technology driven development" rather than "user driven development", which inherently reduces the effectiveness of any project that is intended for use by anyone other than the author.

The author raises a point that those of us with fancy smartphones easily forget: A lot of people are still using devices that can only practically handle "Web 2.0". By deciding which tool to use based soley on what we like, we might be inadvertantly worsening inequality of access to information. By not simply letting people use what they like without being bothered, the author stands up for the disadvantaged. Bothering a select few who don't want to be bothered, but for the greater good, is a heroic thing to do.

Collapse
Sloan, the sloth mascot
Comment deleted
Collapse
joshuaamaju profile image
Joshua

I've really gotten to that point. I've stopped using react for most of my projects, tried doing things the good old way, and damn - it's good. Although, I know there might be some issues as things get bigger, but I'll cross that bridge when I get there. I won't let the fear of some unknown scalability issue push me to make the wrong choice.

Things can be a lot simpler than they are now, if you want an SPA, do it the old way and use Turbolinks. I've never felt more saner since I stopped using react.

Collapse
joelbonetr profile image
JoelBonetR • Edited

I see that as an Analysis issue from the beginning.

I've stopped using react for most of my projects, tried doing things the good old way, and damn - it's good.

This means you didn't analyzed properly what you are about to build so you chosen react for everything and now you are pleased and how well the things that shouldn't be done with react work without react.

For giving an example you can use PHP for coding a simple form handler for a landing page or you can use java.
If you chose java for code 100 landing pages and then you switch to PHP you will be pleased (and your cloud server's bills too) because java was not the right technology for that job from the beginning.

Collapse
joshuaamaju profile image
Joshua

That has no bearing on what I'm talking about

Collapse
markohologram profile image
Marko A

So, you would just replace one JS library (React) with another (Turbolinks)? On top of that, Turbolinks wasn't updated in ~2 years unfortunately.

I know React isn't supposed to be used anywhere and everywhere because that doesn't make sense, but people offering alternatives don't always have the best arguments really.

Collapse
joshuaamaju profile image
Joshua

Turbolinks is just to give it a SPA feel, I'm not building the whole site with turbolinks. I don't write turbolinks, there's a difference.

Collapse
rwoodnz profile image
Richard Wood • Edited

Try Svelte. It's a lot more fun and fast to get results. And the pages run faster. You feel like you are just doing html pages with minimal templating/framework bullshit. You can add self contained components into plain JS sites very easily so long as you are prepared to use webpack or rollup. I'm an Elm fan for real engineering otherwise but if you want something quickly such as your own project then Svelte wins.

Collapse
bnrosa profile image
Bernardo Rosa

I agree. Take a website such as github for an example, it is fetching html as you use it and it is very fluent and complex (much like an SPA) without all the overload a big JS bundle brings.

This is why I'm interested on initiatives such as LiveWire, that try to bring the benefits of not having to reload a page without all the extra stuff that makes development with tech such as react a big pain.

Collapse
tettoffensive profile image
Stuart Tett

Can you explain more about what Github is doing? Are they using a particular tech stack? I’m curious if what alternatives there are for developing web applications.

I’ve used both Vue and React and sometimes I prefer templating and other times I prefer JSX depending on the complexity of the component.

I’m always curious about solutions that follow the “ Ship HTML, not too much, mostly plain.” mentality.

Collapse
jwkicklighter profile image
Jordan Kicklighter

At its core, GitHub is a Ruby on Rails monolith. I can't speak to what they use for frontend interactivity, but the main application is a traditional rendered-on-server Rails app.

Collapse
bnrosa profile image
Bernardo Rosa

I think they use Turbolinks.

Collapse
loouislow profile image
Loouis Low

I only learn and using some tiny parts of React, such as how to make web component, looping and props, for creating a basic templating based on the given prototype UI design, just to pleasing my frontend dev team.

I personally not a fan of React language design. It's ugly to me.

Collapse
sebbdk profile image
Sebastian Vargr • Edited

Do you mean JSX?

modern react can be done almost purely functional, and libraries like htm (github.com/developit/htm) bridge the gap of sanity so we do not have to use tools like JSX anymore. :)

Collapse
loouislow profile image
Loouis Low • Edited

Yeah, JSX is one of the main reasons. And also looping is not look pretty to me. Thanks for the module that you recommended. I try not to add additional modules to the build. I still can live with the stock feature from React. I just give myself a chance to complaining about my experience in React. Developer Experience is also important to me. I also understand React is made by the big company and it is famous on the internet. But, I am more a practical person. If a tool is good for me, then it's good. Very controversial, yeah?

ender_minyard profile image
ender minyard Author

There's no evidence that JavaScript frameworks consistently improve the user experience but you're considered out of touch for not using them because they're in style right now. Trends are exhausting, but don't worry. They come and go.

Thread Thread
Collapse
naismith profile image
Chris Naismith

I think you have to look at what you're building. For example Netflix is really big on React, and the JavaScript you're shipping to the user is much smaller in comparison to the CPU and bandwidth required to stream video.

I'd also say it comes into the other libraries people end up including into their bundles, for example Moment. React + React-Dom is only 38.5 KB where as Moment is 70 KB (both when minified and gzipped).

Collapse
ducaale profile image
Mohamed Dahir • Edited

You can do so much with plain Javascript considering the advances it made in the last several years. There is also Vue.js which could be imported using a good old script tag.

Personally, I prefer the React's approach to UI (one-way data flow, views as composable functions, hooks), and it is where other ecosystems are converging to (android's Jetpack compose, iOS's SwiftUI).

Collapse
velua profile image
John Williamson

While a lot of these related to SPA's it's also just related to a sites overall page load size including media like photos and videos. While these should be optimised we're heavily held back by the web's transmission layer, HTTP, we should move towards less wasteful methods like IPFS where data is much more accessible and cached. This will ensure no time is wasted on downloading the same thing twice, even across several sites.

Some comments have been hidden by the post's author - find out more

Forem Open with the Forem app