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

Plain Vanilla Web

plainvanillaweb.com

Post reply on HN
Print view View original

121–130 of 715 posts

Re: Plain Vanilla Web

#121

Post by mschuster91 »

zero_shift wrote: post #109
mschuster91 wrote: post #105

From https://plainvanillaweb.com/pages/components.html I see this piece: if (!this.#span) What is that kind of magic syntax sugar?! A shorthand for document.getElementById?

No, the hash is a red herring. It's a way of signifying a private field on an object.

Ah. Thanks, that hint pointed me to [1]. Seems like it's been supported by every major browser since 2021, and only specified in the upcoming ECMAScript 2026 spec.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Plain Vanilla Web

#123

Post by skrebbel »

troupo wrote: post #97
skrebbel wrote: post #22

I support the general idea here but just because something is in a browser doesn't mean it's a good formalism. Notably, Web Components. They're fantastic for distributing components - after all, a Web Component will work in every framework (even React, the IE of frameworks, finally added support), or even in vanilla HTML. So you can build a component once and everybody can use it. It's fantastic. But for internally c…

> then we wouldn't have had 5+ years of people mistaking them for a React competitor. The browser people literally promoted them as a React alternative. Then their goals and role changed every year, and now they are again promoted as an alternative

Yeah what a waste of collective brainspace that was eh. If they had promoted them as "custom elements are the best way to distribute components!" then I bet they'd have been much more widely embraced by now, by merit of not overselling them.

Re: Plain Vanilla Web

#124

Post by pinoy420 »

donohoe wrote: post #66

I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code. My team and I built https://restofworld.org without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience. We might adopt a frame…

[dead]

Re: Plain Vanilla Web

#125

Post by zero_shift »

mschuster91 wrote: post #121
zero_shift wrote: post #109

Earlier quoted context omitted.

No, the hash is a red herring. It's a way of signifying a private field on an object.

Ah. Thanks, that hint pointed me to [1]. Seems like it's been supported by every major browser since 2021, and only specified in the upcoming ECMAScript 2026 spec. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

It has a contentious history and largely was forced through by one person in TC39 who focused on a particular corner case

Re: Plain Vanilla Web

#126

Post by throwitaway1123 »

troupo wrote: post #91
mikebelanger wrote: post #86

Great resource! I particularly like the fact that their web component section doesn't use the shadow DOM. It's really too bad custom elements got associated with shadow DOM, as they're so useful beyond the more niche usage cases of the shadow DOM.

> It's really too bad custom elements got associated with shadow DOM Because it was heavily pushed, advertised, and is the default way of writing web components (you have to explicitly specify mode: open)

> you have to explicitly specify mode: open

The mode does not toggle the shadow DOM on and off. It just specifies whether or not the element's shadowRoot object is a public property. An open mode makes this possible: `document.querySelector('my-component').shadowRoot`.

You have to explicitly opt-in to the shadow DOM either imperatively by calling `attachShadow`, or declaratively in HTML by giving the element a template child element with a `shadowrootmode` attribute.

Re: Plain Vanilla Web

#127

Post by nzgrover »

eduction wrote: post #79
donohoe wrote: post #66

I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code. My team and I built https://restofworld.org without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience. We might adopt a frame…

Kudos, the site feels really snappy and I’ve definitely come across the journalism before. Any sharp edges to this approach?

In my experience, the sharp edges are browser compatibility issues, and I've been gratefully avoiding them for years by using jQuery.

Re: Plain Vanilla Web

#128

Post by troupo »

throwitaway1123 wrote: post #126
troupo wrote: post #91

Earlier quoted context omitted.

> It's really too bad custom elements got associated with shadow DOM Because it was heavily pushed, advertised, and is the default way of writing web components (you have to explicitly specify mode: open)

> you have to explicitly specify mode: open The mode does not toggle the shadow DOM on and off. It just specifies whether or not the element's shadowRoot object is a public property. An open mode makes this possible: `document.querySelector('my-component').shadowRoot`. You have to explicitly opt-in to the shadow DOM either imperatively by calling `attachShadow`, or declaratively in HTML by giving the element a templa…

I stand corrected!

Re: Plain Vanilla Web

#129

Post by spoonsort »

Be wary of building a website without a framework to abstract stuff like DOM usage and page generation. Raw webdev is hard, due to lots of compatibility issues at every level (CSS, HTML, JS) and are moving targets. You shouldn't even try it until you understand protocol design and have implemented some medium complexity standards like IRC and a basic DNS client or server.

Re: Plain Vanilla Web

#130

Post by spankalee »

90s_dev wrote: post #24
braden-lk wrote: post #4

Very cool overview and a great article—it’s fascinating to see how far web components have come. Data passing, interactivity, and state management still seem pretty tedious in vanilla, though!

Data passing seems inherently broken in web components, because all HTML attrs must have string keys and values. Such a model just can't be built on top of.

This is just a lie perpetuated by the React team 10 years ago

All HTML elements are JavaScript objects that have properties. You can pass arbitrary data to custom elements via those properties.

Look at any modern HTML template system and you'll see the ability to pass data to properties declaratively.

Post reply on HN