With hindsight, the 'browser' doesn't actually have to be Firefox, Chrome etc. Any component able to render HTML to a UI, execute logical operations and communicate via HTTP will do just as well as far as the rest of the system is concerned. As you say, the client can be substituted without the server having to alter its behavior, or even to know about the change. It would also be free of the sandbox and could be written in any system language. Just thinking out loud - I have no idea where I'm going with this...
I am actually making an app for my mum that holds a shoe store, and I used this pattern. It is the first time I am doing anything else than classical PHP backend serving the front end all it needs.
This time for this app, I used PHP but only to act as an API, serving just the data, and my front-end in Javascript is generating the HTML and with the help of some AJAX call, compiles the templates into visual components (I use the help of Vue.js to do so).
So far I am liking it, the web experience results in a smooth navigation, and no flash of loading. I just need to work out the display of the loading indicators, but else this is a very pleasant navigation experience. I recommend it.
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.
With hindsight, the 'browser' doesn't actually have to be Firefox, Chrome etc. Any component able to render HTML to a UI, execute logical operations and communicate via HTTP will do just as well as far as the rest of the system is concerned. As you say, the client can be substituted without the server having to alter its behavior, or even to know about the change. It would also be free of the sandbox and could be written in any system language. Just thinking out loud - I have no idea where I'm going with this...
I am actually making an app for my mum that holds a shoe store, and I used this pattern. It is the first time I am doing anything else than classical PHP backend serving the front end all it needs.
This time for this app, I used PHP but only to act as an API, serving just the data, and my front-end in Javascript is generating the HTML and with the help of some AJAX call, compiles the templates into visual components (I use the help of Vue.js to do so).
So far I am liking it, the web experience results in a smooth navigation, and no flash of loading. I just need to work out the display of the loading indicators, but else this is a very pleasant navigation experience. I recommend it.
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.