4 ms·

> I would much rather take "boring", stable languages and frameworks I would argue that you don't need a heavy framework to make maintainable JavaScript applic

> I would much rather take "boring", stable languages and frameworks I would argue that you don't need a heavy framework to make maintainable JavaScript application. For large enterprise applications that must last a decade or more you want to use standards (such as Web Components) implemented by the web browser itself instead of third-party libs such as React.

nicoburns 6y ago
I suspect React has a much greater chance of being around in 10 years time than web components. Simply because there are a lot more people using React than web components. React is a boring, stable framework at this point.
- flowerlad 6y ago
  > Simply because there are a lot more people using React than web components. Couldn't you have said that about React vs Angular 5 years ago? > React is a boring, stable framework at this point. And that's why it won't be the most popular framework in 10 years time. React started off as a simple and straightforward library. The React team didn't want to stand still, so they improved it. The "improvements" are making React big, fat, bloated and complex, and failures and perf issues harder to debug
  - nicoburns 6y ago
    1. 5 years ago no: React was already the #1 JS frontend framework at that point. In terms of mindshare if not project volume. 2. I think the key difference is that Angular was a nightmare to work with, especially on larger projects. Whereas React is fairly simple, and tends to be easily maintainable over time. > React started off as a simple and straightforward library. It still is. The implementation is kinda complex at this point, but the API is still super simple.
    - flowerlad 6y ago
      > In terms of mindshare if not project volume. Regardless, you missed the point. Which was that, frameworks come and go. The DOM and other APIs implemented by the browser, on the other hand, are here to stay. Very few things built into the browser have been taken away (such as blink and frameset). > The implementation is kinda complex at this point Right. And that makes failures and perf issues hard to track down. If you know how to program using APIs and components built into the browser, that is easier at this point.
      - nicoburns 6y ago
        > Regardless, you missed the point. Which was that, frameworks come and go. Do they? Rails was released in 2005: it's still here. Ditto for Django. It's true that historically frontend frameworks haven't had the same longevity. But nothing in that space had gotten to the same level of momentum as React has. Except jQuery, and that's still here and maintained too. In contrast, the web component APIs do not have momentum. I would not be entirely surprised if parts of them were removed in future due to lack of use. > Right. And that makes failures and perf issues hard to track down. > If you know how to program using APIs and components built into the browser, that is easier at this point. I rather disagree on this point. I've only seen React slow in 2 circumstances: 1. Too many DOM elements for the browser to cope with. At this point you need to start looking into virtualisation solutions, which is easy to do with a library like react-window. And is exactly what you would do with raw DOM APIs. 2. Excessive re-renders. There is excellent documentation on how to avoid this (memoising transformation functions). And a very simple mental model for how it works (following the usual JavaScript === equality rules). Avoiding this in vanilla DOM code is much harder, because you have a choice between re-rendering everything any time anything updates, doing very tricky piecemeal updates which quickly becomes unmaintainable, or re-inventing a react-like diffing system.

nicoburns 6y ago

I suspect React has a much greater chance of being around in 10 years time than web components. Simply because there are a lot more people using React than web components. React is a boring, stable framework at this point.

flowerlad 6y ago
> Simply because there are a lot more people using React than web components. Couldn't you have said that about React vs Angular 5 years ago? > React is a boring, stable framework at this point. And that's why it won't be the most popular framework in 10 years time. React started off as a simple and straightforward library. The React team didn't want to stand still, so they improved it. The "improvements" are making React big, fat, bloated and complex, and failures and perf issues harder to debug
- nicoburns 6y ago
  1. 5 years ago no: React was already the #1 JS frontend framework at that point. In terms of mindshare if not project volume. 2. I think the key difference is that Angular was a nightmare to work with, especially on larger projects. Whereas React is fairly simple, and tends to be easily maintainable over time. > React started off as a simple and straightforward library. It still is. The implementation is kinda complex at this point, but the API is still super simple.
  - flowerlad 6y ago
    > In terms of mindshare if not project volume. Regardless, you missed the point. Which was that, frameworks come and go. The DOM and other APIs implemented by the browser, on the other hand, are here to stay. Very few things built into the browser have been taken away (such as blink and frameset). > The implementation is kinda complex at this point Right. And that makes failures and perf issues hard to track down. If you know how to program using APIs and components built into the browser, that is easier at this point.
    - nicoburns 6y ago
      > Regardless, you missed the point. Which was that, frameworks come and go. Do they? Rails was released in 2005: it's still here. Ditto for Django. It's true that historically frontend frameworks haven't had the same longevity. But nothing in that space had gotten to the same level of momentum as React has. Except jQuery, and that's still here and maintained too. In contrast, the web component APIs do not have momentum. I would not be entirely surprised if parts of them were removed in future due to lack of use. > Right. And that makes failures and perf issues hard to track down. > If you know how to program using APIs and components built into the browser, that is easier at this point. I rather disagree on this point. I've only seen React slow in 2 circumstances: 1. Too many DOM elements for the browser to cope with. At this point you need to start looking into virtualisation solutions, which is easy to do with a library like react-window. And is exactly what you would do with raw DOM APIs. 2. Excessive re-renders. There is excellent documentation on how to avoid this (memoising transformation functions). And a very simple mental model for how it works (following the usual JavaScript === equality rules). Avoiding this in vanilla DOM code is much harder, because you have a choice between re-rendering everything any time anything updates, doing very tricky piecemeal updates which quickly becomes unmaintainable, or re-inventing a react-like diffing system.