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

HTML Web Components

blog.jim-nielsen.com

Post reply on HN
Print view View original

221–230 of 247 posts

Re: HTML Web Components

#221

Post by andai »

mewpmewp2 wrote: post #187
andai wrote: post #182

Earlier quoted context omitted.

I am of course, slightly exaggerating, but... by way of analogy: I used a PDF library that didn't automatically flow text onto the page. You had to do it yourself. Line by line. Page by page. So, I wrote a few routines to do it. Maybe 50 lines? And I'm just like... this PDF library is twenty eight thousand lines lines long... and they couldn't have included those fifty?! Why! Meanwhile, a browser is 10-20 MILLION lin…

At least PDF libray you can update to include new functionality under a new version, but you can't just out of blue change the JS behaviour of undefined being rendered. It would definitely break something without warning.

https://xkcd.com/1172/

No need to break existing software. "use strict" was a great idea. Let's do "use sane"!

Re: HTML Web Components

#222

Post by davedx »

continuational wrote: post #55
joshstrange wrote: post #49

I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Does it just have styles in it? If so why wouldn't I just use css classes? I also think having a `user-avatar` take a `src` prop makes way more sense than having to add an `img` tag inside it everywhere I use it. In that case what am I saving? What is reusable? Vue/React/Angular don't seem like they are trying to "…

> I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Yeah, the lack of concrete examples makes this feel a bit too much like a shower thought to me.

Lack of substantial concrete examples is an issue with many of these anti-react technologies. Even svelte doesn’t seem to have many (any?) examples of large scale commercial projects using it.

In the last 10 years the only new web tech I’ve seen get traction outside of tech communities - so actual job postings etc - is vue.

Re: HTML Web Components

#223

Post by andai »

quickthrower2 wrote: post #192
andai wrote: post #182

Earlier quoted context omitted.

I am of course, slightly exaggerating, but... by way of analogy: I used a PDF library that didn't automatically flow text onto the page. You had to do it yourself. Line by line. Page by page. So, I wrote a few routines to do it. Maybe 50 lines? And I'm just like... this PDF library is twenty eight thousand lines lines long... and they couldn't have included those fifty?! Why! Meanwhile, a browser is 10-20 MILLION lin…

> 100% realistic and achievable in a dynamic language Achievable by just removing automatic type coercion. Throw errors instead. Would need to be feature flagged for backwards compatiability.

Exactly! You put that very elegantly. (I call that proposed flag "use sane")

I always thought JS needed static types to fix the insanity until I tried Python and realized that almost all the insane BS I get in JS are all runtime errors in Python.

There's a very good case to be made for reducing runtime errors, but it's a hell of a good start to at least have them!

Rather than what we have now, which is "assume the programmer is a beginner, who also never makes mistakes", and "given nonsensical commands, just do nonsense, and propagate garbage data throughout the entire program".

Re: HTML Web Components

#224

Post by Vinnl »

iteratethis wrote: post #126
codingdave wrote: post #66

I'm not sure I buy the "React is replacement, not augmentation" argument. At the end of the day/render, React still renders HTML elements... with javascript event handlers. Wrapping an ' ' in a React component doesn't mean I've taken away any functionality of 'img'. I just add to it -- augmentation. Maybe the author has worked in different React codebases than I have, but in my experience, we use built-in browser fun…

Surely every single web architecture ultimately renders HTML elements, that wasn't the point. The point is that the flavor "HTML Web Component" does not rely on JS to start rendering, unlike React.

I believe Flutter doesn't (or didn't use to) - it rendered to canvas, and then in parallel built a hidden DOM structure so an accessibility tree could be derived and made available to screen readers.

Re: HTML Web Components

#225

Post by Xeamek »

morbicer wrote: post #216
Xeamek wrote: post #143

Earlier quoted context omitted.

Would this example be considered "trivial"? https://www.youtube.com/watch?v=3GObi93tjZI But also, you can mix things togheter. You can just use react based app 'embeded' into mpa for when you need that heavy lifting, and the same keep the content part of your app simple. "But why would i do that, if i'd already use react for some parts, why not every where". Becuase then it leads to abominations like reddit or facebo…

The wall of HTML soup he shows for facet "component" (time 11.33) is something I don't want to ever see again in professional setting. Stringly typed logic and CSS / JS somewhere miles away in directory structure making it very hard to reason about. I very much prefer sticking to small, composable, encapsulated, actual components made in React or sth similar.

That file has like, 60 lines. Calling it a "wall of HTML soup" is a bit disingenuous. But if you REALLY have that much aversion to code, there is no inherent reason why you couldn't split it even more. CSS being miles away is again, just a matter of taste. No inherent reason why you could't use Tailwind for example.

Re: HTML Web Components

#226

Post by morbicer »

j-bos wrote: post #213

As someone forced to use an in-house library of html web components at work,I will opine, run. Run at full speed away from the shadow DOM. It's cumbersome to work, poorly supported in testing tools, and web components themselves are a pain to deal with when your use case doesn't perfectly match the original build. I'd like to like them, but, no.

Hugs to you brother. I am in exactly same boat.

The encapsulation coming with shadow DOM can be done in other ways (CSS modules) so light DOM seems a like saner approach... but then you lose the slots and they are must have for any composability.

Re: HTML Web Components

#227

Post by bryanrasmussen »

Xeamek wrote: post #220
davedx wrote: post #218

Earlier quoted context omitted.

I don’t like Facebook but claiming it’s a “glorified text forum” is utterly absurd. Please argue in good faith here

But it is though? I'm not talking about everything facebook provides, but main content page is just a list of posts with with discussion underneath them. Sure, you can embed some media into the it, but still. There is nothing inherently different about structure of facebook post compared to a post on a forum. And yet, despite everything facebook is doing, the most (and only) reliable way to load new comments under th…

>But it is though?

At some point quantitative change achieves a qualitative effect. I would think Facebook or LinkedIn or Twitter have all reached that qualitative effect to change from being just a discussion forum.

However qualitatively the social functions of these apps present an extra functionality missing from traditional discussion forums. Being able to track users, notifications of the users updates, blocking certain users from being in the message - which is a traditional messaging function not found in discussion forums. Suggestions of people or subjects to follow given on what you have done in the past, weighted based on various algorithms to determine how recent your past activity was and what your current interests seem to be.. I'm sure you could think of a load of other functions that are not traditional discussion forum functionalities.

Re: HTML Web Components

#228

Post by morbicer »

Xeamek wrote: post #225
morbicer wrote: post #216

Earlier quoted context omitted.

The wall of HTML soup he shows for facet "component" (time 11.33) is something I don't want to ever see again in professional setting. Stringly typed logic and CSS / JS somewhere miles away in directory structure making it very hard to reason about. I very much prefer sticking to small, composable, encapsulated, actual components made in React or sth similar.

That file has like, 60 lines. Calling it a "wall of HTML soup" is a bit disingenuous. But if you REALLY have that much aversion to code, there is no inherent reason why you couldn't split it even more. CSS being miles away is again, just a matter of taste. No inherent reason why you could't use Tailwind for example.

> why you could't use Tailwind for example

To have even more HTML soup? No thanks. Luckily I live in a world of better DX. With styled-components my CSS primitives are typechecked. Hell even with SCSS and CSS modules I have more sane and IDE supported experience.

Re: HTML Web Components

#229

Post by Xeamek »

bryanrasmussen wrote: post #227
Xeamek wrote: post #220

Earlier quoted context omitted.

But it is though? I'm not talking about everything facebook provides, but main content page is just a list of posts with with discussion underneath them. Sure, you can embed some media into the it, but still. There is nothing inherently different about structure of facebook post compared to a post on a forum. And yet, despite everything facebook is doing, the most (and only) reliable way to load new comments under th…

>But it is though? At some point quantitative change achieves a qualitative effect. I would think Facebook or LinkedIn or Twitter have all reached that qualitative effect to change from being just a discussion forum. However qualitatively the social functions of these apps present an extra functionality missing from traditional discussion forums. Being able to track users, notifications of the users updates, blocking…

I don't know if you are doing that intentionally, but you are completely ignoring the context of the argument, which is advocating of mixing and matching statically generated content and using component based spas only where it's needed.

In the parent coment alone I emphasized that I acknowledge that Facebook as a whole provides more then just a forum, but it's core content inherently doesn't differ much from being one.

Moreover, functionality like notifications or suggestions are inherently server generated, as such they don't require content itself to be served in specific way.

Re: HTML Web Components

#230

Post by Xeamek »

morbicer wrote: post #228
Xeamek wrote: post #225

Earlier quoted context omitted.

That file has like, 60 lines. Calling it a "wall of HTML soup" is a bit disingenuous. But if you REALLY have that much aversion to code, there is no inherent reason why you couldn't split it even more. CSS being miles away is again, just a matter of taste. No inherent reason why you could't use Tailwind for example.

> why you could't use Tailwind for example To have even more HTML soup? No thanks. Luckily I live in a world of better DX. With styled-components my CSS primitives are typechecked. Hell even with SCSS and CSS modules I have more sane and IDE supported experience.

But this styling lives in your component file, doesn't it? So it makes just as much "wall of [code] soup there as it makes it here". Tailwind was just an example pointing out you don't need a separate your code across entirely different directories, not recommendation of specific technology
Post reply on HN