Web Components could replace frontend frameworks? • Hacker News Board

Re: Web Components could replace frontend frameworks?

#231

Post by galaxyLogic » Fri, Apr 12, 2019, 11:46 PM UTC

westbrookjo wrote: post #175

One thing that is particularly important to take into account when comparing web components to framework is that they can and should work together. If indeed "web components" replace your "framework" it will most likely be because a new framework that takes advantage of web components and all that the web is now replaces your old framework. Already libraries that combine popular concepts like hooks from React with we…

True. One more thing about web-components is that they are a standard. Vue, React, JQuery are not.

Re: Web Components could replace frontend frameworks?

#232

Post by galaxyLogic » Fri, Apr 12, 2019, 11:49 PM UTC

revskill wrote: post #4

It's not about implementation details, it's about programming paradigm. In the case of React, it's - Declarative, functional API to write reuseable UI. - REAL reusable business logic with React Hooks. - REAL universal data fetching with React Suspense. - REAL error boundary with Error Boundary. - Learn once, write everywhere! Do Web Components have the above benefits (yet) ?

Of course not. But many smaller apps don't need all of those.

Think about HTML how it started it was very rudimentary. At that point there was very many better "frameworks" for creating GUIs and applications. Yet HTML was in many cases good enough and since it was so simple it was able to evolve.

Re: Web Components could replace frontend frameworks?

#233

Post by AaronFriel » Fri, Apr 12, 2019, 11:56 PM UTC

no_way wrote: post #223

AaronFriel wrote: post #211

Earlier quoted context omitted.

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…

There exists plugin for VSCode which checks for attributes inside template literal https://marketplace.visualstudio.com/items?itemName=runem.li...

That looks extremely useful though it's definitely in the "early adopter" phase of utility. It looks like this extension and the underlying TypeScript plugin that allows typechecking are being developed by a single person, and I think a team or individual would have to make a judgment call on whether to depend on it.

Re: Web Components could replace frontend frameworks?

#234

Post by westbrookjo » Sat, Apr 13, 2019, 2:33 AM UTC

threeaccents wrote: post #226

westbrookjo wrote: post #72

Earlier quoted context omitted.

You might be interested in https://github.com/bennypowers/stripe-elements Stripe v3 with Shadow DOM.

Thanks I had actually seen this while looking into a workaround for us. However I thought that LitHTML elements only worked with other LitHTML elements since you need the correct bundler for it. StencilJS projects don't have any bundling system.

LitHTML and LitElement don't need a specific bundler, they work with whatever tools (or not) you'd like. You might want to get them another look!

Re: Web Components could replace frontend frameworks?

#235

Post by westbrookjo » Sat, Apr 13, 2019, 3:10 AM UTC

lstamour wrote: post #93

spankalee wrote: post #51

Earlier quoted context omitted.

Performance issues? Native Shadow DOM, especially with Constructible Stylesheets, is a perf boost. Limiting style resolution to smaller scopes and less rules is good.

True, I don’t have benchmarks, but there was a time period where shadow DOM was popularly disabled due to performance hits, but perhaps it was all the performance hit of polyfills and less efficient implementations in browsers. https://github.com/WICG/construct-stylesheets/blob/gh-pages/... is interesting, though Sass still looks unlikely to be added to the browser so we’ll always need some amount of CSS compilation…

You might want to check out https://cssdb.org/#nesting-rules native nested CSS rules have hit stage 1!

Re: Web Components could replace frontend frameworks?

#236

Post by lstamour » Sat, Apr 13, 2019, 4:22 AM UTC

westbrookjo wrote: post #235

lstamour wrote: post #93

Earlier quoted context omitted.

True, I don’t have benchmarks, but there was a time period where shadow DOM was popularly disabled due to performance hits, but perhaps it was all the performance hit of polyfills and less efficient implementations in browsers. https://github.com/WICG/construct-stylesheets/blob/gh-pages/... is interesting, though Sass still looks unlikely to be added to the browser so we’ll always need some amount of CSS compilation…

You might want to check out https://cssdb.org/#nesting-rules native nested CSS rules have hit stage 1!

I checked the spec earlier and it’s impossible to make it backwards compatible with Sass without some slight edits, at least according to their GH issue on it. It’s worth watching though I suspect or something like it will be added before we see broad adoption! :)

Re: Web Components could replace frontend frameworks?

#237

Post by founderling » Sat, Apr 13, 2019, 7:28 AM UTC

zarzz wrote: post #218

founderling wrote: post #184

Earlier quoted context omitted.

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,…

    the WC equivalent of  is the  tag

I beg to differ. My would insert the html in the footer.html file. While will execute javascript. Then the javascript has to somehow prepare magic so that will be replaced by some html.

The link to the library you gave does not help here. Because I am thinking about browser technology here. What has to go into components.js (without using a library) to make be replaced with the html in footer.html?

Re: Web Components could replace frontend frameworks?

#238

Post by Hurtak » Sat, Apr 13, 2019, 7:34 AM UTC

founderling wrote: post #119

I wonder why HTML never got includes. It would be so nice to just write: On Hacker News, for the first pageview, this would load the whole "Guidelines | FAQ | Support ..." section. On all other pageloads, the browser would already have it in the cache. So it does not have to be loaded again. Building complex websites would become so much nicer. Because each part of a page would be an include.

Because that would cause cascade of tens or even hundreds of http requests just to download the html.

On the other hand new JS modules work like that, this is less of a problem on http2 and also can be mitigated by tooling.

Re: Web Components could replace frontend frameworks?

#239

Post by madeofpalk » Sat, Apr 13, 2019, 11:04 AM UTC

augustl wrote: post #220

madeofpalk wrote: post #181

Earlier quoted context omitted.

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.

....no and no. The call was for a declarative interface to the DOM, like React, built into the browser. Flutter, being not built into the browser, is not that.

Re: Web Components could replace frontend frameworks?

#240

Post by MaulingMonkey » Sat, Apr 13, 2019, 12:08 PM UTC

kccqzy wrote: post #216

roguecoder wrote: post #149

Earlier quoted context omitted.

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.

In the words of Jeff Atwood, "Give me parameterized SQL, or give me death" - and HTML escaping is little different. My fellow "software engineers" are human. They will screw up. That's simply a matter of human nature and statistics. Even if we only employ godlings, we'll eventually hire a human intern.

"It happens to be safe for the moment because it's a constant" isn't a high enough bar. I've refactored plenty of string constants to new locations, and then to dynamic strings. If that's the bar you're using, every such refactoring is now a security critical change that requires a thorough security audit.

There are uses of innerHTML, but the post you're replying to acknowledges that - "almost never". If you're building the APIs that enable safe DOM manipulation, you have some use cases. If you're serving HTML fragments directly from the server, you have some use cases - although I'd hope you're using safe APIs serverside if it's dynamic, instead of hand-building HTML in code!