> 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 :)

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.

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)

Your thoughts on webpack/babel/grunt/gulp well echo my sentiment towards seasoned programmers.

I've only been at this for around 15+ years right now. I agree I am starting to see repeated problems solved in new JS languages that I've seen solved in the past.

That's part of the fun in what we do for a living though. I consider myself at least mildly seasoned, but still a ton to learn from those fresh to the field and those who have been around the block at least twice.

I quite well understand what WebPack is doing, and find it very useful. Anytime I find myself thinking I'll make my own recipe for a build system with custom scripting, I seek a well supported framework, you know on the off chance someone else wants to understand and contribute to the build system.

I think it's a poor choice frankly to build 100% custom frameworks for building when you can use a widely adopted community choice. I was more pointing to the volatility of JS frameworks vs stable frameworks in Java like Spring.

As we age in our career though it seems we should avoid condescending tones with more junior programmers though, as they may have a unique solution to problems. I've seen some junior folks get quite offended when a non-producing "seasoned" programmer gives them the "I've been doing this for 20 years" schtick, then turn around to spend a few days on a powerpoint instead of contributing to the team.

Anyways, I don't want to rant.

I hear you. Instead of thinking about a build system (custom or not), I normally begin by trying to keep the project simple enough that file copy is my build and deploy mechanism.

I don't mean to be rude, but you clearly aren't talking about the same kind of application. I have worked on a SPA before that used knockout and jquery with an ASP.NET MVC backend and Razor-rendered 'templates'. It was a much different beast than an angular or react app.

I am observing that you are right, there is no definition globally accepted by the community on what an SPA is.

For me, a better definition is the one that it is independent of the technology used to implement it. An SPa is a way to structure an app, is not a vendor feature or a tool.

While is true about nowadays angular et all are the tools commonly used to create SPA, the tool shouldn't have the power to change the definition, so your knockout MVC is still an SPA.

If the OT chose a complicated set of tools to develop an SPA, then is his decision and the difficulty lies in his decision of the tools chosen, not on the SPA type of app.

I agree we aren't talking about the same apps.

I don't know if folks much consider vanilla JS / JQuery apps Single Page Applications.

I think (but am not sure) that all SPAs are built these days with Angular, React, Ember, Elm, Vue, or some other framework I haven't paid attention to.

Usually tied into Restful webservices that don't do any templating server side unless it's via Isomorphic JS. Maybe I got it all wrong though.

None of them? Are you just doing everything vanilla js/html/css with no build tools, or just using bash/npm scripts?

The thing about build tools and frameworks is that once you have tools for managing complexity then the penalty for complexity goes down and complexity explodes.

The apps I have seen built with all of these "modern" tools are much more complex and difficult to maintain than the apps I was seeing 10 years ago that were architected and managed by hand.

That is why many of the people using these tools are switching toolsets every 12 months because they can't maintain what they are creating and have to throw it away.

My experience boils down to inconsistent mindsets on large teams too though.

You get a variety of folks in a room working on a complex business problem, some favor simple tools, some are constantly distracted by shiny new tools, you end up with crazy complexity at times in terms of the solution.

I think it's important to focus on a team and vision for managing the complexity and the rest should fall into place. It boils down to good engineering vision.

Nothing beyond jQuery, Bootstrap at the core.

Sometimes some libraries for UI components like datatables.js, or a datetimepicker, but that it is.

Does anyone else even have a desire to work on the apps you are contributing to with you?

<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.

Wow, ok.

I won't get into a pissing contest, but I've solved and managed large and small teams. Folks don't like to maintain custom built software solutions that don't use common accepted best practice frameworks.

JQuery is widely accepted as an anti-pattern by huge swathes of the programming community.

You are right though, I've paid off most of my bills and do have a choice in what I work on anymore. I definitely don't live in a basement.

I agree about the pissing contest, Just to document the issue: the same way that my sarcasm touched a nerve in you, the comment "Does anyone else even have a desire" can be read as belittling and condescending. But I rather laugh at it with a sarcasm.

I have never been a follower of what the community says. Half of the time figureheads make bold statements based on an economic agenda more than a technical one. If JQuery is an antipattern... don't know, don't care, what I do know is that is light enough, and provide a simple, compatibility layer across browsers. That is good enough for me.

Technically speaking the only reason to avoid JQuery now is because DOM manipulation is more costly than dealing with a more efficient Shadow DOM to manage the lifecycle of UI updates on a screen.

JQuery may be a fast download but JQuery applications can be quite costly to run especially in a non-browser-refresh environment.

I'm sure your JQuery applications are quite efficient, but I am an advocate for choosing modern tools that developers want to work on when you inevitably move on from your projects/customers. I do also advocate for tools that are going to be around to stand the test of time, and in your favor JQuery is a ubiquitous library used all over the place, people do know it, and a customer of yours will have no issue finding someone who is willing to work on it.

I by choice avoid those projects, and have worked with quite a few folks who do things the JQuery way when we are using React or Angular.

Enjoyed the debate today, but my question was largely left unanswered. I was curious if you worked on a large team with your framework/JQuery or if it was a smaller deliverable managed by you and another person or maybe just you.

I have witnessed React and Angular apps with as little as one developer, but up to 30 in some cases all on the same application. Complex applications like Trading Systems and Document delivery with multiple connected users.

I'd wager it's tough to get all of that done without some documented tools and complexity, given the complexity of the business problems at hand.

JQuery is widely accepted as a productive and appropriate tool for many types of projects by huge swathes of the programming community.

I currently help maintain a React app that's approximately a one dev project. It's a beast though. 900 transitive npm dependencies. Huge, brittle build process that has broken in the past and prevented us from deploying critical changes for periods of time while we debugged it. Several long-standing bugs because it's such a hassle to get into. I'm a big fan of jQuery sprinkles in light of this experience.

I think you're conflating React with other complexities. React doesn't require 900 npm dependencies.

Are any of the apps you made public? :)

Also sounds like you’re working in a small group? I’ve found large teams will value clarity and maintainabiliy lots more.

Lots of my work is under very restrictive NDAs, so not much public, all though heavily used internally by my clients.

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."

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?

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.

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.

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?

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

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.

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_inv...

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?

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.

Rails and Turbolinks are doing just that, but with its own take on shoring up latency, and it is fantastic!

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.

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.

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.

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.