I wrote a famous Javascript in '97, went onto make some very complex GWT and Silverlight apps where I had to figure out how to do complex choreography with the server despite asynchronous communications long before most people understood there was a problem...
Despite that (or because of that?) I was a hater on SPAs throughout most of the 2010. I know agencies that did PHP/ColdFusion/ASP work before 2005 or Ruby on Rails work 2005-2010 who found their customers were asking for SPAs and they just couldn't sell the traditional sites anymore.
I think it's a situation that people blundered into. Web forms weren't originally designed to make complex applications. At the beginning you typically made a web form and then had the form POST to a cgi-script at a different URL. (e.g. Back them you had a static HTML page and a separate Perl script in your cgi-script directory)
If you wanted to validate the form you were in trouble because doing that on the back end required the script to be able to display different pages depending on the content of the form, and ultimately that requires a back-end framework that separates HTML content from the exact URLs it is served as at.
Ruby on Rails was an example of the kind of framework that addresses that -- what you get when you think systematically about these issues. Around the same time Microsoft was coming out with ASP.NET which had some brilliant ideas but didn't understand that you might need to display a different page at the same URL, then they got ASP.NET MVC that threw out all the good things from ASP.NET. On top of that there were many frameworks and apps that did very bad things keeping session state on the server that led to major bugs.
The SPA answers many of those issues by having (medium term) persistent state on the front end rather than having to have something that manages that state cooperatively between the front end and back end.
I did a lot of home automation and related work recently and that got me looking at cross-platform GUI frameworks and I found that these were uniformly awful. For instance if you are working in Python you can use tkinter or GWT but the Python side isn't really documented so you have to look at the Python docs, source code, and the tk or C or C++ docs to guess what you're supposed to do. I kinda liked JavaFX but it is being phased out...
I got back into programming React-style SPAs for work, and I finally got over my hate for SPAs and (particularly) Electron.
Yes, it's annoying to install 20 crapplets on your machine that are all 30 - 32 MB in size, but just try using any other x-platform gui framework and Electron, React-Native and other web derived things look good.
Despite that (or because of that?) I was a hater on SPAs throughout most of the 2010. I know agencies that did PHP/ColdFusion/ASP work before 2005 or Ruby on Rails work 2005-2010 who found their customers were asking for SPAs and they just couldn't sell the traditional sites anymore.
I think it's a situation that people blundered into. Web forms weren't originally designed to make complex applications. At the beginning you typically made a web form and then had the form POST to a cgi-script at a different URL. (e.g. Back them you had a static HTML page and a separate Perl script in your cgi-script directory)
If you wanted to validate the form you were in trouble because doing that on the back end required the script to be able to display different pages depending on the content of the form, and ultimately that requires a back-end framework that separates HTML content from the exact URLs it is served as at.
Ruby on Rails was an example of the kind of framework that addresses that -- what you get when you think systematically about these issues. Around the same time Microsoft was coming out with ASP.NET which had some brilliant ideas but didn't understand that you might need to display a different page at the same URL, then they got ASP.NET MVC that threw out all the good things from ASP.NET. On top of that there were many frameworks and apps that did very bad things keeping session state on the server that led to major bugs.
The SPA answers many of those issues by having (medium term) persistent state on the front end rather than having to have something that manages that state cooperatively between the front end and back end.
I did a lot of home automation and related work recently and that got me looking at cross-platform GUI frameworks and I found that these were uniformly awful. For instance if you are working in Python you can use tkinter or GWT but the Python side isn't really documented so you have to look at the Python docs, source code, and the tk or C or C++ docs to guess what you're supposed to do. I kinda liked JavaFX but it is being phased out...
I got back into programming React-style SPAs for work, and I finally got over my hate for SPAs and (particularly) Electron.
Yes, it's annoying to install 20 crapplets on your machine that are all 30 - 32 MB in size, but just try using any other x-platform gui framework and Electron, React-Native and other web derived things look good.
reply