Live data from Hacker News

Web Components Eliminate JavaScript Framework Lock-In

jakelazaroff.com

91–100 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

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

As someone who just had to answer this for my startup, the value of React is that it's robust and immensely hire-able. If you're looking for frontend developers, the one thing you can always expect is at least passable React knowledge. Everything else, even if it has a better technical fit for your project, is likely riskier for your organization.

Some of the most productive teams I've worked with (not as a dev) have been for tech stacks I personally don't enjoy using. Java, .NET/C#, React, etc. In practice, I'd rather quickly hire a local senior Java/C# dev for 1X than scour the interwebs to hire a Golang dev that requires relocation for 1.5-2X.

If I was going to learn a language though, I'd probably learn Golang. Their rate is so much higher.

Re: Web Components Eliminate JavaScript Framework Lock-In

#92
As far as I can see, web components take only strings as arguments. That alone disqualifies them from being a serious component framework. I've looked at them only for a short time last month, because I was excited about a web native component framework, but they provide basically nothing I would expect from such a framework. They are not even in the same arena as React.

Re: Web Components Eliminate JavaScript Framework Lock-In

#94

Earlier quoted context omitted.

Your criticism was the biggest one of React when it came out -- mixing view code with your controller code. Big no no. Everyone loved the MVC pattern (model-viewer-controller where you separate these things in different places) and what React did was a big no no. But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. In other lan…

> But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. It's not actually, with HTTP/2. The separate requests are all multiplexed over the same connection, often with prefetching, and compressed together so that there's little to no overhead vs. putting them in the same file. This illustrates a common failure point for web frame…

Multiplexing requests doesn't help when there is a logical dependency between them, e.g. some javascript code needs to download and then execute just to determine what template files it needs to subsequently download. That can't be parallelized.

Re: Web Components Eliminate JavaScript Framework Lock-In

#95

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…

What if you could have the best of both worlds? What if you could use JSX templates and use standards-based web components? You can. Here's an example of using a web component in a JSX template (look for zx-listeditor): https://github.com/wisercoder/uibuilder/blob/master/WebCompo... Here's how the web component is implemented, also using JSX: https://github.com/wisercoder/uibuilder/blob/master/WebCompo...

Also, the entire OP article is demonstrating this... I'm not sure many of the comments here actually read it...

Re: Web Components Eliminate JavaScript Framework Lock-In

#96

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'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

Re: Web Components Eliminate JavaScript Framework Lock-In

#98
I like the idea of web components, but really dislike html and js being intermingled (the reason I don't like React/JSX). In web components its even worse because its HTML as a string which means it has no validation and isn't syntax aware. I much prefer the angular approach where you have separate css,html,ts files, and would love a web component framework that could work similarly.

Searching for this I found some kinda hacky solutions on Stack Overflow which use fetch to load html/css at runtime.

Re: Web Components Eliminate JavaScript Framework Lock-In

#100

As far as I can see, web components take only strings as arguments. That alone disqualifies them from being a serious component framework. I've looked at them only for a short time last month, because I was excited about a web native component framework, but they provide basically nothing I would expect from such a framework. They are not even in the same arena as React.

> They are not even in the same arena as React.

This is 100% correct. I think a lot of the disappointment about web components comes from a mismatch in expectation between the spec writers and what people when they think "components".

Web Components allow you to make new HTML elements. That is, you can make new kinds of DOM nodes out of other DOM nodes. This is powerful, but the resultant API is still a DOM-level API, and not a full templating system like React.

On the other hand, because all these templating systems (React, lit, svelte, etc.) ultimately boil down to a series of DOM manipulations, this allows you to create a kind of element that can be plugged into all of these systems.

Custom elements are a lot more akin to the C ABI. Than a fully featured framework.

Post reply on HN