9 ms·

And... nope! 1) Hard and easy are relative terms, You feel it hard because it is foreign to 'you', not because it is intrinsically hard. If it seems hard to yo

And... nope! 1) Hard and easy are relative terms, You feel it hard because it is foreign to 'you', not because it is intrinsically hard. If it seems hard to you then get comfortable with the new pattern, or create a pattern that is more familiar to you, but please don't tell me this is hard because I have to write more code or because there is one more thing that you have to know and maintain. That is not hard, that is been laaaaazy. 2) The 2 points become irrelevant if you do SPA using server rendering. To give an example using C# and MVC: I have 1 javascript function with 0, I repeat: 0 business logic. All my MVC methods return a partial view with a tag saying where it goes. The javascript function does an AJAX call to the controller and on successful return it looks for the tag, and do a $('#' + tagvalue).html(partialView). All the business logic is on the server, all the drawing is on the server, all the validation is on the server. The only UI validation logic is the same one that you would write in the case of non-SPA. There is no data synchronization because the server manages the data. The browser gets reduced to a pretty HTML document display, which is all that it is. SPAs are not harder, they never were.

seekbeak 9y ago
I need to get into server rendering more. I find myself doing double validation these days and server rendering could solve some of that. I validate client side, then again server side to make sure people aren't throwing garbage at my API.
- brucephillips 9y ago
  You don't need server rendering to avoid double validation, right? Just validate on the server, and return error codes that the client can render.
neosavvy 9y ago
I'll agree that SPAs are a bit of a departure for folks who have been building legacy ASP.NET or JSP / Java Request / Response apps. There are some new things they must learn, so they may have a higher learning curve. Additionally the technology is really unstable. The build tools for example (webpack, babel, gulp, grunt) have changed tremendously and in breaking fashion now drastically over the past 4-5 years. Lots of legacy technology has stable tooling and so a more "seasoned" programmer may be a bit put off by that. Maybe that's this guys's problem. He should Green Egg's and Ham this mofo and just "try it" earnestly before writing a total dump of a blog post and sharing it on Hacker news.
- jorgeleo 9y ago
  Doing SPA commercially for years now, never needed any of those: webpack, babel, gulp, grunt, etc. If the developer understands the technology that they are built upon he will realize that there is no need for them. Surely they add nice things, but in my experience, they add nothing that worth the learning curve. BTW, I have 25+ years developing software, so I kind of consider my self a "seasoned" programmer, and I can tell you, I am not put off by technology, if anything else, every once in a while, I get a good chuckle out how the javascript world is reinventing what has been done 20 or 30 years ago. And I don't know many people that get to be "seasoned" programmers and that they get put off by what the new kids are doing. Actually, I don't know any at all. Most of the time the reaction is: Do you remember when we did something similar on that old xyz computer? Yeah! and we had to do a, b and c to adjust to the lack of memory space, now this library is wasting it (https://news.ycombinator.com/item?id=15472325 https://news.ycombinator.com/item?id=15472325)
  - seekbeak 9y ago
    None of them? Are you just doing everything vanilla js/html/css with no build tools, or just using bash/npm scripts?
    - jorgeleo 9y ago
      Nothing beyond jQuery, Bootstrap at the core. Sometimes some libraries for UI components like datatables.js, or a datetimepicker, but that it is.
      - neosavvy 9y ago
        Does anyone else even have a desire to work on the apps you are contributing to with you?
        jorgeleo 9y ago
        <sarcasm> I guess you must still be living in your parent's basement because you must not have many bills to pay </sarcasm> LOL Now seriously: Quite the opposite, I always receive comments on the simplicity of my code. Also, I code so the user has a pleasant work experience, and also so the CPU executes the code faster, I don't put much attention to the comfort of the next developer, but I am always willing to show and explain what I did and why.
icedchai 9y ago
I've done the approach you describe with #2. It is much simpler, but is limiting, and generally not what most people mean by "single page app."
- jorgeleo 9y ago
  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
betageek 9y ago
Your second option seems to suggest that the way to make building SPA's easy is to stop building SPA's and go back to building web apps the way we did in 2005?
- tomc1985 9y ago
  Rails and Turbolinks are doing just that, but with its own take on shoring up latency, and it is fantastic!
- jorgeleo 9y ago
  1. To me, it is an SPA as long as you are not updating the whole page every time. The year of the tools has nothing to do with it. 2. I use the tools I use because they work and produce the proper and performant results. To be honest, I don't care for developer tool fashion statements, and so the year is irrelevant to me.
megaman22 9y ago
This is a horrific pattern - and I know because I've done it in some half-asssed jQuery/Razor/MVC projects in the past. As soon as things get more than the slightest bit complicated, this turns into a huge mess. If you're building a SPA, and you need it to actually be a SPA, use a framework, don't try rolling your own mess.
- pqh 9y ago
  Indeed, code reuse, testing, maintainability, etc are harder with the latter pattern. And with the latter you also end up using at least 3 languages in the same files. It's just really awful. Yes, browser-rendering SPA frameworks are heavyweight, but they give an undeniably-better development experience. And that shows in the quality of the interfaces created through them, assuming your interface requirements are complex enough to justify it. I mean, I'm happy with Hacker News' interface and it's simple, but if I'm building the next Google Calendar, I am not using ajax and server-rendered templates.
saas_co_de 9y ago
> SPAs are not harder, they never were. Yes, they are harder 1) instead of using browsers based on standards with hundreds of millions invested in developing them for things like routing, caching, history, etc, you are using ad-hoc amateur implementations of all those things that are full of bugs and unimplemented corner cases. 2) Instead of executing your code in a safe environment you control you are executing it in an unsafe environment on an unknown runtime that you have no control of. 3) Instead of processing stateless requests with large chunks of synchronous code backed by a database that imposes some sane limits on state manipulation you are maintaining all of your app state yourself, continually updating it asynchronously, in an insecure environment, with dropped requests, and layers of hacked together client/server data synchronization and caching. Sure sounds harder to me :)

seekbeak 9y ago

I need to get into server rendering more. I find myself doing double validation these days and server rendering could solve some of that. I validate client side, then again server side to make sure people aren't throwing garbage at my API.

brucephillips 9y ago
You don't need server rendering to avoid double validation, right? Just validate on the server, and return error codes that the client can render.

neosavvy 9y ago

I'll agree that SPAs are a bit of a departure for folks who have been building legacy ASP.NET or JSP / Java Request / Response apps. There are some new things they must learn, so they may have a higher learning curve. Additionally the technology is really unstable. The build tools for example (webpack, babel, gulp, grunt) have changed tremendously and in breaking fashion now drastically over the past 4-5 years. Lots of legacy technology has stable tooling and so a more "seasoned" programmer may be a bit put off by that. Maybe that's this guys's problem. He should Green Egg's and Ham this mofo and just "try it" earnestly before writing a total dump of a blog post and sharing it on Hacker news.

jorgeleo 9y ago
Doing SPA commercially for years now, never needed any of those: webpack, babel, gulp, grunt, etc. If the developer understands the technology that they are built upon he will realize that there is no need for them. Surely they add nice things, but in my experience, they add nothing that worth the learning curve. BTW, I have 25+ years developing software, so I kind of consider my self a "seasoned" programmer, and I can tell you, I am not put off by technology, if anything else, every once in a while, I get a good chuckle out how the javascript world is reinventing what has been done 20 or 30 years ago. And I don't know many people that get to be "seasoned" programmers and that they get put off by what the new kids are doing. Actually, I don't know any at all. Most of the time the reaction is: Do you remember when we did something similar on that old xyz computer? Yeah! and we had to do a, b and c to adjust to the lack of memory space, now this library is wasting it (https://news.ycombinator.com/item?id=15472325 https://news.ycombinator.com/item?id=15472325)
- seekbeak 9y ago
  None of them? Are you just doing everything vanilla js/html/css with no build tools, or just using bash/npm scripts?
  - jorgeleo 9y ago
    Nothing beyond jQuery, Bootstrap at the core. Sometimes some libraries for UI components like datatables.js, or a datetimepicker, but that it is.
    - neosavvy 9y ago
      Does anyone else even have a desire to work on the apps you are contributing to with you?
      - jorgeleo 9y ago
        <sarcasm> I guess you must still be living in your parent's basement because you must not have many bills to pay </sarcasm> LOL Now seriously: Quite the opposite, I always receive comments on the simplicity of my code. Also, I code so the user has a pleasant work experience, and also so the CPU executes the code faster, I don't put much attention to the comfort of the next developer, but I am always willing to show and explain what I did and why.

icedchai 9y ago

I've done the approach you describe with #2. It is much simpler, but is limiting, and generally not what most people mean by "single page app."

jorgeleo 9y ago
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

betageek 9y ago

Your second option seems to suggest that the way to make building SPA's easy is to stop building SPA's and go back to building web apps the way we did in 2005?

tomc1985 9y ago
Rails and Turbolinks are doing just that, but with its own take on shoring up latency, and it is fantastic!
jorgeleo 9y ago
1. To me, it is an SPA as long as you are not updating the whole page every time. The year of the tools has nothing to do with it. 2. I use the tools I use because they work and produce the proper and performant results. To be honest, I don't care for developer tool fashion statements, and so the year is irrelevant to me.

megaman22 9y ago

This is a horrific pattern - and I know because I've done it in some half-asssed jQuery/Razor/MVC projects in the past. As soon as things get more than the slightest bit complicated, this turns into a huge mess. If you're building a SPA, and you need it to actually be a SPA, use a framework, don't try rolling your own mess.

pqh 9y ago
Indeed, code reuse, testing, maintainability, etc are harder with the latter pattern. And with the latter you also end up using at least 3 languages in the same files. It's just really awful. Yes, browser-rendering SPA frameworks are heavyweight, but they give an undeniably-better development experience. And that shows in the quality of the interfaces created through them, assuming your interface requirements are complex enough to justify it. I mean, I'm happy with Hacker News' interface and it's simple, but if I'm building the next Google Calendar, I am not using ajax and server-rendered templates.

saas_co_de 9y ago

> SPAs are not harder, they never were. Yes, they are harder 1) instead of using browsers based on standards with hundreds of millions invested in developing them for things like routing, caching, history, etc, you are using ad-hoc amateur implementations of all those things that are full of bugs and unimplemented corner cases. 2) Instead of executing your code in a safe environment you control you are executing it in an unsafe environment on an unknown runtime that you have no control of. 3) Instead of processing stateless requests with large chunks of synchronous code backed by a database that imposes some sane limits on state manipulation you are maintaining all of your app state yourself, continually updating it asynchronously, in an insecure environment, with dropped requests, and layers of hacked together client/server data synchronization and caching. Sure sounds harder to me :)