3 ms·

Power and memory hungry web apps are usually the result of sloppy coding or a lazy architecture. Web apps should solely be responsible of rendering a view based

by mmcnl 10y ago

Power and memory hungry web apps are usually the result of sloppy coding or a lazy architecture. Web apps should solely be responsible of rendering a view based on state and allowing for interaction with the state through the view. Any heavy lifting can (and should?) still be done by a backend.

Piskvorrr 10y ago
In my experience, there's a significant overhead even before anyone can apply their sloppy coding skills - and scaling, oh boy the scaling (super-linear, more likely exponential). "Clientside filter works great for 10 items, and sort of okay for 100 items, ship it!" (And becomes unusably slow at 1000 items).
- mmcnl 10y ago
  That is true, though I think it is becoming a problem of the past. What you're saying originates from the jQuery days, when suddenly a magic band-aid appeared that could seemingly fix previously difficult to achieve features in a nutshell (ofcourse, at the expense of performance). Libraries like Vue and React make it easy to create high-quality maintainable code.
  - Piskvorrr 10y ago
    I do remember jQuery 1.0. And I do remember what was before it. That time is now called Browser Dark Ages - for good reasons. Your description of "magic band-aid at expense of performance" is IMNSHO unfair - before it became a huge golden hammer (and long before small replacements like Zepto), jQuery brought usable, cross-browser scripting, with features that the browsers themselves did not have (We're talking IE6 here, remember?). This allowed robust coding, and it was actually more optimized for common operations than a naïve "pure" JS implementation. This is indeed becoming a problem of the past, precisely because browsers started to implement those features natively - but the choice of features was often driven by "oh, and jQuery does this, it would be nice if we didn't need a library for it".

by mmcnl 10y ago

Piskvorrr 10y ago

In my experience, there's a significant overhead even before anyone can apply their sloppy coding skills - and scaling, oh boy the scaling (super-linear, more likely exponential). "Clientside filter works great for 10 items, and sort of okay for 100 items, ship it!" (And becomes unusably slow at 1000 items).

mmcnl 10y ago
That is true, though I think it is becoming a problem of the past. What you're saying originates from the jQuery days, when suddenly a magic band-aid appeared that could seemingly fix previously difficult to achieve features in a nutshell (ofcourse, at the expense of performance). Libraries like Vue and React make it easy to create high-quality maintainable code.
- Piskvorrr 10y ago
  I do remember jQuery 1.0. And I do remember what was before it. That time is now called Browser Dark Ages - for good reasons. Your description of "magic band-aid at expense of performance" is IMNSHO unfair - before it became a huge golden hammer (and long before small replacements like Zepto), jQuery brought usable, cross-browser scripting, with features that the browsers themselves did not have (We're talking IE6 here, remember?). This allowed robust coding, and it was actually more optimized for common operations than a naïve "pure" JS implementation. This is indeed becoming a problem of the past, precisely because browsers started to implement those features natively - but the choice of features was often driven by "oh, and jQuery does this, it would be nice if we didn't need a library for it".