71–80 of 248 posts
It's insane to me that everything Polymer was got reduced to LitElement which is basically a complete copy of React without React and without the immeasurable support of typescript, VSCode support IN the view and debugging directly in the TSX.
Web components are awesome I've been using them in production using StencilJS for a pretty large app for about a year now. Even though browser support is widely available there are still a few gotchas with web components, specially Shadow DOM. Not all community tools have caught up as well. For example you can't use Stripe v3 with Shadow DOM. Most analytics tools also cannot access the Shadow DOM. We had to remove Sh…
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.…
As expected, no mention of server-side rendering.
Ploymer was a crapshow and HTML import a nightmare for load times. Unless some sort of topology bundling is provided for web components I'm out. We tried to do generic components for multiple frameworks based in webcomponets and it was an utter failure in practice especially for low band networks.
I don’t understand the push to make userland component abstractions into native primitives. It’s perfectly fine for the browser to just implement low level primitives for frameworks like React to build on top of. It allows the framework to develop much faster. Web components kind of miss a lot of the reasons why React has taken off. Encapsulation is one thing but it’s the declarative way of handling state, effects, a…
They aren't trying to solve the same problems. The main problem they solve, that no other userland framework solves, is that I can now share a collection of my rich JavaScript components with every single web developer in the world regardless of the technology they build web apps with.
Earlier quoted context omitted.
> Web Components don’t offer a declarative way of updating the DOM; What does that mean? The methods provided by the web components spec appear declarative as do the methods provided by the DOM spec. Declarative example with nothing like innerHTML: https://developer.mozilla.org/en-US/docs/Web/API/Element/att... Either way this discussion is stupid as updating the DOM is stupid simple even without a framework. The DOM…
> The DOM is neither stateful or stateless, but rather that describes the implementation of your application logic. One of the bizarre realities with those forced to write their own "virtual DOM" library, as I have done, is to deal with all the so-called hidden state. Form field values, the user's current text selection, scrolling position. Without a virtual DOM, simply replacing existing nodes with innerHTML or repl…
Earlier quoted context omitted.
With LitElement you are still encoding markup in strings and only the interpolated expressions are typechecked [1]. Not to mention that LitElement is far more clunkier and tedious. [1] https://lit-element.polymer-project.org/guide/start#use-lite...
The lit-plugin VS Code extension provides type-checking and code-completion for lit-html temptlates. The approach can be adopted for a tsc plugin.
As expected, no mention of server-side rendering.
You can server side render a `video` element just the same way you would a `custom-element`. We've been doing it for years and there's no reason to think anything about that has changed. If you're looking to deep SSR which is arguable as far as benefit, check out approaches like https://github.com/ionic-team/stencil-ssr-starter
>Web Components will replace your frontend framework Yeah, I very much doubt that. Web Components is basically a suite of browser technologies. It's actually particularly heavy and I kind of hope it doesn't catch on personally, since it pushes so much to already giant monolithic web browsers. Frameworks and libraries like React and Angular are tools for developing applications first and foremost. The actual technolog…
Huh? It's a very small API built _into_ the web browser. What's heavy about it? It's kinda similar to how JSX works just with less bells and whistles, more standard web stuff.
> It disagrees with many of the (much more popular) frontend frameworks far too much.
Ember, React and others plan to eventually support them. So, I am unconvinced that it disagrees with them at all. In fact I think it enables them to have wider access to developers.