101–110 of 248 posts
I worked with Polymer-based components ~2 years ago (an eternity in frontend-land), and I want to share my biggest pain point: you may want to integrate a ` `, but it does not "look right" in your design (eg white website, but the carousel has a black background). If the author did not set up CSS variables, you have to either try overriding stuff, or fork it. This problem is why every organization (eg GE with Predix…
Given that they were introduced in 2011, and in regards to their usage you hear... well crickets I think we can safely say that web components have failed. It doesn’t look similar to React at all, and still suffers from the same issues that jQuery does.
> Given that they were introduced in 2011, and in regards to their usage you hear... well crickets > I think we can safely say that web components have failed. > It doesn’t look similar to React at all, and still suffers from the same issues that jQuery does. jQuery? I think your just making up nonsense there. Fully ten percent of the web is using web components at this typing, and it's continued growth is steady as…
> Fully ten percent
Citation needed. I’m sure it could be true, but it seems a high number for something that I’ve literally heard about for the first time today.
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…
:is()
https://developer.mozilla.org/en-US/docs/Web/CSS/:is
there's a lot New coming into web all the time. I watch chrome status for drops.
>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…
> "I don't think we need new complicated technologies to solve the kinds of problems React solves. If anything, we need less, like an alternative to the current DOM model." It seems to me as if you're saying: "We don't need new complicated technologies." "Also, we need a new, complicated replacement to the time-tested DOM." This probably wasn't the intent but it exposes the need for web components to be built the way…
display: block;
display: inline;
display: run-in;
display: flow;
display: flow-root;
display: table;
display: flex;
display: grid;
display: ruby;
display: block flow;
display: inline table;
display: flex run-in;
display: list-item;
display: list-item block;
display: list-item inline;
display: list-item flow;
display: list-item flow-root;
display: list-item block flow;
display: list-item block flow-root;
display: flow list-item block;
display: table-row-group;
display: table-header-group;
display: table-footer-group;
display: table-row;
display: table-cell;
display: table-column-group;
display: table-column;
display: table-caption;
display: ruby-base;
display: ruby-text;
display: ruby-base-container;
display: ruby-text-container;
display: contents;
display: none;
display: inline-block;
display: inline-table;
display: inline-flex;
display: inline-grid;
React 16.6.0 base library, minified: 6.21 kb
React 16.6.0 DOM integration, minified: 100.39 kb
Earlier quoted context omitted.
> 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…
Is that really valid ES6? Or are you using typescript
I worked with Polymer-based components ~2 years ago (an eternity in frontend-land), and I want to share my biggest pain point: you may want to integrate a ` `, but it does not "look right" in your design (eg white website, but the carousel has a black background). If the author did not set up CSS variables, you have to either try overriding stuff, or fork it. This problem is why every organization (eg GE with Predix…
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.
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.
Yeah, I didn't really understand why there was a need for an overhaul like that. I honestly was hoping that there'd be a better story for databinding, types, etc. I just gave up and went back to React.
LitElement is able to focus on providing the best base class to build a Web Component. I think it is almost there.
But in answer to the question, no. I doubt it. I tried building a site using polymer when if first came out. It was harder than the in house thing I'd previously been using and after about a year, the spec had moved on and my site looked like this author's blog: a big white page and some JavaScript errors.
I'm not the sort of person who enjoys rewriting my app every year to suit the whims of the framework it's on top of, so my plan is to emit boring HTML until something equally stable yet better comes along.
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.
Perf boost compared to what? It can't be a FCP perf boost relative to server-side rendered plain old CSS and HTML, because shadow DOM requires client-side JavaScript. Plain old CSS is able to parse and render before the JS required to launch web components has even finished.