They should probably start with native browser apis for DOM manipulation, and web components. And then explore the current landscape for options that alleviate the pain points discovered while learning (e.g. Lit is nice for declarative reactive components). All the while being conscious of the tradeoffs.
That's a fine idea if you're not expecting the team to grow beyond the original author(s).
It's a pretty terrible idea if you're going to do it in a business setting, as the original author(s) will always be it's Achilles tendon, making the project a liability before it even goes into production.
Most projects use react or angular because it makes onboarding new members easier, and these frameworks really aren't as bad as some people on hn claim.
How much have you researched this space? Do you know of companies that are successfully building their products with web components? Hint: these would include Adobe, Microsoft, RedHat, and GitHub. How do they onboard new members to their terrible setup, one might wonder?
> How do they onboard new members to their terrible setup, one might wonder?
I can't speak for the specific companies you listed, but the number of times I've heard someone sing praises about a homegrown UI framework at their place of employment is approximately zero. The sentiment expressed about those is generally hatred and agony.
That's not to say it can't be done well, but most don't. Also, a company being able to hire/onboard engineers does not imply that their onboarding process is smooth, or that their house-made framework is well designed.
I am deeply puzzled by both your and the sibling comment, which suggest that the only way to go is to build a framework. To advance such argument, especially when comparing something to React, is to forget that:
- React also for a long time was advertised as a view-layer library for creating UI components, not as a "framework".
- There've been numerous debates in which advocates of Angular or Ember were suggesting that because of such inherent lack of structure, React apps were always different between projects, as opposed to the clear conventions used in Angular or Ember project. This did not deter React supporters and did not prevent React from succeeding.
- React was created as a library when web browsers did not have a standardized component model; just as jQuery was created as a library when browsers did not have a unified way of interacting with the DOM. Years have passed, and web browsers have matured to the point when a native component model has become a reality. You do not need to home-grow a framework in order to take advantage of them.
Problem is, Web Components still don't support reactivity and passing complex props, so you need a framework anyways, and at that point it might as well be React.
I've seen people do abominations like each web component is a React root, message passing systems on the side for complex objects... better use React directly
> Years have passed, and web browsers have matured to the point when a native component model has become a reality.
This is not true at all, at least not enough to be able to completely replace React (or any frontend framework) with native APIs. You still need some sort of high-level abstraction(s) to tie everything together.
Was going to say the same as sibling @ReadTheLicense, but further Web Components were started before React so the idea that they are more modern isn't true.
It does help to have used the basics to understand the benefits of a full framework. But learning things bottom-up isn't suitable for everybody.
As for web components, I'd rather not. Nothing about it works for me. Not the class-based decorator syntax. Not the CSS scoping. Not the use of custom elements. The prop syntax is awful and the paradigm just feels cumbersome.
I work with Angular (its component model is close enough) and have read the Lit docs. Never will I choose that option.
