Live data from Hacker News

Web Components Eliminate JavaScript Framework Lock-In

jakelazaroff.com

191–200 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#191

Earlier quoted context omitted.

If you use a good rendering library, like lit-html then (at least in vscode) you get very nice syntax highlighting, completion and validation: html` `

I was actually just looking at that after posting this (lit is new to me). That's a pretty cool solution. I'd still prefer an option to have the html in its own file, but that is just my taste. I know a lot of people feel exactly the opposite.

Maybe a bit pedantic - but I prefer using lit-html, not lit.

Lit is a bit too "frameworky" for my taste, I generally just use vanilla classes that extend HTMLElement and have a render function that renders the lit-element template to the light dom.

Something like:

    import {html, render} from 'lit-html';

    class AppComponent extends HTMLElement {
      connectedCallback() {
        this.template = () => html``;
        this.render();
      }
    
      render() {
        if(this.template)
          render(this.template(), this)
      }
    }

    customElements.define('app-component', AppComponent);

Re: Web Components Eliminate JavaScript Framework Lock-In

#192
post #149
post #78

Earlier quoted context omitted.

React isn't legacy technology. What a perfidious statement. I can easily justify the reasons I still use React, but I can't be bothered writing it out every time some gimmicky front-end tech hits HN.

Every alternative to React roughly fall into one of 3 categories: 1. Go back to reactive templates. 2. Sprinkle directives over plain HTML a-la early Angular 1. 3. HTML over the wire. All those ideas pre-date React and React won against them back in 2014.

There is also

4. The React model but with compiler support to improve the ergonomics (and with better static checks).

Re: Web Components Eliminate JavaScript Framework Lock-In

#193

Earlier quoted context omitted.

I'm less cynical about web development. Lots of software engineers bemoan writing web interfaces and pine for the days of native GUI development, but web won because it's extremely accessible to people without CS degrees. There just isn't a good native framework that's as forgiving and easy to learn as HTML, JS, and CSS. I think gtk is pretty decent though

Hard disagree, web won because of the deploy story. Users don't have to install anything. Html and css is a terrible API for app layout, because it wasn't designed for that

> Html and css is a terrible API for app layout, because it wasn't designed for that

And yet it's so easy and forgiving that millions of 13 year olds learned it for their myspace and tumblr pages over the last 15 or so years.

Somehow, despite all the CS graduates and 20 year software engineering veterans bemoaning it, more and more people learn HTML, CSS, and Javascript every day while the number of people learning native GUI development struggles to keep up or outright fades away. I truly believe that most software engineers don't understand what ergonomic software or programming languages look like. They're blinded by their expertise

Re: Web Components Eliminate JavaScript Framework Lock-In

#194
post #74

Earlier quoted context omitted.

As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do t…

100% agree. Like you I’ve been building sites since the mid 90s and always was pulling my hair out at all the convoluted ways we would attempt to handle HTML in these JS frameworks. As someone who knows HTML and CSS and vanilla JS, as soon as I saw React all I could think of when I saw JSX was “finally!”. Yeah it’s another framework with its own quirks but it lets me think about the UI in the same way I’ve thought ab…

I remember using PHP and CodeIgniter in the mid-2000s. IIRC PHP had that template-interpolation thing solved since the first day: You populated your Views with PHP code.

Re: Web Components Eliminate JavaScript Framework Lock-In

#195
post #39
post #6

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to buil…

"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…

To add to that, one of the (largely justified) criticisms of React is that it, or at least the way it is commonly used, can have negative performance impact, and thus negatively impacts user experience. However, user experience is broader than just performance, and critically also includes that the application has as few bugs as possible and works well in the first place, and I feel that the model you describe greatly helps there, and it makes unit testing and strict static typing feasible to boot.

(Admittedly, these benefits haven't been thoroughly researched, as far as I'm aware, so it still mostly relies on gut feeling and experience.)

Re: Web Components Eliminate JavaScript Framework Lock-In

#196
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…

> 4. Observables (Ember, maybe Angular 2+?) Don't forget Knockout which was the OG. You can also make the case that Svelte, Vue, and Qwik all are different takes on Observables (at least as much as Angular 2+ is) all with more or less magic and more or fewer escape hatches from Observable best practices to imperative(-looking) code. I got a "What if we did Knockout but with with the compile-time benefits of TSX and P…

I remember 2012, ASP.NET MVC Razor pages, combined with individual page knockout Js. Actually worked quite well. Infact that system is still running for that company. Sure we could have made a angularJS 1.0 SPA at the time, but knockout meant we only had to apply the pattern to the pages that needed it.

Re: Web Components Eliminate JavaScript Framework Lock-In

#197
post #6

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to buil…

Would anyone pick react these days, if they did not already use it/know it/think-it-is-what-they-should-use-because-everyone-else-does? I think that is the point. The original "pitch" for react in my mind was that it was lightweight and simple. I don't think you can say that any more, and I think a lot of rough edges have been identified (e.g. hooks fiasco, app state management, dependency-hell etc to name just 3) af…

It's as you describe, but also the spec and browser support landscape has changed.

Re: Web Components Eliminate JavaScript Framework Lock-In

#198

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" I think because it trojan horsed itself as being "just the view" but then morphed into a hand-rolled kitchen-sink solution, and inertia kept people around.

Accurate quote. Source: I was there.

Re: Web Components Eliminate JavaScript Framework Lock-In

#199

Earlier quoted context omitted.

For sure. SSR is one thing that React has done well, and that Web Components don’t have a great story for.

I'm pretty sure that just shipping the HTML works. The nice thing if I use web components is that I can just have my backend create HTML that uses those components. I can create elements whatever way I want on the backend or the front-end so long as it is HTML.

Yes, if you stick to custom elements. If you want shadow dom encapsulation then you’ll need to wait for declarative shadow dom to turn up in all browsers.

Re: Web Components Eliminate JavaScript Framework Lock-In

#200

Earlier quoted context omitted.

Author here — I'm not sure what you mean by "lock you into one framework per component". The point is that you can encapsulate framework code within web components, not that every component you write should be a web component. Let's say you're writing a Vue app and you really want to use a library that's only available as a React component. You can wrap that library in a web component and use it in your Vue app just…

That sounds awful to be honest. A recipe for total loss of standardization within an org.

Any sufficiently large org already has all the technologies.
Post reply on HN