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

Web Components could replace frontend frameworks?

dannymoerkerke.com

Post reply on HN
Print view View original

211–220 of 248 posts

Re: Web Components could replace frontend frameworks?

#211

Post by AaronFriel »

westbrookjo wrote: post #73
AaronFriel wrote: post #12

The tooling is woefully inadequate, and the premiere Web Component tool is stringly typed to all heck which makes it a non-starter for me. I don't want giant blobs of runtime parsed text with no validation, syntax highlighting, and obviously no type checking. But yet, here's Polymer 3: static get template() { return html` .response { margin-top: 10px; } I like web components. Web components like you, too. `; } Cool.…

Types are cool, TypeScript is cool, and types with JSDocs are cool, https://dev.to/dakmor/type-safe-web-components-with-jsdoc-4i... and what's more, they're all cool with web components.

I'm confused, I scrolled down and still saw this:

    return html`
      ${this.format(this.title)}
      
    `;
That is not type checked. I can change any of the HTML tags in there, any of the attributes on the HTML tags, I can make the template ill-formed HTML, and nothing in my editor or build system will check that.

    const el = /** @type {TitleBar} */ (document.querySelector('title-bar'));
Why would I do that instead of this, if I'm using TypeScript?

    const el: TitleBar = document.querySelector('title-bar');
Moreover, this is an unsafe type coercion, we have no witness that the return value is a TitleBar. document.querySelector returns an HTMLElement, and if you were using strict TypeScript types this assignment would not type check.

Re: Web Components could replace frontend frameworks?

#212

Post by pjmlp »

RussianCow wrote: post #206
pjmlp wrote: post #134

Earlier quoted context omitted.

If I need to use server side rendering, there are plenty of server side rendering frameworks more mature than React/Preac. Any JS component library needs JS by definition.

> If I need to use server side rendering, there are plenty of server side rendering frameworks more mature than React/Preac. Not if you need both server-side rendering AND a rich frontend. Unless you want to duplicate logic between two frameworks.

Server-side rendering and a rich frontend are orthogonal.

And yes, JavaScript is absolutely not the best way to actually make use of the server rack.

https://www.techempower.com/benchmarks/

Re: Web Components could replace frontend frameworks?

#213

Post by pjmlp »

acemarke wrote: post #209
pjmlp wrote: post #145

Earlier quoted context omitted.

Were those discussions public? Yet another Chrome specific API?

https://github.com/WICG/main-thread-scheduling https://twitter.com/sebmarkbage/status/1050782447497961472 https://twitter.com/acdlite/status/1089273195281080335

Thanks for sharing, it seems pretty much specific to Chrome.

So it is anyone's guess if this will ever land in other browsers.

Re: Web Components could replace frontend frameworks?

#214

Post by RussianCow »

pjmlp wrote: post #212
RussianCow wrote: post #206

Earlier quoted context omitted.

> If I need to use server side rendering, there are plenty of server side rendering frameworks more mature than React/Preac. Not if you need both server-side rendering AND a rich frontend. Unless you want to duplicate logic between two frameworks.

Server-side rendering and a rich frontend are orthogonal. And yes, JavaScript is absolutely not the best way to actually make use of the server rack. https://www.techempower.com/benchmarks/

They are, unless you want to avoid duplicating logic, like I said. That's where most of the benefit of server-side rendering via JS comes from: you can render the initial page on the server, but then have the client-side framework take over on load, all from the same framework and with very minimal code duplication. Otherwise you have to write most of your rendering logic twice, in two different languages/frameworks.

Re: benchmarks, I don't know what that has to do with anything. JavaScript (via V8) is much faster than Ruby and Python, and yet Rails and Django are still massively popular. For most apps, using a super fast backend language is not a concern.

Re: Web Components could replace frontend frameworks?

#215

Post by kccqzy »

nitrogen wrote: post #136
kccqzy wrote: post #86

Earlier quoted context omitted.

When you control the data, innerHTML is fine. It's only untrusted data coming from the user that's the problem.

innerHTML has to parse the html, so won't it be a bit slower?

Wouldn't the JavaScript engine need to parse your long and complicated chains of `document.createTextNode(blah)` or `parent.appendChild(foo)`?

Re: Web Components could replace frontend frameworks?

#216

Post by kccqzy »

roguecoder wrote: post #149
kccqzy wrote: post #86

Earlier quoted context omitted.

When you control the data, innerHTML is fine. It's only untrusted data coming from the user that's the problem.

Only if you can, with absolute certainty, keep track of which of those is which, and never have it change, or have some offline process polute data that was supposed to be clean. There is almost never a reason to use innerHTML, and by avoiding it you reduce the surface that could be attacked.

You are just making things extreme without giving your fellow software engineers some confidence that they won't screw up. Plenty of variables are string constants, or numbers coerced into strings or some such. A good type system will always help though.

Re: Web Components could replace frontend frameworks?

#217

Post by tracker1 »

lstamour wrote: post #23
ssorallen wrote: post #11

Web Components don’t offer a declarative way of updating the DOM; it’s still `innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was a hassle to manage in any sizeable app because updating the view was left up to every dev to figure out themselves. React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature that Web Components does not offer at all. Vu…

There is lit-html and lit-element, though you can get tripped up by the difference between props and attributes coming from React JSX where everything is props because it’s all native JS until the DOM render... It’s tricky to recommend them because I’m using web components at work and find the transition from React especially rocky. But they are native and standard, and other frameworks are slowly moving in that dire…

You can absolutely use web components with react... you just have to use `` for webcomponents, since a capital first character will trigger JSX transforms.

So you can use, for example this set of components with a react application and get some of the best of both worlds. The only down side is attributes in web components aren't passable via the markup, only via DOM reference.

I happen to like react as-is, but Vue is probably much closer to web components and could see Vue becoming a compile to web components option sooner than later.

Re: Web Components could replace frontend frameworks?

#218

Post by zarzz »

founderling wrote: post #184
zarzz wrote: post #174

Earlier quoted context omitted.

If you are looking for just a simple load some html and replace this where my tag is kind of thing you are right, nothing does that because it’s more complicated then that... what about the styles of the included html? What about the behaviors (JavaScript) for it. How does that translate with the include? But, if you use Web Components, organize your code, and plan ahead, this is very doable today with Web Components…

It’s clean and simple How so? What is the Web Components equivalent of ?

As an example HN here on might structure things like this:

... all the main body content ...

To answer your direct question, the WC equivalent of is the tag. The loads the component definition and all the resources related to them (See ZephJS for how this is super easy to do: https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...)

and are defined in the script. They carry with them all the content, layout, and behavior for those parts of the site. This provides a nice clean separation between the page and the header and footer pieces. Changing the header or footer becomes just changing those parts. This is absolutely easier then using react or angular for the equivalent kind of things. Does it provide all that react/angular does, of course not. But it is infinitely cleaner then using either. Especially with ZephJS (gratuitous plug).

Re: Web Components could replace frontend frameworks?

#219

Post by WorldMaker »

_bxg1 wrote: post #118
ssorallen wrote: post #11

Web Components don’t offer a declarative way of updating the DOM; it’s still `innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was a hassle to manage in any sizeable app because updating the view was left up to every dev to figure out themselves. React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature that Web Components does not offer at all. Vu…

What I don't get is why there isn't a native, declarative DOM templating API yet. It would be so much faster and would mostly eliminate the need for React and the like. Instead of a "virtual dom", a native "dom buffer".

In terms of "dom buffer" there's a proposal in the works for the buffer "other half" to `window.requestAnimationFrame()` to queue DOM reads (where RAF is the place to queue DOM writes). So far I've heard it has the unimaginative and odd use of grammar name `window.requestAnimationFrameAfter()`.

Still would be too low level to easily work with though without a framework like React.

Re: Web Components could replace frontend frameworks?

#220

Post by augustl »

madeofpalk wrote: post #181
augustl wrote: post #138

Earlier quoted context omitted.

I have high hopes for Flutter/Hummingbird in that regard. When their renderer is implemented using web APIs, this is basically what we'll be getting.

this is just replacing framework a with framework b. It's not a "native, declarative DOM templating API yet"

Well, yes and no. They are implementing a rendering engine that supports things the web famously doesn't support, which includes fundamentals like UITableView from iOS. They are doing this by leveraging new APIs to access what browser layout engines do under the hood. So in that way, it generates native browser elements, and their API is declarative. So it's at least one abstraction layer below React and friends.
Post reply on HN