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

Ways to make a web component

webcomponents.dev

Post reply on HN
Print view View original

121–130 of 200 posts

Re: Ways to make a web component

#121

Post by frozenlettuce »

crazygringo wrote: post #113
rishav_sharan wrote: post #60

It infuriates me that the concept of composable web pages using small templates/components is not baked into the html spec and supported by browsers. Every bit of code that we write in any programming language is made of composable bits which can be imported into other bits of code. But we cannot do anything similar with html. every time any attempt at having composable component based html is made, it gets mired dow…

Your frustration is understandable, but so too is why they never were -- HTML was never intended to be a programming language or component-based. HTML was originally meant to be page-based. And pretty much everything added to it (CSS, JavaScript) is scoped to the page. (Some data storage like cookies is scoped to the domain.) So shoehorning a "component" model to what is fundamentally page-based is essentially an imp…

The sad thing about HTML is that its original markup was designed for academic texts (h1,h2, p), but now it is unused because every publisher uses PDF for that end

Re: Ways to make a web component

#122

Post by bob1029 »

I have a server-side rendering approach that can get instantaneous paint of arbitrarily-complex views after pulling down index.html and exchanging a single pair of websocket messages. Once the initial page is loaded, redraws are as fast as you can get packets between the machines plus 2-3ms for decoding. It involves some very unorthodox methodologies and has latency constraints (similar to Google Stadia hosting model), but there are serious upsides. Including completely untouchable load & response times.

I strongly believe we are stuck in a Malthusian Trap regarding the use of HTML/iOS/UWP/Android for clients and then an entirely separate stack of things for the server - Go/.NET/Rust/Python/C++/etc. This separation adds such a huge burden to the development and maintenance of any application. I argue that if we must have some division between client & server, lets move as much of the complexity to the server as we possibly can. It's so much more manageable when you have all of your state in 1 domain like that. If the client doesn't have to track state or reason about its views, the application implementation for each device can be trivial.

I don't think that HTML/JS/CSS/JSON APIs represent a good boundary layer. I think final rasterized views, viewport dimensions and client events do. JPEG/MPEG can be decoded incredibly quickly on most mobile client devices due to availability of hardware acceleration. You will never be able to write a website in the traditional sense that can outperform the speed at which you could decode a full-screen JPEG image and display it. Server hardware is also getting insanely powerful with the new generations of AMD CPUs rolling out. Encoding JPEGs using something like LibJpegTurbo on TR/Epyc is ridiculously fast. This is also a type of application that does trivially parallelize across many cores. As bandwidth becomes ever more ubiquitous, and services more geographically-distributed, there is a good chance something like this could become practical in the general case.

For now, this is all just a crazy experimental thing that only works for a narrow range of applications. But, I would strongly encourage other developers to start thinking outside of the box. As networks get faster and latency gets lower, we will begin to encounter new "step function" opportunities that fundamentally shift how we do business.

Re: Ways to make a web component

#123

Post by spankalee »

sequoia wrote: post #67
spankalee wrote: post #54

Earlier quoted context omitted.

> Doesn't using a framework in this case mean that you also have to at least bundle that framework with the component? You should depend on any dependencies (including frameworks), but you shouldn't bundle them, exactly so that when an app is bundled it can do the efficient thing and share dependencies. > What happens if you want 10 components that each use a different framework? One reason to now use frameworks, but…

I downvoted this because these are (in my opinion) entirely theoretical and not practical answers. This reminds me of the "React is better than Angular(js) because look how compact and clean the API is compared to Angular!" type arguments. This implies that "React apps" are going to be less complex than Angularjs apps but the reality is anything but: large React applications tend to be just as heavyweight and hard to…

I've worked with a ton of apps migration frameworks in my career. From GWT, jQuery, Angular 1, and several non-OSS ones. The only successful incremental migrations I've ever seen have been via web components.

I'm working with one now that rather than convert from Angular 1 to Angular 9 in one shot is converting component-by-component to web components and working on features as they go. They'd have to stop features for at least 6 months otherwise.

Re: Ways to make a web component

#124

Post by agquick »

georges_gomes wrote: post #114
agquick wrote: post #105

Our company had been looking to move our project away from Knockout.JS and on to Vue/React. I started playing around with native Web Components just because I like the idea of not being locked into a single framework. However, I also wanted to keep using observables/computeds so I wrote a quick library that ties MobX with Native Web components, but has a Vue-like binding syntax. Yes I know it’s yet another library, b…

I love this creativity :) We should have you in the next update of the blog post!

Thanks, that would be awesome! It really makes state management within custom elements a breeze. I'm hoping others who appreciate observables/mobx will take interest and help me grow/maintain it :)

Re: Ways to make a web component

#125

Post by preommr »

martini333 wrote: post #120

Why would you ever have the logic in methods in Vue? Just keep it simple

Because templates should be declarative.

Error checking code becomes much more difficult because of the ambiguity and special parsing that has to be done. Its not just the loader, but things like the ide extensions used.

Allowing small bits of logic like this makes for very nice one-liners and demos, but in the long term its well worth it to make the template as declarative as possible - ideally just a method name.

Re: Ways to make a web component

#126

Post by no_wizard »

staticvar wrote: post #64
staticvar wrote: post #61

Earlier quoted context omitted.

I appreciate how Web Components are not opinionated meanwhile Component libraries are free to innovate and build on the Web Component foundation.

There are also simpler ways to write vanilla Web Components. Here's an example of the counter component written in what I find a simpler fashion. https://gist.github.com/rjsteinert/779d94dfc886723c2967a6f5f...

I like that this illustrates how easy it is to make a web component.

What I don't like is this also shows (via the render method) how you can foot gun yourself if you aren't careful. Just slabbing in everything via `this.innerHTML` will lead to gross performance problems, among other things. There's also no real diffing (only matters on more complex concerns, in a way) so you're replacing everything just to update the count.

I know we're all suppose to know better (I doubt you did this except for the express purpose of showing just how simple the Web Component API can be), but I've seen example code end up in production more times than I can count, from all over the web, so be forewarned stewards!

Re: Ways to make a web component

#127

Post by jhk4 »

spankalee wrote: post #118
jhk4 wrote: post #110

Earlier quoted context omitted.

HTML Modules never shipped which is the biggest hole in the current Custom Elements ecosystem.

HTML, CSS, and JSON Modules are currently blocked by Import Conditions, which is going for stage 3 at the next TC39.

TIL, that's awesome. I was under the impression they'd stalled out entirely.

Re: Ways to make a web component

#128

Post by wolco »

fuubi wrote: post #117
staticvar wrote: post #64

Earlier quoted context omitted.

There are also simpler ways to write vanilla Web Components. Here's an example of the counter component written in what I find a simpler fashion. https://gist.github.com/rjsteinert/779d94dfc886723c2967a6f5f...

That looks very clean - cool! I applied the redux pattern to WebComponents a while ago https://gitlab.com/f.parrillo/web-components/-/tree/master/s... .

Is gitlabs down?

Re: Ways to make a web component

#129

Post by alex7o »

agquick wrote: post #105

Our company had been looking to move our project away from Knockout.JS and on to Vue/React. I started playing around with native Web Components just because I like the idea of not being locked into a single framework. However, I also wanted to keep using observables/computeds so I wrote a quick library that ties MobX with Native Web components, but has a Vue-like binding syntax. Yes I know it’s yet another library, b…

You might not have to replace knockout.js the solid framework author actually has implemented a html rendering lib that has bindings for both knockout.js and mobx. You might find it useful https://github.com/ryansolid/dom-expressions.

Re: Ways to make a web component

#130

Post by georges_gomes »

hitekker wrote: post #90
srameshc wrote: post #6

I love the simplicity of StencilJS. Not sure why it's adoption is so low but those guys have put a lot of work. Much better than what Google is doing with Lit Element.

Curious: how does Stencil compare to Lit Element?

The link should give you some answers on code style and performance. What else are you looking for?
Post reply on HN