There are three levels of frontend interaction complexity:
Up to form action=foo method=post and button type=submit. For this, HTML + CSS is the easiest solution.
Up to buttons with simple animations. Jquery or vanilla is the easiest solution.
Anything over it. React with potentially extra state management libraries is the easiest solution.
Yes, you don’t need React for websites with minimal interactivity requirements, but as soon as you have to add just a few of those requirements, you quickly regret not having React.
Also, things like GatsbyJS or NextJS can be configured to output static sites. This may look like totally overkill, except for a tiny detail. You get to use all the module management and import semantics from Javascript to manage your components, which is way better than plain old CSS files and copy-pasta for HTML snippets. Add in Typescript and you have a strong proposition. Though WebComponents may do something similar here…
There’s a level past React too though. React can’t really do high performance things, so for those you need to turn to Canvas or something and handroll it. Tom MacWright made this point in the now classic “Rethinking the Modern Web”.
Here’s one way to think of it:
Google search: can be handled as HTML, CSS, sprinkles of JS animation
Gmail: you’ll want some kind of JS framework to handle all the zillions of screens
Google maps: you don’t want a framework doing the map because it will be too slow. The map is canvas or some other smart layer that can load tiles on the fly. (Nav buttons can be whatever.)
It’s extremely easy to migrate from a simple HTML + CSS site to a site with JQuery or vanilla JavaScript, because JavaScript is basically just a layer over the HTML page that’s already there. React wants to have the center stage, and most knowledge about the underlying technology is useless at best and sometimes even harmful, as React wants everything done in a very specific way.
It doesn’t have to be like this. You can tell React to render on any subsection of the page, and manage the rest of the page in a different way. (This is the big secret behind all that microframeworks hipe we saw a few months ago). When you do React this way, it becomes another layer of the system. It becomes just an element with incredibly advanced functionality. And you can delete the element with node.parent.removeChild(node) and the React node goes away and the React runtime stops.
React doesn’t want to have the center stage. People put React in the center stage.
The author hit the nail on the head in his own piece. Most of these job offers are not for webSITE building, they’re for wepAPP building and as a consequence the framework they’re written in matters when hiring for new people.
Has anyone tried to define the difference between the two? It always seems like there’s an implicit assumption that it’s easy and obvious to tell what defines a site vs. app.
For me the differentiating factor is the degree of interactivity. A web site is largely concerned with displaying largely static information, and potentially sending some data back to a server with standard HTML forms. A web app on the other hand often has a high degree of interactivity, possibly communicates with a REST API, database, or other collaborating service, and works more like a traditional application that just so happens to run inside a web browser.
You implement websites with HTML forms and webspps with React
How do I know if it’s a webapp or a website?
Well websites use HTML forms and webspps use REST APIs etc.
I know I’m exaggerating a little :) But I think it’s important to keep implementation out of the definition if these terms are to be useful in this discussion. Because then what do I call applications that are built with technologies like Hotwire? They aspire to handle fairly complex interactivity with very minimal JavaScript.
If you want to have a Web Dev Career, you’ll have to work as a part of team, and traditional HTML/CSS won’t take you very far, app needs to be divided into modules, and state management becomes a necessity.
Are there really that many positions suggesting the use of React for (mostly) static sites? I’ve spent nearly my entire (web) career building large/complex apps, where something like a React has significant benefit so the positions I’ve looked at make sense to call out React and similar.
I’ve been a mentor for a local free code bootcamp, and most of the students are unaware that it is possible to build a website with just HTML and CSS. I had this discussion with someone who was rather bright, and they couldn’t grasp not using React for static sites.
I believe this is the cause of so many problems plaguing the web right now.
Large bundles, bad accessibility, 27 nested divs to make a button, etc.
I helped at bootcamps and with juniors too. People were taught React before they had a solid grasp of nested for loops.
To be clear, I don’t think they shouldn’t teach frameworks, but they should drill the fundamentals first. React/Angular/Vue should be given an overview during the last week and that’s it.
I’ve been substitute teaching at a boot camp and they don’t cover React till roughly the last quarter of the class. They don’t even touch templating tools, like handlebars, till about half way in. It’s 50% just vanilla html/css/js, and some jQuery.
I noticed that, for the most part, the students had a fairly solid grasp on the fundamentals by the time they started using more and more libraries. The possibly downside is that the class is essentially a crash course of the past 10 years of web in about 6 months of 3 classes a week. They often only spend 3 days on a topic and that topic could be as broad as “non-relational databases”.
It’s the new tech all companies fancy. It’s a requirement if you want to get a job where I live, no matter what the project is. Project managers think of NodeJS/React like the new PHP/MySQL combo.
I know react well but don’t think it applies to everything. However, this post doesn’t really even make any arguments about why react isn’t necessary and where it may apply. The author admits they don’t understand it. React itself is a view library. It is pretty simple overall, but it prevents you from having to deal with custom elements and the clunky DOM APIs that you’d need for a webapp without a library or framework (lumping Vue/Ng/Ember in here too).
There are pros and cons, but the author’s inability to understand something that is pretty much ubiquitous now says more about the author than it does about the library.
There are pros and cons, but the author’s inability to understand something that is pretty much ubiquitous now says more about the author than it does about the library.
I know people who write React for a living, and they complain that React is hard to reason about as well, which matches my own experience. I don’t think you can just brush it off as “oh, the author just doesn’t understand it”.
My point is that if you’re trying to write an argument against it, you need to understand the pros and cons of it. If you don’t understand it at all, yet somehow it’s everywhere, you should really try to grok it before you knock it.
We’ve been building web apps (with and without JS) before React so I, never having touched React, of course don’t understand it. I can still tell you that you don’t need it and I don’t feel bad.
The only thing I can’t claim is knowledge whether React would the better or worse solution than what I would suggest as a solution to a certain problem.
Or maybe I misunderstood the original post, but it didn’t read as “React is bad” to me, or “Never use React”.
You don’t need any framework ever. But if you’re building a web application from scratch, it’s easier to use tools with a huge community to help out when you get stuck rather than rolling it yourself.
If you are Facebook, using React makes sense. For a plain business website, React just introduce a shit ton of complexity and security issues while providing very little, if any, advantages. Why people use that crap for normal websites is beyond me.
It’s been a while since I last used Facebook (and it was mostly for the “marketplace” stuff anyway), but when I last used it about a year ago it was slow, buggy, and generally just not a very pleasant experience.
I don’t know the causes for this, but it’s not like React is necessarily working out all that great for them.
I don’t work at FB, but having worked on many large web apps using many different frameworks, React likely isn’t the bottleneck. The poor performance is likely due to how much tracking they do. Tracking adds tons of excess events, http requests, and general bloat.
We were in the middle of rolling out the new website one year ago. Check it out now. The new site (no blue bar at the top) is quite a bit faster, at least compared to the old one.
It is even worse now than it used to be. Frequently freezes up entirely while typing and clicking buttons often does nothing at all. If react is supposed to prevent bugs, Facebook is about the worst advertisement I could imagine.
While your personal experience may differ I promise that performance in general is MUCH better on the new site (individual interactions, the initial page load, incremental page loads, average and median, slower machines faster machines, etc). We measure extensively.
It makes sense if you’re building web applications, basically. Not that it’s the only technology anyone should ever use, it definitely competes with a few other amazing tools I can think of, but it’s still a viable choice.
That’s true, as soon as you pull in React you’ll also need a bundler, something to strip the JSX, and all the complexity that comes from managing those tools. Not to mention how React components and hooks are both their own DSL that has its own separate rules from JS.
and security issues
Care to elaborate? Do you mean security issues from using tons of JS libraries? You can actually use React without pulling in tens of libraries to do everything, and if you’re still concerned about bundle/code size you can also use Preact in production.
while providing very little, if any, advantages.
This is simply not true. Keeping UI and application state in sync starts out simple but quickly becomes tremendously complex, so having a library that takes care of that for me is invaluable. Making reusable components is also hard and clunky and React also makes that incredibly easy.
I don’t consider the jsx parser or bundler, which come preconfigured for most projects via create-react-app, as complexity. If we are considering that complexity, then anything that comes with dependencies is automatically complex even if you have no need to configure anything.
The complexity of react is really based around understanding of hooks and lifecycle. If you’re building a webapp, you need to deal with state somewhere so that’s universal. I guess you could say jsx is complex but it’s basically html instead of a bunch of function calls, which should be pretty easy to understand.
I would argue that hooks made JSX more complex because now there are extra things to consider when rendering your components. I only say this because I had a coworker who was learning React get thoroughly confused by when and how they could use hooks in relation to JSX syntax. Additionally, JSX isn’t just html but an additional hidden function call. It used to be a simpler h('div', attributes, children) but it’s gotten a little more complex under the hood with what that function does now.
I’d also be tempted to argue that JSX is a poorer version of how to structure html because it only accepts attributes and not properties, so it actually adds extra complexity around how to set properties on real dom nodes. Which in turn complicates how one uses web components within React.
Regarding security issues, I’m primarly thinking about, yes, dependencies and the use of JavaScript on the server side. When you first go down that Node.js rabbit hole, the libraries tend to stack up pretty fast. I’ve seen pretty simple webpages passing 100.000 files in node_modules - with God knows how many people behind them. And why JS are all kinds of bad ideas, is a whole discussion in itself.
Add in the issues complexity in itself introduces and you end up with a system which, for a normal webpage, is totally overkill, hard to maintain, expensive to host and stable if you’re lucky.
In my honest opinion, that whole Node craze, was a big mistake. There are numerous alternatives out there, but if I were to pick one, I would go with Elixir and Phoenix LiveView. That stuff is just on a whole other level.
I know that I didn’t justify my argument against React. I don’t know React, and I decided not to talk bad about it.
What I wanted to clarify is that I can do my everyday tasks without React. I am working in the web industry for almost ten years, and I have been part of many website projects, some pretty big ones. Knowing HTML, CSS, JavaScript, and its possibilities is hugely undervalued these days. I don’t need to know 0(n) or similar algorithms to build a site that is looking good, performing well, and is accessible to most of the users.
That is just my opinion, and I wanted to make a statement. Knowing React, algorithms, or anything similar might get you a job, but it doesn’t mean you could build a well-performing, fast, and easy to use and understand website.
I want to thank everyone for their comments. I appreciate the passion in these discussions, and I know everyone is talking from their point of view. I just wish to see more sites that aren’t bad and that follow the best practices.
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.
to be fair I’m using it for one hobby project (not a webdev at day) and still feel overwhelmed by the amount of additional plugins (Redux, how do you do global state for login + user-menu that is decoupled, hooks…). Add the whole JS stack on top (with its 40k modules) and you are starting to feel like every major rust dependency graph is irrelevant in comparison. Vue felt way easier but lacked one major component for one thing I needed (QR code display) and often it’s not obvious how you use any external JS libraries together with these self-managing frameworks.
Don’t do Redux. Only big sites warrant using it. Start with minimal hooks (useState) passing the state and setters as params. everywhere. Once you understand this, work your way up using contexts and effects. You don’t need more than this for 80% complex sites out there.
I wonder if there should be an ELI5 for vanilla javascript vs jquery vs react or some framework. Sometimes ELI5s are good to explain this for people who are outside the job role. A sysadmin has heard a lot of hype about React and they want to make an admin page. They try it out but it all seems greek because maybe they haven’t gone through the pain progression that the community has: where does jquery fail etc.
Or another, way a high level overview of what problems these tools solve and what size does the tool naturally fit? Where would you skip it? High level overviews are (to me) imprecise and annoying to experienced workers but if this is really impenetrable then someone should make a video. Maybe I’m searching with my own terms and words but I don’t see anything on Youtube like this.
So what is then the go-to for that ? Easy device aware frontends that use REST APIs without bootstrap that actually look good and not like some bare HTML stuff from the 2000s ? I just want to throw the logic inside, not hire a frontend dev for my hobby projects. QT frontends feel easier..
Writing HTML and CSS, maybe using a CSS framework (other than bootstrap if you prefer). Using JavaScript fetch() calls when you need to contact an API.
If you weren’t writing CSS with a React site, then you are already using a CSS framework just via React components.
which is something you’ll do sooner or later, as you reach reactive components that need JS to run (date pickers, search bars with dropdown etc). At which point you’ll throw your hands in the air trying to marry the bootstrap code with your react render pipeline.
For teams of a significant size I’m sure this is the case, it’s been a while since I did frontend development in that context.
I still believe it’s entirely possible to write those yourself if needed though, or to bring in React for only a few elements on the page. People made interactive websites before React, of course 😅.
Is my position the most practical? Maybe not. I prefer avoiding react as a first choice because I think that it encourages not understanding the software you are writing.
I had a few attempts to learn it, but I failed every time. It is fair to say that I don’t understand it.
For some context, I use angular at work every day. I am learning a little bit of react for a personal project. I am not exactly sure why it would be difficult to learn.
Sometimes people just don’t click with a certain way of doing things.
At a former job we had a rather small web app written in emberjs. A year after it was created two developers tried to understand and improve it and had major problems with it. They proposed to rewrite it in angularjs in a single week, because they (and most of the team) knew angularjs. They finished quicker than a week and we never had any problems, even with onboarding new people.
That is not to knock on emberjs, but in this case it simply didn’t work out. Had we had different developers we might have been happy with emberjs.
I wish there was a great way of doing composition of presentation logic without having to pull in JavaScript. Not so much because modern JS is so bad, but because the build system and the leaky abstractions that mostly work but then don’t and it ends up costing me several hours to figure out what’s wrong.
I haven’t come across a good solution for this. NextJS is great and I use it all the time, but the static website still involves tons of JavaScript. Would be nice to find a way to do composition without bringing in all that runtime dependency.
As a veteran of many battles with webpack configuration: the “build system” situation is getting better. esbuild has given me no cause for complaint so far; it’s simpler and hundreds of times faster.
There are three levels of frontend interaction complexity:
form action=foo method=postandbutton type=submit. For this, HTML + CSS is the easiest solution.Yes, you don’t need React for websites with minimal interactivity requirements, but as soon as you have to add just a few of those requirements, you quickly regret not having React.
Also, things like GatsbyJS or NextJS can be configured to output static sites. This may look like totally overkill, except for a tiny detail. You get to use all the module management and import semantics from Javascript to manage your components, which is way better than plain old CSS files and copy-pasta for HTML snippets. Add in Typescript and you have a strong proposition. Though WebComponents may do something similar here…
There’s a level past React too though. React can’t really do high performance things, so for those you need to turn to Canvas or something and handroll it. Tom MacWright made this point in the now classic “Rethinking the Modern Web”.
Here’s one way to think of it:
It’s extremely easy to migrate from a simple HTML + CSS site to a site with JQuery or vanilla JavaScript, because JavaScript is basically just a layer over the HTML page that’s already there. React wants to have the center stage, and most knowledge about the underlying technology is useless at best and sometimes even harmful, as React wants everything done in a very specific way.
See this line of code? https://github.com/manirul41/react-mvc-app/blob/master/src/index.js#L7 It tells React to do its thing on the id=“root” element in the page. What tends to happen is https://github.com/manirul41/react-mvc-app/blob/master/src/index.html#L15 - I/E the only element in the page is that id=“root”.
It doesn’t have to be like this. You can tell React to render on any subsection of the page, and manage the rest of the page in a different way. (This is the big secret behind all that microframeworks hipe we saw a few months ago). When you do React this way, it becomes another layer of the system. It becomes just an element with incredibly advanced functionality. And you can delete the element with node.parent.removeChild(node) and the React node goes away and the React runtime stops.
React doesn’t want to have the center stage. People put React in the center stage.
In my experience, this hasn’t been the case. React outputs some HTML, and you still have to know what HTML to use and how to use it.
The author hit the nail on the head in his own piece. Most of these job offers are not for webSITE building, they’re for wepAPP building and as a consequence the framework they’re written in matters when hiring for new people.
Has anyone tried to define the difference between the two? It always seems like there’s an implicit assumption that it’s easy and obvious to tell what defines a site vs. app.
For me the differentiating factor is the degree of interactivity. A web site is largely concerned with displaying largely static information, and potentially sending some data back to a server with standard HTML forms. A web app on the other hand often has a high degree of interactivity, possibly communicates with a REST API, database, or other collaborating service, and works more like a traditional application that just so happens to run inside a web browser.
This definition is a little circular, though.
I know I’m exaggerating a little :) But I think it’s important to keep implementation out of the definition if these terms are to be useful in this discussion. Because then what do I call applications that are built with technologies like Hotwire? They aspire to handle fairly complex interactivity with very minimal JavaScript.
If you want to have a Web Dev Career, you’ll have to work as a part of team, and traditional HTML/CSS won’t take you very far, app needs to be divided into modules, and state management becomes a necessity.
For basic landing pages, it’s not required.
Are there really that many positions suggesting the use of React for (mostly) static sites? I’ve spent nearly my entire (web) career building large/complex apps, where something like a React has significant benefit so the positions I’ve looked at make sense to call out React and similar.
I’ve been a mentor for a local free code bootcamp, and most of the students are unaware that it is possible to build a website with just HTML and CSS. I had this discussion with someone who was rather bright, and they couldn’t grasp not using React for static sites.
that is actually sad, probably the same when people realize you can write programs in a systems language and without electron
I understand why they thought that. The class is a skills program. It’s meant to help people get jobs, not learn theories.
But yeah, it’s sad on general that the prevalent path is to start with js frameworks.
I believe this is the cause of so many problems plaguing the web right now.
Large bundles, bad accessibility, 27 nested divs to make a button, etc. I helped at bootcamps and with juniors too. People were taught React before they had a solid grasp of nested for loops.
To be clear, I don’t think they shouldn’t teach frameworks, but they should drill the fundamentals first. React/Angular/Vue should be given an overview during the last week and that’s it.
I’ve been substitute teaching at a boot camp and they don’t cover React till roughly the last quarter of the class. They don’t even touch templating tools, like handlebars, till about half way in. It’s 50% just vanilla html/css/js, and some jQuery.
I noticed that, for the most part, the students had a fairly solid grasp on the fundamentals by the time they started using more and more libraries. The possibly downside is that the class is essentially a crash course of the past 10 years of web in about 6 months of 3 classes a week. They often only spend 3 days on a topic and that topic could be as broad as “non-relational databases”.
It’s the new tech all companies fancy. It’s a requirement if you want to get a job where I live, no matter what the project is. Project managers think of NodeJS/React like the new PHP/MySQL combo.
I know react well but don’t think it applies to everything. However, this post doesn’t really even make any arguments about why react isn’t necessary and where it may apply. The author admits they don’t understand it. React itself is a view library. It is pretty simple overall, but it prevents you from having to deal with custom elements and the clunky DOM APIs that you’d need for a webapp without a library or framework (lumping Vue/Ng/Ember in here too).
There are pros and cons, but the author’s inability to understand something that is pretty much ubiquitous now says more about the author than it does about the library.
I know people who write React for a living, and they complain that React is hard to reason about as well, which matches my own experience. I don’t think you can just brush it off as “oh, the author just doesn’t understand it”.
My point is that if you’re trying to write an argument against it, you need to understand the pros and cons of it. If you don’t understand it at all, yet somehow it’s everywhere, you should really try to grok it before you knock it.
We’ve been building web apps (with and without JS) before React so I, never having touched React, of course don’t understand it. I can still tell you that you don’t need it and I don’t feel bad.
The only thing I can’t claim is knowledge whether React would the better or worse solution than what I would suggest as a solution to a certain problem.
Or maybe I misunderstood the original post, but it didn’t read as “React is bad” to me, or “Never use React”.
You don’t need any framework ever. But if you’re building a web application from scratch, it’s easier to use tools with a huge community to help out when you get stuck rather than rolling it yourself.
If you are Facebook, using React makes sense. For a plain business website, React just introduce a shit ton of complexity and security issues while providing very little, if any, advantages. Why people use that crap for normal websites is beyond me.
It’s been a while since I last used Facebook (and it was mostly for the “marketplace” stuff anyway), but when I last used it about a year ago it was slow, buggy, and generally just not a very pleasant experience.
I don’t know the causes for this, but it’s not like React is necessarily working out all that great for them.
I don’t work at FB, but having worked on many large web apps using many different frameworks, React likely isn’t the bottleneck. The poor performance is likely due to how much tracking they do. Tracking adds tons of excess events, http requests, and general bloat.
We were in the middle of rolling out the new website one year ago. Check it out now. The new site (no blue bar at the top) is quite a bit faster, at least compared to the old one.
It is even worse now than it used to be. Frequently freezes up entirely while typing and clicking buttons often does nothing at all. If react is supposed to prevent bugs, Facebook is about the worst advertisement I could imagine.
While your personal experience may differ I promise that performance in general is MUCH better on the new site (individual interactions, the initial page load, incremental page loads, average and median, slower machines faster machines, etc). We measure extensively.
It makes sense if you’re building web applications, basically. Not that it’s the only technology anyone should ever use, it definitely competes with a few other amazing tools I can think of, but it’s still a viable choice.
That’s true, as soon as you pull in React you’ll also need a bundler, something to strip the JSX, and all the complexity that comes from managing those tools. Not to mention how React components and hooks are both their own DSL that has its own separate rules from JS.
Care to elaborate? Do you mean security issues from using tons of JS libraries? You can actually use React without pulling in tens of libraries to do everything, and if you’re still concerned about bundle/code size you can also use Preact in production.
This is simply not true. Keeping UI and application state in sync starts out simple but quickly becomes tremendously complex, so having a library that takes care of that for me is invaluable. Making reusable components is also hard and clunky and React also makes that incredibly easy.
I don’t consider the jsx parser or bundler, which come preconfigured for most projects via create-react-app, as complexity. If we are considering that complexity, then anything that comes with dependencies is automatically complex even if you have no need to configure anything.
The complexity of react is really based around understanding of hooks and lifecycle. If you’re building a webapp, you need to deal with state somewhere so that’s universal. I guess you could say jsx is complex but it’s basically html instead of a bunch of function calls, which should be pretty easy to understand.
I would argue that hooks made JSX more complex because now there are extra things to consider when rendering your components. I only say this because I had a coworker who was learning React get thoroughly confused by when and how they could use hooks in relation to JSX syntax. Additionally, JSX isn’t just html but an additional hidden function call. It used to be a simpler
h('div', attributes, children)but it’s gotten a little more complex under the hood with what that function does now.I’d also be tempted to argue that JSX is a poorer version of how to structure html because it only accepts attributes and not properties, so it actually adds extra complexity around how to set properties on real dom nodes. Which in turn complicates how one uses web components within React.
Regarding security issues, I’m primarly thinking about, yes, dependencies and the use of JavaScript on the server side. When you first go down that Node.js rabbit hole, the libraries tend to stack up pretty fast. I’ve seen pretty simple webpages passing 100.000 files in node_modules - with God knows how many people behind them. And why JS are all kinds of bad ideas, is a whole discussion in itself.
Add in the issues complexity in itself introduces and you end up with a system which, for a normal webpage, is totally overkill, hard to maintain, expensive to host and stable if you’re lucky.
In my honest opinion, that whole Node craze, was a big mistake. There are numerous alternatives out there, but if I were to pick one, I would go with Elixir and Phoenix LiveView. That stuff is just on a whole other level.
I know that I didn’t justify my argument against React. I don’t know React, and I decided not to talk bad about it. What I wanted to clarify is that I can do my everyday tasks without React. I am working in the web industry for almost ten years, and I have been part of many website projects, some pretty big ones. Knowing HTML, CSS, JavaScript, and its possibilities is hugely undervalued these days. I don’t need to know 0(n) or similar algorithms to build a site that is looking good, performing well, and is accessible to most of the users.
That is just my opinion, and I wanted to make a statement. Knowing React, algorithms, or anything similar might get you a job, but it doesn’t mean you could build a well-performing, fast, and easy to use and understand website.
I want to thank everyone for their comments. I appreciate the passion in these discussions, and I know everyone is talking from their point of view. I just wish to see more sites that aren’t bad and that follow the best practices.
Nice 👍🏻
to be fair I’m using it for one hobby project (not a webdev at day) and still feel overwhelmed by the amount of additional plugins (Redux, how do you do global state for login + user-menu that is decoupled, hooks…). Add the whole JS stack on top (with its 40k modules) and you are starting to feel like every major rust dependency graph is irrelevant in comparison. Vue felt way easier but lacked one major component for one thing I needed (QR code display) and often it’s not obvious how you use any external JS libraries together with these self-managing frameworks.
Don’t do Redux. Only big sites warrant using it. Start with minimal hooks (useState) passing the state and setters as params. everywhere. Once you understand this, work your way up using contexts and effects. You don’t need more than this for 80% complex sites out there.
thanks for the explanation, will look into that
contexts and hooks are probably the best thing to happen to react since JSX
I wonder if there should be an ELI5 for vanilla javascript vs jquery vs react or some framework. Sometimes ELI5s are good to explain this for people who are outside the job role. A sysadmin has heard a lot of hype about React and they want to make an admin page. They try it out but it all seems greek because maybe they haven’t gone through the pain progression that the community has: where does jquery fail etc.
Or another, way a high level overview of what problems these tools solve and what size does the tool naturally fit? Where would you skip it? High level overviews are (to me) imprecise and annoying to experienced workers but if this is really impenetrable then someone should make a video. Maybe I’m searching with my own terms and words but I don’t see anything on Youtube like this.
File under “posts whose titles state incredibly obvious facts but are still somehow necessary for certain folks to read”
So what is then the go-to for that ? Easy device aware frontends that use REST APIs without bootstrap that actually look good and not like some bare HTML stuff from the 2000s ? I just want to throw the logic inside, not hire a frontend dev for my hobby projects. QT frontends feel easier..
Writing HTML and CSS, maybe using a CSS framework (other than bootstrap if you prefer). Using JavaScript fetch() calls when you need to contact an API.
If you weren’t writing CSS with a React site, then you are already using a CSS framework just via React components.
which is something you’ll do sooner or later, as you reach reactive components that need JS to run (date pickers, search bars with dropdown etc). At which point you’ll throw your hands in the air trying to marry the bootstrap code with your react render pipeline.
For teams of a significant size I’m sure this is the case, it’s been a while since I did frontend development in that context.
I still believe it’s entirely possible to write those yourself if needed though, or to bring in React for only a few elements on the page. People made interactive websites before React, of course 😅.
Is my position the most practical? Maybe not. I prefer avoiding react as a first choice because I think that it encourages not understanding the software you are writing.
One thing I was curious about:
For some context, I use angular at work every day. I am learning a little bit of react for a personal project. I am not exactly sure why it would be difficult to learn.
Sometimes people just don’t click with a certain way of doing things.
At a former job we had a rather small web app written in emberjs. A year after it was created two developers tried to understand and improve it and had major problems with it. They proposed to rewrite it in angularjs in a single week, because they (and most of the team) knew angularjs. They finished quicker than a week and we never had any problems, even with onboarding new people.
That is not to knock on emberjs, but in this case it simply didn’t work out. Had we had different developers we might have been happy with emberjs.
I wish there was a great way of doing composition of presentation logic without having to pull in JavaScript. Not so much because modern JS is so bad, but because the build system and the leaky abstractions that mostly work but then don’t and it ends up costing me several hours to figure out what’s wrong.
I haven’t come across a good solution for this. NextJS is great and I use it all the time, but the static website still involves tons of JavaScript. Would be nice to find a way to do composition without bringing in all that runtime dependency.
As a veteran of many battles with webpack configuration: the “build system” situation is getting better.
esbuildhas given me no cause for complaint so far; it’s simpler and hundreds of times faster.In theory what you’re asking for is what Astro does, but I haven’t used it yet.