My rant about React
silvestar.codes
silvestar.codes
That's the real substance of the post right there. It's a valid expression of the author's experience. But it's irrelevant to people who know they need React and know how to use it appropriately.
I've been building websites since 1996, using HTML, JavaScript and CSS right from those early days.
I always found it frustrating for building rich web applications, or even "plain" websites with any significant amount of interactive functionality, and I made several attempts at building frameworks of my own to make it faster and simpler.
jQuery, Prototype, ExtJS/Sencha, Backbone.js and Angular all seemed promising, but none took enough of the pain away.
Since I started using React about 4 years ago, I've found building rich web applications a joyful experience for the first time in my career.
To be clear, I'm not using it for tasks where plain HTML/JS/CSS are adequate for the job. When I build basic info webpages, I just use plain HTML/JS/CSS, with maybe a bit of jQuery. It's fine.
But a lot of my work is on sites/applications where many data entities need to be updated in many different places across a view or the whole app frequently and quickly (notably, apps that display live weather/environment/crop data for farmers and researchers), and React with Redux makes it very simple to do, with the app still being lightweight and fast to load and very responsive to user interaction.
And it's a nice bonus that I can re-use a lot of the code for native-ish mobile apps using React Native.
But I only knew that React was useful for me, and learned how to use it, because I had a pre-existing need and many years of frustration using frameworks/libraries that didn't tick the boxes.
If the author isn't building products that would actually benefit from the introduction of React, then it's unsurprising that they don't see the benefit or find it easy to learn.
Anyway, is there really such a widespread pattern of employers requiring React experience when plain-vanilla HTML/JS/CSS is all that's needed on the job?
The weight of the post rests on that assumption, but where's the evidence for it?
But I agree with everything you’ve said in both your comments. I think that a lot of companies are asking for React because a lot of them are building web apps or “mildly interactive” websites, where (I agree with you) React is also fit for purpose.
I feel the same. Coming from MooTools, Prototype, Dojo I have found that modern frameworks like Vue and Svelte make my life so much easier.
The whole JavaScript ecosystem with Node.js and npm has helped such ideas/implementations/frameworks bloom and I'm grateful for that.
I learnt the basic web technologies 20 years ago, and have kept mostly up to date with the subset of improvements to browser APIs that are actually important. This knowledge has served me well, and I don't have to re-learn the latest thing every year because something new is trendy.
The less unnecessary complexity between me and the browser, the better. I can spend my time being productive instead of wasting it learning about how to migrate from version 15 to version 16 of some overhyped framework.
a) is deprecated
b) has security issue, with no patch
c) web framework has major changes, making it challenging to upgrade, so you need help from framework maintainers for upgrading
Any code that you have not written yourself has pontential to break. It's same for every programming language.
The other day I pruned unused dependencies from a medium sized app we’re about to launch and package.json was not much more than the above.
If you’re doing some kind of code-splitting or SSR you can probably serve a fraction of that.
Unless you’re developing for a very particular use case like embedded, I fail to see how the raw size of the package is any concern given how much MaterialUI brings to the table in terms of interaction design capabilities and dev speed.
Regarding your comment on the network tab, that’s really got me scratching my head… I’ve done a lot of profiling of React apps and when they’re bundled you don’t see a network call explosion because you’re just downloading a couple of JS bundles at worst… I can guarantee that a React app with the dependencies you describe would have anywhere between good and excellent network performance in 3G and above.
thats a very classic problem. some people like frameworks some dont. some poeple like ORMs some dont.
at this point im done fighting these battles - whatever job market requires im just gonna use.
2. You'll need at least a transpiler (if writing anything above ES5) and polyfills to solve #1, and if you're diving that far into the JavaScript tooling chain (bundler + babel), might as well choose to use a framework.
But you do have a point - the browser itself can sort of be considered a framework (some might say runtime), in the sense that it's a layer of abstraction. Certainly an imperfect one, but an extremely mature and stable framework with excellent backwards compatibility.
Then I don't understand why you're writing an article about it? Just to rant about the React hype? That seems a bit pointless.
I mean, the thesis is "If you are building websites, you don’t need React (in most cases)." And it ends with "Knowing React could only make you a better developer, and I am not saying you shouldn’t learn it. However, I am saying that it is not needed in most cases if your goal is to build websites."
On HN, we too quickly circlejerk over whether a given project really "needed" some bit of tech and brag about how we could build it without, as if that's the metric that matters.
If you used React unnecessarily and the project is worse off for it, fine, you're still learning. But it all too often becomes one of these blog post rants with the extra whammy of people coming into the comments to brag about how they've been hand-coding HTML since 1999 and don't see the point of a tool like React or Javascript.
Even a small preface that this doesn’t apply to web apps or business software etc.
This puts a lot of weight on the reader when it’s the authors job to communicate effectively when asking for people’s time investment.
Because to me React and Vue are basically the same concept under the hood but presented differently (single file components vs functions that render html).
Having done a fair number of side by side implementations of things with React and vanilla JS / jQuery, React has always ended up more code and complexity (and an inconvenient extra build step). More shunting state up and down the call stack to conform to the functional architectural ideals, etc.
It shines on certain types of problems, but seems to get shoehorned into a lot of others due to hype and groupthink.
If they had focused down on "you don't need react for static sites", it would have been a more valid complaint. But as written, it seems that the author just doesn't have experience with larger web apps.
It’s big and it’s slow when compared to other frameworks and particularly when compared to no framework at all.
I think the important takeaway is that there is no single answer here: different sites have different needs. If you’re making a highly interactive site people will sit on for a long time (say, Gmail) then React’s downsides will matter very little. But if you’re making a “one and done” single page, or a site where the vast majority of the page is static content (e.g. a blog) React is wasteful: a wasteful addition to the page download size and a wasteful process of serialising prop data and hydrating a bunch of components that never see their content change once. It doesn’t matter a whole lot on a desktop machine but try profiling on a low powered Android device, the Chrome performance burndown chart is sobering reading. Even on the server, too… I’ve run into issues before now running React SSR on high traffic web sites.
When making a highly interactive web app a framework like Svelte is smaller, performs better and is a joy to use (a matter of opinion of course). At the very least I’d ask “why not Preact?” when starting a project: it does 90% of what React does at a tiny fraction of the size. That Facebook hasn’t made any meaningful progress in shrinking React shows that it isn’t really a priority for them.
So I added JQuery, which was fine, but you still had to build a lot on top once you start building something web-application like.
I tried Angular when that came out, but that felt like it was a little too heavy and opinionated, sort of like a "rails for the front-end".
Then finally React just seemed natural to work with. I could finally build fairly re-usable components, and you had the behavioral logic and state neatly packaged with the "view" definition. It seems like the first time someone had really nailed it with a structure for web front-end, and like that's the way it should have worked all the way along.
Those jobs are not for developing webSITES. They are for web APPLICATIONS, which need a lot more developer manpower than just basic sites. So of course the demand will be higher
Like 90% of random static business websites nowadays are made with wordpress. That’s where the webSITE development happens.
Why? Because the client needs to easily host it. Because the client wants to update the text without needing to know HTML. No need to reinvent the wheel for every single ”we sell cars” website
The problem the author identifies is when really popular frameworks overshadow their respective languages such that people think you have to use them for everything.
With NextJS, you develop everything with React. Then on a page by page basis, decide how static/dynamic that page is, and you can completely remove runtime React entirely if you want.
You get the best of all worlds: a nice dev experience, a consistent dev experience (as in your fully static pages are still built in the exact same way as your dynamic ones), compliant HTML, a wide variety of libraries to use if needed, etc.
I have entire websites developed with React that don't use React at runtime for many, even most, of their pages.
You can also accomlish this with Gatsby, but I've since switched completely to Next as I feel it now outshines Gatsby.
I took a mixed approach for our SaaS that needed rebuilt (it was previously in Adobe Flex) to keep things simple and fast with Laravel.
Most of the site is just basic html/crud, so that portion is just simple templates/forms. It went up super fast and remains simple/easy enough for someone just starting out to modify.
There are some bits that could do without a page refresh however. For that Livewire is sprinkled in as needed. I think someone like the author could even handle that.
Finally, there is an actual creating/editing canvas application portion of the product where you can outline, draw, drag/drop, resize and a whole bunch real interactivity. This simply could not be done without a full on javascript app, so you will need to be experienced developer to get in and build this portion.
It has been a real joy to not only build but also maintain since it's launch. I certainly don't miss 1 giant build to update some label in the old Flex app.
All things in moderation and KISS :)
...I feel like the author is strictly talking about static webpages, and doesn't have much frontend experience outside of that.
I really wish people would be more careful about their language here. Not everything running in the browser has the same level of complexity.
This is literally the author's point.
The main benefit of React, if you're an engineering manager somewhere, is to bloat your staff, bloat your toolchain, bloat your builds, and as a consequence, bloat your budget. And when the enormous dependency tree download+parse+JIT, runtime scaffolding, all the ridiculous virtual dom diffing and other completely unnecessary garbage slows down the user experience to near-unusability, you can hire some "performance engineers" to consolidate your fiefdom even more.
I will admit that if your status is proportional to your headcount, React is an absolute gamechanger for your career.
Also: developer time, React is like a shared language, I can jump in virtually any React project and get started in less than an hour, from memory: this wasn't always the case with good old HTML/CSS/JS applications, because developers are doing things in different ways, give me a React component and I'll probably be able to tell you exactly what it does by just having a look.
The thing that gets me here: the "tech industry," or the industry we commonly think of when speaking about software positions, no longer "builds websites." They build web applications. There is still an industry that builds websites: marketing. In fact, taking a scroll down the author's portfolio confirms the lens in which this post was created: it's all marketing-driven websites in various technology stacks. I'm not mocking them, I'm just observing.
The marketing industry certainly builds websites, but the pay is crap even for independents. Don't want to learn React/other framework for a position? Want to focus on specializing in vanilla fundamentals? Want to eventually be forced to work on developing email templates? Want to pump out landing pages all day? Narrow that job search to the marketing industry, and you'll find plenty of work. But you shouldn't expect the compensation to be competitive with the tech industry. Marketing is sunk cost, risky, and the ROI is much less straightforward.
I'm not attempting to devalue the fundamentals, and there is certainly an opportunity for experts in those fundamentals to exist. In fact, I feel that engineers with better fundamentals are apt to improve everything from performance to accessibility. But the demand for experts on those fundamental technologies alone just doesn't exist. And even the marketing industry is changing: they're adopting headless CMS, static site generators, and other, modern web technologies.
The entire point of being upset that React is an expected skill in tech-progressive job postings is ridiculous at best and apathetic at worst.
I work now with a small team. A backend server guy, who builds the API endpoints; a 'designer' guy, who helps make sure things look the way they should (not a JS coder at all); and myself who wires it all together and deploys the sites.
I ended up choosing Angular over React, and have been extremely pleased with the experience.
But one of the key reasons for picking Angular over React was the nice way it deals with 'components' and the TS/JS, HTML and (S)CSS they need.
If I'd opted for React, there didn't seem to be any easy way the 'designer guy' to still contribute, since much of the markup is deeply embedded into the JavaScript.
Angular has been an absolute pleasure to work with, in the team setup we operate within.
And I've grown to really like working with TypeScript, along with the deployment pipeline we've now evolved.
I still don't quite know what it is about React that makes it seemingly so popular with developers (and job ads), over another framework like Angular. Is it a Facebook thing/attraction over Google? Very curious to know why.
Having acquired at least a year of commercial experience in every leading framework I acknowledge that the developer experience is top notch, but it's oversold on a few key features, namely:
-"it's a library, not a framework" was BS as early as in 2017, when create-react-app v1.0.0 was introduced.
-It's said to be backwards compatible, but that's true to the same extent as in JS - new features introduced new conventions, which appeared to be driven more by hype than anything else, to the detriment of productivity. Hooks stand out as an example - it's a "junior killer" at least as much as Redux, and on top of that I've seen React developers misunderstand the premise to a point where they introduced obvious performance bottlenecks when trying to "update" the codebase. Performance tuning of React is a major PITA, but mostly because people new to front-end don't understand how the DOM works, which brings me to another point:
-The virtual DOM isn't a silver bullet(duh), but developers often ignore that. One glaring example is ironically Facebook itself, in which text selection tends to jump around and GC pauses are not only visible, but manage to freeze the page for seconds at a time. All because (I assume) the devs trust the framework too much.
Overall I'm thankful for next generation frameworks like Svelte or SolidJS, which manage to bring the developer experience to the same level of simplicity that I remember from over a decade ago, but without the drawbacks of the technology of that time.
> I don’t get it. Why would I need to use React if I am supposed to work on building websites?
Haven’t we established already that you need a client-side JS frameworks for managing complex interfaces? There’s a point where you website becomes so interaction-heavy you end up writing your own “React”. Until then - feel free to go with plain JS.
I'm guessing there are lot of folks who have all sorts of frustrations with React (as there will be with any tool/service that is used by that many people), but this article is 100% devoid of any actual criticism of it, constructive or otherwise.
Simply put, if you don't use it at first, you are gonna end up needing the same feature set. Creating DOM elements based on a model/state. Try making something as simple as a date-picker without one.
Except if you decide to do it yourself, not only do you have to organise your business logic, but also the logic of how your custom front-end framework handles stuff.
A front-end framework you'll have to train all your new hires to use.
A front-end framework your existing developers can hold you hostage over.
And finally a front-end framework that you will have to fix and support yourself, and that you can't google solutions to, and that has received zero scrutiny from a security standpoint.
Unfortunately, it's not always that easy. Often times, this same camp will forget about accessibility or other performance indicators like image optimization. Also, native web platform features usually lag behind the web performance and JavaScript communities.
Yes, React isn't always needed – but more often than not, it's a solid choice for your company. There are no absolutes. But there's a reason it's the most popular way of building frontends right now.
Based on that a framework would end up as a set of simple add-ons, rather like Unix.
Whether react, webpack, etc is efficient/neccessary is sometimes irellevant, if they happen to fit the mental model of some people and make them more productive. Same to any other pop language/frameworks that might be deemed inefficient: python, rails, PHP... You don't "need" to use them, but that's a silly thing to say.
I'll stick with React (or another framework) though. I can build faster with it, which solves my users problems faster. They seem to like that.
* You now have a uniform way of generating HTML, whether your project is highly interactive or not.
* In very basic terms it is a highly productive template system that is easily and gradually extendable with interaction and UI state if needed.
The author suggests that you typically just need HTML and CSS and a bit of JS to generate simple/static websites. This is just not true. If someone is paying you to create a website, you certainly need some way of decomposing a design (-system) into reusable parts that are fed with data from somewhere. So you end up with a template engine + the above things. React solves this problem right off the bat. It is really easy to use it that way and the only leap from a more traditional template engine is syntax and composability.
There are a lot of good alternatives worth considering. Just don't compare it to "just" HTML/CSS/JS because on that front it is simply superior in almost every way imaginable.