3 ms·

Another option, rather than going back to client-server style programming, is that you could write your web app like it's 2004 and leverage the unique network a

Another option, rather than going back to client-server style programming, is that you could write your web app like it's 2004 and leverage the unique network architecture it had (REST/HATEOAS): http://intercoolerjs.org/2016/05/19/back-to-the-future.html http://intercoolerjs.org/2016/05/19/back-to-the-future.html That is probably the biggest issue: no one cares about long-term support or maintainability of UI applications nearly enough to actually create the ecosystem that it deserves. Absolutely. Not a lot of long term, slow thinking going on these days.

ggregoire 10y ago
Please, can you stop promoting your lib in every topic about JavaScript...
- carsongross 10y ago
  I try not to unless it is reasonably relevant. In this case, the author is suggesting a way to deal with the fact that we are building apps like we were back in the 90's, but in javascript, and I have an alternative suggestion, which is that we build them like we did in the 00's. But I appreciate that people who have seen it before are sick of seeing it again.
vidarh 10y ago
REST/HATEOS is an entirely orthogonal issue to the structural issues of the javascript code that he is discussing. So are the models referenced in the image you link to.
- shoover 10y ago
  Orthogonal to the structural issues, yes, but not to the original premise, which is the problem of rewriting JavaScript UIs. It seems fair to extend the discussion to ways to avoid writing JavaScript UIs in the first place.
  - oldmanjay 10y ago
    The best way to avoid writing JS UIs is to invent a time machine and kill Brendan Eich before he puts it in Netscape. People prefer the interactivity that it enables, and no amount of server-side architecture is going to replace that.
    - shoover 10y ago
      I should have said write less JavaScript, not avoid. Still, the tradeoffs of interactivity and client-side architecture required to keep it sane seems like an ok discussion to have.
    - the_gastropod 10y ago
      While this is probably true, I think this argument is used to defend things that could totally be handled without any (or with very minimal) javascript. Turbolinks or Pjax will get you most of the way toward the interactivity people are used to with single page JS apps. Of course there are interactions that necessitate more Javascript. In my experience, those cases are the exception, not the rule.
deleted 10y ago
[deleted]

ggregoire 10y ago

Please, can you stop promoting your lib in every topic about JavaScript...

carsongross 10y ago
I try not to unless it is reasonably relevant. In this case, the author is suggesting a way to deal with the fact that we are building apps like we were back in the 90's, but in javascript, and I have an alternative suggestion, which is that we build them like we did in the 00's. But I appreciate that people who have seen it before are sick of seeing it again.

vidarh 10y ago

REST/HATEOS is an entirely orthogonal issue to the structural issues of the javascript code that he is discussing. So are the models referenced in the image you link to.

shoover 10y ago
Orthogonal to the structural issues, yes, but not to the original premise, which is the problem of rewriting JavaScript UIs. It seems fair to extend the discussion to ways to avoid writing JavaScript UIs in the first place.
- oldmanjay 10y ago
  The best way to avoid writing JS UIs is to invent a time machine and kill Brendan Eich before he puts it in Netscape. People prefer the interactivity that it enables, and no amount of server-side architecture is going to replace that.
  - shoover 10y ago
    I should have said write less JavaScript, not avoid. Still, the tradeoffs of interactivity and client-side architecture required to keep it sane seems like an ok discussion to have.
  - the_gastropod 10y ago
    While this is probably true, I think this argument is used to defend things that could totally be handled without any (or with very minimal) javascript. Turbolinks or Pjax will get you most of the way toward the interactivity people are used to with single page JS apps. Of course there are interactions that necessitate more Javascript. In my experience, those cases are the exception, not the rule.

deleted 10y ago

[deleted]