Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Components Eliminate JavaScript Framework Lock-In

jakelazaroff.com

Post reply on HN
Print view View original

161–170 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#161

Post by josephg »

yCombLinks wrote: post #141
shortrounddev2 wrote: post #96

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

Given how important the web’s deploy story has been for its success, I’m surprised we haven’t seen more zero deployment application platforms / prototypes appear. Docker is an attempt at something similar on the server, but docker images are huge and docker still separates its docker fetch and docker run steps.

Maybe part of the problem is that the web is the only platform where people obsess over the size of deployed artefacts. Websites are certainly getting bigger, but they’re still an order of magnitude smaller than the average snap package or iOS app.

Re: Web Components Eliminate JavaScript Framework Lock-In

#162

Post by [deleted] »

switchbak wrote: post #69

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…

[deleted]

Re: Web Components Eliminate JavaScript Framework Lock-In

#163

Post by EMM_386 »

switchbak wrote: post #69

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…

> Something something get off my lawn...

While I agree, this is what we're stuck with. I have 25+ years of experience. Before JavaScript and CSS existed.

Now? I'm on an Angular 16 (moving to 17 SPA).

Worked with almost everything else in between.

I had all the same feelings. "We're doing what with JavaScript now??".

It turns out, it's not all that bad. TypeScript is pleasant enough, for me Angular is logical, and sure at the end of the day it's all just HTML/JS/CSS but what can you do?

We're stuck with it, unless WASM totally up-ends the entire thing and we have JIT'd languages like .Net and Java running on the client ... which is ...

Well, I'm not even sure what that is anymore. It's not HTML, JS, and CSS!

Re: Web Components Eliminate JavaScript Framework Lock-In

#164

Post by jacobsimon »

brlewis wrote: post #150
switchbak wrote: post #69

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…

Not OP but at the end of the day, custom components like this still have to be rendered down to primitive HTML and CSS, and are plagued by all sorts of browser-specific issues and conventions that make higher level abstraction way more difficult than they need to be.

As a random example, HTML specifies that clicking a `` inside a `` automatically submits a POST request to the current URL. We can't change that because it will break a lot of webpages that rely on this default behavior, so now every component system built on top of or needs to prevent the default browser behavior, and there are so many more examples of things like this.

Re: Web Components Eliminate JavaScript Framework Lock-In

#165

Post by deergomoo »

agloe_dreams wrote: post #80
switchbak wrote: post #69

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…

The problem is CSS. CSS is so freaking complex with millions of possible outcomes. https://www.w3.org/Style/CSS/all-properties.en.html Building a declarative UI that compiles to that sort of declaration means building that from scratch. We do currently work like that though. React isn't that far and web components built into an element of that.

I wonder how different things would look if you could opt out of the cascade for CSS. It's great for documents but signifcantly less so for "apps", where the widget is the widget and by-and-large should not be affected by the other bits of interface it's inside.

I think that's why frameworks like Tailwind etc. have got so popular -- they're much closer to the traditional native application way of styling. You set all the appearance details on the component and then you reuse the component, styles and all.

Re: Web Components Eliminate JavaScript Framework Lock-In

#166

Post by troupo »

spankalee wrote: post #48
troupo wrote: post #29

Earlier quoted context omitted.

> lock-in as low as possible. As in: - reactivity. Specific to lit - declarative templates. Specific to lit - SSR. Specific to lit. - context. Specific to lit. - tasks. Specific to lit "minimal" and "low lock-in". Please do not hesitate to call it a framework. If you call React a framework, then lit is definitely a framework.

Lit's features are internal to each component (except context which is being developed as an open community protocol with the Web Components Community Group) and there is no coupling between components written in Lit. So you can port from Lit to something else component-by-component. Lit is also modular. The template library, lit-html, is usable independently and used by other web component and non-web component libr…

This is just splitting hairs in an attempt to pretend that lit isn't a framework (or framework-like lib), or that it's somehow unopinionated, or that it somehow prevents you from lock-in.

Almost all of the things you listed are specific to lit, and lit only. So, people who will develop with lit will be locked in to lit. Because it's not like you can just pop the code you wrote with lit into stencil or ionic, and will just work.

> So you can port from Lit to something else component-by-component.

I personally saw a huge project ported from Angular to React basically doing the same. It's not a testament to lit. It's what people have been doing since time immemorial.

Re: Web Components Eliminate JavaScript Framework Lock-In

#167

Post by josephg »

mardifoufs wrote: post #144
ecmascript wrote: post #86

Earlier quoted context omitted.

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.

I feel the same after playing with SwiftUI and UIKit on iOS and trying to make something simple like a text editor with a hideable keyboard. The whole platform feels half baked, with various overlapping features that each have serious, barely documented drawbacks and bugs. “I’m getting a warning about my constraints being defined badly” “oh just ignore that - you can’t make it work without that warning”. “Everything in my project looks the same as the example but mine doesn’t work” “Try deleting your constraints and re-adding them. Sometimes Xcode is just buggy like that”. “I tried but Xcode hard crashed”. Etc.

The web feels downright cohesive, stable and well documented in comparison.

Re: Web Components Eliminate JavaScript Framework Lock-In

#168

Post by megaman821 »

jacobsimon wrote: post #142
mattlondon wrote: post #85

Earlier quoted context omitted.

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…

I am not sure it would look that different. It would be more consistent with terminology. Things like SwiftUI and Jetpack Compose look a lot more like HTML and CSS than their predecessors, and there is nothing forcing them to go in that direction.

The biggest difference between other major platforms and the web, is that the web doesn't come with a default UI framework. The primitives for building UI on the web are pretty good though.

Re: Web Components Eliminate JavaScript Framework Lock-In

#169

Post by aegypti »

paulddraper wrote: post #125
usea wrote: post #119

Earlier quoted context omitted.

They said things should be better than they are, not that we should go back to the 90s or even use it as inspiration.

Oh well, yes, it would be nice for things to be better than they are. (^ feel free to copy-paste that to any HN thread)

It would be nice for conversations to be kinder, less snarky, and more curious. Could even edit out any swipes and internet-style cross examination as well.

Re: Web Components Eliminate JavaScript Framework Lock-In

#170

Post by whartung »

ecmascript wrote: post #86
switchbak wrote: post #69

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…

> Most other GUI libraries is in a much worse state than front end web dev.

I'm certainly not going to suggest you're wrong. But I would like a sincere comparison between JavaFX (because I sorta know it) and "the web".

Maybe its unfair, since the Web is "just the DOM", an empty vessel many of the other techs are built upon, which is why there's so many options.

I'm not a front end person, by any means, and have been striving to make things work with FX. I mostly "get" FX, how it does things with its containers and layouts and properties and bindings and events and UI thread. It has CSS, I mostly don't use it (better living through gray!).

The web, honestly, intimidates me. It intimidates me with its vast variety, its complex build processes, the apparently galaxy of dependencies and tools and what not. Cross browser stuff terrifies me. And maybe that's the wrong reality, but that's the impression I get.

I'm managing to Forest Gump my way through FX, but I have a Java background.

Post reply on HN