Live data from Hacker News

Web Components Eliminate JavaScript Framework Lock-In

jakelazaroff.com

81–90 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#81
No they don't eliminate anything. Framework never HAD to have a lock-in. They WANT to have a lock-in. They want to have a flashy site, with short sexy demos, and to give you slogans to repeat, and create in you a sense that all your struggles as a developer were caused by %PREVIOUS_TECH%, that you've been wronged and now you get to be a part of a revolution.

And they want to CAPTURE you. This is why 99% of frameworks have a deliberately monolithic and isolating architecture, where it's all in, or all out. You don't want to miss the revolution are you? Are you stupid? Of course you're not stupid. So now your apps are locked in.

And Web Components won't stop frameworks from finding highly specific ways to be "useful" in a way where you need to do everything in them.

The solution is to know how to architect your app and stop believing marketing BS. Otherwise you'll keep fleeting to the Next Big Thing (tm) and never realize why it always ends the same way.

Re: Web Components Eliminate JavaScript Framework Lock-In

#82

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…

that's how it is if you're using high-level react components or web components, it's just an XML-like layout, user-friendly. What the article is showing is their low-level implementation, but as a consumer you can just import and use them

Re: Web Components Eliminate JavaScript Framework Lock-In

#83

In case anyone was wondering, JavaScript per se isn't replaced at all. All mentioned examples still use event listeners, querySelectorAll, ES modules, and what not. Most importantly, you need to subclass HTMLElement and register your custom element using JavaScript in the first place eg: class MyElement extends HTMLElement { } window.customElements .register('my-element', MyElement) (the hyphen in the name is idiosyn…

For me, being able to offer my library as a web component is kind of neat. Sure I can ask users of my library to import it then query select math inputs, then apply my library on these, and remember to apply it also on DOM change. import lib from "/path/to/my/lib.js"; for (const target of document.querySelectorAll(".target")) { lib(target); } // TODO: Watch for DOM change and apply lib. Some Input Or I can simply ask…

Or you can do a little more work in your lib for your users and offer:

   
     import lib from "the-lib.co.uk";
     lib({ target: ".target" });
    
If your users might not want you to watch the _whole_ DOM for performance reasons:

   
     import lib from "the-lib.co.uk";
     lib({
        target: ".target",
        root: ".all-the-targets-show-up-here"
      });
    
And if your users might already have a mutation observer in their apps:

    
     import lib from "the-lib.co.uk";
     lib({
        target: ".target",
        observer: theAppObserver
      });
    

Re: Web Components Eliminate JavaScript Framework Lock-In

#84
post #35

Earlier quoted context omitted.

React “won” because Facebook spent three years flying devrel to every web conference on earth to persuade other people that Facebook’s problem space was applicable to small agencies. Back in reality, React is slow and massively overbuilt for the majority of stuff that most people are building. If you played around with Web Components a long time ago then you probably played with the v0 spec, which was somewhat differ…

> React “won” because Facebook spent three years flying devrel to every web conference You do know that Google sponsored and ran things like Polymer conf? That it builds lit? That Google's devs have literally overrun and overruled most web specs committees? That Google has spend hundreds of millions of dollars promoting Web Components? And yet here we are.

I'm glad to have read this today. I'm going to look into how I could use web components in my next side project. I'd really like something that worked easily with SSR and client-side, maybe using htmx.

In retrospect, I think I avoided web components because of Google and their aggressive dev relations pushing Polymer. It felt so one-sided that it didn't seem like a web standard. It felt more like a Google "standard" like NaCL. Having to ship Polymer to support non-Google browsers felt even more heavy weight than React.

Re: Web Components Eliminate JavaScript Framework Lock-In

#85

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…

I think you are talking about web components.

Even in the old desktop world someone had to build the button widget (and all the others) that let you just throw stuff together in MFC or Swing or whatever.

Same today - someone has to build the web components in order for us to declaratively use them as high-level Lego.

Trouble is, there is no real high-level "general purpose" library of components beyond the core HTML elements (they'll get you a long way but there are notable things missing that we expect from apps, e.g. toolbars, menus, tab strips etc), and then the probably reason for their not being a general high-level library is that everyone wants something special for their websites (because historically websites have always allowed a lot of design flexibility, way more than your typical win32 app ever did for example).

I have several times really wished to have some solid "desktop style" components to use for things like menus, tool bars etc. That would make prototypes in electron/neutralino/tauri way way way faster to do.

Re: Web Components Eliminate JavaScript Framework Lock-In

#86

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…

I do front end stuff for a living and have been in the javascript space for several years. I do other backend development as well and I can't see why people think like you honestly.

Most other GUI libraries is in a much worse state than front end web dev. That is probably also the reason why people use front end tech to make native apps today, because you can customize and make apps much faster than in basically any other way.

I think front end gui development is very easy today and very powerful as well and we have progressed a lot. Making stuff with web components isn't event that hard and if you want you can just use one of the many available syntax sugar libraries that exist like Lit and others.

Re: Web Components Eliminate JavaScript Framework Lock-In

#87
post #43

Web components are a half-baked solution. It only becomes useful with another framework (even if it's very lightweight) like lit. At which point I might as well use vue/react/svelte since I am already brining in a library. Tech like preact is really lightweight as well, and given the popularity of react, is enough to offset any benefits web components have. I would really like it if we reached a point where a web pro…

"half-baked solution"

Can you elaborate further ? Anything that removes dependencies from external libraries is a huge plus for me so I am curious as someone who is not great at JS.

Re: Web Components Eliminate JavaScript Framework Lock-In

#88
post #16

I've been fought by people insisting that if we're using a framework, we should be using it for everything, if it has it, even when both agree that doing it natively is actually less cumbersome. All that in the name of consistency. I think middle ground is a good solution. On topic: I don't think WebComponents are going to "make it" until someone builds a nice framework on top of them. React, Vue, Svelte, etc. solve…

> I've been fought by people insisting that if we're using a framework, we should be using it for everything,

Remember the definition of a framework: a framework is just a library that does not play well with others.

Re: Web Components Eliminate JavaScript Framework Lock-In

#89
post #7
post #5

I've seen the entire industry move towards React/Angular type frameworks and it's invariably been a really bad thing. Large projects end up with front end specialists and backend specialists and very few actual full stack devs. What ends up happening is that no one person can do an entire feature anymore. I'm all for web components!

This is not my experience at all. Why can't a full stack dev know react or angular?

GP didnt say that. They said lot of devs become "front end" or "back end" specialists which means that they cannot do full stack. Full stack devs knowing React is fine. The problem is that most "React devs" don't know full stack and most "backend devs" don't know full stack.

Re: Web Components Eliminate JavaScript Framework Lock-In

#90
post #39

Earlier quoted context omitted.

"Lots of people are still using it, but nobody can quite remember why." I can remember why. This, and every other article I've ever read arguing to replace React with Web Components, completely misunderstands the point of React. It isn't about JSX. It isn't about encapsulation. It isn't about reusability. It is about enabling a design pattern where *the user interface is a pure functional transformation of the applic…

With modern browsers, " completely re-output the entire user interface on every state change" is kinda viable. I recently wrote a trebuchet simulator app (hastingsgreer.github.io/jstreb) without a framework. instead I wrote a "rebuild UI" function that I call on every new state, and the user experience is super snappy

It doesn't seem to work at all in Chrome, so maybe not the best example.
Post reply on HN