6 ms·

> Everyone likes to complain about SPAs, as if terrible load times are a fundamental trait of frontend frameworks. That is not at all the case. I disagree. SPA

> Everyone likes to complain about SPAs, as if terrible load times are a fundamental trait of frontend frameworks. That is not at all the case. I disagree. SPA frameworks attempt to re-implement browser UI and DOM within Javascript. Of course the result is buggy and slow. The browser already has a UI and DOM framework. Use it. (Yes, I know it's ugly. Such is life.)

nickserv 7y ago
Depends on the target audience. Many customers will be sold on how pretty an app is, sometimes to the point of overlooking missing features. Having a good looking app becomes a competitive advantage, and therefore important to spend time on. Such is life.
- otabdeveloper4 7y ago
  Your point is orthogonal, even if true. My point is that SPA frameworks are necessarily buggy and inefficient - after all, their whole point is to reimplement in a bespoke fashion the stuff that the browser already implemented. Buggy and inefficient stuff sometimes makes sense to a business, this is true.
  - jiofih 7y ago
    That’s a common misunderstanding and absolutely not true. They are abstractions and not reimplementation, and in practice can help achieve way better performance than what would naively come out. React is not a particularly good example of that. They also solve problems like state synchronization and mutations that the browser has zero facilities for. As mentioned in another comment above, in any medium sized project you’ll have implemented more than half a framework abstracting the DOM already.
  - SirHound 7y ago
    Trying to remember the last bug I encountered in React. I’ll be a while.
- pjmlp 7y ago
  That can be achievable with designers that actually know their way around HTML and CSS.
cynicalreason 7y ago
The problem with UI/DOM is the mental model of working with it. For me I think SPA frameworks need to provide an abstraction layer that makes it easy to work with. Thus React. I can think of it in a functional pattern and let it abstract the DOM/UI for me, ofc I understand there's a cost to it but that cost will greatly be overshadowed development & maintenance costs.
- rimliu 7y ago
  Whatever happened to the "think of the user experience first". I am sad this shift to "it's easier for me to develop, who cares about the users" happened.
  - snowl 7y ago
    a developer who doesn't think of that is going to do that with react or without react. freeing up development time to focus on better user experience is more possible by using a framework such as react.
  - Blaiz0r 7y ago
    This is because Front-end web developement has been taken over by back-end developers. Few developers complained about JavaScript until Back-end developers became 'Fullstack' and had to start working with it and tried to apply the same mental model they had used with Java or Python etc. CSS was always something you had to dedicate time to, to master and learn the quirks of the current and past browsers, until Back-end developers decided it was 'terrible' and a race to the bottom of CSS frameworks was created and nobody remembered proper selection or specicifity as BEM was adopted. HTML was a tool for layout which developers made good choices for thoughtful semantic code, so that it was easily readable, for both man and machine, yet it was a manual process. Then Back-end developers didn't have the time to learn something new and everything is a div and if you're lucky it will have a role.
    - calferreira 7y ago
      As a "fullstack" i disagree with this view. This is the "if all you have is a hammer, everything looks like a nail" kind of view. What i believe is, the complexity of developing software has been increasing and we have a lot of pressure specially due to time constraints that we are always reinventing the wheel in order to meet deadlines and try to make things easier. And the result is always the same: bloat.
gridlockd 7y ago
> I disagree. SPA frameworks attempt to re-implement browser UI and DOM within Javascript. Of course the result is buggy and slow. SPA frameworks don't re-implement the DOM, they provide an interface to the DOM that is more usable. That may or may not have significant overhead, but it's not a given. You have these benchmarks to show that "vanilla JS" is faster, but that's not real-world application code. Because of the usability issues, application authors are way more likely to not write optimal vanilla code. In particular, any DOM modification is extremely slow, so redundant modifications are very wasteful. Avoiding those is something that a framework/virtual-dom can do for you, to let you write simpler code. Furthermore, anybody who writes a real application ends up abstracting the DOM interface, so they're already halfway at an ad-hoc framework. Not abstracting the DOM would result in an insane amount of boilerplate code, which would hamper developer productivity, which would result in even less time spent considering performance. Disclaimer: All of this is true for applications, not for simple websites with minimal dynamic interaction. You're likely better off rendering those server-side and then attaching a couple of event handlers on page load.
- deleted 7y ago
  [deleted]
SirHound 7y ago
The imperative DOM “framework” available is far more error-prone than the state->view, declarative model of React. It’s ugliness is more than skin deep.
vearwhershuh 7y ago
I agree entirely, except for the necessarily ugly part. You can use intercooler.js to wire in very usable modern UX with very little overhead, relying on the native, screaming fast DOM implementation.
pkstn 7y ago
I'd argue most of the modern frameworks with all the bells and whistles (Redux, Hooks, ...) are even more ugly, and actually harder to master. https://medium.com/re-dom/master-the-dom-bc1a2a06089b https://medium.com/re-dom/master-the-dom-bc1a2a06089b

nickserv 7y ago

Depends on the target audience. Many customers will be sold on how pretty an app is, sometimes to the point of overlooking missing features. Having a good looking app becomes a competitive advantage, and therefore important to spend time on. Such is life.

otabdeveloper4 7y ago
Your point is orthogonal, even if true. My point is that SPA frameworks are necessarily buggy and inefficient - after all, their whole point is to reimplement in a bespoke fashion the stuff that the browser already implemented. Buggy and inefficient stuff sometimes makes sense to a business, this is true.
- jiofih 7y ago
  That’s a common misunderstanding and absolutely not true. They are abstractions and not reimplementation, and in practice can help achieve way better performance than what would naively come out. React is not a particularly good example of that. They also solve problems like state synchronization and mutations that the browser has zero facilities for. As mentioned in another comment above, in any medium sized project you’ll have implemented more than half a framework abstracting the DOM already.
- SirHound 7y ago
  Trying to remember the last bug I encountered in React. I’ll be a while.
pjmlp 7y ago
That can be achievable with designers that actually know their way around HTML and CSS.

cynicalreason 7y ago

The problem with UI/DOM is the mental model of working with it. For me I think SPA frameworks need to provide an abstraction layer that makes it easy to work with. Thus React. I can think of it in a functional pattern and let it abstract the DOM/UI for me, ofc I understand there's a cost to it but that cost will greatly be overshadowed development & maintenance costs.

rimliu 7y ago
Whatever happened to the "think of the user experience first". I am sad this shift to "it's easier for me to develop, who cares about the users" happened.
- snowl 7y ago
  a developer who doesn't think of that is going to do that with react or without react. freeing up development time to focus on better user experience is more possible by using a framework such as react.
- Blaiz0r 7y ago
  This is because Front-end web developement has been taken over by back-end developers. Few developers complained about JavaScript until Back-end developers became 'Fullstack' and had to start working with it and tried to apply the same mental model they had used with Java or Python etc. CSS was always something you had to dedicate time to, to master and learn the quirks of the current and past browsers, until Back-end developers decided it was 'terrible' and a race to the bottom of CSS frameworks was created and nobody remembered proper selection or specicifity as BEM was adopted. HTML was a tool for layout which developers made good choices for thoughtful semantic code, so that it was easily readable, for both man and machine, yet it was a manual process. Then Back-end developers didn't have the time to learn something new and everything is a div and if you're lucky it will have a role.
  - calferreira 7y ago
    As a "fullstack" i disagree with this view. This is the "if all you have is a hammer, everything looks like a nail" kind of view. What i believe is, the complexity of developing software has been increasing and we have a lot of pressure specially due to time constraints that we are always reinventing the wheel in order to meet deadlines and try to make things easier. And the result is always the same: bloat.

gridlockd 7y ago

> I disagree. SPA frameworks attempt to re-implement browser UI and DOM within Javascript. Of course the result is buggy and slow. SPA frameworks don't re-implement the DOM, they provide an interface to the DOM that is more usable. That may or may not have significant overhead, but it's not a given. You have these benchmarks to show that "vanilla JS" is faster, but that's not real-world application code. Because of the usability issues, application authors are way more likely to not write optimal vanilla code. In particular, any DOM modification is extremely slow, so redundant modifications are very wasteful. Avoiding those is something that a framework/virtual-dom can do for you, to let you write simpler code. Furthermore, anybody who writes a real application ends up abstracting the DOM interface, so they're already halfway at an ad-hoc framework. Not abstracting the DOM would result in an insane amount of boilerplate code, which would hamper developer productivity, which would result in even less time spent considering performance. Disclaimer: All of this is true for applications, not for simple websites with minimal dynamic interaction. You're likely better off rendering those server-side and then attaching a couple of event handlers on page load.

deleted 7y ago
[deleted]

SirHound 7y ago

The imperative DOM “framework” available is far more error-prone than the state->view, declarative model of React. It’s ugliness is more than skin deep.

vearwhershuh 7y ago

I agree entirely, except for the necessarily ugly part. You can use intercooler.js to wire in very usable modern UX with very little overhead, relying on the native, screaming fast DOM implementation.

pkstn 7y ago

I'd argue most of the modern frameworks with all the bells and whistles (Redux, Hooks, ...) are even more ugly, and actually harder to master. https://medium.com/re-dom/master-the-dom-bc1a2a06089b https://medium.com/re-dom/master-the-dom-bc1a2a06089b