Ways to make a web component • Hacker News Board

Re: Ways to make a web component

#141

Post by temp42 » Fri, Jul 17, 2020, 10:29 PM UTC

deergomoo wrote: post #131

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…

I would 100% be in favour of an alternative to the DOM designed specifically for building rich application UIs. With upcoming features like portals it could even be embedded within existing HTML documents, or vice versa. I’ve griped about this before, but I firmly believe that the trope of JavaScript developers needing a million dependencies and constantly reinventing the wheel stems from the fact that you have to do…

Not that it diminishes your general point, but are you aware of the datalist element? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

Re: Ways to make a web component

#142

Post by golemiprague » Fri, Jul 17, 2020, 10:34 PM UTC

staycoolboy wrote: post #40

sillysaurusx wrote: post #25

Earlier quoted context omitted.

Nope, your thoughts are all essentially correct. The answer is “yes” to all of them; even the ones where it seems that “yes” would be contradictory. Bundle everything? Yep. Self contained? Yep. 10 components that open connections to 10 different severs? Yep. The web is so massive that there is a way for pretty much everything (though for some reason webdevs try not to admit this).

Except for the pure HTML5 solutions, everything else uses a JS framework.

While they use a JS framework it doesn't mean the framework is used also in run time, in pre compiled frameworks like svelte the generated components are just vanilla JS and can be used later in any webpage.

Re: Ways to make a web component

#143

Post by portroyal » Fri, Jul 17, 2020, 10:52 PM UTC

nonbirithm wrote: post #82

"Compare coding style, bundle size and performance of 33 different ways to make a Web Component." I thought this was a joke at first. But it suddenly made sense in the context of modern web frameworks and micropackages and all these different ways of doing the same thing. But wait, I thought. Surely it was a typo and they meant to type "3" and fat-fingered it instead? But no. It really is 33. Which one of those 33 wo…

Use Svelte and be happy.

Re: Ways to make a web component

#144

Post by rebelnz » Fri, Jul 17, 2020, 11:43 PM UTC

sequoia wrote: post #70

Web components to me represent the architecture I’d like to have. I think a good arch could be: 1. Build a rails/django type site, make everything work vanilla http+html etc. 2. Create standalone web components for the places you need some more interactivity, like type-ahead search box, “click to add” type thing, or a datatable So most of your performance stuff could be handled/improved on the server, focus on aggres…

This is exactly how I work - albeit on my own projects - vanilla html/css Go and Postgres for all server side operations with a few modular web components here and there for the interactivity you mentioned. No frameworks, build tools or config files ...

Re: Ways to make a web component

#145

Post by fouc » Sat, Jul 18, 2020, 12:28 AM UTC

georges_gomes wrote: post #75

co-author of the blog post here. Thank you @kjhughes for sharing our work here :pray: I don't know you but I love you already :heart: :) I'm trying to comment where I have something to bring. If you have questions or maybe a list of things that you would like to see in the next update, please shoot at me! Many thanks

I wanted to suggest that you could consider adding mithril.js to the list of libraries perhaps. It's a nice alternative to preact/svelte, and it's been around awhile.

-

BTW, When I go to https://webcomponents.dev/edit/uLX8C4bJf4Kmg2jWu1dL?pm=1 it doesn't load the component in the "Stories" tab for latest Safari or an old Chromium v68. Works fine in latest Firefox.

I see error message "Unhandled Promise Rejection: SyntaxError: Invalid character '\ud835'" on the worker.helper file in Safari. Chromium 68 ends up with "Unknown worker: undefined"

Re: Ways to make a web component

#146

Post by shhsshs » Sat, Jul 18, 2020, 12:40 AM UTC

clairity wrote: post #45

olex wrote: post #33

Earlier quoted context omitted.

This is exactly how vue.js "single file components" work - a with the "bunch of html", and optional blocks.

that's pretty close to what i'm thinking of, but still has some limitations (from https://vuejs.org/v2/guide/single-file-components.html ): • Global definitions force unique names for every component • String templates lack syntax highlighting and require ugly slashes for multiline HTML • No CSS support means that while HTML and JavaScript are modularized into components, CSS is conspicuously left out • No build step…

You may be misunderstanding (or I’m not understanding your intent). Single-file components were made specifically to overcome those issues, as mentioned on the page you linked.

Re: Ways to make a web component

#147

Post by aylmao » Sat, Jul 18, 2020, 12:42 AM UTC

georges_gomes wrote: post #133

aylmao wrote: post #115

Earlier quoted context omitted.

> For me, the most interesting aspect was that it's part of standards, requiring no dependency, so it means that I can use this app for decades without having to maintain it. I mean, you can also do that with React. Just don't update the library. The reason a web-component for decades without maintenance is because you won't be using all the new features— same thing.

I think the difference is that when you design a full React app, everything sit on the same "React base". If you want to move to upgrade to a new React version everything needs to upgrade. And if you need to migrate to Vue or Ember or Svelte... everything needs to migrate (or move to some sort of microfrontend strategy. But given the javascript cost of some of these frameworks, it's not cheap to go this route). Web C…

React is built to interop with "general" JavaScript, so in theory you can use it with other rendering frameworks. I used React and D3 all the time.

Performance-wise, it IS better to stick to a single framework, so I see what you mean. Web components being implemented in the browser do mean the user doesn't have to download any more JS.

Re: Ways to make a web component

#148

Post by ezequiel-garzon » Sat, Jul 18, 2020, 12:55 AM UTC

frozenlettuce wrote: post #121

crazygringo wrote: post #113

Earlier quoted context omitted.

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

But now? Publishers, even independent self publishers, have overwhelmingly never left PDF as output of choice, as it is superior in terms of typography, consistency and layout. Take any (non-Print Replica; i.e., reflowable) Kindle book that has just a few logical symbols, and you’ll see they soon become sufficiently ugly to be distracting, and in some cases just unclear due to poor typography. I celebrate projects such as MathJax, but what is sad is that 30 years on MathJax should be necessary at all, and here the typography is better but still doesn’t feel completely natural as in PDF documents.

And from a practical, layman’s standpoint, now that we’re all becoming “mobile first”, while it’s natural to complain when a web link points to a PDF file, the resulting app makes the experience more immersive and self-contained, enabling any average user to save that document. Just saving an HTML document with all its linked material using your phone requieres a l337 browser, Evernote, Notion, or wget from a terminal emulator with the right flags... undoubtedly it’s a chore. I agree this is all sad, but by now I don’t see this changing anytime soon.

Re: Ways to make a web component

#149

Post by madeofpalk » Sat, Jul 18, 2020, 12:57 AM UTC

bob1029 wrote: post #122

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…

Granted you don’t go into much detail, what I can gather you’re describing sounds incredibly unusually by vast amounts of people.

Shipping web pages as rendered jpeg images is a terrible idea for many many reasons.

Re: Ways to make a web component

#150

Post by JMTQp8lwXL » Sat, Jul 18, 2020, 1:01 AM UTC

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.

There are basic things StencilJS are missing, like source maps. Development has seemed to slow down on it as well.

There's also no types for web components. So, you can't statically analyze your code and know you are indeed passing in the correct property types.

There are wrappers for Stencil components for React/Angular/Vue, so you can ensure typings, but it goes to show the developer experience is far superior at the framework level.