4 ms·

As a general rule things are moving into the browser because that is the point closest to the user where the most interactivity is possible. It's simply not po

by sfeng 10y ago

As a general rule things are moving into the browser because that is the point closest to the user where the most interactivity is possible. It's simply not possible to provide the desktop-like experience of a modern web app when you have to reload the page to make any change. I would actually ask the opposite question, what is the purpose of keeping your rendering far away from the user when it could just as easily be done by the high-performance engine built into their browser?

Piskvorrr 10y ago
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".
cmoscoso 10y ago
Why do you want desktop-like experience on a browser?

by sfeng 10y ago

Piskvorrr 10y ago

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

cmoscoso 10y ago

Why do you want desktop-like experience on a browser?