What a load of dung.
If not React, then what?
501–510 of 756 posts
Re: If not React, then what?
#502I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…
A more generous way to say this is that the code is more readable, which is in fact important in a growing codebase.
plenty of react code looks nice but is still unreadable
Re: If not React, then what?
#503Once you get to the examples of different types of webpages, the author basically admits React (and SPAs in general) is likely appropriate for a bunch of application types. At that point the argument seems to boil down to "use a CMS and a simple frontend if user sessions are simple enough".
Re: If not React, then what?
#504Earlier quoted context omitted.
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…
>Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor. if that isn't enough for your react powered site, you are doing something very wr…
React sites still feel janky on my 24cores and 48gigs or ram. Which is impressive for all the wrong reasons.
Re: If not React, then what?
#505Earlier quoted context omitted.
To your third point - the author would recommend doing research and prototyping with all the options you might consider based on your use-cases. He actively avoids being prescriptive in generic contexts like this because he wants to avoid arbitrary dogmatic solutions (like React tends to be). Source: I work closely with him and have been frustrated with this stance until I saw people using Next and Remix for things l…
(Sorry, somewhat copying this, since I responded to a similar point elsewhere.) This is not practical advice for the vast majority of software engineering teams. Most teams do not have the privilege of being able to do research and prototypes across multiple options, at least in a way representative of what their final product will look like. Most teams - at least those in small to mid-size startups - will start out…
My experiences don’t really align with yours - most people are playing “follow the leader” with tech - “X uses Y, so we should to” and that’s it.
To your point though - use the platform. Vanilla HTML, CSS, and JS. All of that will be reusable no matter where you pivot and not lock you in to a pattern that might not work well for where you land.
Re: If not React, then what?
#506Earlier quoted context omitted.
> Maybe you write isomorphic javascript I’m surprised to see people still misusing the word isomorphic.
it's been a term of art for a long time
That's technically true. Indeed, "isomorphism" has been a term of art for about 200 years.
More recently though — over the past decade or so — JavaScript enthusiasts have been using this word to describe code sharing, which isn't quite right.
Re: If not React, then what?
#507Earlier quoted context omitted.
Which one of these technologies is React built on top of?
HTML, specifically react-dom. It’s built with JavaScript
Back in 2013 there was a nifty little library that everyone, absolutely everyone ended up using called https://vanilla-js.com. They even had a size calculator depending on the features, amounting to zero bytes every time (25 bytes gzipped).
Re: If not React, then what?
#508Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Try opening facebook.com; click the messenger, (+1 second) Click one of your chat groups (~2 seconds) This is merely just to show something From what I have seen, its quite easy to have performance issues with React
but i think the reason for +1s, +2s feeling comes not from the client side aka react, render is fast, but they do make two requests to backend which takes ~230ms (for me in EU) and one request of ~130ms every other click on already visited chat/group chat.
Re: If not React, then what?
#509I think React is fine, especially when using it mainly for rendering, keeping async stuff out of the components as much as possible. The React API is way nicer to construct DOM trees than using Fragments, creating and appending children elements, concatenating strings to produce HTML, etc. Imagine being able to do this without importing any 3rd party code: const content = html` Hello world! `; // New API: html Tagged…
Apart from running screaming in the opposite direction from tagged templates for security reasons, I think a more suitable approach (that fits current ECMAScript naming conventions / namespacing) might just be something like: const content = document.createTemplate(`tagged string`).content You can already effectively do this, though you'll have to decide for yourself if putting the following lines of code into a top-…
What security reasons? Tagged template libraries like lit-html are extremely safe.
Re: If not React, then what?
#510> Frameworkism isn't delivering. The answer isn't a different tool, it's the courage to do engineering.
While frameworkism has bad sides, React (hooks) is bad in very unique and particular ways, sometimes switching a different tool is the answer.