TIL of which can get by with very little JS. But why is Safari refusing to implement it and why did Firefox put it behind a feature flag for years?
I think the reason Firefox hasn't exposed it completely yet is to deal with accessibility issues.
The Failed Promise of Web Components
151–160 of 235 posts
Re: The Failed Promise of Web Components
#152This 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…
It's not snarky. It's good natured, and justifiedly awesome and elegantly mocking the bullshit of these ridiculous JS afficianadas/os. I was hinting the hype in 2014 with shadow v0 and the promise has been broken.
Re: The Failed Promise of Web Components
#153Earlier quoted context omitted.
In lighthouse, I see a score of 100 performance and time to interactive at 1.8secs. This is comparable to hacker news home page (which is purely static), but my first contentful paint was slightly faster (probably because my site is slightly smaller). Both sites were about 4 times faster (TTI) than google home page and typescript home page.
I’d be interested in checking out your site. I normally only have a 2G connection on my phone, I’d love to be able to read something that’s NOT HN. This site is the only site I know that takes less than 5-10 mins to load, if it loads at all.
Ok, here it is https://ricklove.me
Here is a post that explains some of the content that is interesting: https://ricklove.me/cool-stuff
Let me know how it does on a slow connection.
Re: The Failed Promise of Web Components
#154I'm using lit-element for a project it's much more usable than writing components from scratch. The growth of complexity on the client side is really quite staggering and thanks to browser stagnation I doubt it will get better any time soon. A platform that should be low code is really maximum over code!
Re: The Failed Promise of Web Components
#155I recently stumbled across "shoelace", which at a glance seems like an example of what the article is hoping for. It's a thoughtfully designed library of UI web components. https://shoelace.style/
Thanks for the link. This library unfortunately highlights further challenges with Web Components like mixing custom WCs with native form elements. To use Shoelace form elements at all, you'll end up writing a bunch of JavaScript. > Shoelace forms don't make use of action and method attributes and they don't submit the same was as native forms. To handle submission, you need to listen for the slSubmit event as shown…
> To use Shoelace form elements at all, you'll end up writing a bunch of JavaScript.
Shoelace author here. This is somewhat true (I wouldn’t call it “a bunch” though), and it will be until form-associated custom elements are standard. However, I’d argue that most form validation and submission is done with JavaScript these days. I can’t think of the last time I saw a post request submitted from a form in the wild. (Not that it doesn’t happen, but it seems to be quite rare now.)
Re: The Failed Promise of Web Components
#156> Can we fix this? Sure, by returning to basics. Let's assume that Web Component is a DOM element with a code associated with it + lifecycle events. Here is how Components are done in Sciter ( https://sciter.com ) 1. CSS has got `prototype` property: div.my-component { prototype: MyComponent url(script/components.js); } where MyComponent is the name of class in JS, url (optional) is an URL where this MyComponent can…
This is literally what a custom element is. Assuming your @event decorator is built upon the EventTarget interface: class MyComponent extends HTMLElement { // lifecycle event/method connectedCallback() {} // lifecycle event/method disconnectedCallback() {} @event("mousedown") onMouseDown(evt) { } @event("click", "button#submit") onSubmit(evt, button) { } @event("change", "input.name") onNameChange(evt, input) { } } T…
> @event decorator is built upon the EventTarget
In Sciter it is not. @event there is not calling Element.addEventListener but declares event handlers as static table associated with class.
Essentially components are attached to DOM elements by calling Object.setPrototypeOf(element, MyComponent) - no memory allocation is happening (modulo code in componentDidMount) - very fast and lightweight.
Yet, in your sample, you've missed the call of customElements.define(), that alone is limiting use cases quite a lot.
> custom elements don't cost $310 for an indie license.
Sciter is free, as browsers too, components in SDK, hundreds of them, are free too. You will need to pay $310 only if you need source code of Sciter Engine itself.
Sciter is like a browser in that respect, try to request source of MS Edge or Google Chrome for any money - good luck with that.
Re: The Failed Promise of Web Components
#157Earlier quoted context omitted.
I built lots of HTML form UIs in the early 2000s. They were garbage. Many modern web UIs are on par with native apps, so much so that folks are now using web technologies to build actual native apps. With 150 years of evolution (at current W3C standards pace) you might get an HTML spec that is capable of expressing the behavior that users expect from present-day applications. Until then we have React et al.
> Many modern web UIs are on par with native apps I strongly disagree. Form/ fields are one of the areas that a native app can slaughter HTML, even if using a WebView within an app. For example, just showing the correct keyboard layout is a nightmare, and heaven help you if you need to do something slightly custom. Another example: browsers do funky shit with scrolling and zooming on input focus. Try using the best H…
> For example, just showing the correct keyboard layout is a nightmare
It’s literally just an attribute on the input element?
Re: The Failed Promise of Web Components
#158what 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
I wrote the response. Maybe someone will submit it another three times and then it will finally catch on…
Re: The Failed Promise of Web Components
#159Earlier quoted context omitted.
Perhaps, but as a web developer html imports let me pull in and use web-components without writing any Javascript. Give an HTML editor to a 15 year old, some links to a decent web-component library and they're off to the races without mastering JS.
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.
Re: The Failed Promise of Web Components
#160Earlier quoted context omitted.
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…
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 produce a system that is easier to maintain.
Look at the new default "razor pages" web project for .NET core. While it it is a little bit fancier, it basically brings back the same mental model that PHP has been using for decades. That is, cram all of the logic into a single file, and use a "service locator" pattern (I know it's actually DI under the hood) to "inject" extra functionality. In this way it is easy to trace where all of the pieces are coming from. Why abstract your `UserRegistrationView` to accept any `UserRegistrationModel` from a `UserRegistrationController` in a "decoupled" manner when the reality is that only one of any of that actually needs to exist ever? Might as well have the orchestration right next to the use-case!
The above applies to (what I believe to be) a significant majority of use-cases. At least the interesting ones.