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.
The good thing about the vanilla APIs is that you don't have to do knowingly broken things. The APIs themselves are stupid fast.
When I need to store state I put all the state goodness into a single object. Just one object, and its generally small even on extremely large applications. I update that object as often as the user interactions dictate. I let the needs of the application determine where that object is written: localStorage, a file, a database, or something else. I only ever need the state object when the page loads or reloads, because I am not doing things some weird framework way.
Built-in things are represented as data structures, so they are inherently as extensible as your programming capabilities allow.
> There's a reason popular frameworks are popular.
Because that is what employers dictate for hiring. If you want to work you have to do the stupid things for newbs. Framework popularity also does not indicate other positive qualities. 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.
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.
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.
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'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
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.
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.
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.