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

The Failed Promise of Web Components

lea.verou.me

Post reply on HN
Print view View original

211–220 of 235 posts

Re: The Failed Promise of Web Components

#211

Post by aasasd »

nwienert wrote: post #75
jeroenhd wrote: post #61

Earlier quoted context omitted.

I'm a strong proponent of separation of duties on the web (style and visuals in CSS, layout in HTML, anything interactive in JS). Enabling data binding in HTML would only serve to blur those lines. With some minimal JS, you can update each web component already. Is writing nameField.innerText = response.name really that difficult? What problem does it solve to make a standard for it? As for (de)serialization, JS has…

Web Components are a total mess and impossible to build anything of significance with. I can't even imagine how anyone would get anything done with them. It's like an Angular developer, an artist, and a mid-2010s neural net walked into a bar and sketched out a spec by taking shots and passing it clockwise. Separation of languages is a silly way to separate things. You're building components : logic, structure and sty…

> Twitter is a good example, great performance

This statement alone invalidates your arguments, because evidently you never once tried opening Twitter on an underpowered machine, be that desktop or a phone.

Re: The Failed Promise of Web Components

#212

Post by bernawil »

franciscop wrote: post #32
onion2k wrote: post #26

Earlier quoted context omitted.

One huge advantage is that you can isolate a web component in its own shadow DOM, which means it has CSS that's independent from the rest of the page. If you're making something for other people to embed in their code, even if you're on the same project, you can save them from breaking it by styling it by mistake. You can also close the shadow DOM to stop people easily inspecting it, but I must admit I haven't actual…

That is the same if you use e.g. styled components with React, where every component is self-contained and doesn't leak the styles. The mechanism is different, but the end result is the same, and oh it's a game changer IMHO.

you can make your component's css "not leak" if you name all it's classes with random uuid and scope all selectors accordingly, exactly what styled components does. But "not leaking css" is a nicer way of saying that you can't customize it.

Re: The Failed Promise of Web Components

#213

Post by mikelward »

darkhorse13 wrote: post #163
jeroenhd wrote: post #77

Earlier quoted context omitted.

Web browsers provide many features out of the box but frameworks rarely use them. Web components are one thing; HTML templates are another. Streaming video is being decoded by Javascript even though every browser supports H.264, input elements such as calendar controls are rewritten, animations are done in JS instead of smooth CSS transitions, drag and drop support is manually rewritten in JS... Whenever a feature ge…

>input elements such as calendar controls are rewritten Popular browsers such as Firefox and Safari don't have native date controls: https://caniuse.com/input-datetime

Looks like Firefox now supports `date` and `time`.

Re: The Failed Promise of Web Components

#214

Post by TiredGuy »

ChrisMarshallNY wrote: post #14

I love her description of using a dependency-laden component: > Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”. Many steps are even omitted, likely because they are “obvious”. Often, you wade through the maze only to find the component doesn’t w…

There are some lightweight approaches to web components. For example µce is extremely small and provides web components with no build step [1]. If you use the author's once-defined 140 byte library, you can also avoid having to bundle everything per component [2].

For those not quite ready to throw away frameworks, heresy [3] might be more up their alley, or if you're not as set on production readiness yet, check out my own barleytea.js [4] which is written in a little over 300 SLOC and has zero dependencies or necessary build steps.

I guess my point is, there is a good variety of microframeworks out there striving to meet this need.

[1] https://github.com/WebReflection/uce [2] https://github.com/WebReflection/once-defined [3] https://github.com/WebReflection/heresy [4] https://andrewfulrich.gitlab.io/barleytea/

Re: The Failed Promise of Web Components

#215

Post by kingdomcome50 »

flowerlad wrote: post #186
kingdomcome50 wrote: post #160

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…

Most of the frameworks you mention above are 5+ years old. Back when jQuery was the THE THING to know.

In any case, my critique is not levied against MVC the pattern, rather, how it is manifest. One can logically follow MVC without the physical separation of concerns (files). It's a continuum: You start by defining your state, view, and orchestration all in the same place. Should any one piece of the above suddenly need to be reused elsewhere, you then abstract as necessary.

I was pushing back against the idea that "inlining" CSS/JS with HTML is poor practice. What React achieves, because it demands you inline JS (and CSS if you want) with the HTML, is a simple, declarative development paradigm. It's like reading a function. No procedural ad-hoc `let el = document.querySelector('#id')` garbage getting in the way. The behavior is with the component, not around the component. In many ways, this is how OOP was supposed to work.

Re: The Failed Promise of Web Components

#216

Post by elcritch »

saalweachter wrote: post #159
goatlover wrote: post #73

Earlier quoted context omitted.

Exactly this. Why should JS be required for something the browser could handle when we're talking about HTML?

Hell, you'd think it'd be a bigger thing among the noscript/privacy world to be able to do more things without JS.

Unfortunately, web components always require JS to work. However, they can hide the JS from the user. Though I suspect that it'd be fairly easy to "whitelist" web-component CDN libraries and disable other JS still.

Re: The Failed Promise of Web Components

#217

Post by c-smile »

xmprt wrote: post #183
c-smile wrote: post #178

Earlier quoted context omitted.

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.

Yes, it is BSD, but who pays for Chromium development?

By financing that BSD project that organization is buying the right to define Web standards by its own.

BSD is just a business model for them : you wine her, you dine her, you buy her. Such an Open Source, eh?

Re: The Failed Promise of Web Components

#218

Post by WorldMaker »

svachalek wrote: post #170
WorldMaker wrote: post #18

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.

> The goal keeps moving though.

I think the goal posts have stayed the same:

1) Module support in browsers. (Now ~92% per caniuse.)

2) Optional: Wide support for HTTP/2 in browsers. (Now ~95% per caniuse.)

3) Optional: Wide support for HTTP/2 in servers. I don't have good statistics on this one, but things feel "close" to ready.

(2) and (3) are desirous for performance, and we've known that all along as modules balloon the number of HTTP requests.

Maybe you also want to count super option (4) "smart HTTP ES module push preloading", but that seems unnecessary gilding to me.

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

If you are outputting modules you shouldn't have to "link"; admittedly performance is still a concern, but that's what HTTP/2 (and/or HTTP/3) are supposed to help with.

If you are outputting modules rather than "linking"/"packing" you shouldn't have much to tree-shake and the browser will naturally tree shake in terms of simply not requesting modules outside of the execution path.

Just because you have a build step doesn't mean you have to "build all the things", and it shouldn't be a surprise and should be obvious that a type-checking-and-stripping only run of Typescript is faster than a Typescript+Webpack+Rollup+Terser or whatever stack.

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

That's an orthogonal issue, though. Does it matter that the browser is running code "exactly as authored"? Even then, Typescript outputting ES2015+ modules is more often than not just stripping types. The distance between ES2015+ and Typescript today is often minuscule. Typescript has been pretty focused on sticking to TC39 Stage 3 so even features that aren't currently supported by browsers are most often tomorrow's features (not "next decade's features").

Plus, Typescript even gives you the option today of moving all your type checks to JSDoc comments and running as a type-checker only and you can feed the JS directly to browser as is, if that really is a concern that you think the browser should be using the same files that you are writing. (But again, does that really matter? And also, that isn't stopping you from using ES2015+ modules today. It doesn't matter if you are using a Typescript build step or not.)

Re: The Failed Promise of Web Components

#219

Post by WorldMaker »

rektide wrote: post #182
svachalek wrote: post #170

Earlier quoted context omitted.

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…

> can people with no tools, with no type-script, are they capable of using modules?

With a "modern framework"? Probably not. At least not with current documentation.

With everyone's classic "framework" Vanilla JS? Yes, absolutely. There's nothing stopping anyone. It's rather easy, and I've done it for small projects at this point.

There's one subtle change to the SCRIPT tag (type="module"), and new syntax to learn (if you haven't already learned it from Typescript or Babel), but that's it.

Sharing modules "just works" if you use what has always worked in SCRIPT tags: URLs. You don't need "import-maps" if you have URLs you trust (and "cool URLs don't change"), and Deno is exploring that as well as the way forward for "server side" applications as well that you can build complex dependency graphs solely on top of URLs.

Sure, "modern frameworks" are built on top of a house of cards of CommonJS (and sometimes still ancient AMD/UMD/weirder) dependencies, Node-style "bare" imports (imports by package name only, imports without file extensions, etc), npm package.json configuration and file meta (contributing to Node-style bare import complexity), and other issues. It would be a amazing if we could just rip the legacy code band-aid off and presto every "modern framework" would be ES2015 module native and just an `import framework from 'https://myawesome.framework.example/myawesome.js'` away. Deno has even pointed out that we can automate more of that (than we currently do) and move the "bunch of tools" to the the servers that serve the URLs, there could be a service out there for `import { React, Vue, etc } from 'https://oldworldnodetomodernmodules.example/modern-framework...'` doing all the hard "tool" work and bringing "people with no tools" to the same table, if that were something we cared about doing. (Just as web hosts like unpkg have helped a lot of SCRIPT tag only people able to use npm dependencies for years now.) (ETA: But again, that's useful for old code with legacy dependencies; new code could be entirely written with URLs as the "package manager" no sweat. URLs are just as capable of most of the complexity we put up with from npm.)

Re: The Failed Promise of Web Components

#220

Post by pjmlp »

throw1234651234 wrote: post #104
la_fayette wrote: post #88

Earlier quoted context omitted.

React is a nightmare when it comes to performance or energy efficiency... Downloading 500kb of js and processing this is just a nogo. The best advice to anyone interested in page speed, dont use this crap. https://youtu.be/plt-iH_47GE

Use Gatsby and generate a static site w/ React? At least React is faster than Angular, which I strongly prefer.

Better, generate a static site without frameworks.
Post reply on HN