Comment by toddmorey
8 hours ago
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".
> "In urban planning they have a concept called "desire paths""
If you're wondering what that looks like, people post pictures of them found in the wild on Reddit:
https://reddit.com/r/DesirePaths/
> 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.
from <https://en.wikipedia.org/w/index.php?title=Desire_path&oldid...>
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).
> The platform APIs were terrible.
In what way?
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.
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.
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.
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.
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.
So you could do:<div id="myname">my name <div>
Then do myname += "John";
Or <div id="a">42<div><input id="b" value="123">
Then do a = a * b / 2
That is cool. Reactive without song and dance
> In what way?
State management.
I have to track what items I want to remove, hide, show, alter, etc. in each handler.
That is a cumbersome mental model, which is why React, Angular, Vue, Svelte and every other web framework calculate that automatically for you.
To be clear: I don't necessarily begrudge the mutation APIs; but there's no way I'm going to use them directly for anything except very simple things.
> 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.
1 reply →
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.
> In what way?
For starters, you can start by checking https://caniuse.com .
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'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 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
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.
> 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.
The "fun" angle slots in perfectly with the other parallel false narrative about the devs who hate AI.
> building things yourself is just more fun
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
> 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.