My rant about React(silvestar.codes)
silvestar.codes
My rant about React
https://www.silvestar.codes/articles/you-don-t-need-react-for-building-websites/
78 comments
The author went to some length to explain he is not talking about building web applications - but websites.
Well, not so much "some length", but they introduce the distinction and make that clarification briefly towards the end of the post. But they don't go into detail about what the distinction really is. Some of the projects I've used React for have been consumer-facing, informational "websites", but have benefited from the structure and data integration that React enables.
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?
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?
Anecdotal, but a lot of front-end positions I see do require either of a) experience with some framework or b) experience with React specifically.
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.
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.
> jQuery, Prototype, ExtJS/Sencha, Backbone.js and Angular all seemed promising, but none took enough of the pain away.
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 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.
There is a significant caveat here: you mention "building rich web applications", but that is different than building a simple website.
Not really. React gives you the ability to create "rich web applications", but it can be used just as well for the most basic of landing pages. Couple that with SSR and you get basically the old "HTML,CSS,JS" setup with much better tooling,.
I can't call the constantly shifting sands of "nodejs" ecosystem a better tooling.
I understand many React tools depend on Node but the React side of it has felt very stable to me in the last three or so years.
You don't even need a damn framework.
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.
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.
I've seen a lot of bad React websites that are slow because the developer was a half-assed React developer or just learning and didn't notice on his 4Ghz i9 machine that something is making rerender every component on scroll event or something
This. When someone needs to solve some particular problem, they reach for the most convenient npm package called "react-something-something" that works great until, a month later, there is more data or complexity in the application that the performance issues introduced by the component become apparent.
Or, that npm package
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.
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.
And, that npm package brings 200 MB of dependencies, even though it actually requires only 10 files total.
Funny, another commenter below made that exact comment - "I love how fast I am able to deliver features by just bringing in a few libraries"
This does not mean that you’re bringing in dead weight or security black holes. The statement remains true if you bring just a couple libraries like Material UI, an SDK or two for key API interactions, and maybe a state management lib if the situation calls for it.
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.
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.
Bringing in Material-UI actually feels like a good example - the last time I used that framework, it felt fairly large. I guess it was ~3mb as of their last publish (0.20?). Now, it's large enough that they've split it into ~4/5 packages, although it appears you would want to take the @material-ui/core to get started? This is 6mb alone, and the other pieces that are just material bring in another couple of megabytes, and then there are additional dependencies. So, a fairly sizable starting point, and then you've got your own code, and then you've got whatever additional components you want to pull in (more widgets, a drag-n-drop, etc), and suddenly you're looking at what the GPs were saying. The package file is probably still pretty clean, but pop open node_modules or the network tab when the page is loading. Even a small number of dependencies pretty quickly bloats up size
Material UI core is around ~100kb bundled.
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.
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.
Same story here. I have around 50ish web applications that I run for customers. There is hardly any time spent on maintenance and is recurring revenue for me, and I can spend most of my work time on creating new business opportunities. Some of the web applications are from 2005 and display real-time information about available items in their inventory, real time customer support chat, real time sensor data from oil rigs offshore.
> You don't even need a damn framework.
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.
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.
1. Browser APIs have subtle differences, or don't always exist in every browser you need to support (e.g, https://caniuse.com/)
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.
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.
I have a hard time learning react, because the 'language' used is so divorced from the concepts or actions of what it is the code does... If that makes sense. So I memorize some language chunks in react that does something and this is supposed to be 'programming?' How can I ever know what this stuff does? And why I'm supposed to use it. I just get frustrated with all these frameworks.
Unless you’re using machine code, it’s all frameworks on frameworks.
Well, language != 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.
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.
"It is fair to say that I don’t understand it, so I cannot even rant about its features, shortcomings, or flaws."
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.
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.
> 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."
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."
Whether you "need" something seems like a rather vapid bar to quibble over. You don't really "need" anything, but evaluating the trade-offs of using something is one of the primary roles of an engineer.
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.
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.
“You don’t need react for websites” would be the better headline. Even then you’d expect the author to have at least some experience using the tools in order to make a good critique or informative article.
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.
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.
The author might not realize it but he actually confirmed a point. React just doesn’t click for some people. I’m one of them. I have fairly extensive coding experience though only a few years professionally. I’m not a front end engineer but have created and maintained websites that were in production. I’d not consider my code scalable though. I have used jquery and now I use vue. I have tried again and again and react (and let’s not start with redux) just doesn’t click. It seems too cumbersome, at the least for anything less than a massive massive application. I also abhor SPAs. I am genuinely curious why I and apparently some others as well have so much trouble clicking with react.
I'm curious how well you would describe your understanding of Vue?
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).
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).
Yeah - I agree with the article's premise, but it's a pretty weak effort given that the author hasn't really delved into React.
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.
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.
Looking at more of the authors site, it seems they're primarily a wordpress developer.
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.
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.
I use to build websites before react, so I know how to, but I love react. To me it’s setup (and I’m one of those who still use classes) is basically how my brain would organize them before while states keep all the different data stores and api calls nicely abstracted and contained. I honestly don’t know why you’d want to not use it (or some equivalent, though I don’t yet know any.)
> I honestly don’t know why you’d want to not use it
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.
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 what’s an alternative to react for simpler websites like blogs? Surely the answer isn’t to just go for vanilla js and html? There’s a lot of differences between browsers and a lot of abstraction that lets me just get to work in react. I’ve built a couple of blogs, using react for the frontend, and I didn’t see anything wrong with that.
Yeah same. I remember when I started messing around with web front-end, I wanted to do pure HTML/CSS/JS, but I found it doesn't really work on web since there's all these little browser fragmentation issues you have to contend with.
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.
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.
”I feel like 9 out of 10 job ads for a frontend developer mention React.”
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
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
I'm surprised this incredibly low effort post has garnered this many votes on HN. The fact that React is "just javascript" itself, notwithstanding, the author seems to conflate the needs he's had when building websites with needs that folks encounter when building web applications. Knowing javascript, html, and css, are wonderful and necessary skills to being proficient at web development, but discounting a framework like React and all the utilities it provides for common patterns and needs you encounter in building applications is akin to saying that you need not bother with things like .indexOf because, well, if you know javascript well enough, you could just implement it yourself!
And Rails is just ruby. But like React, it’s a framework for the web built on top of the language. It’s additional complexity you don’t need to use when it’s not beneficial. React is great for web apps. The author is building websites. Those don’t need React.
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.
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.
My counterpoint is: I don't want to make any website today without React. But hear me out.
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.
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.
The author of this seems to be talking about simple static sites and has issues learning React, however I think his rant could be extended to a bunch of "web apps" (that aren't actually apps)
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 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 cannot think of any part of the website that would require React.
...I feel like the author is strictly talking about static webpages, and doesn't have much frontend experience outside of that.
...I feel like the author is strictly talking about static webpages, and doesn't have much frontend experience outside of that.
Yeah if you are building static websites you of course do not need React. React is useful building dynamic websites which is exactly what it's built for and the way that the modern web is going (in terms of interactive applications). It makes sense for frontend devs who want to work for a SaaS to know React. If you are building landing pages, not so much.
You don't need React for building websites. You absolutely need React (or something like it) for building web apps. The more interaction your client-side code has the more you'll regret just using HTML+JS.
I really wish people would be more careful about their language here. Not everything running in the browser has the same level of complexity.
I really wish people would be more careful about their language here. Not everything running in the browser has the same level of complexity.
> Not everything running in the browser has the same level of complexity.
This is literally the author's point.
This is literally the author's point.
You don't need React for web apps, either. There are plenty of alternatives out there for that, too.
jQuery/stock JS works just fine for literally every possible use case.
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.
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.
This is just flat untrue. There's so many usecases where you would have to be a masochist to choose only jQuery or stock JS.
I mean, the article did say: "The web app developer does need React or similar frameworks. The website developer doesn’t need React or similar frameworks."
There is a thing I feel a lot of developer forget about React: the ecosystem. I'm currently building a relatively complex side-project, and I love how fast I am able to deliver features by just bringing-in a few libraries, every clicks together and it "just works". Pretty much anything these days is possible in React, you have tons of well-maintained and documented libraries, this is, in my opinion, maybe even more valuable than the library itself.
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.
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.
Look, I've been building stuff for the web for over 20 years now, and I started with learning basic HTML/CSS/JS. I fondly remember the days when we had to for-loop through the DOM in order to find every element we wanted to modify, or hack around IE6 limitations. I've had the pleasure of watching front-end evolve from server-rendered pages to "enhanced interactions" with JS/jQuery to massively optimized, client-driven web applications built with technologies like React.
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.
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.
Having built websites for about 25 years now, and initially feeling quite against these large frameworks/toolchains for building large 'web apps' which needed to update things on the page without reloading, I looked in to React and Angular.
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.
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.
I have been using Angular for a few months now, honestly pretty happy with it so far.
The one thing that made me consciously avoid React for years (in favour of other frameworks) was the sheer amount of hype surrounding it. My experience is that more often than not this is a major red flag.
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.
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’m surprised this made the front page.
> 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 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 felt exactly the same way. In its most generous form, the rant boils down to "well... if you know Javascript well enough, you could dispense with things like .indexOf because you could implement it yourself!" It's quite low-effort, and I don't understand how it's made its way to the front page.
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.
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.
If you are making a web-app, if you decide to go Vanilla JS, you are eventually gonna end up with a react-like library regardless.
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.
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.
Where is info about how much scrutiny each framework received from security standpoint?
> rely on good old HTML, CSS, and vanilla JavaScript.
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.
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.
[deleted]
It's simple - just pick the best tool for the job. If whatever you're building only needs flat file storage just use flat file storage instead of bemoaning the database as overrated.
For our company website we use React but just as a server-side rendering engine (similar to express-react-views, so not even next.js because we don't need or want client-side react)
I feel the same way about Spring (and especially Spring Boot).
With Spring this is actually true - there are better alternatives for Java, and there is too much magic under the covers. I use plain servlets, jsp and a handful of libraries for common operations, and it is so much easier to debug when something goes wrong.
Musk's 5 steps:
Design
Delete
Simplify
Accelerate
Automate
Based on that a framework would end up as a set of simple add-ons, rather like Unix.
Based on that a framework would end up as a set of simple add-ons, rather like Unix.
I would still stick to Bootstrap/jQuery as my weapons for buildings web apps for easy to mid complex work.
I think most of the usual stuff in jQuery can be done with vanilla JS really these days. It does have its odd use but i've not needed it. Your needs may obviously differ. I would see if you can skip it though as it saves on loading more files.
[deleted]
has it occured to these people that it's possible to... like React? And use it for that reason? Same for webpack, typescript etc. There is no church of modern front-end development going around indoctrinating people on these (there seem to be some forces doing the opposite actually).
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.
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 can strongly recommend to learn React & NextJS. The two make you highly productive. Plain HTML + CSS + JS is just a waste of time.
Sure, you don't need React, but it makes the process much easier. Take a framework like NextJS or Gatsby, these frameworks are tailored for landing pages and "websites". While yes you could do the same thing with regular HTML, CSS and JS, the tooling and other features that you in React make it a much better framework IMO to move quickly on a website.
You don't need React, but it is a powerful tool. Many people have decided that they want to use React to build websites. It feels as though the author should be trying to understand why everyone is opting into the React ecosystem rather than complaining about it
You don't need a framework. You don't even need JS. You don't really need CSS. You can fire plain HTML 1.1 code at people and it'll work fine.
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.
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 can however use React to build (static) websites, and it works really well for two reasons:
* 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.
* 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.
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.