5 ms·

> In Toggle if you click start stop too quickly, to create a bunch of tasks to add, it doesn't register it. > That's SPAs for you, there's always something a b

> In Toggle if you click start stop too quickly, to create a bunch of tasks to add, it doesn't register it. > That's SPAs for you, there's always something a bit wrong with them, they're extremely hard to get right, unlike traditional web apps. I often find myself rolling my eyes at YetAnotherPointlessSPA because there will always be something you have to fight with in it. Okay, I'll bite: What would have been the alternative in these cases? Having each action submit a form POST to refresh the entire page, like in the 90s? Then you wouldn't have been able to click it multiple times in the first place, because each one would have caused a page refresh. Or are you saying that they could have implemented it in JavaScript without implementing an entire SPA? In which case, the problem sounds like it's with the logic, and has little to do with the fact that it's a SPA, so you would have likely seen the same bug regardless. I totally understand all the frustrations people have with modern web apps, but your frustrations are with sloppy engineering, not with the idea of SPAs. I believe that, in most cases, the superior user experience that SPAs provide far outweighs the extra margin for error that comes with the territory.

kingdomcome50 9y ago
Another user made a similar comment and although you are (both) correct that the issue is sloppy engineering and not directly related to the idea of a SPA, I think you are (both) missing the point. The issues pointed out above are likely not manifesting out of laziness or inexperience, rather, the sheer amount/complexity of Javascript used to create an SPA can result in seemingly simple issues (like the one above) to crop up, and often makes fixing them far more complex than updating a few lines of code. If I make a page with a few simple JS functions and one is used to "add items to a list on click" (or whatever), yeah, detecting the cause and identifying a solution is trivial. But these days we have an entire front-end ecosystem of controllers, components, events, models, callbacks etc. with many of the above including numerous life-cycle states and actions themselves. Add to that the sheer amount of indirection many of the popular JS frameworks employ, and it no longer takes a sloppy developer to create a bug like the example. In fact with today's component-based architectural style, it's likely the functionality to add items to that list was developed and tested in a completely different context than where the user above was encountering it. I think it is entirely possible (maybe even reasonable) to assume that the folks who built that web app are aware of that bug, but know that the solution isn't worth the amount of time needed to deploy a fix (in relation to other bugs of course) or, even worse, are constrained in such a way that prevents a fix from being possible.
- brucephillips 9y ago
  > But these days we have an entire front-end ecosystem of controllers, components, events, models, callbacks etc. with many of the above including numerous life-cycle states and actions themselves. Can you be more specific? Because to me this looks like essential complexity that's going to exist somewhere, regardless of what's on the client and what's on the server.
  - kingdomcome50 9y ago
    While you are absolutely correct that many of the "pieces" of an application I list above are going to have to exist somewhere, "Essential complexity" is a loaded statement here. There are different contexts and use-cases for complexity. A traditional 3(or 4)-layer MVC web application will obviously contain quite a bit of complexity surrounding data persistence/access, enforcing business rules, and view semantics, but it likely won't have much complexity surrounding "adding an item to a list" on the client. In fact, up until the last 10 years or so, my simple example of how that might look in JS is probably how that would have been implemented on a client (a full page reload is a moot point here). With a SPA, we are adding another MVC (or MVVM) application on the client that is entirely focused on managing the view. That is the complexity to which I'm referring in the point I made above. I named it a "front-end ecosystem" as to not be opinionated on how it might work. I'm certainly not arguing against developing SPAs, rather, adding some context surrounding the OP about how/why bugs develop. To reiterate, I think it's an oversimplification to simply hand-wave the OPs example bug as sloppy engineering that has nothing to do with creating a SPA, because doing so glosses over "why" that bug may be occurring in the first place. The point that I am trying to make is that it may very well be the case that such a bug is occurring because of the added complexity an SPA tends to introduce into the view. Does that make sense?
    - deleted 9y ago
      [deleted]
    - brucephillips 9y ago
      It's a bit misleading to say we're adding another MVC app on the client. By adding that complexity, we reduce complexity on the backend. Views on the backend are no longer true views, but rather serializations of the models. And models on the frontend don't duplicate business logic. That's still all on the backend.

kingdomcome50 9y ago

Another user made a similar comment and although you are (both) correct that the issue is sloppy engineering and not directly related to the idea of a SPA, I think you are (both) missing the point. The issues pointed out above are likely not manifesting out of laziness or inexperience, rather, the sheer amount/complexity of Javascript used to create an SPA can result in seemingly simple issues (like the one above) to crop up, and often makes fixing them far more complex than updating a few lines of code. If I make a page with a few simple JS functions and one is used to "add items to a list on click" (or whatever), yeah, detecting the cause and identifying a solution is trivial. But these days we have an entire front-end ecosystem of controllers, components, events, models, callbacks etc. with many of the above including numerous life-cycle states and actions themselves. Add to that the sheer amount of indirection many of the popular JS frameworks employ, and it no longer takes a sloppy developer to create a bug like the example. In fact with today's component-based architectural style, it's likely the functionality to add items to that list was developed and tested in a completely different context than where the user above was encountering it. I think it is entirely possible (maybe even reasonable) to assume that the folks who built that web app are aware of that bug, but know that the solution isn't worth the amount of time needed to deploy a fix (in relation to other bugs of course) or, even worse, are constrained in such a way that prevents a fix from being possible.

brucephillips 9y ago
> But these days we have an entire front-end ecosystem of controllers, components, events, models, callbacks etc. with many of the above including numerous life-cycle states and actions themselves. Can you be more specific? Because to me this looks like essential complexity that's going to exist somewhere, regardless of what's on the client and what's on the server.
- kingdomcome50 9y ago
  While you are absolutely correct that many of the "pieces" of an application I list above are going to have to exist somewhere, "Essential complexity" is a loaded statement here. There are different contexts and use-cases for complexity. A traditional 3(or 4)-layer MVC web application will obviously contain quite a bit of complexity surrounding data persistence/access, enforcing business rules, and view semantics, but it likely won't have much complexity surrounding "adding an item to a list" on the client. In fact, up until the last 10 years or so, my simple example of how that might look in JS is probably how that would have been implemented on a client (a full page reload is a moot point here). With a SPA, we are adding another MVC (or MVVM) application on the client that is entirely focused on managing the view. That is the complexity to which I'm referring in the point I made above. I named it a "front-end ecosystem" as to not be opinionated on how it might work. I'm certainly not arguing against developing SPAs, rather, adding some context surrounding the OP about how/why bugs develop. To reiterate, I think it's an oversimplification to simply hand-wave the OPs example bug as sloppy engineering that has nothing to do with creating a SPA, because doing so glosses over "why" that bug may be occurring in the first place. The point that I am trying to make is that it may very well be the case that such a bug is occurring because of the added complexity an SPA tends to introduce into the view. Does that make sense?
  - deleted 9y ago
    [deleted]
  - brucephillips 9y ago
    It's a bit misleading to say we're adding another MVC app on the client. By adding that complexity, we reduce complexity on the backend. Views on the backend are no longer true views, but rather serializations of the models. And models on the frontend don't duplicate business logic. That's still all on the backend.