> developers need to be more vigilant with React code as
> articles on managing this complexity that every React developer should read
Here's the thing. You can do your best to spread how things ought to be done and what people should be doing. The majority of developers are not going to be vigilant, nor are they going to read these, nor does it occur to them that they're being suffering from its complexity. In a way it's similar to git - people use git because other people use git. It lets you get into difficult situations. The difference is that git also lets you get out quickly. Web codebases are not so forgiving, a lot of mistakes can be forever as it's costly to unwind.
I've encountered this a few times before realizing we were doing a lot better with Angular. It's not as popular, and its complexity does not grow as fast. Similarly for Vue as the author noted.
> but I do sense that there is a growing wave against the complexity brought forth by the current champs.
I certainly hope so, but I'm not seeing it. The industry seems to prefer the most complicated solution in different areas. k8s has won the orchestration mindshare and demonstrates a similar pattern of complexity and maintenance.
Svelte is still the best by just about every metric that matters. The consensus seems to be clear that once you get a real taste of the Svelte DX, everything else is a downgrade.
Angular is more like Svelte+SvelteKit. Router and plumbing included. Angular 16 adds signals, so that's a recent difference.
Svelte handles shared state+reactivity as stores. Svelte contexts allows partitioning of shared state. Reactivity comes from a small superset syntax of JavaScript that acts a bit like a spreadsheet. Svelte is a compiler rather than a full-size runtime library.
Angular relies heavily on rxjs, and synchronous vs asynchronous state is quite distinct and "boilerplatey". Switching between sync and async can be a real pain sometimes. That said, Angular is VERY opinionated, which makes it predictable from a developer point of view. (I think SvelteKit is as well, but its track record is a lot shorter than Angular's.)
Variable interpolation looks about the same, but Angular uses custom HTML attributes for control flow whereas Svelte uses syntax that's more akin to Velocity templates.
Angular still has a virtual DOM, and the smallest app bundle is still often more than a megabyte even before it hits your code. Time to first render is still pretty bad. Angular's compiler, while faster in v15-v16, is still dog slow compared to many younger frameworks.
Svelte is smaller and faster at both compile time and runtime, at least when you have fewer than 250 components, give or take.
Angular components use annotations heavily and use separate files for logic, markup, and styling. Svelte components put logic, markup, and styling in a single file but with less boilerplate. Both support two-way data binding. Angular is more mature but somewhat arcane while Svelte looks much more like vanilla HTML/CSS/JS.
Svelte CSS styles are scoped to the component automatically by default without worrying about prefixes or naming conventions.
Angular routing is more programmatic. SvelteKit routing is filesystem path-based.
Svelte has a REPL. I don't know of one for Angular.
Angular has a massive ecosystem. Svelte's ecosystem is far smaller, but integration of vanilla JS libraries is typically easier with Svelte than Angular. Still, Angular's breadth of community is undeniably larger.
I don't know that I prefer Sveltekit over Nextjs yet, but Svelte vs React is quite nice.
But I might still use React for large projects with many components if it doesn't need animations/transitions, and the global/shared state is pretty lightweight
I think mainly the tooling is much better in React.
I can get by with "sort-of typescript" for Svelte, but it's a bit annoying that I can't get VS code to provide type hinting everywhere, and to also enforce "no-implicit-any". In smaller projects I'm probably not touching files I've completely forgotten all the time, so it's not too much of a problem
I can deal with the fact that the tailwind extension intellisense might not work in Svelte (or it didn't last time I tried it); for smaller Svelte projects I'm happier to use component-scoped styling 90% of the time. At that point I probably haven't typed the same combination of styles enough times that I want to share them across the project.
When the project grows, these become much more of a pain. I end up with lots of small to medium sized components, and I want to compose these along with mixins defined elsewhere (utility functions that can be pulled into them, etc). At that point I really want Typescript to be as strict as possible, and I want the Intellisense on tailwind partial class names. I'm sure there are plenty of other similar tooling issues that I'm forgetting right now.
React also has many more libraries, as you said, including the wonderful Tanstack query (I know there's a Svelte engine now, though I haven't tried it yet)
But the actual framework is so much easier in Svelte, enough so that I'd almost always choose it for smaller projects. React has its pain points even at medium scale, whereas with Svelte they really hit me harder as the project gets bigger. So it probably comes down to what I'm doing.
But yeah, I'm still going to reach for Svelte the majority of the time
No framework is going to teach someone how to design a complex application that not only does everything it's supposed to, but does it well, and lends itself well to extension and modification over time by a constantly changing array of people. That takes years of experience, an excellent engineering culture and a well designed infrastructure.
You can't expect React to do that. It's just a tool.
React takes a developer from zero to one very quickly, but the rest is the craft.
I agree it can be very confusing to set all of this up from scratch, but if you're using something like Vue CLI, all of these dependencies and configs are generated for you.
If you stay on the same version of the init script, you're still marginally better than rolling your own.
On the other hand, if you learn it once and then allow updates to occur, you'll still understand the process in the abstract. You'll just have to let go of the notion of knowing all details of your stacks from top to bottom. This is why we have teams and specializations. Computing long ago exceeded typical human capacity for complete knowledge. Now we learn as much as we can including the wisdom of who to trust when the solution is bigger than we can individually muster.
We trust compilers and browsers and libraries and frameworks all the time. When they break, hopefully the broken area is in our wheelhouse or at least well-documented. But the issue of complexity isn't going away if we want to continue making forward progress.
My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
Change happens.
"Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
Also, things seem to be converging towards simplicity in a positive way, comparing e.g. Vite to Webpack.
But without any disagreement:
the churn is real.
Not upgrading is only an option if you
1) are sure you don't run vulnerable code on a server (e.g. through SSR) - if any code is public-facing, ignoring most "npm audit" reports ceases to be an option.
2) don't need new packages to change your build setup that are significantly newer than your previous setup.
To repeat, I don't disagree and I prefer the spirit of your comment to my critique.
Almost all of the time it is a good idea to settle on versions and evaluate when upgrading is worth it.
Update costs can also vary a lot depending on the project.
In other words, preserving behavior while fixing dependency conflicts, breaking changes etc after updating major versions.
If one avoids to do clever stuff with the bundler and if the project requirements are simple, it can be easy upgrade or even swap tools (e.g. Webpack for Vite).
This rings very true for me, bravo:
> My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
> Change happens.
> "Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
Except just needing HTML, CSS, and JS was never true. Back in 1995, JS and CSS didn't exist. But Perl did, which is what most cgi-bin scripts were written in. Then you had to learn mod_perl after you figured out Apache's crazy non-regular config file format. (Are you markup or not?! Pick a lane!).
Build scripts? LOL! Learn FTP sucka, and copy those files manually.
Wait… now I'm on a Windows server? What in the hell is ISAPI?
Now you want to send an email from that contact form on your site? Better learn how to set up sendmail servers. (WTF is m4? I need a macro language to generate the config file for my email server?!)
document.write("Hello World!");
Fast forward to 2004. Firefox (or was it Phoenix?) is hoping to slowly wrench dominance away from IE, but for now frontend devs gotta know ActiveX (insecure), Java applets (slow as molasses), and Macromedia Flash (you've got a DSL connection, right?). Don't forget JS has competition in VBScript. And oh, those .htc behavior files. All the old <font color=red> and table-based layouts are passé, and folks are demanding they be rewritten in that cool CSS now that Netscape 4 usage is officially dead. Still gotta fit those PDFs in sometimes though.
HTML is looking drab compared to that XML hotness. Better get on board with XHTML! Scratch that! All the XML flavors: XSLT, XSL:FO, SOAP, XML Schema (or RelaxNG for the cool kids), XPath, SAX, X-Force! (Okay, maybe not that last one.)
Firefox is getting better so much faster than IE, so don't forget to polyfill all the things.
Jump to 2010. We've got more browser engines than we know what to do with and they all render differently. Maybe not a lot in this one case, but different enough. Bring on the JSON! The rise of JS libraries brings us the choices of Prototype (the OG, but already obsolete), YUI, Jquery, and a new entry every month at least. Tree shaking? CI/CD? What crazy talk are you spouting now? I'm just barely handling minification and manual image optimization.
-----
Thank [deity] things today aren't as complex as they were back then!
To quote BSG: "This has all happened before. And it will happen again."
Still have an Ember app that was last touched in 2016 other than library updates working perfectly in production earning millions of dollars. The React replacement we struggled with took many man-years longer to develop and is still not as easy to deal with.
With Ember we went through the entire 2 way binding -> DDAU transition in the middle of developing the app (and many other transitions, since we started with a pre 1.0 version of the framework), but the core team did such a fantastic job of making the transition as easy as possible that I don’t have a single nightmare from those days. In fact it seemed completely uneventful.
With H/3, modern frameworks have become unnecessary deviations from web standards that result in high costs and lower app lifetimes. Do standard server side work, don’t use node as a server, sprinkle a bit of typescript where needed, and keep things lean.
As a recovering front end developer of 20 years, someone who has played with every damn framework and used most of them professionally; just stick to web standards and ignore the frameworks unless you specifically need them.
For example: we are using HN. It is simple. It works. It does not need to change. It does not need to be reddit or twitter or whatever, to be engaging. It’s good because it’s focused simple and well maintained. Almost every app I enjoy that has been over complicated or lost touch with its user base has done so while implementing these frameworks. They are business death. See; Facebook (react destroyed fb), Google (angular destroyed AdWords and G Suite), and so on. You lose analytics, accessibility, performance for the end user, less server side bugs is bad when clients are running the bugs, and most importantly you lose track of your customers needs.
If you want your shit to work, keep it close to the metal, conform to standards, scale only where necessary, and listen to your customers.
Your example does not align with your closing statement. Using Arc is certainly not "sticking to web standards" in the way you're proposing.
HN is simple and works, from a user perspective. I don't have my hands on the codebase, but I imagine it's kind of fun to work on precisely because it isn't "close to the metal". DX is just as important as UX is, you have to strike a balance.
Not sure there's much correlation between frameworks and apps becoming complicated or losing touch with their userbase. Using AdWords as an example, I'm like ~75% sure they went from one framework (Google Web Toolkit) to another (AngularJS).
GWT and Facebook’s PHP stack were both effectively server side technologies. GWT was pretty awful, but angular is probably the worst of the bunch when it comes to front end frameworks too. What I’m saying is you should run your app on the server and use HTML as a presentation layer. This is standard, it gives you visibility into bugs, it simplifies the end user payload, and it works quickly and reliably without needing huge refactoring projects and complex abstractions that your business does not need.
You probably don’t need a front end stack. You should just use the web standards as designed first, and then add improvements that customers like.
You've been here since 2014. How much value have you derived from this code? How long would it take you to write it?
https://news.ycombinator.com/hn.js
I don't think there's a person I've asked who prefers the modern web over the way it was 10 years ago. All we've done is create a bunch of busywork that results in a cushion class of yes-men who are paid to protect the oligarchs from the peons they control. The specific kind of user you're talking about unfortunately includes these people.
If we stop navel-gazing at our salaries for a second, we should take a look at what developers who make a real difference do. I'm not talking about people who build stuff that leeches off consumer credit cards. I'm talking about TimBL, Matt Mullenweg, Bjarne Stroustrup, John Resig, Greg Kroah-Hartman, Linus Torvalds. They do things on principle, on values, and are self-confident enough not to care about chasing status. They're people who look at a world full of problems and want to actually help by sharing their ideas.
Those people generally build open, self-hosted solutions. They want to empower people, freeing us from the modern versions of AT&T and IBM. They make stuff that can run on a Pi or an old Celeron. Their stuff is standards-compliant, open, clean, simple, and user-auditable, so that it can be trusted and contributed to.
React was developed by Facebook, an app that steals your own family members' valuable time. Angular was developed by Google, and app that drains your own wallet. If you want to emulate their outcomes, by all means use their technologies. If you want to make a difference in the world, observe those who are making a difference and emulate them.
> React was developed by Facebook, an app that steals your own family members' valuable time. Angular was developed by Google, and app that drains your own wallet. If you want to emulate their outcomes, by all means use their technologies. If you want to make a difference in the world, observe those who are making a difference and emulate them.
They're unrelated. The tech and outcomes are unrelated. You can make great things for the world with React. Using Arc isn't gonna make Facebook a better company
You're welcome to that opinion, but I disagree. In my experience, Conway's Law applies directly to code, not just to networks and systems.
It is also my opinion that at all levels, motives and intent are driving dynamic forces in life. Ignoring them is a great way to waste your time, money and efforts. I can understand that not everyone feels this way, but I do. So perhaps that's where our interpretations differ.
> For example: we are using HN. It is simple. It works. It does not need to change.
There are lots of basic issues with HN. For example, if you vote on a comment while writing a reply, the page reloads and you lose your comment. A web component for voting would do wonders here.
> Next.js is having a moment and likely to be the platform of choice for the foreseeable near- and mid-term future in both the enterprise and startup space because React on its own is too un-opinionated and therefore, somewhat open to being misused, mis-configured, and poorly architected since there are many choices involved in any non-trivial implementation..
Lolol all those people who said React was superior to backbone, angular, etc because it was a library not a framework.
That's a real bummer as it's really the only modern web technology that's getting me hyped. Let's move it all back into HTML. I'm begging you all. Please, let's move back to markup.
I used to think react mattered, but then I realised it's the idea of the view library (not framework) that matters and probably the streamlining of the web's stack (webpack, typescript, jsx).
Honestly I don't know what people're on about. webpack, typescript, jsx are simple enough for me while vanilla js & whatever template langue/obscure toolset other frameworks invented are the complex stuff.
React these days is no longer the "minimal API surface" not-a-framework it used to be, but that should be the direction, not the one Vue & everything else is going with.
43 comments
[ 3.2 ms ] story [ 91.3 ms ] thread> articles on managing this complexity that every React developer should read
Here's the thing. You can do your best to spread how things ought to be done and what people should be doing. The majority of developers are not going to be vigilant, nor are they going to read these, nor does it occur to them that they're being suffering from its complexity. In a way it's similar to git - people use git because other people use git. It lets you get into difficult situations. The difference is that git also lets you get out quickly. Web codebases are not so forgiving, a lot of mistakes can be forever as it's costly to unwind.
I've encountered this a few times before realizing we were doing a lot better with Angular. It's not as popular, and its complexity does not grow as fast. Similarly for Vue as the author noted.
> but I do sense that there is a growing wave against the complexity brought forth by the current champs.
I certainly hope so, but I'm not seeing it. The industry seems to prefer the most complicated solution in different areas. k8s has won the orchestration mindshare and demonstrates a similar pattern of complexity and maintenance.
Svelte, SolidJS, and Qwik all fit that bill.
I’ve been making a living as a freelance Svelte dev for years now and never struggle to find work, but your point stands — job market share matters.
Hopefully (for devs, execs, and users sake) Svelte adoption will continue to rise!
I looked into Svelte when it was first emerging and at the time it seemed a reinvented Angular.
Angular is more like Svelte+SvelteKit. Router and plumbing included. Angular 16 adds signals, so that's a recent difference.
Svelte handles shared state+reactivity as stores. Svelte contexts allows partitioning of shared state. Reactivity comes from a small superset syntax of JavaScript that acts a bit like a spreadsheet. Svelte is a compiler rather than a full-size runtime library.
Angular relies heavily on rxjs, and synchronous vs asynchronous state is quite distinct and "boilerplatey". Switching between sync and async can be a real pain sometimes. That said, Angular is VERY opinionated, which makes it predictable from a developer point of view. (I think SvelteKit is as well, but its track record is a lot shorter than Angular's.)
Variable interpolation looks about the same, but Angular uses custom HTML attributes for control flow whereas Svelte uses syntax that's more akin to Velocity templates.
Angular still has a virtual DOM, and the smallest app bundle is still often more than a megabyte even before it hits your code. Time to first render is still pretty bad. Angular's compiler, while faster in v15-v16, is still dog slow compared to many younger frameworks.
Svelte is smaller and faster at both compile time and runtime, at least when you have fewer than 250 components, give or take.
Angular components use annotations heavily and use separate files for logic, markup, and styling. Svelte components put logic, markup, and styling in a single file but with less boilerplate. Both support two-way data binding. Angular is more mature but somewhat arcane while Svelte looks much more like vanilla HTML/CSS/JS.
Svelte CSS styles are scoped to the component automatically by default without worrying about prefixes or naming conventions.
Angular routing is more programmatic. SvelteKit routing is filesystem path-based.
Svelte has a REPL. I don't know of one for Angular.
Angular has a massive ecosystem. Svelte's ecosystem is far smaller, but integration of vanilla JS libraries is typically easier with Svelte than Angular. Still, Angular's breadth of community is undeniably larger.
> Angular still has a virtual DOM
It does not.
Thank you.
Virtual DOM (React, Vue) is a technique that produces a complete version of the DOM which is then reconciled.
Incremental DOM (Angular, Svelte) is a technique that computes the DOM diff/update directly.
But I might still use React for large projects with many components if it doesn't need animations/transitions, and the global/shared state is pretty lightweight
You're really hitting a point there with the animations. Framer is cool and all, but animating exits still sucks.
I can get by with "sort-of typescript" for Svelte, but it's a bit annoying that I can't get VS code to provide type hinting everywhere, and to also enforce "no-implicit-any". In smaller projects I'm probably not touching files I've completely forgotten all the time, so it's not too much of a problem
I can deal with the fact that the tailwind extension intellisense might not work in Svelte (or it didn't last time I tried it); for smaller Svelte projects I'm happier to use component-scoped styling 90% of the time. At that point I probably haven't typed the same combination of styles enough times that I want to share them across the project.
When the project grows, these become much more of a pain. I end up with lots of small to medium sized components, and I want to compose these along with mixins defined elsewhere (utility functions that can be pulled into them, etc). At that point I really want Typescript to be as strict as possible, and I want the Intellisense on tailwind partial class names. I'm sure there are plenty of other similar tooling issues that I'm forgetting right now.
React also has many more libraries, as you said, including the wonderful Tanstack query (I know there's a Svelte engine now, though I haven't tried it yet)
But the actual framework is so much easier in Svelte, enough so that I'd almost always choose it for smaller projects. React has its pain points even at medium scale, whereas with Svelte they really hit me harder as the project gets bigger. So it probably comes down to what I'm doing.
But yeah, I'm still going to reach for Svelte the majority of the time
I’m currently fixing a React app for client. I’m convinced the previous “Dev Team” had no idea how it all actually worked.
It’s all so fragile they seemed to never be able to change anything with breaking something.
You can't expect React to do that. It's just a tool.
React takes a developer from zero to one very quickly, but the rest is the craft.
If you stay on the same version of the init script, you're still marginally better than rolling your own.
On the other hand, if you learn it once and then allow updates to occur, you'll still understand the process in the abstract. You'll just have to let go of the notion of knowing all details of your stacks from top to bottom. This is why we have teams and specializations. Computing long ago exceeded typical human capacity for complete knowledge. Now we learn as much as we can including the wisdom of who to trust when the solution is bigger than we can individually muster.
We trust compilers and browsers and libraries and frameworks all the time. When they break, hopefully the broken area is in our wheelhouse or at least well-documented. But the issue of complexity isn't going away if we want to continue making forward progress.
My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
Change happens.
"Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
Also, things seem to be converging towards simplicity in a positive way, comparing e.g. Vite to Webpack.
But without any disagreement: the churn is real.
Not upgrading is only an option if you
1) are sure you don't run vulnerable code on a server (e.g. through SSR) - if any code is public-facing, ignoring most "npm audit" reports ceases to be an option. 2) don't need new packages to change your build setup that are significantly newer than your previous setup.
To repeat, I don't disagree and I prefer the spirit of your comment to my critique.
Almost all of the time it is a good idea to settle on versions and evaluate when upgrading is worth it.
Update costs can also vary a lot depending on the project.
In other words, preserving behavior while fixing dependency conflicts, breaking changes etc after updating major versions.
If one avoids to do clever stuff with the bundler and if the project requirements are simple, it can be easy upgrade or even swap tools (e.g. Webpack for Vite).
This rings very true for me, bravo:
> My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
> Change happens.
> "Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
Build scripts? LOL! Learn FTP sucka, and copy those files manually.
Wait… now I'm on a Windows server? What in the hell is ISAPI?
Now you want to send an email from that contact form on your site? Better learn how to set up sendmail servers. (WTF is m4? I need a macro language to generate the config file for my email server?!)
document.write("Hello World!");
Fast forward to 2004. Firefox (or was it Phoenix?) is hoping to slowly wrench dominance away from IE, but for now frontend devs gotta know ActiveX (insecure), Java applets (slow as molasses), and Macromedia Flash (you've got a DSL connection, right?). Don't forget JS has competition in VBScript. And oh, those .htc behavior files. All the old <font color=red> and table-based layouts are passé, and folks are demanding they be rewritten in that cool CSS now that Netscape 4 usage is officially dead. Still gotta fit those PDFs in sometimes though.
HTML is looking drab compared to that XML hotness. Better get on board with XHTML! Scratch that! All the XML flavors: XSLT, XSL:FO, SOAP, XML Schema (or RelaxNG for the cool kids), XPath, SAX, X-Force! (Okay, maybe not that last one.)
Firefox is getting better so much faster than IE, so don't forget to polyfill all the things.
Jump to 2010. We've got more browser engines than we know what to do with and they all render differently. Maybe not a lot in this one case, but different enough. Bring on the JSON! The rise of JS libraries brings us the choices of Prototype (the OG, but already obsolete), YUI, Jquery, and a new entry every month at least. Tree shaking? CI/CD? What crazy talk are you spouting now? I'm just barely handling minification and manual image optimization.
-----
Thank [deity] things today aren't as complex as they were back then!
To quote BSG: "This has all happened before. And it will happen again."
With Ember we went through the entire 2 way binding -> DDAU transition in the middle of developing the app (and many other transitions, since we started with a pre 1.0 version of the framework), but the core team did such a fantastic job of making the transition as easy as possible that I don’t have a single nightmare from those days. In fact it seemed completely uneventful.
As a recovering front end developer of 20 years, someone who has played with every damn framework and used most of them professionally; just stick to web standards and ignore the frameworks unless you specifically need them.
For example: we are using HN. It is simple. It works. It does not need to change. It does not need to be reddit or twitter or whatever, to be engaging. It’s good because it’s focused simple and well maintained. Almost every app I enjoy that has been over complicated or lost touch with its user base has done so while implementing these frameworks. They are business death. See; Facebook (react destroyed fb), Google (angular destroyed AdWords and G Suite), and so on. You lose analytics, accessibility, performance for the end user, less server side bugs is bad when clients are running the bugs, and most importantly you lose track of your customers needs.
If you want your shit to work, keep it close to the metal, conform to standards, scale only where necessary, and listen to your customers.
HN is simple and works, from a user perspective. I don't have my hands on the codebase, but I imagine it's kind of fun to work on precisely because it isn't "close to the metal". DX is just as important as UX is, you have to strike a balance.
Not sure there's much correlation between frameworks and apps becoming complicated or losing touch with their userbase. Using AdWords as an example, I'm like ~75% sure they went from one framework (Google Web Toolkit) to another (AngularJS).
You probably don’t need a front end stack. You should just use the web standards as designed first, and then add improvements that customers like.
Developers wasting time on unnecessary fripperies is not a new thing: https://youtu.be/wHdHCoeUbU4
I'm also smart enough to know that HN caters to a very specific kind of user.
If we stop navel-gazing at our salaries for a second, we should take a look at what developers who make a real difference do. I'm not talking about people who build stuff that leeches off consumer credit cards. I'm talking about TimBL, Matt Mullenweg, Bjarne Stroustrup, John Resig, Greg Kroah-Hartman, Linus Torvalds. They do things on principle, on values, and are self-confident enough not to care about chasing status. They're people who look at a world full of problems and want to actually help by sharing their ideas.
Those people generally build open, self-hosted solutions. They want to empower people, freeing us from the modern versions of AT&T and IBM. They make stuff that can run on a Pi or an old Celeron. Their stuff is standards-compliant, open, clean, simple, and user-auditable, so that it can be trusted and contributed to.
React was developed by Facebook, an app that steals your own family members' valuable time. Angular was developed by Google, and app that drains your own wallet. If you want to emulate their outcomes, by all means use their technologies. If you want to make a difference in the world, observe those who are making a difference and emulate them.
They're unrelated. The tech and outcomes are unrelated. You can make great things for the world with React. Using Arc isn't gonna make Facebook a better company
It is also my opinion that at all levels, motives and intent are driving dynamic forces in life. Ignoring them is a great way to waste your time, money and efforts. I can understand that not everyone feels this way, but I do. So perhaps that's where our interpretations differ.
There are lots of basic issues with HN. For example, if you vote on a comment while writing a reply, the page reloads and you lose your comment. A web component for voting would do wonders here.
Lolol all those people who said React was superior to backbone, angular, etc because it was a library not a framework.
That's a real bummer as it's really the only modern web technology that's getting me hyped. Let's move it all back into HTML. I'm begging you all. Please, let's move back to markup.
[1]https://htmx.org/
Honestly I don't know what people're on about. webpack, typescript, jsx are simple enough for me while vanilla js & whatever template langue/obscure toolset other frameworks invented are the complex stuff.
React these days is no longer the "minimal API surface" not-a-framework it used to be, but that should be the direction, not the one Vue & everything else is going with.