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.
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.
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.
> 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."
“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.
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.
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.
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).
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.
I am in a situation where I don’t need to apply to new positions and choose my employer often, but I keep my eye on job ads frequently. I sympathize with developers who are capable of building solid websites but struggle to find a job because of the lack of React skills. I know at least one person who would be thankful if React skill wouldn’t be listed so often — a friend of mine (and my mentee) with whom I share the office these days.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
> I had a few attempts to learn it, but I failed every time. It is fair to say that I don’t understand it, so I cannot even rant about its features, shortcomings, or flaws.
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.
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,.
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?
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.
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 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."
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.
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.
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.
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)
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.
> 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.
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.
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.
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.
78 comments
[ 3.2 ms ] story [ 148 ms ] thread...I feel like the author is strictly talking about static webpages, and doesn't have much frontend experience outside of that.
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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
* 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.
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 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.
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.
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.
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.
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.