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

Web Components Eliminate JavaScript Framework Lock-In

jakelazaroff.com

Post reply on HN
Print view View original

231–240 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#231

Post by WorldMaker »

recursive wrote: post #227
WorldMaker wrote: post #208

Earlier quoted context omitted.

Interesting, thanks. Your mutation tracker isn't enough like "pure" RxJS Observables for my tastes and what I've been doing with my itch, but you captured a few of the things I'm covering in my system and are probably the next closest I've seen to what I've been doing (and I tried to research a deep dive). I think the only other thing is that I took an approach that observable change bindings look different from stat…

I was also influenced quite a bit by knockout. SSR was explicitly not a goal of mine. To me, SSR as a feature in a framework like this is mostly interesting in the context of server/client continuity like rehydration. But I have a feeling the constraints imposed by anything like this aren't going to be worth it. If I was doing pure server rendering, flat text templates seem like the sweet spot, since it's fundamental…

Knockout was designed in the heyday of the "progressive enhancement" era so it seems hard for me to claim a Knockout influence/inspiration if I'm not at least contemplating "progressive enhancement" of some sort. SSR isn't really my goal on that front but progressive enhancement/SSG (static site generation) certainly is a side goal for me (that's what I would like to have to self-host my own documentation site in something resembling the framework itself, rather than Jekyll or Docusaurus or whatever), but again not a main priority. It feels like the case for me where there is a lot of bleedover between SSR, SSG, and progressive enhancement and solving one basically solves all of them.

> I probably would not choose to use javascript or observables/signals.

This seems to be a case where we differ. In one obvious part because I don't tend to like signals and think they are very different from observables (because they are harder to encapsulate and offer fewer operators and tend to bleed too many accidental imperative escape hatches). Observables, to me, are just as useful to describe "open this file, read its contents, convert it from Markdown to HTML, then bind it to innerHTML here" on the server side as "fetch this URL, read its contents, convert it from Markdown to HTML, then bind it to innerHTML here" on the client side. Very different forms of interactivity, but there is still an interactivity there that a good observable pipeline can describe. Especially when you start to get into the idea that the difference between "open this file" and "fetch this URL" is tiny and can be dependency injected. Same component, slightly different inputs, slightly different expected outputs (you expect the server side binding to complete, whereas you expect the client side one to live for some time and continue to respond to different URLs from input).

Re: Web Components Eliminate JavaScript Framework Lock-In

#232

Post by zztop44 »

codegeek wrote: post #89
lopis wrote: post #7

Earlier quoted context omitted.

This is not my experience at all. Why can't a full stack dev know react or angular?

GP didnt say that. They said lot of devs become "front end" or "back end" specialists which means that they cannot do full stack. Full stack devs knowing React is fine. The problem is that most "React devs" don't know full stack and most "backend devs" don't know full stack.

Why does being a front end or back end specialist mean you can’t do full stack? If I’m a full stack dev that’s a back end specialist I can still write a complete feature myself just fine, thank you very much. But of course, if I’m having trouble with some part on the front end I might ask a front end specialist colleague for help, and vice versa.

Re: Web Components Eliminate JavaScript Framework Lock-In

#233

Post by socketcluster »

djrenren wrote: post #226
socketcluster wrote: post #220

The main problem with the Shadow DOM which makes people avoid it is the inability to use CSS externally to style the elements which are generated internally by the component... This is unfortunate because the Shadow DOM is essential if you want to work with child components slotted into it from the outside. This opens up many use cases. There is one alternative which is not being considered; it's possible for compone…

This is a great approach for components that want to inherit all styling from their context. In cases where you want to introduce just a little styling, the CSS Parts API is really cool: https://developer.mozilla.org/en-US/docs/Web/CSS/::part

Thanks for pointing this out. I should probably mention this approach in my article for cases when you need to work with slotted elements but don't want to inherit all page styles.

Re: Web Components Eliminate JavaScript Framework Lock-In

#234

Post by itslennysfault »

claytongulick wrote: post #191
itslennysfault wrote: post #118

Earlier quoted context omitted.

I was actually just looking at that after posting this (lit is new to me). That's a pretty cool solution. I'd still prefer an option to have the html in its own file, but that is just my taste. I know a lot of people feel exactly the opposite.

Maybe a bit pedantic - but I prefer using lit-html, not lit. Lit is a bit too "frameworky" for my taste, I generally just use vanilla classes that extend HTMLElement and have a render function that renders the lit-element template to the light dom. Something like: import {html, render} from 'lit-html'; class AppComponent extends HTMLElement { connectedCallback() { this.template = () => html` `; this.render(); } rende…

Perfect, and perfect timing. I was recently tasked with creating a small standalone web app and everything feels like overkill to me. This might be the perfect fit. Thanks for the explanation.

Re: Web Components Eliminate JavaScript Framework Lock-In

#235

Post by wayfinder »

WorldMaker wrote: post #148
wayfinder wrote: post #14

Earlier quoted context omitted.

As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do t…

> HTML(Div(Strong(text))) is terrible* > This is what JSX compiles to behind the scenes. Oh, it is much worse than that. By classic default it is: React.createElement('div', { /* props and attributes ... */ }, React.createElement('strong', { /* ... */ }, text)) Recent updates and other JSX frameworks simplified the name of `React.createElement` to just `jsx` or `h`. I've seen projects that manually write `h` calls li…

Yeah, you're right. I was kind of simplifying it. API-wise, it's more like document.createElement() but I didn't want to asterisk that because document.createElement() is actually a thing and I didn't want people to think it was a simple layer on top of document.createElement.

Re: Web Components Eliminate JavaScript Framework Lock-In

#236

Post by wayfinder »

marcosdumay wrote: post #68
wayfinder wrote: post #14

Earlier quoted context omitted.

As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do t…

> template It's new and has no significance for the history. But I think it's relevant to point out that isn't horrible. And that those articles about web components are doing a really bad job of using constant strings instead of this.shaddow.innerHTML = getElementById("myhtml").innerHTML.

The implementation is new but as far as the UX goes, it's very similar to . That said, the UX is going to be slightly better for simply because it's is an official standard and so IDEs and tooling will be more likely to support it without additional extensions or plugins.

Re: Web Components Eliminate JavaScript Framework Lock-In

#237

Post by [deleted] »

throwaway_1987 wrote: post #145
wayfinder wrote: post #40

Earlier quoted context omitted.

Your criticism was the biggest one of React when it came out -- mixing view code with your controller code. Big no no. Everyone loved the MVC pattern (model-viewer-controller where you separate these things in different places) and what React did was a big no no. But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. In other lan…

>But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. Most projects that I have been involved with have some kind of build system that does all sort of magic. It should be possible to include the template in the JS file during the build process

[deleted]

Re: Web Components Eliminate JavaScript Framework Lock-In

#238

Post by jakelazaroff »

EnergyAmy wrote: post #216
jakelazaroff wrote: post #155

Earlier quoted context omitted.

I find it very useful for embedding interactive demos on my blog that are mostly independent of the styles for the rest of the site (for example, the article here). But for what it’s worth, there is discussion of an “open-stylable” shadow DOM mode that addresses those concerns: https://github.com/WICG/webcomponents/issues/909

Shadow DOM was a mistake. It's a 0.1 version that was unfortunately pushed out as a completed standard. Basic stuff is missing like your link. The entire thing should be deprecated and we should start from scratch. If you want to embed something that doesn't use your page's styles, we already have iframes. Shadow DOM is just a half-assed recreation of that.

How would you build, say, a component library like Shoelace [1] using iframes?

[1] https://shoelace.style/

Re: Web Components Eliminate JavaScript Framework Lock-In

#239

Post by wayfinder »

menssen wrote: post #39
dbingham wrote: post #6

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to buil…

"Lots of people are still using it, but nobody can quite remember why." I can remember why. This, and every other article I've ever read arguing to replace React with Web Components, completely misunderstands the point of React. It isn't about JSX. It isn't about encapsulation. It isn't about reusability. It is about enabling a design pattern where *the user interface is a pure functional transformation of the applic…

I have to disagree.

It can't be that that design pattern because React did not invent it. Every server-side templating library is a pure functional transformation of application state. I can tell you that many people also ported that design pattern to JS.

What tripped library writers up is once they applied that pattern to JS, there is no way to actually define the transformation because to do that, you either write a template or the code-equivalent (i.e. using DOM as your data model). And that's where JSX came in.

Also, I think you have patterns completely confused.

Backbone is NOT in the same class as jQuery or React. Backbone is more like Redux, mobx, or React hooks because it's a data model library. In Backbone, you define "models" and "collections" -- basically, you use Backbone to store your application data in memory.

Backbone did have a views component to it but it actually could not generate any HTML. Look at this example from their docs:

  var Bookmark = Backbone.View.extend({
    template: _.template(...),
    render: function() {
      this.$el.html(this.template(this.model.attributes));
      return this;
    }
  });
It literally has jQuery and underscore.js! Backbone had no templating/HTML generation ability so when you used Backbone, you combined the fat Backbone classes with whatever horrific HTML-generation method you used to create a huge monster.

You can actually use Backbone.js with React since they are not in the same class. You would not, of course, because mobx is basically the same style of data modeling as Backbone.js but with almost no boilerplate.

Re: Web Components Eliminate JavaScript Framework Lock-In

#240

Post by joshstrange »

xutopia wrote: post #5

I've seen the entire industry move towards React/Angular type frameworks and it's invariably been a really bad thing. Large projects end up with front end specialists and backend specialists and very few actual full stack devs. What ends up happening is that no one person can do an entire feature anymore. I'm all for web components!

In your opinion what is the “really bad thing” that React/Angular have resulted in? Is it just the fewer full stack devs? I mean I’m a full stack dev still while using Vue. But also specialization (at a certain scale) is nearly unavoidable.
Post reply on HN