3 ms·

Yes, that is great and wonderful, allowing for things that are Indistinguishable From Magic (tm). There's a catch, though: "high-performance engine" is usually

Yes, that is great and wonderful, allowing for things that are Indistinguishable From Magic (tm). There's a catch, though: "high-performance engine" is usually power- and memory-hungry. This means client-side bloat, which translates to: "Underpowered computer, or worse, a phone? Go away!" (Literally. Webview-wrapped apps that do nothing beyond a few REST operations bloat to hundreds of MBs, because RAM Is Cheap And It's Not Our RAM Anyway Amirite.) So, although the client-side non-thin non-native apps (a.k.a. in-browser JS fat clients) are easy to write, nice and responsive, I'm sorely missing a way to do some of their heavy lifting server-side.

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".

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".