4 ms·

What I understand by SPA: Single Page Application: No need to reload the full page every time, but only to update the proper parts of the UI that has changed. I

What I understand by SPA: Single Page Application: No need to reload the full page every time, but only to update the proper parts of the UI that has changed. It started with the GMail client and the ability to use AJAX. I like this definition because is conceptual, it is not tied to any specific technique I am curious, in 5 years of doing SPA this way I have never hit a limit, what have you found?

icedchai 9y ago
Anything where you want low latency interactivity. For example, a graph where you are applying various filters. The more traditional “SPA” would fetch only the data and do local re-rendering on a canvas, SVG, etc.
- jorgeleo 9y ago
  Right, because you want to reduce the network traffic by reducing the amount of data traveling, and it allows more frequent round trips updates. The times I got that kind of requirement clients always jump back to a winform/wpf UI client. So far I have not faced this problem on a web browser, sounds fun.
  - brucephillips 9y ago
    Can I ask where you work? I'm trying to get a better sense of who is still building native business apps and why. What leads to you building a WPF app vs. A Web app?
    - jorgeleo 9y ago
      I am an independent contractor, for NDA reasons I cannot tell you were, but here are some of the apps that I have developed recently: - Image analysis for a massive amount of images. A system generates 60 images per second for hours. Each image needs to be statistically analyzed, and depending on the results, saved to a database for further processing. - An underwater robotic controlling software. The UI gets very complex as it has to process in real time a couple of video network feeds, some other position information, and coordinate with other pieces on the system. Several custom network protocols used by other vendors. - On the fly manipulation of mobile backups. There are certain types of data stored on mobile devices that need to be analyzed and secured beyond what the manufacturer provides. - 3d data of cavern shapes. While the data could be easily processed on the browser, part of the requirements is to keep the isolation level to the machine where the software is running, sometimes to help compliance laws, sometimes to help companies operate under different countries with specific laws, sometimes because by law restrictions there is no internet on site. - Marketing data analysis. There are a couple of applications that benefit from being a desktop app because they give an "Excel like" experience that gives confidence to the client's customers. By "Excel like" I mean a desktop app with a single file container for the data. Using local CPU cycles, and 2 people can take the same data and manipulate it differently disconnected from everything. In this project, there is another group that has a web version of it, but it just does not gain user acceptance because continuous performance problems compared with the desktop app. Hope it helps
natecavanaugh 9y ago
I think your architecture is sound, and I think it's the easiest way to build a site. But there are two aspects I think you're missing: 1. SPA means something different to everyone. I believe the most common definition is a site where the UI is rendered on the client and the server is just a bunch of API end points that return JSON. At least that's where the phrase started coming from however it has grown to include some flavor of what you're doing (returning fragments from the server). Some people think of SPAs as isomorphic or universal webapps, but those both leverage and suffer from the code sharing aspect. 2. Depending on the flavor of SPA, it's a different kind of hard, and I do think it is hard simply because of how drastically different each architecture is. Even sites that run on Node and share code can use anything from a traditional MVC, to using a Redux architecture, etc. And a new paradigm will always be "hard". My overall point though, is that of all of the architectures, I do believe that rendering on the server and transporting fragments is by far both the cleanest and easiest to implement and rendering on the client will always suffer in complexity and/or performance. But, the wealth of options does make everything a lot harder.
gokhan 9y ago
It started way before GMail client. OWA was the first application to partially manipulate the UI on the client. GMail was the first decent app doing it in a modern way. Even AJAX is invented for OWA. https://garrettsmith.net/blog/archives/2006/01/microsoft_inven_1.html https://garrettsmith.net/blog/archives/2006/01/microsoft_inv...

icedchai 9y ago

Anything where you want low latency interactivity. For example, a graph where you are applying various filters. The more traditional “SPA” would fetch only the data and do local re-rendering on a canvas, SVG, etc.

jorgeleo 9y ago
Right, because you want to reduce the network traffic by reducing the amount of data traveling, and it allows more frequent round trips updates. The times I got that kind of requirement clients always jump back to a winform/wpf UI client. So far I have not faced this problem on a web browser, sounds fun.
- brucephillips 9y ago
  Can I ask where you work? I'm trying to get a better sense of who is still building native business apps and why. What leads to you building a WPF app vs. A Web app?
  - jorgeleo 9y ago
    I am an independent contractor, for NDA reasons I cannot tell you were, but here are some of the apps that I have developed recently: - Image analysis for a massive amount of images. A system generates 60 images per second for hours. Each image needs to be statistically analyzed, and depending on the results, saved to a database for further processing. - An underwater robotic controlling software. The UI gets very complex as it has to process in real time a couple of video network feeds, some other position information, and coordinate with other pieces on the system. Several custom network protocols used by other vendors. - On the fly manipulation of mobile backups. There are certain types of data stored on mobile devices that need to be analyzed and secured beyond what the manufacturer provides. - 3d data of cavern shapes. While the data could be easily processed on the browser, part of the requirements is to keep the isolation level to the machine where the software is running, sometimes to help compliance laws, sometimes to help companies operate under different countries with specific laws, sometimes because by law restrictions there is no internet on site. - Marketing data analysis. There are a couple of applications that benefit from being a desktop app because they give an "Excel like" experience that gives confidence to the client's customers. By "Excel like" I mean a desktop app with a single file container for the data. Using local CPU cycles, and 2 people can take the same data and manipulate it differently disconnected from everything. In this project, there is another group that has a web version of it, but it just does not gain user acceptance because continuous performance problems compared with the desktop app. Hope it helps

natecavanaugh 9y ago

I think your architecture is sound, and I think it's the easiest way to build a site. But there are two aspects I think you're missing: 1. SPA means something different to everyone. I believe the most common definition is a site where the UI is rendered on the client and the server is just a bunch of API end points that return JSON. At least that's where the phrase started coming from however it has grown to include some flavor of what you're doing (returning fragments from the server). Some people think of SPAs as isomorphic or universal webapps, but those both leverage and suffer from the code sharing aspect. 2. Depending on the flavor of SPA, it's a different kind of hard, and I do think it is hard simply because of how drastically different each architecture is. Even sites that run on Node and share code can use anything from a traditional MVC, to using a Redux architecture, etc. And a new paradigm will always be "hard". My overall point though, is that of all of the architectures, I do believe that rendering on the server and transporting fragments is by far both the cleanest and easiest to implement and rendering on the client will always suffer in complexity and/or performance. But, the wealth of options does make everything a lot harder.

gokhan 9y ago

It started way before GMail client. OWA was the first application to partially manipulate the UI on the client. GMail was the first decent app doing it in a modern way. Even AJAX is invented for OWA. https://garrettsmith.net/blog/archives/2006/01/microsoft_inven_1.html https://garrettsmith.net/blog/archives/2006/01/microsoft_inv...