Live data from Hacker News

Ways to make a web component

webcomponents.dev

171–180 of 200 posts

Re: Ways to make a web component

#171
post #145

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: Syn…

Adding Mithril.js to the list :thumbsup:

Thanks for reporting the issues we will look into it. How to you install a Chrome v68?

Re: Ways to make a web component

#172
post #167

I've been working on a webcomponent based reddit/patreon competitor for about a year now, and one thing I found was how incredibly easy it was to spin up my own micro framework. I would highly encourage people to give it a shot. It's just going back to basics and working with class-based inheritance. It will take you a day to write out the basic functions you will need for 95% of your components, and you'll be left w…

Don't be stupid, how do you know those 26 lines of code are free of bugs? They're not battle tested and you're just re-inventing the wheel instead of following best practices.

Re: Ways to make a web component

#173

Earlier quoted context omitted.

How is it atrocious exactly? I mean it’s decidedly not React to be clear, but I’m not sure what makes it atrocious

It's overly verbose and error prone. Try adding an observable attribute. Then add another one. Then do something simple like change the name of the first one. And that's just two attributes.

The Web Component APIs don't aim to be easy to use by application developers. That is simply not a goal of the spec. They're low level APIs which expose behavour and hooks on which libraries and frameworks can be built. As an application developer you are supposed to use those friendly libraries.

Re: Ways to make a web component

#174

Earlier quoted context omitted.

It's overly verbose and error prone. Try adding an observable attribute. Then add another one. Then do something simple like change the name of the first one. And that's just two attributes.

The Web Component APIs don't aim to be easy to use by application developers. That is simply not a goal of the spec. They're low level APIs which expose behavour and hooks on which libraries and frameworks can be built. As an application developer you are supposed to use those friendly libraries.

Aaand that's the problem with the API. The question was, how is API atrocious. Once an answer is received, it's immediately diverted to "the API is not for devs, you have to use libraries".

This doesn't make the API any less atrocious. And it would be nice if the platform didn't rely on libraries to make it usable.

Re: Ways to make a web component

#175
post #167

I've been working on a webcomponent based reddit/patreon competitor for about a year now, and one thing I found was how incredibly easy it was to spin up my own micro framework. I would highly encourage people to give it a shot. It's just going back to basics and working with class-based inheritance. It will take you a day to write out the basic functions you will need for 95% of your components, and you'll be left w…

A friend of mine did the same thing, I did a small project in his framework and it was really fun.

https://github.com/ruphin/gluonjs

I'm not sure if he still maintains it or it's just done, it grew to about a hundred lines but it's quite comfortable. He used it himself to create a quite amazing portfolio page that unfortunately is down right now.

Re: Ways to make a web component

#176
post #67

Earlier quoted context omitted.

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…

> large React applications tend to be just as heavyweight and hard to understand as Angular ones once you need a router, state manager, and 20 or 30 other "compact" libraries to do what you're trying to do. I largely disagree with the comment you're replying to in its oversimplification of things, however, this simply isn't true. 'Create React App' plus 'React-Router' is literally all you need for the vast majority o…

Aren’t form validation and http also separate libraries for React?

Re: Ways to make a web component

#177
post #151

Earlier quoted context omitted.

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

Link to proposals: https://github.com/tc39/proposal-import-conditions https://github.com/w3c/webcomponents/blob/gh-pages/proposals...

With type="module" and need to set ContentType they've invented new attribute and alias

    
but there is no need

    
is not executed, so it can be used as is.

And "if" keyword means make a request with ContentType: "/", discard if result ContentType does not match. Which is ... strange?

Re: Ways to make a web component

#178

Earlier quoted context omitted.

The Web Component APIs don't aim to be easy to use by application developers. That is simply not a goal of the spec. They're low level APIs which expose behavour and hooks on which libraries and frameworks can be built. As an application developer you are supposed to use those friendly libraries.

Aaand that's the problem with the API. The question was, how is API atrocious. Once an answer is received, it's immediately diverted to "the API is not for devs, you have to use libraries". This doesn't make the API any less atrocious. And it would be nice if the platform didn't rely on libraries to make it usable.

Sure, from a dev perspective the API may be bad. But I'm saying that that isn't the right perspective to use when judging it.

"Nice" APIs or higher level APIs are desirable of course, but they tend to be much bigger in size and scope, much more opinionated and brittle than a smaller low level API. A portable API which browser makers can accurately implement and support for the long term, is a smarter goal even if it does expect devs to build a "nice" layer on top of it first.

Re: Ways to make a web component

#179
post #62

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…

SVG has the concept of re-usable components. Maybe in 10 years we can replace HTML with SVG. hides I'm sure that would make it much, much harder for people with accessible needs.

Years ago I heard someone saying that SVG should have replaced what CSS does nowdays, i.e use it for anything graphical. Not sure how well it would have worked though. But it is vector graphics so maybe very well?

Re: Ways to make a web component

#180

Earlier quoted context omitted.

Aaand that's the problem with the API. The question was, how is API atrocious. Once an answer is received, it's immediately diverted to "the API is not for devs, you have to use libraries". This doesn't make the API any less atrocious. And it would be nice if the platform didn't rely on libraries to make it usable.

Sure, from a dev perspective the API may be bad. But I'm saying that that isn't the right perspective to use when judging it. "Nice" APIs or higher level APIs are desirable of course, but they tend to be much bigger in size and scope, much more opinionated and brittle than a smaller low level API. A portable API which browser makers can accurately implement and support for the long term, is a smarter goal even if it…

In case of WebComponents it could have a small sane layer on top that wouldn't be too large. See WebComponents vs Polymer: [1]

As it stands now, it's nigh unusable by developers. Almost no frameworks even use it as their foundation. And those that do compile to them go out of their way to never ever use it anywhere except in base classes, maybe: [2]

As a result, today, 9 years (!!!) after they were first proposed, the very person who proposed them relegates them to "webcomponents will be used incidentally not totally" [3]

[1] https://twitter.com/dmitriid/status/865518972380237825?s=20

[2] Stencil compilation: https://twitter.com/dmitriid/status/1283445578853158917

[3] https://twitter.com/slightlylate/status/1283053719563563008

Post reply on HN