I came up mostly the same way. Over the years I added bits of JS and the bits gradually got bigger until the point was reached where I decided to roll them all up into a proper client-side programming language. Now I code as little as possible on the server, leaving it to just handle the system data and the comms to all the connected users.
Just a thought: When you need to poll the server for changes, a key decision is how often to poll. If you have many users the polling overhead can get quite large. Though I've never actually done it, I would add JS code to assess when the user is active, and increase the polling frequency so the system feels more responsive. Then when the user leaves the screen untouched for a while the polling frequency can be reduced. JavaScript has a rich set of features for detecting user activity.
Absolutely! I was thinking the same, until I came up to this article (I cannot find it right now) where the author state that long polling can quickly exhaust the server, and advices to use a bi-directional web socket connection instead.
I personally use Odoo at my work (which is a Python based framework for rapidly prototyping UI for ERPs), and it uses internally long polling (for users to users chat, notifications, ...). So far, no downsides regarding using it, and this framework is widely used, so I guess polls are okay.
That is great to have this conversation, because your answers are actually what I was thinking of the future of web development: we will tend to create more and more responsive web app, until eventually reaching real-time capabability web app, using intuitive event driven features (like we can already with the Javascript Notification API).
The future looks bright, but I think the patterns are still to be reinforced, because for the moment frameworks that propose embeded long polling features are not legion.
I just Googled bidirectional web sockets (which I've never come across before) and they seem to be well worth looking into. For the scenario in this article series, both ends will be on the same machine and interrupted connections are unlikely to happen. If that configuration is supported (I can see no reason for it not to be) then they greatly add to the benefits of using a browser as a GUI for a local application. If I get time I'll try them out; maybe I'll then need to write an extra part for the series!
I actually just finished to follow this YouTube video in which a presenter demonstrate how websockets can be implemented in PHP by showing a plain PHP example followed by a simple chat app using the Ratchet frameworks :
He also give his feedback on some things to have in mind, like maximum file opened (because web sockets are using file descriptors behind the scene). Very instructive.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I came up mostly the same way. Over the years I added bits of JS and the bits gradually got bigger until the point was reached where I decided to roll them all up into a proper client-side programming language. Now I code as little as possible on the server, leaving it to just handle the system data and the comms to all the connected users.
Just a thought: When you need to poll the server for changes, a key decision is how often to poll. If you have many users the polling overhead can get quite large. Though I've never actually done it, I would add JS code to assess when the user is active, and increase the polling frequency so the system feels more responsive. Then when the user leaves the screen untouched for a while the polling frequency can be reduced. JavaScript has a rich set of features for detecting user activity.
Absolutely! I was thinking the same, until I came up to this article (I cannot find it right now) where the author state that long polling can quickly exhaust the server, and advices to use a bi-directional web socket connection instead.
I personally use Odoo at my work (which is a Python based framework for rapidly prototyping UI for ERPs), and it uses internally long polling (for users to users chat, notifications, ...). So far, no downsides regarding using it, and this framework is widely used, so I guess polls are okay.
That is great to have this conversation, because your answers are actually what I was thinking of the future of web development: we will tend to create more and more responsive web app, until eventually reaching real-time capabability web app, using intuitive event driven features (like we can already with the Javascript Notification API).
The future looks bright, but I think the patterns are still to be reinforced, because for the moment frameworks that propose embeded long polling features are not legion.
I just Googled bidirectional web sockets (which I've never come across before) and they seem to be well worth looking into. For the scenario in this article series, both ends will be on the same machine and interrupted connections are unlikely to happen. If that configuration is supported (I can see no reason for it not to be) then they greatly add to the benefits of using a browser as a GUI for a local application. If I get time I'll try them out; maybe I'll then need to write an extra part for the series!
I actually just finished to follow this YouTube video in which a presenter demonstrate how websockets can be implemented in PHP by showing a plain PHP example followed by a simple chat app using the Ratchet frameworks :
youtu.be/Q7Us_DjMbXU
He also give his feedback on some things to have in mind, like maximum file opened (because web sockets are using file descriptors behind the scene). Very instructive.