3 ms·

An excellent piece. The only problem is that it is now 2015, and everybody's moving to Websocket-based backends. Without WS support, new web frameworks are quit

An excellent piece. The only problem is that it is now 2015, and everybody's moving to Websocket-based backends. Without WS support, new web frameworks are quite doomed.

chii 11y ago
Web sockets isn't the be all and end all tech. There's still a place for server rendered, simple pages. Not every web app needs to be a single page app.
- vdaniuk 11y ago
  That's not what they said. Not every web app needs to be a single page app, that's true but it's a non sequitur. The point was that if a new framework aims to capture enough attention and traction to be a sustainable alternative to the incumbents it has to support websocket .
  - mschuster91 11y ago
    Where are websockets truly needed for functionality of any application? The only part I think where websockets enable truly new functionality is displaying of live data and push notifications.
    - vdaniuk 11y ago
      The subject of the discussion is required features of frameworks, not apps.
      - mschuster91 11y ago
        Why does a framework have to carry features only needed in edge cases? Feature bloat/mission creep sucks.
        vdaniuk 11y ago
        >Why does a framework have to carry features only needed in edge cases? Because most apps are being built in the conditions of uncertainty and the development team doesn't know if the edge case will become a business requirement. >Feature bloat/mission creep sucks. Unqualified, this statement is nothing more than a thought terminating cliche. Whatever constitutes "bloat" depends on the context and preferences of a decision maker.
        coldtea 11y ago
        >Whatever constitutes "bloat" depends on the context and preferences of a decision maker. Same goes for whatever constitutes a necessity. I seriously challenge the idea that "websockets" are a must have. Case in point, their lack haven't prevented tons of PHP, Ruby, Python, etc frameworks (all the tons of them that are not async/event based and can't handle websockets well if at all), from succeeding. Heck, 1/4 of the web is based on Wordpress (including players like CNN, Forbes, Sony, and NYT blogs) and that doesn't even touch websockets, not to mention not being a proper CMS/framework in lots of other ways.
        vdaniuk 11y ago
        >prevented tons of PHP, Ruby, Python,etc frameworks Django is adding websockets support using the $150K grant from Mozilla. Rails is adding websockets support in the next version with ActionCable. Phoenix and Play frameworks have great support for websockets. Websockets are an integral part of node ecosystem. Your websockets "challenge" is not based on facts.
        coldtea 11y ago
        >Django is adding websockets support using the $150K grant from Mozilla. Rails is adding websockets support in the next version with ActionCable. Note the future tense. By which time Rapidoid might or might not have them as well. >Your websockets "challenge" is not based on facts. No challenge at all. Just plain old reality. Most successful frameworks don't support websockets at the moment, and are still widely used. The fact that Node and some Java frameworks do (as does Python with Tornado and co) doesn't change that fact. Note also how I never said there don't exist frameworks that DO support websockets, so I don't get why you mention these to me.
    - smt88 11y ago
      I wonder if websockets could be used to speed up non-live apps by decreasing overhead. Or, rather, would it be worthwhile?
      - atemerev 11y ago
        For me, it is. I get nearly instantaneous reaction times for UI events, even where round-trip to server is involved (WS session is already created, so no duplicated headers, etc.) Additionally, especially for mobile apps, if connection is dropped, it is immediately detectable and it can go to offline mode right away.
        smt88 11y ago
        To clarify, are you talking about an app that does not have any real-time data? The part about knowing when the connection has dropped is actually really interesting...
        paulddraper 11y ago
        navigator.onLine
      - creshal 11y ago
        That sounds like a hammer in search of nails.
        smt88 11y ago
        That's exactly what it is. The obvious nail for websockets is real-time data. I'm curious to know if there are other nails.
Kiro 11y ago
Should you use WS even if you don't need to push data to the client in real-time?
- atemerev 11y ago
  For webapps, certainly. You'd get much responsive UI, as there is much less overhead in responding to events, which improves end-user experience. Public APIs should stay REST, perhaps.
- patates 11y ago
  I don't see any negative aspects of exposing the same REST API through WebSockets internally. Public API (if exists) doesn't need to change, private API loses the redundant transfer of headers and cookies.
bcg1 11y ago
Sometimes it makes sense to ship in 2015 and add shiny features in 2016.
- atemerev 11y ago
  Yes, of course.
coldtea 11y ago
>everybody's moving to Websocket-based backends You'd really be surprised. Not everybody moves or even has a use case for a websocket-based backend.

An excellent piece. The only problem is that it is now 2015, and everybody's moving to Websocket-based backends. Without WS support, new web frameworks are quite doomed.

chii 11y ago

Web sockets isn't the be all and end all tech. There's still a place for server rendered, simple pages. Not every web app needs to be a single page app.

vdaniuk 11y ago
That's not what they said. Not every web app needs to be a single page app, that's true but it's a non sequitur. The point was that if a new framework aims to capture enough attention and traction to be a sustainable alternative to the incumbents it has to support websocket .
- mschuster91 11y ago
  Where are websockets truly needed for functionality of any application? The only part I think where websockets enable truly new functionality is displaying of live data and push notifications.
  - vdaniuk 11y ago
    The subject of the discussion is required features of frameworks, not apps.
    - mschuster91 11y ago
      Why does a framework have to carry features only needed in edge cases? Feature bloat/mission creep sucks.
      - vdaniuk 11y ago
        >Why does a framework have to carry features only needed in edge cases? Because most apps are being built in the conditions of uncertainty and the development team doesn't know if the edge case will become a business requirement. >Feature bloat/mission creep sucks. Unqualified, this statement is nothing more than a thought terminating cliche. Whatever constitutes "bloat" depends on the context and preferences of a decision maker.
        coldtea 11y ago
        >Whatever constitutes "bloat" depends on the context and preferences of a decision maker. Same goes for whatever constitutes a necessity. I seriously challenge the idea that "websockets" are a must have. Case in point, their lack haven't prevented tons of PHP, Ruby, Python, etc frameworks (all the tons of them that are not async/event based and can't handle websockets well if at all), from succeeding. Heck, 1/4 of the web is based on Wordpress (including players like CNN, Forbes, Sony, and NYT blogs) and that doesn't even touch websockets, not to mention not being a proper CMS/framework in lots of other ways.
        vdaniuk 11y ago
        >prevented tons of PHP, Ruby, Python,etc frameworks Django is adding websockets support using the $150K grant from Mozilla. Rails is adding websockets support in the next version with ActionCable. Phoenix and Play frameworks have great support for websockets. Websockets are an integral part of node ecosystem. Your websockets "challenge" is not based on facts.
        coldtea 11y ago
        >Django is adding websockets support using the $150K grant from Mozilla. Rails is adding websockets support in the next version with ActionCable. Note the future tense. By which time Rapidoid might or might not have them as well. >Your websockets "challenge" is not based on facts. No challenge at all. Just plain old reality. Most successful frameworks don't support websockets at the moment, and are still widely used. The fact that Node and some Java frameworks do (as does Python with Tornado and co) doesn't change that fact. Note also how I never said there don't exist frameworks that DO support websockets, so I don't get why you mention these to me.
  - smt88 11y ago
    I wonder if websockets could be used to speed up non-live apps by decreasing overhead. Or, rather, would it be worthwhile?
    - atemerev 11y ago
      For me, it is. I get nearly instantaneous reaction times for UI events, even where round-trip to server is involved (WS session is already created, so no duplicated headers, etc.) Additionally, especially for mobile apps, if connection is dropped, it is immediately detectable and it can go to offline mode right away.
      - smt88 11y ago
        To clarify, are you talking about an app that does not have any real-time data? The part about knowing when the connection has dropped is actually really interesting...
      - paulddraper 11y ago
        navigator.onLine
    - creshal 11y ago
      That sounds like a hammer in search of nails.
      - smt88 11y ago
        That's exactly what it is. The obvious nail for websockets is real-time data. I'm curious to know if there are other nails.

Kiro 11y ago

Should you use WS even if you don't need to push data to the client in real-time?

atemerev 11y ago
For webapps, certainly. You'd get much responsive UI, as there is much less overhead in responding to events, which improves end-user experience. Public APIs should stay REST, perhaps.
patates 11y ago
I don't see any negative aspects of exposing the same REST API through WebSockets internally. Public API (if exists) doesn't need to change, private API loses the redundant transfer of headers and cookies.

bcg1 11y ago

Sometimes it makes sense to ship in 2015 and add shiny features in 2016.

atemerev 11y ago
Yes, of course.

coldtea 11y ago

>everybody's moving to Websocket-based backends You'd really be surprised. Not everybody moves or even has a use case for a websocket-based backend.