This got to me:
> For a certain type of developer, building things yourself is just more fun
The platform APIs were terrible. React wasn't "more fun"... it just made it possible to do things with the platform that were extremely difficult and cumbersome to get working reliably with platform APIs alone.
To me, web components were an incredible idea poorly implemented. Most of the minimal adoption happened on top of frameworks like Lit that wrapped WCs to try to make the dev experience tolerable.
In urban planning they have a concept called "desire paths" where if you don't put sidewalks and pathways in the right places, people invent their own. I feel like the web community has spent a lot of time and effort patching the platform.
Now credit where credit is due: it has very much improved. And modern standards means it really is time to re-evaluate where and when you need these patches. But don't write off all that annoying and painful effort people put in to trying to making the platform deliver it's promised potential just to "building it yourself is more fun".
After doing this for more than 20 years I have asked that question hundreds of times and the answer is almost always about aesthetics, about 95%+. Of those aesthetics based conclusions most people cannot find their own way to handle it without waiting for somebody else to write a tool that provides the answer they were looking for. Even then the answer tends to be predicated on social acceptance more than technical evaluation. That is a training or human performance problem more than a technical problem. It says a lot about an industry where the people who are able to ask these kinds of questions realize its a training problem and are willing to raise salaries and assume tech debt as opposed to fixing a human capital problem for far less money.
At any rate there is something to be said for the developer who builds things on their own just for themselves. In many cases the result is faster, lighter, and more capable software than what they are paid to do for their employer. Their personal software isn't locked into conventions or abstractions beyond their control.
The APIs are expensive for storing state (read access on attributes) and expensive to write (so many ways to trigger reflows and paints) without a good way to batch them.
WCs have tons of boilerplate to them, such as extra song and dance to make attributes observable. In fact, a custom element can have an attribute and a property with the same name, and they are managed separately unless you explicitly set them up to sync. It's a terrible design.
Built-in things aren't extensible - there's no way to have a number type input that doesn't suck without doing it yourself, and then you need to opt into extra song and dance for your element to participate in form submission data.
There's a reason popular frameworks are popular. They're good enough, you can hire people who already know them, and you benefit from the maintainers fixing bugs for you.
> Built-in things aren't extensible - there's no way to have a number type input that doesn't suck without doing it yourself, and then you need to opt into extra song and dance for your element to participate in form submission data.
This is the bane of every UI out there. "I hate the inbuilt controls so I'm going to write something better that doesn't look terrible!". Then they build some half-arsed thing that doesn't do accessibility right and only works properly on an up-to-date Chrome-based browser in a US locale with javascript enabled.
The built-in controls should always be used, not because they look pretty, but because they work the same across all websites. Users don't have to guess how this site's bespoke time-picker works (and how it doesn't). It won't fail in unexpected ways. It'll deal with your locale's date format so you don't accidentally specify the 5th of June when you meant the 6th of May.
Not everything has to be pretty all the time. Functional works, too.
> The built-in controls should always be used, not because they look pretty, but because they work the same across all websites.
Funny that you mention date/ time but ignored my example of the number type input, which does not work the same across all browsers.
In any case, it proves the point I was originally making; if the built in controls were extensible, we wouldn't be in the position of reinventing the entire stack because the design team wants to be unique.
It seems wild to me that a (subjectively?) pretty-looking site will make more money, even if it's excluding a large proportion of its potential users by ignoring localisation, or usability.
As with all things like this, a lot of the data is hidden behind teams working inside organisations that won't publish their data.
I tend to find good examples of data-driven blog posts on Gov.UK; GDS has done a lot to drive better decision-making with strong data. An example of that is the Input component they use [1] and the data behind the choice and issues with type=number [2].
On the making more money perspective, I can share an anecdote for you, when I was working with a large property portal in the UK, we had a few unstyled dropdowns hanging around the app for sort criteria etc. Simply replacing them with a styled dropdown (and dropdown list) resulted in a 60% uplift of using that sort. We made no functional changes, just styled it. And it wasn't good styling, we broke dropdowns (as many do) in the first iteration (we were testing the hypothesis that people didn't use it because it didn't look like it was our component / wasn't styled like the rest of the site) -- So yes, anecdotally, pretty can be more impactful and result in more clicks.
> These popular frameworks are the primary reason so many people on here bitch about the bloated web.
I'm not saying a framework should be used for every single website. This one doesn't need one. It would be equally absurd to say not to use them.
> It sounds like you are trying to force framework insanity onto the vanilla APIs. That is insanity, but I know why you are doing that... its what you know.
I used to work at an agency that came up during the front-end time of slicing and dicing PSD files to get pixel perfect rendering on IE5-8, with all the quirks and everything. Nothing was allowed to be a framework, not CSS (bootstrap) or JS (aside from jQuery).
As applications got bigger and bigger our code and ability to deliver on time suffered. Nothing was impossible, per se, but the ad-hoc frameworks that got invented in house to cut down on boilerplate didn't keep up with the needs of the projects.
We slowly started allowing things like backbone, then later angularjs and right before I left React started to come on the scene. These came with their own problems, but they generally solved more than they caused.
"Framework insanity" is a meaningless phrase. There's plenty of frameworks that I don't care for, and things I don't like about the ones I do use. I'd rather use almost any of them than go back to doing what I'm doing now with pure vanilla JS. I'm not writing simple blogs or news sites or recipe sites that don't need much interaction. If I were, I'd be using vanilla JS.
> It would be equally absurd to say not to use them.
That only depends on who you are. Seriously ask what are the business objectives behind these frameworks:
1. To reduce an employer's friction to hiring and firing, because now they don't have to train people. In other words developers become a throwaway commodity.
2. These frameworks impose components as the architecture, which allows labor segmentation without need for architecture considerations.
That's it. Developers like to create all kinds of bullshit to justify use of these frameworks, but only because they cannot operate without them. That is not an objective business value.
Think about it on the flip side. If you can build a web application in less time, that executes faster, and requires much less time to maintain without these frameworks then why would you ever want to use them? You wouldn't but it completely misses the point, because its never about the developer. Its about the employer.
For me, I do not perform this work for employment any more and will not do so in the future. Employers have lowered the bar too low and so many people doing that work lack the maturity to operate with any kind of independence. I got tired of carrying other peoples bags or becoming the punching bag when I wouldn't.
The challenge with writing vanilla JS is that you have to make original decisions. In that regard its like writing a novel as opposed to filling in a job application. Some people would rather jump off a building than write a 2 page essay. It isn't challenging or messy, but not everybody has the capacity to perform original work. That's fine, but don't fucking lie about it because you are pretending to be something you aren't. JavaScript work is full of pretenders lying about who they are. That is what wore me out.
On the platform, my code is split between HTML, JS and CSS files.
I like modules. They exist in some form or another in most programming languages and they are one of the few definitively good ideas in software engineering. Give me the ability to split off parts of my work with some public API and hidden internals. Works on different levels too, like with a reusable library that consists of modules.
JS has a module story. But HTML and CSS just aren't connected to it, without using something like JSX.
That's why I end up abandoning "using the platform" every time.
I dont know any other environment except the browser where code is split into three in a similar way.
> That is a cumbersome mental model, which is why React, Angular, Vue, Svelte and every other web framework calculate that automatically for you.
I think this point is what the anti-framework does not get when discussing the topic. They fail to see how hard and unpleasant it is to handle all the real-world problems that hits any production environment with a "platform" approach, and at the same time they fail to see how javascript-based een frameworks not only solve them by making them implementation details but also go through great lengths to improve the developer experience.
Just take a look at JSX. It's where a great deal of the complexity of the framework lies, but simplifies everything so much. It's the exact opposite of platform features.
This is the case with being a zealot for and trying to 100% adhere to any ideology. There’s a very good reason Linux runs on a huge percentage of world server infrastructure and virtually none runs on GNU HURD.
The real world doesn’t care if your model is theoretically better. At the end of the day, actually shipping things is what truly matters and strictly adhering to an ideology tends to stand in the way of that.
Yes, the life is too hard argument. This comes up a lot and its purely subjective. Writing this code without frameworks is not hard. If you know what you are doing it is far less effort. You just cannot do the exact same things you would do if you were using your favorite framework, and this is where most people struggle.
> Yes, the life is too hard argument. This comes up a lot and its purely subjective.
It is pretty obvious that platform-only approaches are riddled with problems that are unacceptable in professional environments that develop production-graded software. Polyfills and caniuse show one part of the problem, "your browser is not supported" and "designed for chrome" is another, etc. Only someone who is completely detached from professional settings would argue otherwise.
> If you know what you are doing it is far less effort.
Those who know what they are doing are knowledgeable enough to simply avoid the problems caused by platform fundamentalism. Not knowing this is a skill issue.
Again, this is only subjective reasoning without evidence. It’s just as correct as it is incorrect depending upon who you ask. The complete inability to perceive that subjectivity is a maturity problem technology cannot fix.
"Why does the page fail to work with this browser?"
That's rather obvious, isn't it?
> Again, this is only subjective reasoning without evidence.
It really isn't. While systems are designed around this problem. Even UI test matrices. How come are you spending so much time discussing an issue you're not aware?
All of these comments unintentionally make an important point about human behavior that screams so much out loud in a way that I alone couldn’t do justice to. That is why.
I have worked on my own component libraries for HTML, but I don't like solving the same problems over and over and over again. I'd prefer a well-supported battle-tested library over my ad-hoc attempts.
The argument presented in the article here is that libraries like jQuery and React were useful, but now the browser has better APIs, so we should use them.
The browser indeed has a components API, but it is by the admission of many, fairly low-level as far as component APIs go. It doesn't really solve how to manage data flow or rendering in your components or application, and has many sore spots.
No problem. There is a pretty nice library called LitElement that provides solutions to some of these problems.
But then we're not really living off the land are we? We still need Lit in this case.
So what's wrong with WebComponents? Frankly, I think this is a bad question. A better question is why people think WebComponents competes with React to begin with. WebComponents intentionally fails to solve some of the most annoying problems with writing components because it is intended to be low-level and used by libraries like Polymer. Because of this, it leaves many problems open-ended. Like for example. WebComponents act like HTML elements. Cool? So you can pass data down using HTML attributes. Neat. Problem: HTML attributes are strings. Okay... So you either need to serialize everything to strings, or you have to pass objects through a separate side channel (usually properties that you assign separately.) In fact, generally speaking, writing WebComponents that compose other WebComponents is ass. I'm pretty sure it has been noted before that WebComponents works best for leaf components... So it would certainly not make a good replacement for a library like React, which is meant to be a substrate you can build large scale applications out of.
Yeah, I don't really like WebComponents either. I have not take the time to examine the WebComponents API. I just don't like the concept as a means of architecture.
For me its all about design freedom and maximum flexibility. To achieve that I go further down the stack, as low as the given platform allows. I have been doing this work for a very long time, so I am not worried about risks with operating in the browser as primitive as possible. The most important APIs and conventions have not changed much, at least for me, since the release of DOM4 spec and the JSON methods entered JavaScript as language methods, then later WebSockets.
When you go lower elsewhere, the risks are higher given there is so much we otherwise take for granted. There are risks to reinventing the wheel on some of the most complex things we use but don't really think about. The benefits, though, are massive if you can create capabilities the technologies allow but nobody else has. Achieving this is more common than it sounds like it should be, only because most people don't try.
My original motivation for reinventing wheels, early in my career, was to have streamlined processes at work so that I could spend lest time doing work assignments and more time browsing the web. Now, I am about to do my first start up so now my motivation is to kneecap the incumbents with a cheaper and more durable technology that allows for writing future tools upon it to scale in ways the competition cannot.
It supports passing arguments via attributes to constructors. And you can pass complex arguments to nested components without serializing them. No signals and no build step either, just import and use on your regular data. And it's faster than just about all the others.
Thank you for typing this all out because I could not articulate this nearly as well as you did but this was exactly what I wanted to respond to that comment.
"After doing this for more than 20 years I have asked that question hundreds of times and the answer is almost always about aesthetics, about 95%+."
It may be that a lot of it is aesthetics (though aesthetics also matter to usability) but some of it is richer functionality.
For example, a pattern I've been asked to implement multiple times is a requirement like this:
"We should have a 'Country prefix' input for a telephone number on the form. It should be a list, but allow the user to filter. They should be able to search by code (+44, 0044) or by country name (United Kingdom). We want a little flag beside the input".
Now I _can_ do that myself from browser APIs, e.g. using something like a datalist, using emojis for flags. But then I've to handle stuff like Win/Chrome not even supporting the emoji properly. Chrome will autocomplete based on label or value but FF won't. Even though there's a datalist, I can't constraint the input to _only_ select one of those values, so I need to do additional client-side validation on inputs anyway.
Then if a designer said of an 'contact book' look-up (e.g displaying an profile photo of people instead of a flag) I now have to come up with some other custom field anyway, to support that.
I think the browser level APIs and supported tags have come a long way from where they were, but they're still at the level of primitives. The libraries people are reaching for are one level above that.
But we've well established patterns on the web now that there's no reason we couldn't have richer OOTB browser chrome and remove the need for a lot of this stuff getting reimplemented in libraries all the time.
Then, dive down into the concept of polyfills to understand what extra work everyone must go through to normalize the platform.
And then look at the features themselves. Web components is a good example. Theywere developed as a hack to extend toe current platform to catch up with basic features provided by JavaScript web frameworks. Except they are virtually unusable, unless they are made palatable with... JavaScript frameworks.
And lastly, compare that with the experience of just using a mainstream JavaScript framework. Any of them. It's world's of difference. JavaScript frameworks prioritize developer experience to the point they even went through great pains to have a xml-like DSL to make their javascript be seamless. Whereas things like web components go the opposite direction and make their platform's first class feature feel like vanilla javascript.
I don't do any work to normalize the platform, and I haven't for more than a decade. I used to have to do that a lot when I started out 20 years ago, but back then IE was very different and there were not native methods of parsing JSON. But, then I also remember jQuery was all the rage and it would frequently break IE so I had to normalize that madness too.
> And lastly, compare that with the experience of just using a mainstream JavaScript framework.
Modern frameworks require much greater effort. The trick to writing vanilla JavaScript is to not do things the way you would in your giant framework. Just keep things simple. A state model is an object. Event handlers are functions, that can be reused. Just keep it simple and its far less effort.
I don’t disagree, but to me web components solve a different problem. I want rich widgets without being bound to any particular JS framework and without having to ad hoc it everywhere.
As an example, I still like the simplicity of Rails for basic apps. I also enjoy the numerous component libraries, such as Antd, available for React. I don’t want to have to pull in React just so I can get a reasonable way to work with a Tree widget.
I’m not trying to only use the platform. The components are free to be built with whatever lightweight lib they need (Lit, UI5 Core, etc.). But that’s contained in the component. I’m free to use my framework or web technology of choice for building my app.
> I don’t disagree, but to me web components solve a different problem. I want rich widgets without being bound to any particular JS framework and without having to ad hoc it everywhere.
The point is that the "platform" way of doing things is lagging behind virtually all JavaScript frameworks particularly in developer experience, and even when the platform tries to catch up with JavaScript frameworks such as web components... The results are between underwhelming and unusable.
> The components are free to be built with whatever lightweight lib they need (Lit, UI5 Core, etc.).
You're still resorting to using JavaScript frameworks. The problems created by the platform are still there if you replace framework foo with framework bar. In fact, it seems React 19 rolled out full support for web components.
The web platform is still garbage. I want something with the simplicity of Classic MacOS, or GTK2, where for e.g. a text editing page like a wiki, I have a toplevel "App" component, and inside a combination of VerticalBox, and HorizontalBox for layout, with a MenuBar on top and a TextBox on the bottom, and some buttons. In total, a tree with a depth of max 4-5, and sane defaults so I never have to think about the "CSS rendering algorithm", divs, CSS selectors, Z-index or other useless details like that, which should be left to those designing a skin for the UI components library.
Web design hasn't caught up with desktop UI frameworks of 30 years ago.
Most browser things live in a bubble of ignorance about what people are trying to build.
It's not overly ambitious to have rich text input fields or a sortable table. If you can have a half assed xpath implementation you can have a shopping cart and a product.
Someone knowledgable once ran off with a fumble of mine acting like I pulled gold from thin air.
It took the id's from the page, created strings with the same name containing the inner html, made a copy, compared the copy with the string every 50ms, if they were no longer the same the dom node and the copy were updated with the new value. Input fields compared the copy with the input value as well.
yes you must be right about this with your 20 years of experience, and nearly literally every tech company that hires full stack devs is probably wrong
Can you write front end JavaScript applications without a giant framework?
It is a simple yes or no answer. If you struggle, give up and talk about yourself, or invent some nonsense about how impossible life is the answer is "no". It does not matter whether I am correct or not. What matters is that people cannot do the work and most of those people look for something else to blame.
I got tired of working with immature people. Its fine if you cannot write front end applications without the giant front end framework, but don't waste my time looking for something to blame or talking about yourself. It is crazy how common that is.
> Landscapers sometimes accommodate desire paths by paving them, thereby integrating them into the official path network rather than blocking them.[…] Sometimes, land planners have deliberately left land fully or partially unpathed, waiting to see what desire paths are created, and then paving those.
That's fascinating that it already had a term! The YC founder I used to work for was adamant that he came up with the term "idealized path" for this phenomenon.
Pathways is an urban open problem that companies like GoodMaps are trying to solve, although in a convoluted way (more sensors = more accuracy, but walled-garden is meh).
I've been involved in successful and unsuccessful platform builds. In the successful ones, I either had absolute authority or I built for the desire paths, even if they weren't the "perfect" ones that I desired. I anchored on the non-negotiables, which I kept to a minimum, and then optimized to get people on board, even if that meant deviating from my perfect vision.
One way to keep myself honest in being on the desire path was to go from win to win (win = someone using platform and being a satisifed "customer") iteratively as part of the full build. It also helps avoid platform fatigue, and ensures that should some priorities change, we've gotten some value out of the effort.
There was a genre of YouTube shorts about Minecraft desire paths. The videos showed increasingly ridiculous attempts at stopping the desire path from forming. The joke of course being that dedicated Minecraft players will somehow make their way even through the unbreakable bedrock. And the admin/owner has to give up.
Unfortunately, the browser is not a Minecraft server. It's a living standard that has to maintain backwards compatibility. The desire path (React, Svelte,...) will always exist. And so will the ridiculous way they tried to stop that.
There is even a book mentioned here a number of years ago - a particulae favorite of mine - that features this as a plot point: Squares of the City by John Brunner
> if you don't put sidewalks and pathways in the right places, people invent their own.
To expand on that a bit, you can deliberately avoid putting in paths so that the natural behaviour becomes clear. You'll see paths develop between areas that you might not have thought of. Pedestrians are flattening grass and showing connections that are actually useful rather than following lines that have been set out for them with competing priorities in mind like aesthetics or budgets. Then you take that data and create paths that "users" actually want, based on their behaviour / use of the previous system.
I definitely love this approach IRL. I think the closest you can get is watching what users try when they’re unfamiliar with the application. Sadly, it seems like actual user testing is rarer now than ever.
“UX Designers” seem to worship at the Jony Ive/Alan Dye altar of minimalism and “airiness” and tell anyone who will listen that every type of user, for every type of task, gets “overwhelmed” if you give them ‘too many choices,’ so instead of natural direct paths that people would have chosen, modern software is more like a series of white rooms with exactly three exits each, and the exits are labeled with an icon when they’re labeled at all (many are impossible to label because they’re swipe gestures), and other exits only appear when you step near them (the hover nonsense).
The other thing that can hurt an applications usability is over fitting for the new user. It is an important aspect, but it feels terrible to be effectively stuck in baby mode all the time.
The hard part is how fitting for the new user and fitting for the experienced user are sort of opposites in interface design. For new or occasional users who will only use the thing a couple times a year, you want a deep design, gently guiding someone unfamiliar with the application through each step in turn, lots of modes/clicks limited information in each. For the experienced user a shallow design is best, information dense, everything in one action, never hide anything. The best designers can sort of navigate this paradox, but for most you have to focus on one and shim the other.
As for design focused design, where the point is how good it looks, well, that sucks for everyone. But it looks good in the ads.
At none of the full-stack jobs I've had would it have been possible to deliver a competitive product just on the web platform. The web platform sucks. You need a general purpose programming language to deliver an sufficiently-complex application.
No form validation before you submit sucks. Page reloads on every action sucks. A native select that don't show you what you're typing sucks. Alerts that can't be styled sucks. The list goes on and on.
The idea that web components slot and template give you close to the same flexibility in functionality that a component library in a programming language does is absurd.
> The idea that web components slot and template give you close to the same flexibility in functionality that a component library in a programming language does is absurd.
The web component API is programmatic, in JS just like all the rest of the platform.
> In urban planning they have a concept called "desire paths" where if you don't put sidewalks and pathways in the right places, people invent their own. I feel like the web community has spent a lot of time and effort patching the platform.
On my university campus there was a well-trod path across the grass where students would traverse in a beeline from their dorms to the cafeteria during mealtime.
Eventually they did put a walkway there. But for a time the only thing paving it was student footfalls.
I don't understand how WebComponents are such a poor idea. I have intentionally reached for them when building frontend code for most of my simple sites and they have been perfectly fine. Not great, but fine.
WebComponents do their job with little-to-no fuss, and they're universally available.
I can relate to this, but React definitely made things more fun for me at least.
Web Components on the other hand seemed to solve a problem that few actually were having, or for those that loathe React & modern frameworks because of bloat or whatever
For one thing, I just genuinely think WebComponents are a badly designed API that is weird and hard to use (how many people are using WebComponents without at least Lit, if not something much bigger?), and React is a relatively well-designed library that isn't really that bloated. There's not really much of a point in trying to argue since this is inherently subjective and people with different values are going to irreconcilably disagree. But, if you don't respect that some people hold this position, we're not going to make any progress towards a consensus.
> React is a relatively well-designed library that isn't really that bloated.
I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior. But it leaves the question of why react is still so popular. I think the biggest reason is all the non-technical aspects of react:
- They have excellent documentation. And have, from day 1.
- They produced videos, sample projects, and all sorts of "getting started" documentation.
- They ran react conferences, teaching everyone who would listen about "1 way data flows" and pretending like they invented FP.
The amount of hype around it made it really feel like the next big thing. Between the very well funded react team and the outside developer community, there was real momentum. People learned it in droves. Taught students. Built websites with it. When react's poor design choices caused issues (and there were a lot of issues), then you were blamed for holding it wrong. (Component classes, state, CSS, hooks, webpack and babel taking ages, big bundle sizes, slow re-renders, and so on.)
By the time the next generation of JS frameworks broke onto the scene, there was a collective moan from the community. "Oh no, not again - we just relearned how to make websites." React was the wave, and in its wake we all had Framework fatigue.
Software doesn't get popular without a lot of work by dedicated people. I really admire the work standards bodies do. But they rarely bother to take the time to produce documentation, videos, tutorials, starter projects, blogs and podcasts and all the rest of that work.
More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary. The creator of React, Jordan Walke, was big into OCaml and one might even say he got some of the ideas of React through working in OCaml, so much so that he tried to bridge both by making ReasonML which is an alternative syntax for OCaml which has JSX and React bindings.
Yeah, there's a lot of people who have either forgotten or never knew that the context React came into was a world full of JQuery and AngularJS two-way bindings. I started my internet touching career having to work on that stuff, and boy, so much of it was a nightmare that just got endless workarounds heaped on top for basic performance issues, let alone other complications.
> More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary.
It doesn't seem all that different from doing your rendering in the WM_PAINT handler, which was already how things were done in the ancient Win32 API (although it's possible [0] to draw outside WM_PAINT).
The web root is a document platform. Every major GUI library have a “paint” or “draw” function you have to overload for custom widgets. And there is always mostly two kind of widgets: actual visible components and others that are responsible for layouts.
There really isn't anything in react that is inherently "bloated", most companies were indeed using it wrong, or at least in a naive way. Over-reliance on useEffects, re-render issues, non-memoized components etc. When used correctly, react 18 provides really fast web apps on whatever scale (small one pager app to massive enterprise apps).
React is very similar to PHP in this regard. PHP has (had?) several major design flaws, and yet it became the default for people with less experience.
I don't think that React is as problematic as PHP ever was, and also frameworks like Laravel have improved the PHP experience tremendously, so there is now a way for less experienced people to use it.
IMO: the problem here is pretending that everyone has an innate right to use React right when it's clearly a library that works better when people have a bit more experience than the average web dev.
We as an industry tell people "don't do your own crypto, it's hard to get it right". We don't blame crypto for being hard, or demand new frameworks. Same for things like assembly, C++, Rust, formal proofs, writing an OS, operating BGP infrastructure, etc.
But with React it has to be "kid gloves on", otherwise it's shit?
This is perhaps a bigger problem in our industry: lack of experience is not seem as an individual problem, and we blame-shift, blame marketing, blame Facebook, Dan Abramov, trends...
Perhaps we should be saying "React is not for beginners", same as "don't do crypto".
Web dev is special. The industry has spent the last 20 years sacrificing almost everything to make building web sites more beginner friendly. There is an expectation that the "full-stack" (everything between node and react) should be effortless, that is absent from other fields. "one click to deploy" in not a thing in crypto, in embedded or in kernel dev, for instance; whereas it's expected that a junior web dev is productive from day one. That's just normal industrialization, specializing jobs and then making them simpler, starting where the numbers are larger.
Ironically, piling up simplistic technologies have created quite complex houses of cards in places. HTTP itself being the most obvious example of a tech meant to be simple and quick to grasp that morphed into a super complex, ineficient and insecure gremlin of which nobody who is not a specialist (or an AI) has a full picture anymore.
Nobody I ever worked with ever said anything even remotely close to that first paragraph.
"Full stack should be effortless"? What? This is definitely not coming from anyone other than two groups: random HN people with an axe to grind, or people trying to diminish the value of the profession.
Hiring for web is difficult, salaries are historically good, people complain about complexities, including yourself: "quite complex", "super complex", "nobody has a full picture".
Nevertheless: React proves that it's not effortless. There are complexities in there and kicking and screaming saying "it was supposed to be easy!!!" won't change the situation.
"It should be simple" yeah Crypto should be simple as well, so there are no bugs. But it's not.
My management didn’t say it explicitly, but did so through their actions.
A self-service portal was created internally. Every infrastructure team was expected to make services available via this new portal. Timelines were tight, primary jobs were still expected to be done, and the chief architect on the project said creating the API only takes 10 minutes.
To onboard and use this self-service portal, these teams (many of which who didn’t have a single developer, but rather sys admins) were expected to leverage Flask, React, an internal component library (3 conflicting ones with poor documentation which tweaked inputs from 3rd party components and required spelunking into the code to find how to use them), and very strict rules around the Flask API… all in managed repos that required approvals for PRs from a non-responsive team.
This was supposed to be a little week-long side project for a bunch of non-developers, with no training, insufficient documentation, and little support by the person who built the portal.
Needless to say, the project is now dead, but it took about 3 years. During those 3 years, the ideas that “full-stack should be effortless” was the prevailing view, and that anyone off the street should be able to effortlessly plug into the framework that was created.
> Nobody I ever worked with ever said anything even remotely close to that first paragraph.
No, they’re correct. Many people in the web dev community spent a couple of decades there obsessed with being beginner friendly. For example, “Anyone can learn to code”. We pushed back against anything perceived as gate keeping. There was general assembly and other coding bootcamps, to teach beginners web dev. And a million beginner videos. Web dev events at the time were full of beginners. I remember a show of hands once at SydJS. 70% of people in the room had been programming for a year or less. I stopped going, because speakers started catering to the audience.
Other areas of programming aren’t like this. Nobody runs 12 week coding bootcamps to teach complete beginners to build operating systems. It’s accepted you shouldn’t roll your own crypto. And we tell beginners to use Postgres, not roll their own database.
I’m not saying it’s a good or a bad thing. But it was definitely a thing.
> We don't blame crypto for being hard, or demand new frameworks
This is not true. There are innumerable cryptography libraries whose primary reason for existence was to replace or offer an alternative to a library with the same affordances but with primitives that were too easy to use incorrectly. “Maybe we should redesign this knife so it’s hard to slice a finger off” is not unique to web dev
> If everyone is using react wrong, react has a design flaw.
You're asserting that everyone is using it wrong. It's your personal opinion, and a baseless one at that which is based on a personal belief that everyone around you is incompetent and incapable of critical reasoning. It's silly posturing.
In the meantime, React is by far the most popular web framework in production. Some surveys list React with a market share of between 60-75% of all web frontend projects. It's so popular that it even leaked into GUI programming with native GUI toolkits.
It's rather obvious that assertions such as yours are detached from reality. Naturally the dominant framework will also dominate the number of newbies taking their first steps as well as drive-bys. It's also natural that the dominant framework will be targeted by the "aktually" crowd, invested in contrarian self-promotioj comments instead of doing anything constructive.
But to assume everyone is incapable of using something... That takes a lot of self delusion.
> based on a personal belief that everyone around you is incompetent and incapable of critical reasoning.
This is all news to me. I don’t think any of that. Do you make a habit of writing fanfic about other people? You also seem upset that I used word “everyone”. I thought my exaggeration was obvious. How embarrassing for us both.
If you want to make any technical arguments in support of react, I’m all ears. The only argument I can find in your comment is that react is popular right now. But that doesn’t mean react can’t be improved upon. Jquery was once that popular. Then react displaced it, by being better. Soon react will be displaced in turn, by a library which addresses react’s flaws. I can’t wait.
> This is all news to me. I don’t think any of that. Do you make a habit of writing fanfic about other people?
Pointing out the absurdity of someone like you throwing blanket accusations of incompetence is something that's very specific and verifiable. If you have strong feelings about making broad accusations about whole communities, you should pause and pay attention to what you are saying.
> If you want to make any technical arguments in support of react, I’m all ears.
Would you listen? I mean, the main issue with your post is the way you throw absurd blanket statements about a technology, on how either everyone using it is incompetent or the framework is somehow broken.
I mean, does it even dawn upon you that maybe perhaps throughout the past decade there might be people using the dominant framework well, and happen to know what they are doing?
It seems not, by the way you opt to disregard it and tell yourself no, everyone is either incompetent or the tool is broken.
Do you understand the absurdity of this sort of claim? Because it isn't even about React, but the way you feel it's reasonable to throw such blanket accusations.
> But that doesn’t mean react can’t be improved upon.
But that's not the claim you made, was it? Do you need me to quote you back at you?
> If everyone is using react wrong, react has a design flaw. Other frameworks aren't slow by default.
The claim that react is frequently misused was from the parent comment, not me. If you read it, you’ll see I’m explicitly not blaming react devs. I’m blaming react. Vdom diffing makes websites slow by default. And it is totally unnecessary.
Most of your comment is a big ad hominem attack. To answer your explicit question, yes I would find a technical argument much more convincing than a list of made up character flaws. Especially from a stranger, based on a two sentence comment. What a waste of time.
For what it’s worth, I don’t go around thinking everyone around me is an idiot. But your comment does get me thinking.
"You're asserting that everyone is using it wrong. It's your personal opinion, and a baseless one at that"
Their comment does not assert that. They are responding to someone else's assertion, and turning it around to make a completely different point. It's a common form of argument - "if you're saying that the problem is everyone's getting it wrong, then I disagree and the problem must be something else."
Basically the exact same point that you are using to launch a stream of insults!
Saying that it is "silly", "detached from reality" and "delusional" for making assumptions about folk is the most incredible self-own.
If most people can’t use it properly perhaps the problem is in react itself and not most people. React is the only framework that will blame the user for its own mistakes.
I have to step in here to say that, at least documentation wise, this is revisionist history.
The original react documentation is fine, but focused almost entirely on class components. What was there on hooks was either outdated or outright harmful.
It's not until 2023, 4 years after react hooks launched, that the new react docs which focused on them were released.
Yes, the original documentation is what I’m talking about. That documentation was not outdated when it was written. It was excellent compared to the standard at the time. The react doc site raised the bar for what we expect from web framework documentation.
Hooks came much later, long after react was already popular.
> I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior.
I don't really think that React is necessarily the best possible library, but there is certainly more to a UI library than simply compiling out the need for diffing. For one thing, I find JSX to be a relatively unobtrusive addition to the language. It is implemented by a variety of things and is a pretty simple transform as far as things go; basically pure sugar, it's possible to avoid it if you want. It could be better designed than it is, but I think it's at least sufficiently general - it is feasible to say, use an alternate library with JSX, like Preact.
Svelte on the other hand by its nature just simply requires a more complicated compiler step to work and deliver on its promises. That's a trade-off. Whether you think it's worth it is up to you, but presenting it as an objectively technically superior design is disingenuous. Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app?
> The amount of hype around it made it really feel like the next big thing.
We are a really long way away from the hype of React. I would argue that hype stopped carrying React a long time ago. Momentum? Sure, but if something was truly dramatically better, then I think it would have a fair shake at beating out React.
The problem is that the web isn't microbenchmarks and developer experience does matter to some degree, so the trade-offs that seem so good on paper don't always pan out.
I'm not a hater of Svelte. On paper, it is a very elegant idea. However, when I actually tried to use it, I genuinely came out feeling that it was simply not for me, and the benefits it has are not enticing enough for me to continue experimenting. My React apps are not particularly slow or bad at handling huge amounts of data. (One of my apps has no problem handling a file grid of over 1 million items, and in fact, I run into issues with browsers not being able to handle a large enough scroll area long before performance of my React code is a problem. That is good enough for me.)
I should probably be more balanced when criticising react. React moved the state of the art forward when it came out. Compared to the other options we had at the time, it was excellent. But it's not better now. At least not for technical reasons.
> Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app?
Virtual dom diffing is pure overhead. It increases the JS bundle size (react is big). Vdom diffing is really slow. And it's simply not necessary.
I agree that if you make heavy use of comparator functions, react apps can feel ok to use. But most sites don't do that. Look at the new reddit site. Insanely slow and insanely inefficient. They've improved it a lot since the new design landed. But it's still 19mb of javascript or something, and much slower than it should be. Maybe reddit is only slow because they're holding react wrong. But if everyone holds react wrong, it's react's fault.
If you don't like the asthetics of svelte, check out SolidJS. Solid is aesthetically almost identical to react. Solid - like react - only needs compilation if you're using jsx. The difference between solid and react is that solid only executes component functions once. Reactivity is implemented via fine-grained signals. Solidjs apps perform better, because there's no vdom. The default way to use solid is already fast.
> if something was truly dramatically better, then I think it would have a fair shake at beating out React.
Eh. Lots of old technologies are still in use. Most software engineers don't enjoy learning new frameworks every few years. And react still works fine, even if there are other options today. I think solid and svelte are better, but they might not be better enough to displace react for the average web developer.
If you like react, give solidjs a try. It's essentially "react with signals", which I find to be a significant improvement. You get much smaller JS bundles, better performance and better state management. All while keeping a lot of the best parts of react's design philosophy. It's great.
React has an incredible ecosystem, it's almost synonymous with web development. The available render backends alone, namely React Native, are currently unbeaten.
As interested as I may be in the alternatives, they simply don't have this.
I don't think React pretended like they've invented FP, and I've always heard them be pretty open about FRP work existing in the past and them leaning on it.
I mean, prior to React the big Framework at the time was AngularJS 1 - a hellscape of two way data binding.
Talking about one-way data flows was an excellent way to speak to a lot of tortured souls at the time (who had just found out they were going to be forced to migrate their projects to something else anyway due to Google's absolutely insane "we're deprecating this, we'll have a replacement for it at... some point, good luck").
The first time my team uses AngularJS professionally, we spent a month to learn the framework, then the velocity and quality were good. The client reported a funny "bug" that the loading icon didn't show, it turned out the async request was too fast that they couldn't see to loading, a fresh experience for them at the time.
> Google's absolutely insane "we're deprecating this, we'll have a replacement for it at... some point, good luck").
Angular 2 came out in 2016, without the two way binding design issues of AngularJS. Google ended support for AngularJS on Dec 31 2021, so there was 5 years of overlap between the two. They even had migration paths that allowed AngularJS and Angular 2 application code to live together from the initial release of Angular 2.
I haven’t found a front end library I like more than React except maybe Astro.
I didn’t really like Svelte and I am pretty opposed to htmx. It is certainly better than Angular and Vue, though Vue 3 is tolerable. Maybe there are more popular options nowadays but tbh I am not really looking to move from React. I have zero complaints other than maybe the push towards server rendering and partnering with Next.js
React is simple and I like that it feels a bit like FP. I love that I can write just about my entire application in TypeScript with all of the benefits that incurs. It requires some knowledge/discipline e.g. around useEffect.
If you care to use native browser APIs and features you can have lightweight, performant applications that behave well in the browser.
Most devs don’t do this, even with vibe coding. It’s a very easy way to filter for those who care about what they are building.
> I just genuinely think WebComponents are a badly designed API that is weird and hard to use
This was exactly what sprang to mind as soon as I saw the title. I’ve been writing front-end code for over 25 years now, and exactly two things in that entire time have made me miserable enough to think about stopping: Internet Explorer 6 and web components. Every time I try to just “use the platform” it makes me miserable and I end up demotivated and stop working on whatever side project I chose to try again with. And I otherwise like the web platform! I’ve been building with it since there was nothing but the web platform. But web components kill my enthusiasm for it stone dead.
Even now in the age of agentic development, AI trips over all the same footguns in web components that humans do. It just seems like everybody involved has been adding to the standards with “yes, and…” without ever thinking about how it will be used by web developers in practice.
I don't know if that's idiomatic webcomponent or not but that looks unmaintainable, even for such a minimal component, imagine once it grows. It's not separating presentation from state and logic. querySelector need to match classes and elements in the markdown. Mutating textContent is going to run out of sync as soon as you have more than one event source doing the same. Those are all problems that React solve by separating state and only rendering in one path.
That's the best case scenario and already looks like crap. If that looks sane to you, I don't know what to say.
Make it have an initial count via attributes, sync it with the DOM so if the attribute changes the count resets, and make the JS property always match the attribute (and vice-versa) so it behaves sanely. You're in for a world of pain even for something as simple as this.
Plus they're not declarative: you will only make me use innerText-based updates by threatening me and my family.
Plus they only work with JS enabled, while I can use JSX in SSR.
I've worked extensively with Web Components. They suck.
Web components are intentionally low-level, they’re not really meant to be used directly. You should see them more as performant, interoperable building blocks. Have you tried lit?
This circles back to the OP's point: they're not appropriate to use directly, so we layer a framework on top of them (Lit), and now we're just using another framework with one small piece swapped out.
Except for the hyphens, I don't feel any closer to the platform when I use Lit.
You can inspect a Lit component directly in Chrome, it’s just a custom element. No need for a browser dev extension. You can use this custom element from React or any other JS framework. You can also use this custom element in a server-rendered template, no need for any custom SSR setup. Feel close to the platform yet?
If you do this you might as well just write JavaScript without using WebComponents. APIs like innerHTML, querySelector, addEventListener have been around for decades.
Well for one thing, I don't find that to be particularly succinct or nice example. There's a lot going on there:
- HTML in a string. No syntax checks. If you interpolate it, you have to escape manually or you could create trivial XSS vulnerabilities. Your editor will probably not syntax highlight it, making it harder to tell when you break it.
- Manually formatted update logic that is redundant with the string. Not so bad here, but try formulating a practical large component.
- Completely ad-hoc state management, no reconciliation. Again, fine for Hello World, not fine after that.
Using raw WebComponents, your application has to care about all of this on its own and more. You can use templates and slots (which you should) but that makes this even messier IMO and brings back the split that React became famous for getting rid of. We left manual DOM reconciliation, ad-hoc data flow and non-reactive components that manually call a render routine at arbitrary points for a reason: it sucked. It made for buggier, harder to maintain code. It can be done, but usually any decent app will wind up encapsulating patterns into utilities that get reused. And... That's precisely why we want a good library. That's what I want, a library that packages up good reusable patterns for constructing UIs effectively.
And that's exactly my point, which is WebComponents or not, the solution is still basically the same, use libraries. Which begs the question: if I have to use Lit, what is the point of "using the platform"? What is WebComponents doing for me here that React wouldn't be? And in my case, I struggle to see it.
Interoperability? The old way of embedding external components works quite fine. Switching APIs where you pass a DOM node for something to mount into and get back an object with an API to one where you instantiate a component and communicate via properties and events feels like a strictly lateral move. I can't think of a condition where this would be particularly more convenient, but I can think of some where it is actually less. Next.
Isolation? Yes, WebComponents does add tools to provide better isolation between components. For some use cases this is a genuinely useful feature, although it also isn't without tradeoffs (I mean, the flexibility of having things be not isolated comes in clutch sometimes, it's hard to argue this.) But I use React primarily to construct components in an application, where I find this property more undesirable than desirable.
The one thing I thought could be cool with WebComponents is if you could build them in pure HTML when you only needed basic templating, but no: the design they went with always requires subclassing in JS AFAIK.
I could go on and get more specific, but I feel like people will pick everything I just said apart quite enough. I hope I'm at least able to make the case that:
- I do in fact, get the general gist of WebComponents.
> If you interpolate it, you have to escape manually
Well, for some definition of "manually".
If you have untrusted variables to interpolate, you can do
this.innerHTML = html`Hello ${name}!`
Where html is a function that escapes the variables.
The arguments brought forward against web components all seem to fall under "But it does not contain every functionality you want to use out of the box". Personally, I don't think browsers should provide more and more functionality, but rather a good base to build upon.
The great thing with software is you can write your own functions. It would look something like this:
function html(strings, ...values) {
let result = strings[0];
for (let i = 0; i < values.length; i++) {
result += escapeHtml(values[i]);
result += strings[i + 1];
}
return result;
}
The reason react sites are bloated is because there are a lot of things that are easy to do once you have better DX, there is nothing stopping you from making completely static sites with no js (solid-js 2.0 has a whole "htmx-like" mode that lets you have good interactivity even with js disabled).
WebComponents are useful for cases where you want something slightly more integrated than an iframe or want to make a library of small widgets
> Isolation? Yes, WebComponents does add tools to provide better isolation between components. For some use cases this is a genuinely useful feature, although it also isn't without tradeoffs
I hate the guts of every site that uses those. Shadow DOM makes the site hard to operate and fix programmatically from user end.
I mean, these days I can just throw an LLM at it so I don't care as much, but sometimes I want to still do things hands-on. Not to mention, Shadow DOM is often a difference between "simple userstyle/userscript that is allowed at work by security extensions" vs "requiring things that are banned on corporate-managed browser".
I think the problem is not what I don't like about WebComponents individually. The problem is that to use WebComponents, you have to use JavaScript anyway and if it does not do exactly what you wanted, then you're right there, in JS, ready to DIY the problem away.
If WebComponents were purely declarative, I would try harder to use them.
(preface by saying I use webcomponents regularly, I can show you a game that's currently online where they're used extensively)
I don't really understand why people are complaining that this is unmaintainable on the replies to this snippet but there's plenty of things with webcomponents in general that could be better done on the browser side.
For one the innerHTML (or some new method) should be able to reference a `template` directly. If you want to use templates you need to do:
And if you want to use templates then you need to render the templates in a part of the dom that is parsed before this JS is run - there's no way of specifying dependencies for this kind of things - which is a short-coming of the platform as a whole.
One the same topic there's no way of providing an url for retrieval of a fragment that contains templates and have it parsed directly and available to subsequent JS if you could do:
`` or doing `fetch("/my-endpoint/returns-templates.html", {DOCUMENT_ID="MAIN_FRAGMENTS")` would parse the result and make it available to the browser engine then you could have on subsequent JS:
The platform APIs were terrible. React wasn't "more fun"... it just made it possible to do things with the platform that were extremely difficult and cumbersome to get working reliably with platform APIs alone.
To me, web components were an incredible idea poorly implemented. Most of the minimal adoption happened on top of frameworks like Lit that wrapped WCs to try to make the dev experience tolerable.
In urban planning they have a concept called "desire paths" where if you don't put sidewalks and pathways in the right places, people invent their own. I feel like the web community has spent a lot of time and effort patching the platform.
Now credit where credit is due: it has very much improved. And modern standards means it really is time to re-evaluate where and when you need these patches. But don't write off all that annoying and painful effort people put in to trying to making the platform deliver it's promised potential just to "building it yourself is more fun".