Live data from Hacker News

Web Components Eliminate JavaScript Framework Lock-In

jakelazaroff.com

141–150 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#141

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

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

Re: Web Components Eliminate JavaScript Framework Lock-In

#142

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…

There are certainly lots of great component libraries out there for various frameworks that help with this, but I agree with the parent comment that it's still not the kind of progress we should have had by this point. I think it's unfortunate that we have to stick to HTML/CSS as the foundation for everything to maintain compatibility and accessibility, but that's how the web works I suppose. If we were to design the web from the ground up today based on what people use it for, it would look pretty different I think.

Re: Web Components Eliminate JavaScript Framework Lock-In

#143
Please remember that Web Components are much more akin to an ABI for web projects and not a full-featured framework.

Any web component easily plugs into React, svelte, lit, etc. Existing components written in those frameworks can pretty easily be wrapped in a web component. It's a common base-layer we can all use.

If you attempt to build a web app using just web components and no libraries, you'll quickly find that you're doing lots of manual DOM updates (no templating engine) and lots of manual state management (no data management API).

As an ABI, it's wildly successful. It does, in fact, just work. It's just very low level.

Re: Web Components Eliminate JavaScript Framework Lock-In

#144

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…

Exactly. I'm starting to understand the push for web UI now that I've started to use qt for a small GUI. I'm sure qt is good for some type of apps. But for my smaller scale project where the graphic interface is not where we want to spend most of our dev time, I'd rather take javascript/react at this point.

Re: Web Components Eliminate JavaScript Framework Lock-In

#145

Earlier quoted context omitted.

Interesting. Yet I find that React HTML—that is not actually HTML, but a look-alike, a dialect if you want—to be exactly what I dislike about React. That is because it still encourages people to put JS in their HTML in their JS in their ... And we are almost back to crazy PHP land of "I treat HTML as a string and blend everything together into one big lump.", instead of using a templating engine, that treats HTML in…

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.

Most projects that I have been involved with have some kind of build system that does all sort of magic. It should be possible to include the template in the JS file during the build process

Re: Web Components Eliminate JavaScript Framework Lock-In

#146
It's not all that shiny. Web components have global names (you should pretty much apply a prefix/namespace if you want to work with others) and managing multiple version of the same component in the same page is an issue in any non trivial codebase (either use a different name per version or fix all breaking changes at once during the upgrade, unless the draft about scoping web elements became standard https://github.com/WICG/webcomponents/blob/gh-pages/proposal... )

Re: Web Components Eliminate JavaScript Framework Lock-In

#147

Earlier quoted context omitted.

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.

Ah, global variables in modules have to be declared with var etc in chrome, but firefox and safari let it slide if you just assign. Fixed, but I guess I’m gonna have to set up a test suite

Re: Web Components Eliminate JavaScript Framework Lock-In

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

> HTML(Div(Strong(text))) is terrible*

> This is what JSX compiles to behind the scenes.

Oh, it is much worse than that. By classic default it is:

    React.createElement('div', { /* props and attributes ... */ },
      React.createElement('strong', { /* ... */ }, text))
Recent updates and other JSX frameworks simplified the name of `React.createElement` to just `jsx` or `h`. I've seen projects that manually write `h` calls like that everywhere, and it is indeed terrible.

(Source: I've just completed a bunch of crazy TSX work and got pretty familiar with the compiled forms.)

Re: Web Components Eliminate JavaScript Framework Lock-In

#149
post #78
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…

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.

Re: Web Components Eliminate JavaScript Framework Lock-In

#150

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…

From the article,

   
     
   
This is talking declaratively at a high level about the kind of interface to render. Lots of component frameworks look like this example. Thinking "how sad it is that we haven't progressed beyond the state of gluing together low level divs and spans" sounds like a preconceived idea rather than a response to this article.

By the way, I come from mid-80's BASIC on 8-bit home computers. You get off my lawn.

Post reply on HN