5 ms·

Web Components are a total mess and impossible to build anything of significance with. I can't even imagine how anyone would get anything done with them. It's l

Web Components are a total mess and impossible to build anything of significance with. I can't even imagine how anyone would get anything done with them. It's like an Angular developer, an artist, and a mid-2010s neural net walked into a bar and sketched out a spec by taking shots and passing it clockwise. Separation of languages is a silly way to separate things. You're building components: logic, structure and style are coupled. SwiftUI adopts the React model, and it succeeds because of it. One can build an app in React/SwiftUI in about 1/2 the time spent "separating concerns", and build systems still extract things out to be clean and performant, there's no sacrifice being made there. CSS is a shitshow and a total mess especially on large teams. React has nothing to do with how performant an app is and if anything speeds them up compared to anything previously, you may be confusing the power and ease with which it enables development as getting some drunk on building larger apps, but that's only because of how effective it is. Twitter is a good example, great performance. It's way more about the team than the tool, though certainly it will get easier over time to have the defaults be better at optimization for smaller teams who are ambitious. Most of the super bloated websites I see are basically news sites and other less-techy sites that are stuffed with ad tracking and have no tree shaking. The majority of React apps build with Webpack which supports tree shaking and lazy loading out of the box, plus React makes it possible to pre-render your entire app and deliver it as HTML that hydrates.

nawitus 6y ago
I've built several complex apps (which I suppose are "of significance") with web components. I just used a framework (Polymer in my case) to abstract away the web components API.
jeroenhd 6y ago
I have never used SwiftUI so I can't comment on it. However, separation of concerns doesn't need to take extra development time. Inlining all CSS and JS is like dropping the MVC model because creating all the necessary classes is taking too much time; focusing on short term gains only lead to a mediocre end result, one that nobody wants to maintain five years down the line. Good React is fine for large applications, but not for websites. Even in applications a few lines of Javascript and a rendering backend can replace entire JS frameworks. Try disabling Javascript for a day and you can see how many pages just become a white screen because whatever is replacing the browser's renderer isn't loading. > Twitter is a good example, great performance. I agree that it's a great example, but it performs horribly for me. I use their website on my phone and videos rarely play back properly, content jumps around while navigating, empty screens and loading bars are everywhere. Sometime I just have to reload because the Twitter website decided it doesn't want to load images anymore. Nitter links, on the other hand, load instantly, including image and video content, because of its minimalist approach. Server side rendering is a welcome improvement because it means the developer doesn't offload the website's calculations to their visitors. I'm fine with whatever framework people pick on the server, as long as my browser doesn't get its rendering engine replaced by the fancy framework for the week.
- nwienert 6y ago
  Writing inline styles != rendering inline styles, look at “atomic style extraction” which with a compile step gives you far better results: automatic dead code elimination, automatic partial loading that’s tied directly to your usage, and no more jumping between the thing you’re styling and the the thing itself. The nitpicks you have on Twitter are on specific behaviors (video and jumping and slow fetch) that have nothing to do with React. The site itself is lightweight and runs fast.
- kingdomcome50 6y ago
  I think the irony here is that MVC in its original form has largely fallen out of fashion the last few years. And it is precisely because physically separating all of the functionality into a model/view/controller files doesn't actually make development easier. This makes sense right? Logically it's all coupled, so separating the pieces, even if they are functionally responsible for different things, doesn't really produce a system that is easier to maintain. Look at the new default "razor pages" web project for .NET core. While it it is a little bit fancier, it basically brings back the same mental model that PHP has been using for decades. That is, cram all of the logic into a single file, and use a "service locator" pattern (I know it's actually DI under the hood) to "inject" extra functionality. In this way it is easy to trace where all of the pieces are coming from. Why abstract your `UserRegistrationView` to accept any `UserRegistrationModel` from a `UserRegistrationController` in a "decoupled" manner when the reality is that only one of any of that actually needs to exist ever? Might as well have the orchestration right next to the use-case! The above applies to (what I believe to be) a significant majority of use-cases. At least the interesting ones.
  - ricksharp 6y ago
    MVC - because spending 50% Of your time looking for the other file with the almost identical name is fun... wait now we need the view... nope back to the controller again... why can’t these files be next to each other... It’s ironic that this is done in the name of “Separation of concerns“ - You know what separates concerns: having everything that affects this component - in one place. That’s true separation of concerns. I’ve worked in multiple frameworks in multiple languages and nothing does it better than modern react (especially with webhooks).
la_fayette 6y ago
React is a nightmare when it comes to performance or energy efficiency... Downloading 500kb of js and processing this is just a nogo. The best advice to anyone interested in page speed, dont use this crap. https://youtu.be/plt-iH_47GE https://youtu.be/plt-iH_47GE
- throw1234651234 6y ago
  Use Gatsby and generate a static site w/ React? At least React is faster than Angular, which I strongly prefer.
  - pjmlp 6y ago
    Better, generate a static site without frameworks.
- ricksharp 6y ago
  My website which is entirely built in react (and uses Gatsby). Takes 4kb to full page render (1 file - static only - JavaScript disabled). That’s smaller than most any html+css especially if using some css library. Of course once that is loaded and if JavaScript is enabled, then it will start to load interactive stuff and prefetch (which is around 100kb - but I have a lot of interactive stuff - including a zork style adventure Easter egg in the site header).
  - la_fayette 6y ago
    Check the time to interactive. Rehydration creates a massive cpu increase. https://developers.google.com/web/updates/2019/02/rendering-on-the-web https://developers.google.com/web/updates/2019/02/rendering-...
    - ricksharp 6y ago
      In lighthouse, I see a score of 100 performance and time to interactive at 1.8secs. This is comparable to hacker news home page (which is purely static), but my first contentful paint was slightly faster (probably because my site is slightly smaller). Both sites were about 4 times faster (TTI) than google home page and typescript home page.
isochronous 6y ago
Weird, because we're using web components at my workplace to build complex web applications. We use Lit-Element as a base class and have come up with a top-down functional state pattern for data that removes the need for two-way binding. If a sub-component needs to update its state due to DOM interaction, it just fires off an event with info about that DOM interaction, and the data store for that component (another web component) does the necessary state modification, then fires off a "state-changed" event that tells all associated components to update their state from the "master" store (one line of code). All of the data elements use pure functions to do state modification, so doing complex operations is simply a matter of composing the appropriate functions. I've not used react myself other than playing with a few demos, but another developer on my team says the pattern is very similar to how react stores work, and the core modules that drive it are like 100 lines of code.
- nwienert 6y ago
  Lit-Element puts lipstick on the low level pig, but React excels in many ways beyond it. Consistency between props (vs attributes), can render server side, awesome side effect system that makes it world class at hmr. I think WebComponents have left a horrible taste in the mouth because they came well after React and others existed, didn’t take any inspiration or provide any abstractions that would help, did basically everything worse and seemingly without any discussion with real world devs, and then were hyped and pushed on everyone for years while they basically lacked all necessary features. Now, years later they have evolved and added libraries on top to smooth over all the weirdness, and if you squint they look similar, but the web would have been a better place if they had just provided some VDOM abstractions, style containment in a simple way, and so on rather than master-planned a High Modernist dystopia and then slowly painted over it until it resembled something like the organic cities that already existed.
  - isochronous 6y ago
    I guess maybe you had a different experience than I did, because I never had web components "pushed" at me in any way. It was always a technology I was keeping my eye on but was hesitant to invest in until the browser support was there, and now that the browser support arrived I've seen a grand total of ONE web-component-focused talk at the web dev conferences I've attended, and that one was given by our project lead.
aasasd 6y ago
> Twitter is a good example, great performance This statement alone invalidates your arguments, because evidently you never once tried opening Twitter on an underpowered machine, be that desktop or a phone.

nawitus 6y ago

I've built several complex apps (which I suppose are "of significance") with web components. I just used a framework (Polymer in my case) to abstract away the web components API.

jeroenhd 6y ago

I have never used SwiftUI so I can't comment on it. However, separation of concerns doesn't need to take extra development time. Inlining all CSS and JS is like dropping the MVC model because creating all the necessary classes is taking too much time; focusing on short term gains only lead to a mediocre end result, one that nobody wants to maintain five years down the line. Good React is fine for large applications, but not for websites. Even in applications a few lines of Javascript and a rendering backend can replace entire JS frameworks. Try disabling Javascript for a day and you can see how many pages just become a white screen because whatever is replacing the browser's renderer isn't loading. > Twitter is a good example, great performance. I agree that it's a great example, but it performs horribly for me. I use their website on my phone and videos rarely play back properly, content jumps around while navigating, empty screens and loading bars are everywhere. Sometime I just have to reload because the Twitter website decided it doesn't want to load images anymore. Nitter links, on the other hand, load instantly, including image and video content, because of its minimalist approach. Server side rendering is a welcome improvement because it means the developer doesn't offload the website's calculations to their visitors. I'm fine with whatever framework people pick on the server, as long as my browser doesn't get its rendering engine replaced by the fancy framework for the week.

nwienert 6y ago
Writing inline styles != rendering inline styles, look at “atomic style extraction” which with a compile step gives you far better results: automatic dead code elimination, automatic partial loading that’s tied directly to your usage, and no more jumping between the thing you’re styling and the the thing itself. The nitpicks you have on Twitter are on specific behaviors (video and jumping and slow fetch) that have nothing to do with React. The site itself is lightweight and runs fast.
kingdomcome50 6y ago
I think the irony here is that MVC in its original form has largely fallen out of fashion the last few years. And it is precisely because physically separating all of the functionality into a model/view/controller files doesn't actually make development easier. This makes sense right? Logically it's all coupled, so separating the pieces, even if they are functionally responsible for different things, doesn't really produce a system that is easier to maintain. Look at the new default "razor pages" web project for .NET core. While it it is a little bit fancier, it basically brings back the same mental model that PHP has been using for decades. That is, cram all of the logic into a single file, and use a "service locator" pattern (I know it's actually DI under the hood) to "inject" extra functionality. In this way it is easy to trace where all of the pieces are coming from. Why abstract your `UserRegistrationView` to accept any `UserRegistrationModel` from a `UserRegistrationController` in a "decoupled" manner when the reality is that only one of any of that actually needs to exist ever? Might as well have the orchestration right next to the use-case! The above applies to (what I believe to be) a significant majority of use-cases. At least the interesting ones.
- ricksharp 6y ago
  MVC - because spending 50% Of your time looking for the other file with the almost identical name is fun... wait now we need the view... nope back to the controller again... why can’t these files be next to each other... It’s ironic that this is done in the name of “Separation of concerns“ - You know what separates concerns: having everything that affects this component - in one place. That’s true separation of concerns. I’ve worked in multiple frameworks in multiple languages and nothing does it better than modern react (especially with webhooks).

la_fayette 6y ago

React is a nightmare when it comes to performance or energy efficiency... Downloading 500kb of js and processing this is just a nogo. The best advice to anyone interested in page speed, dont use this crap. https://youtu.be/plt-iH_47GE https://youtu.be/plt-iH_47GE

throw1234651234 6y ago
Use Gatsby and generate a static site w/ React? At least React is faster than Angular, which I strongly prefer.
- pjmlp 6y ago
  Better, generate a static site without frameworks.
ricksharp 6y ago
My website which is entirely built in react (and uses Gatsby). Takes 4kb to full page render (1 file - static only - JavaScript disabled). That’s smaller than most any html+css especially if using some css library. Of course once that is loaded and if JavaScript is enabled, then it will start to load interactive stuff and prefetch (which is around 100kb - but I have a lot of interactive stuff - including a zork style adventure Easter egg in the site header).
- la_fayette 6y ago
  Check the time to interactive. Rehydration creates a massive cpu increase. https://developers.google.com/web/updates/2019/02/rendering-on-the-web https://developers.google.com/web/updates/2019/02/rendering-...
  - ricksharp 6y ago
    In lighthouse, I see a score of 100 performance and time to interactive at 1.8secs. This is comparable to hacker news home page (which is purely static), but my first contentful paint was slightly faster (probably because my site is slightly smaller). Both sites were about 4 times faster (TTI) than google home page and typescript home page.

isochronous 6y ago

Weird, because we're using web components at my workplace to build complex web applications. We use Lit-Element as a base class and have come up with a top-down functional state pattern for data that removes the need for two-way binding. If a sub-component needs to update its state due to DOM interaction, it just fires off an event with info about that DOM interaction, and the data store for that component (another web component) does the necessary state modification, then fires off a "state-changed" event that tells all associated components to update their state from the "master" store (one line of code). All of the data elements use pure functions to do state modification, so doing complex operations is simply a matter of composing the appropriate functions. I've not used react myself other than playing with a few demos, but another developer on my team says the pattern is very similar to how react stores work, and the core modules that drive it are like 100 lines of code.

nwienert 6y ago
Lit-Element puts lipstick on the low level pig, but React excels in many ways beyond it. Consistency between props (vs attributes), can render server side, awesome side effect system that makes it world class at hmr. I think WebComponents have left a horrible taste in the mouth because they came well after React and others existed, didn’t take any inspiration or provide any abstractions that would help, did basically everything worse and seemingly without any discussion with real world devs, and then were hyped and pushed on everyone for years while they basically lacked all necessary features. Now, years later they have evolved and added libraries on top to smooth over all the weirdness, and if you squint they look similar, but the web would have been a better place if they had just provided some VDOM abstractions, style containment in a simple way, and so on rather than master-planned a High Modernist dystopia and then slowly painted over it until it resembled something like the organic cities that already existed.
- isochronous 6y ago
  I guess maybe you had a different experience than I did, because I never had web components "pushed" at me in any way. It was always a technology I was keeping my eye on but was hesitant to invest in until the browser support was there, and now that the browser support arrived I've seen a grand total of ONE web-component-focused talk at the web dev conferences I've attended, and that one was given by our project lead.

aasasd 6y ago

> Twitter is a good example, great performance This statement alone invalidates your arguments, because evidently you never once tried opening Twitter on an underpowered machine, be that desktop or a phone.