Live data from Hacker News

The Failed Promise of Web Components

lea.verou.me

181–190 of 235 posts

Re: The Failed Promise of Web Components

#181

Earlier quoted context omitted.

Just to set the record straight, here's why I mentioned it: I like her writing style. She writes in a pithy vernacular that belies her educational credentials. She writes like a cranky old man (takes one to know one). I think we need more writing like that, as opposed to the usual buzzword bouillabaisse that makes up a significant chunk of the tech WordSphere. When someone writes like that, it can be easy to dismiss…

I empathize with you in strongest way possible. I think we all should stop being offended so damn much. I don’t know why I felt the way I did but you’re right - take it easy, we need to be a bit more flexible and allow for room of interpretation. Sorry I felt that way in my initial comment. I think the offending word was “def”. > This lady has a Masters from MIT. She probably knows her way around things Sounds much b…

The whole sentence? I couldn't even find a part of it other than the sentiment and "flugelhorn"

Seems like a coincidence especially since bashing on all the steps required for modern web development isn't a new idea.

Re: The Failed Promise of Web Components

#182

Earlier quoted context omitted.

caniuse statistics say that ES2015 module support has reached something like 92% of browsers: https://caniuse.com/es6-module

The goal keeps moving though. If I need to process TypeScript files into JS to load them in the browser, why stop at modules and not just go ahead and link and tree shake and all that too? Maybe things will settle down and browsers will actually run the code that web developers are writing, but the way things are going I don’t see that ever happening. Likely we’ll end up coding in any language and downloading WASM.

people do have other expectations like typescript. but whether we can meet the expectation of "this code should be a module that i can use or you can use or they can use" is much closer to the obvious "what-it-says-on-the-tin" definition of modules. and currently, without a lot of rewriting the module & it's dependencies, that goal is effectively impossible.

i'm not worried about fancy or more. i'm worried about the base case. and right now the base case is a no-go. it doesn't work. es6-modules have not brought modular modules to the web. it has failed to do it's most important goal.

can people with no tools, with no type-script, are they capable of using modules? if they require a bunch of tools to do so, i feel like the answer is that the web does not have modules. systems like import-maps begin to give consumers of libraries ways to assemble dependencies in a way that they can take off the shelf modules & plug them together on the web. until we see something like this, some way of sharing modules, the web platform does may have the language feature, but it has none of the benefits of modules that software-developers require to build systems atop even-mildly complex module graphs.

Re: The Failed Promise of Web Components

#183
post #166

Earlier quoted context omitted.

The web components in Chrome and Edge are both implemented in the open source Chromium project. So, it is free for all to read, use and modify as they wish (in accordance with the terms of the license https://chromium.googlesource.com/chromium/src/+/master/LICE... )

Here is running campaign to Open Source Sciter: https://www.kickstarter.com/projects/c-smile/open-source-sci... By donating there you can help to make it happen, your move? That will be real Open Source. Edge and Chrome are not Open Source, they are users of it.

Holding open source hostage to a $100,000 goal doesn't sound like "real" open source to me either. And you're still going to offer it under either GPL or paid commercial licenses. Chromium is released under a BSD license which is a lot more permissive.

It's totally fine to make money but when people have valid critiques you shouldn't turn around and try shaming competitors about something that you're not even doing.

Re: The Failed Promise of Web Components

#184

This post is needlessly snarky, but I don't disagree with the basic premise. Here's what killed web components: lack of native databinding on the web. That's the reason the standard is useless without JS. Any modular, dynamic, modern UI requires databinding, which means it's going to bring in a framework anyway, which means that self-contained widgets are all going to bring in their own frameworks, which means that i…

> Here's what killed web components

Wait, what? Web browsers have only recently implemented standards underlying Web Components, such as Shadow DOM. Microsoft has only recently announced the end-of-life of IE11, which doesn't support Web Components. Web Components have only just gotten started!

> lack of native databinding on the web ... it's going to bring in a framework anyway

Here's a lib for data binding Web Components using JSX: https://github.com/wisercoder/uibuilder This is a 200-line lib, hardly a "framework".

Re: The Failed Promise of Web Components

#185

what the, this was already on here a bunch of times a week ago when it was news https://news.ycombinator.com/item?id=24581439 https://news.ycombinator.com/item?id=24587413 https://news.ycombinator.com/item?id=24587413 and a response post: https://news.ycombinator.com/item?id=24606342

Looks like many people were desperately trying for the post to trend which it din't until this one, not sure if this is breaking any HN guidelines, maybe moderator can chime in.

Re: The Failed Promise of Web Components

#186

Earlier quoted context omitted.

I have never used SwiftUI so I can't comment on it. However, separation of concerns doesn't need to take extra development time. Inlining all CSS and JS is like dropping the MVC model because creating all the necessary classes is taking too much time; focusing on short term gains only lead to a mediocre end result, one that nobody wants to maintain five years down the line. Good React is fine for large applications,…

I think the irony here is that MVC in its original form has largely fallen out of fashion the last few years. And it is precisely because physically separating all of the functionality into a model/view/controller files doesn't actually make development easier. This makes sense right? Logically it's all coupled, so separating the pieces, even if they are functionally responsible for different things, doesn't really p…

> I think the irony here is that MVC in its original form has largely fallen out of fashion the last few years.

Not really — unless React is the only library you use.. MVC is still the best pattern. If you are an iOS developer you may already be familiar with MVC in Cocoa. Most UI frameworks, including ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC. That's no accident. These disparate platforms — mobile and Web — all converged on MVC because it is the best architectural pattern for developing user interfaces.

Re: The Failed Promise of Web Components

#187

The death of HTML imports killed web components for me. With HTML imports, you would import a HTML file. In that file would be css, html and the js to make the component. Then you’d use HTML as usual in your main file. Finally you could create custom components easily while keeping yourself dealing primarily with HTML. Instead, you were forced to use bizarre js import systems. And at that point you were in JS land. F…

> In that file would be css, html and the js to make the component.

You can do that. Here's an example Web Component that contains the css, html and javascript:

https://github.com/wisercoder/uibuilder/blob/master/WebCompo...

Re: The Failed Promise of Web Components

#188

This post is needlessly snarky, but I don't disagree with the basic premise. Here's what killed web components: lack of native databinding on the web. That's the reason the standard is useless without JS. Any modular, dynamic, modern UI requires databinding, which means it's going to bring in a framework anyway, which means that self-contained widgets are all going to bring in their own frameworks, which means that i…

Data binding needs to be added to the JS standard. I am all for "separation of concerns" but I think we need to admit that HTML/CSS/JS has become a de facto tightly coupled standard of modern applications. I don't like it. I would much rather use JavaFX or somethjng else, but Web apps are here to stay. And like it or not, having to import external libraries to do something as simple as data binding is unacceptable. J…

Lit-html (not LitElement) would seem to fit the bill.

I build very large and complex apps for my clients using lit-html and vanilla web components.

Mostly just stay in the light dom unless there's a reason to hide in the shadow.

Re: The Failed Promise of Web Components

#189

Earlier quoted context omitted.

The web components under the hood would still need a way to program themselves in response to that data, so a templating language would need to be baked in along with data binding. Secondary languages are a bad idea, so hopefully this templating language would be something like jsx/ejs. The proposal really is to bake applications support in to the browser. That seems right to me. The browser is more and more an os, a…

Lit-HTML is a templating system that's baked into Lit-Element, which is basically the successor to the Polymer framework. It simply uses JS template strings, with a few little niceties in the binding syntax to allow for things like setting properties rather than attributes, adding/removing boolean attributes, and defining event handlers inline. It lacks two-way data binding, but we use "data" elements as a centralize…

We do very similar things.

Works great.

Re: The Failed Promise of Web Components

#190

Earlier quoted context omitted.

I think the irony here is that MVC in its original form has largely fallen out of fashion the last few years. And it is precisely because physically separating all of the functionality into a model/view/controller files doesn't actually make development easier. This makes sense right? Logically it's all coupled, so separating the pieces, even if they are functionally responsible for different things, doesn't really p…

> I think the irony here is that MVC in its original form has largely fallen out of fashion the last few years. Not really — unless React is the only library you use.. MVC is still the best pattern. If you are an iOS developer you may already be familiar with MVC in Cocoa. Most UI frameworks, including ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC. That's n…

There’s a whole ecosystem of alternatives that have sprung up I have a feeling you haven’t tried (not MVVM or anything like that). Without appealing to any of them you aren’t convincing.

Even within the frontend world and not in React you have all sorts of new state systems and structures that are in my opinion far more intuitive, less code, less cross cutting concerns, easier to change and grow more naturally. The gist of it is either a global state store with cursors and namespaces (I like this less than most) or a global state system with state split out (see Recoil) or an entirely tree based reactive state system (see mobx-state-tree or mobx-store) or even just nesting reducers or any simple nesting state container (pure react, zustand). I’ve recently put together gqless[0] with a state system similar to recoil but simpler (sort of like use-atom). It’s wonderful.

Your data is a tree/graph, you app is a tree, your file system is a tree, everything matches. You just slot in state with corresponding actions and at the level of the view hierarchy where it first becomes relevant (router at top, view controllers are spread in the middle layers however needed, and leafs get their own state as needed). And all data level things stay up in the graph, which I guess you could argue is an M sitting above it all, the VC are blurred together with more C at the top of the tree and pure V at the leafs. Even styling is all encapsulated where it’s used. Each piece is a lego block that can be moved around. And yes, it works, and works well, even without all the handlebars of Rails.

Wouldn’t dream of going back. It’s perhaps not a mature enough ecosystem for most to navigate their way to getting a good DX on a stack like that. Many pieces have rough edges if you don’t know what to avoid, it’s not like these huge mature frameworks that keep you away from scary stuff but also box you into a rigid structure. But of course it means you can do all sorts of things unimaginable in MVC land.

Post reply on HN