If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours poured into making these frameworks work correctly under any condition.
> If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves
This is a classic red-herring argument from developers who have not built anything complex with vanilla js. You can build rich interactions with or without a framework, you’re just making different trade-offs (conventions, learning curve, flexibility, tooling).
There is a much larger amount of man-hours put into browser APIs, and web components is one of them. I don’t see anything wrong or that warrants a “you’re wasting your time” warning in his argument. And note, he’s talking about the chrome dev tools everyone including the react team use daily, not “basic forms”.
Using web components makes your forms instantly inaccessible without JS. Browser APIs evolved over time and albeit most are pretty good nowadays, a lot of stuff is still bad in HTML world and frameworks like these solve that painpoint. The framework still allows usage of FormData and whatnot, there's even a new framework ontop of React now that aims for form handling without any JS at all in the browser so there are good reasons to adapt them.
And the fun part is that when you are going with the browser APIs like a responsible developers, do aim for backwards compatibility and browser support and all that jazz you will at some point also be annoyed to write a lot of imperative code to add a modal, add this field dynamically, handle class toggles and make another button somewhere change something else in the UI that it's inevitable that you write a poor-mans version of React that now no one knows how to maintain and onboard people.
React didn't come from PHDs in some university, it came from the real needs and desires of developers to just think in "I want my UI to look like this, get it done" and not in "Aight, I add a class here now, but update the value here, this button also needs to be disabled now and then make the request and if it fails then add this element for the error in this spot and enable the button again but if it works yeah just throw all of these away and replace it with a success message"
I’m not sure I can even make out what argument you’re trying to make, but let’s go.
Nowhere in the article the author claims web components is a great choice for everything. He works on DevTools, which is not a website, and 100% js already. Seems like a perfectly ok choice.
> be annoyed to write a lot of imperative code to add a modal
I’ve recently added a modal system to a react app using react-aria-modal, and no kidding, it took over 1000 lines of code* to get it working, following their guide to the letter. Later, out of frustration, I reimplemented the same feature using Svelte (which lets you get much closer to plain JS and HTML), with the same features and aria support, in a couple of hours and 10x less code.
> it's inevitable that you write a poor-mans version of React… it came from the real needs and desires of developers
React uses a very specific architecture of VDOM, stateful components, hooks etc. There are plenty of alternatives, including well developed “poor-man’s versions” like Preact, hyperapp or SolidJS.
It seems you’re under the impression React is some kind of universal solution to all frontend apps, developed by “the people”. It’s just a framework, developed at facebook, born from the evolution of their existing server component system. It works, feels nice for small apps, I use it along with a million other people, but it’s not a panacea, and it’s sad that a lot of people simply dismiss everything else before they’ve had a chance to actually understand the trade-offs.
* id say it’s imperative code too - calling hooks in the correct order, passing data from one to another, telling react what the dependencies are, updating and transforming values
You call the argument a red herring, then name all the reasons people use a framework over vanilla js: conventions, learning curve, flexibility, tooling.
Sure, the browser apis are great and always getting better, but I don't see how that's a reason not to use the framework.
> There is a huge amount of man-hours poured into making these frameworks work correctly under any condition.
The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.
I can advertise for a "React developer" and find people familiar with react rendering. I will never be able to do that with in-house render solution. This will apply to whatever replaces react as well.
Unless I'm selling a render solution, I don't want to be maintaining a render solution. Maintaining glue code might suck, but writing everything from scratch limits the scale of the work that a person can accomplish. I liken it to polishing gears rather than driving the car.
I think that's the biggest thing to me. It's easy to say 'we can do just fine without $BAG_OF_TOOLS, there's no real need for it, it's simpler and faster and we get off the ground with it', but then once you have enough people that a bag of tools is needed, you create an in-house bag and soon you have a 'simple' system for managing state that is nevertheless much less exciting to the new cohort of $BAG_OF_TOOLS bootcamp graduates, etc. And people pointing to the framework graveyard ignore that you need to hire people now, not 10 years from now. If 10 years from now React is as obscure as an in-house framework, meh?
It's people that think electric motors are always the right solution to every problem and it's only a matter of rube Goldberging it up to shoehorn electric motors in to places that that's better without them.
It's against arrogant dogmatic rose colored glasses fanboyism being mistaken for software engineering
And this isn't straw-manning, the internet is full of these evangelists that exist as effectively marketing arms, as if they're bicycling around wearing nametags on behalf of the Church of Current Day Frameworks.
All it does is create messy piles of tangled garbage that wastes people's times and gets thrown away to be rewritten when the next flashy thing comes around. It's hot fashion for programming
It's gross and needs to stop. Seriously. Let's build the future, help fix the world's problems and quit fucking around.
This fetishism for shiny things have left us impotent executioners of meaningful change and thus we are amidst the tech stagnation
The way it played out with jQuery is that there was a transition period; gradually more and more classes of app didn't need to be built with jQuery and it was easier to build them without it.
The implication was that we're in a transition like that presently.
The steam engines will continue to run on coal after the natural gas to the power plant is shut off and the power stops working for the electric trains
You implied it. What you should have alluded to is that it is necessary to use technologies today that won’t necessarily be in use in the future, merely as a stepping stone to get us to the next destination, where we will use a new but still temporary technology.
Quoting absolutes expressed by highly opinionated people is also for fighting. Not saying you shouldn’t, but maybe there’s some nuance missing. Not even saying the particular analogy was devoid of conflict, it has plenty of room for disagreement. But it didn’t feel to me like it was inviting any which wasn’t already present.
I would classify Scott Adam's statement as a trueism -- true for most people, under most circumstances, for most times. Unfortunately, couching a trueism in its most precise linguistic form with associated probabilities and error margins is a path to simply being ignored. Once a thread switches to rhetoric, dialectic responses are like pissing in the wind, forgive the analogy :-)
Well I’ll give you this: quoting Scott Adams then correctly using and understanding the word dialectic is definitely not on my HN comment threads bingo card.
I do wish that people would engage in dialectic conversation when they encounter an analogy, rather than rhetoric. Unfortunately, I find Scott Adam's words ring true.
I heard it from Scott Adams, the creator of Dilbert. In addition to writing that comic he is a very interesting thinker. He is also a trained hypnotist.
The longer something has existed on top, the longer it will continue to. React still hasn't peaked yet. Its tail to obsolescence will outlast anything you build in it today.
Which is certainly more about popularity and subsequently littering the world with soon to be legacy apps. React and Wordpress, pick those up and you'll have work for your whole career I suspect. Also a legacy knowledgebase on how to achieve just about anything with both of those tools.
That’s a pretty funny stance. The library has a gigantic developer share and is supported by a tech giant. A world where React isn’t used and remembered is one where the web isn’t based on the same primitive. The idea of a thin layer on top of JS offering composition is not complex, and the execution by react is still trend setting. Remember when they introduced hooks and now tons of libraries have the same thing? That’s not because React is behind the times and possible to supplant as a small team
Just a friendly reminder that React is approaching a decade in life. There are no other competing frameworks that look to be taking it’s place.
Not saying it will never go away, just that, maybe the front-end world has finally, significantly slowed down in churn. Things could always be better (Svelte is nice) but overall, React does what I need and I rarely curse at its design.
From jQuery’s release to 2014 there were multiple phases of front-end frameworks.
Backbone, Knockout, AngularJS, Ember. All of these had their time in the light during that phase. Most companies were already switched over to one of these frameworks. React was the new kid on the block at this time.
You Don’t Need jQuery was out well before 2014.
It’s also a bit difficult to compare jQuery since it’s a library that can linger in a codebase indefinitely. It’s not a framework.
Also jQuery release date was 2006, so the equivalent year 9 would be 2015. By which point React migrations were in full swing. I wrote my first on the job React + Flux application in 2014 and then joined a new larger company in 2015 where we were making plans for a React migration.
> jQuery has faded into the background, no longer interesting.
It’s a mature, stable technology, still in wide use - and not really a competitor with react. That you claim it’s “no longer interesting” says more about your own preferences and ironically makes it sound that you are personally interested in the newest shiny fads - so I’m confused, what is your objection to react then?
Angular isn’t exactly dead - and is a more apt comparison.
Honestly I bet a significant portion of the code I have maintained (and even some I’ve written) was reinventing a wheel someone didn’t know existed. Not even out of a desire to solve a problem, but simply not realizing it was done already.
I suspect people still reach for jquery for similar reasons. They know it makes complicated stuff work, it’s reliable, they don’t need to think about the specifics of the problems it solves… As a result, they’re less likely to discover that it’s no longer necessary in the first place. They’ll just keep using it.
The same will happen to react.
React will become a victim of its success, because the more it is used the more likely its concepts will be integrated directly into the browser or ECMAScript
Maybe this is less obvious if you’re deep in the React ecosystem and nothing else but I’d argue that React is already in early stages of a death spiral for a few reasons.
These mostly come down to
1. It’s no longer the fastest, in fact it’s barely competitive speed wise with many things that have come after it.
2. It’s architectured in such a way that it is fundamentally misaligned with the rest of many web standards (I.e the DOM) which made a lot of sense when it was released but is now a major liability.
3. It now has to ship around a lot of code that now lives natively inside the browser and is now rather bloated as a result compared to newer iterations such as Lit as mentioned in the article.
Personally, I think it’s fatal in the sense that they have painted themselves into a very specific corner with no obvious engineering solution to get them back on the standards path. Its problems as a result aren’t really fixable without major architectural changes that would fundamentally change the project. On top of that they are only going to get actively worse over time as more things get moved into the browser and they are still stuck shipping a bunch of JS code to do the same thing. In short they are on a bad long term path with no clear off ramp.
I wouldn’t start a major project in React in 2022 for something I wanted to be around in 5 years from now as a result.
jQuery was and continues to be just about as successful as it is possible for a project to be. The reason it’s no longer as widely used is because it essentially became part of the platform. Most of what jQuery does is now possible with platform APIs, and those APIs exist mostly thanks to jQuery proving their utility.
A similar thing happened to CoffeeScript: no one uses it anymore because nearly all of its good ideas made their way into JavaScript itself.
What sharp edges? (This is an honest, curious question.)
I don't find many sharp edges in day-to-day React work. I say this having once been a very strong proponent of framework-less frontends, before trying Vue, then Svelte, and then settling on React.
React has edges. Hooks are an anti-pattern with all kinds of footguns. Suspense is also a crazy anti-pattern by literally throwing and catching errors as a means for communicating between parts of the framework.
And this isn't an issue of me not understanding React or hooks, I would consider myself to be as expertly acquainted with hooks as it's possible to be.
Now, do I still use React for everything? Yes. Do I prefer hooks to class components? Also, yes.
> Suspense is also a crazy anti-pattern by literally throwing and catching errors as a means for communicating between parts of the framework.
Okay I can criticize React and its weird solutions until the cows come home, but this is a pretty weird one because it’s entirely an implementation detail. No one working with Suspense ever needs to know that’s how it works unless they’re building a library to be compatible with its behavior. Otherwise it’s just trivia.
Wouldn't the debugger break on exception? So any exceptions used in "nonexceptional" situations have a potential to "pollute" the debugging experience?
Admittedly, I haven't tried debugging React 18 yet, so I don't know if that actually happens in practice.
Only if you set it to break on handled exceptions/Promise rejections. This isn’t new behavior in React 18, it’s been the mechanism used for Suspense since it was introduced. If you have used Suspense and haven’t had unexpected debugger pauses, that’s what you should expect going forward.
In practice, because they don't work the way most people think they work, and because it's really easy to screw up using them.
Hooks are called every render, which is a relatively transparent process that happens all of the time. All hooks have to be called every render, otherwise you're breaking the rules of hooks. The reason why is because the only way hooks know which hook they even are, is the order in which you call them.
For example, if I have
const a = useRef(true);
const b = useRef(false);
The only way react knows that the first value it should return the next time it renders is what I'm expecting to be value `a` is because that useRef is called first every render. These are all kinds of rules and assumptions about hooks that make them not behave at all like normal functions. I don't think people understand that, for useRef, for example, those two lines of code are run every render, passing in the initial starting values, which then react disregards after the initial render, and maintains a mapping of ref and state and memo etc values all by the order the hooks are called in. I see people use hooks in callbacks all of the time and just fundamentally not understand that they're doing it wrong.
Then there are all of the closure problems with useEffect and useCallback that I see people really struggle with.
And useState...lordie. The fact that it defers setting the state value, whereas useRef will immediately have its value updated. Deferring useState has caused so many bugs.
I don't like them because they hide program state in innocuous-seeming function calls. Want to call useContext in a helper? It'll work, until it doesn't. Want to display a loading spinner? You'd better not have any useState calls below it. Want to see what hooks a function will use? You have to run it or go through each line of every piece of code it calls, they're not in any way declarative.
The programming paradigms I like best are declarative and make invalid or undefined behaviour impossible to represent. Hooks do the opposite: they're procedural, make it very easy to write a program that compiles with subtle errors, and don't have compile time checks to stop bad code.
Seriously, Google stuff is infamous for being smothered by Google itself, what's your point
> nobody cares anymore
Literally the only non-Google example you could think of is still popular. But jQuery wasn't a graceful idea with a strong implementation, it was a wrapper to alleviate the pain of browser APIs. React is a wrapper to alleviate the pain of JS. Thus my original claim: "[a] world where React isn’t used and remembered is one where the web isn’t based on the same primitives". I don't see that happening soon.
Web components might change those primatives. It is still pretty early days, but I would be surpriaed if react isn't replaced either by something built on web components, or maybe even native web components.
Web components were proposed 11 years ago. Widely available for at least six. When will it stop being "early days"?
Now all the air in browser development has been sucked out of the room by them. Instead of actually moving the web forward browsers are busy patching holes and problems created by web components because they are horrendously badly designed.
And they still have an issue list as long as the equator. Any framework in such a state in "early days" would be laughed out of the room.
Custom Elements weren't available until 2018. So unless you are referring to the chrome-only experimental v0 version, I don't think you can say it has been widely available for more than 4. And there will likely be substantial improvements to it before it starts dominating web development.
> I don't think you can say it has been widely available for more than 4
Yes, my timeline was off.
> And there will likely be substantial improvements to it before it starts dominating web development.
I'm definitely veering away from my original statement, but here goes :)
There won't be any substantial improvements in web components. It's painfully obvious how many shortcomings they have, and how many holes have to be patched before they can become actually useful. I mean, they had to come up with a whole new Javascript API just to make them participate in forms.
And now their existence taints and poisons most other improvements to the platform. For example, Scoped CSS (which on its own would solve a huge chunk of what web components offer) now have to be twisted to accommodate web components, and will likely be a worse spec as a result.
Chrome "developer advocates" will incessantly berate and gaslight other projects and frameworks, and will claim that web components are a success because companies with billions of dollars in revenue and thousands of developers use them to create a yet another avatar or breadcrumbs component. That... that is neither success nor a path towards any substantial improvement.
"It's almost as if congealing 2010-era best practices in the platform before we'd finished exploring this territory was a mistake" [1] And the future is likely to be component-less [2]
If the tens of millions of dollars that Google alone has poured into Web Components had gone into something meaningful like https://open-ui.org we'd have a significantly better and a substantially more future-proof web. Alas.
> without implementing a significant chunk of the frameworks
In my experience, it hasn't seemed all that significant. These frameworks are absurdly general and cover a range of use cases and deployment methods that most people don't use. I just need the kitchen sink, not everything else.
So far, just using custom elements and a small wrapper around the <template> element, I've not been struggling to create the features I need or would otherwise miss.
Yeah, my experience is that people frequently overestimate the cost of building something for your needs and underestimate the integration cost of buying something.
Also, the trend of hiring <framework> developers is a plague: if you know JavaScript and the DOM well, learning the basics of react is a couple afternoons of work and you can figure out the pitfalls via code review and learning on the job.
That’s right, except I think it would take most people longer than an afternoon. There’s stuff that’s quite unique (and powerful) like useEffect and JSX takes a bit to get used to.
But generally I wouldn’t be worried about onboarding a web dev who doesn’t know the lib, it’s not rocket science. One of the appealing things is how very straight forward and clear it is.
> This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much
I am currently working on an app at work that wants SPA functionality, but they won't let me use any of the frameworks. Tons of vanilla JS and Jquery. I am sure what I have written is probably considered a crime against humanity in some place.
Does it work? Yes. Is it an elegant and maintainable codebase? Not by my definition.
I actually have quite happy memories of working with Backbone and jQuery - there were obviously all manner of problems, but everything was quite easy to understand and a lot less magical. Apparently this was in 2012 - how time flies! - so I imagine rose-tinted spectacles must be in full effect here!
That raises an interesting question: what would be the declarative framework easiest to minimally reimplement?
I’m thinking you could have a single file, jQuery-based, hand rolled version of some framework and get many of the benefits while still technically complying with the “no frameworks” rule. In the same way that you could reimplement Redux easily if you for some reason weren’t allowed to use it.
I suspect diffing performance would be the bottleneck but I wonder if you could come up with some weird half solution that worked for your particular use case.
I would love something like this, but I do not think I am at the level to be able to build something like this, at least not in a reason amount of time.
I've not used Redux for anything before, but I will look into for sure. I've heard the name thrown around a few times on here, and I could probably use something like that. Just nothing that would require a staunch learning curve to use.
I doubt I will be able to roll my own version of whatever these project due mainly because of time constraints and because I am the only developer working on it. Since we have adopted all the Agile stuff, Sprints are basically deadlines and not very...Agile.
I've built my own framework once out of frustration, thinking typescript will make it easy... after a while I realized that I was just rebuilding chunks of existing frameworks and most likely not in the best way. Webtech is really messy to begin with, typescript didn't really save me. So I stopped. Sure it was nice to know how to build your own viewstack, navigation and state management and how to some newer html5 features, but it really was not the way to go. Vue js seems to be closest match to the way my mind works and built a very crippled version of it minus all the good tooling and plugins. I was also influenced by Knockout and Wpf/C#, so it had some similarities of what I used to do in those. I honestly do not like the way react works or the way it wants me to work, it feels extremely messy too (syntax and project structure)! I get the same feeling from react that I got from own crappy framework!
So anyone reading this, I encourage you to build your own frameworks, but think very carefully if you need it in production and can support it in the long term. Try to keep emotion/ego out of the decision.
I think react sits really well with some people, and with others it doesn't. For me I find I have to fight against the platform to separate presentation from behaviour. And let's not kid ourselves, a lot of react code bases do the classic winforms mistake of having an essentially code behind architecture.
IME marrying business logic so closely to presentation makes it very hard to change one without the other. Especially relevant for web apps, where you may want to re-use business logic for mobile apps, which becomes very difficult when they're tied to a react component.
Also makes it harder to test. There's a great paper called "Naked Objects" which I'd recommend for anyone doing GUIs, but powerful idea I got from it is make your presentation code so immediately obvious from your business objects that you can practically generate it automatically.
Because it was implemented via inheritance. Which is why the argument is BS, nobody does react like this. They specifically tell you not to do it, and I think there's a bunch of stuff in there to stop it from working.
This is totally uncalled for. He's not attacking you. He's explaining a tradeoff, very reasonably.
> I would even say that if this is not a core part of your product, you are simply wasting time and resources.
I find especially interesting that this phrase can be used to defend both sides of the argument. If you are building a highly rich application, chances are that using a framework for that is the right choice, agreed.
But.
Not all the apps being build out there need to be Very Rich Apps. There's indeed a lot of space for only-slightly-rich-but-mostly-static apps, despite the recent HN article.
And for those, introducing a framework is ... precisely, a waste of time and resources.
Their comment is perfectly reasonable and measured. I don't think anything in it is 'uncalled for'. Your own comment is a confusingly ironically ill-tempered response.
The phrase “The frameworks that you dislike so much” is not an argument. It’s a characterisation. It implies that the OP is blinded by his own personal preferences, and that his arguments have no weight because of that.
Imagine if I had started my answer with “Since you love frameworks so much, then…”. That would have been a similar mischaracterisation on my part (equally uncalled for, since I don’t know the other person enough to make such judgement)
