You probably don't need a single-page app • Hacker News Board

Re: You probably don't need a single-page app

#201

Post by fyfy18 » Sun, Feb 17, 2019, 5:34 PM UTC

petilon wrote: post #137

trimbo wrote: post #115

Earlier quoted context omitted.

> Developing SPAs is easier than server-render applications. Not sure about "easier". I'm a backend person so take this with a grain of salt but, to me, nothing on the web is easier than doing everything server side. All of your code can be in one language (plus a template) and the same build. Consider what it takes to make a change in each model. In an SPA with one of the frameworks mentioned, it requires several ch…

You have to deal with multiple languages in any case: Java/C#/etc for the server logic, HTML for rendering and CSS for styling. You also have to deal with whatever syntax you are using to embed expressions in the template. If you use SPA there is one additional language (unless you use Nodejs for server logic) that's true. And you also have two different build chains. But the advantage is that the server logic become…

> Your server can focus on being a stateless REST service which is more scalable

You can do exactly the same with server side rendering. In all the applications I've built over the past decade, the only state I've had is an encrypted session cookie to say which user you are logged in as - but that's send by the browser on each request, so it doesn't matter which server handles it.

The urls I've built are basically the same as you would for a REST API, to view a widget you do a GET /widgets/1, to view the form to edit you do GET /widgets/1/edit, to save the update you to PATCH /widgets/1, which redirects you to the list of widgets at GET /widgets. I admit that trying to fit multi-step workflows into this scheme doesn't always fit so nicely, but with good API design (that's what you are building, an API for the browser to call directly without JavaScript) you can make it perfectly stateless.

Re: You probably don't need a single-page app

#202

Post by aaaaaaaaaaab » Sun, Feb 17, 2019, 5:37 PM UTC

matchagaucho wrote: post #187

Counterpoint... how many times have you clicked on a Show More link and thought to yourself "No, no... please don't redirect me to another page". Progressive reveal patterns are expected by end users. It's just lazy for a programmer to assume old-world CRUD patterns with server-side render.

Counterpoint: how many times have you browsed an infinite list of progressively revealed items only to accidentally refresh it and start scrolling again from the top. And of course the items are randomized by our latest AI-based clickdriver algorithm so you won’t be able to find the item you were looking at no matter how long you scroll ;)

Re: You probably don't need a single-page app

#203

Post by Ericson2314 » Sun, Feb 17, 2019, 5:38 PM UTC

Porque no los dos?

We pretender enough so if you turn off JavaScript you get old school and if you turn on you get SPA. All the basic widgets are server/client agnostic, and we have a combinator to special-case the server vs client code when needed. The types enforce client-specific functionality isn't used otherwise.

We also have a "DOM puppet" backend which allows everything to be compiled to native code puppeteering browser APIs from a fair. Prerendering, that, and direct JS output all all supported through related typed abstractions. Soon we will compile the puppeteer to WASM too, so we won't even need the direct JS output anymore.

Re: You probably don't need a single-page app

#204

Post by zhobbs » Sun, Feb 17, 2019, 5:39 PM UTC

WrtCdEvrydy wrote: post #150

ccalvert wrote: post #39

I have modest skills as a developer. I was trying to convert an old static web site into something more interactive. Without really thinking it through, I started building a SPA. I got stuck on the SEO part. I found it innately complex, but the real trouble came from trying to bring together the disparate sections of the old static site while preserving and abetting SEO. One day I just ditched the SPA and rebuilt the…

React Server Side rendering with Next.js is the best of both worlds. You get streamed JS, with pre-rendered HTML for SEO.

I second this. I use Next.js with lambda, so I don't have to worry about servers. Works great...

Re: You probably don't need a single-page app

#205

Post by woah » Sun, Feb 17, 2019, 5:39 PM UTC

cfv wrote: post #119

You probably don't need a single-page app, right up to the point where it's a business requirement and you have to translate a GB worth of convoluted JSPs into one because the client likes smoothness in their flows, continuous saving, and all those nicely choreographed state transitions you just cannot get without having a framework hijack the History and File APIs from the browser's paws. Yes, a nice state machine-l…

This is what HN is always missing on the anti-SPA rants. It’s almost always a requirement from the client. How many hours have been wasted on here by programmers writing overwrought comments about how we’re losing touch with the user because of all of our complicated frontend frameworks? No. It’s almost always because the client’s designer wanted a real-time updating hamburger menu or whatever.

Re: You probably don't need a single-page app

#206

Post by barbecue_sauce » Sun, Feb 17, 2019, 5:39 PM UTC

save_ferris wrote: post #26

This. So much this. My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well. Since the a…

Would it be accurate to characterize your opinion as "SKA not SPA?"

Re: You probably don't need a single-page app

#207

Post by fauigerzigerk » Sun, Feb 17, 2019, 5:41 PM UTC

mycall wrote: post #132

todd3834 wrote: post #73

Earlier quoted context omitted.

I don’t think this is about edge cases but SPA have been abused. Imagine using google docs as a server rendered experience. Or any of the apps in iCloud.com. There are use cases where it makes sense and use cases where it doesn’t. Most of your complaints are about poor implementation but if a large percentage of people poorly implement SPA then it still looks bad. I used to say you could make a very native experience…

I tell people don't implement SPA. Implement PWA. PWAs give you actual benefits that SSR doesn't provide (eg. offline).

I don't think PWA offline storage is anywhere reliable or predictable enough to be advertised as an actual benefit. It's essentially a fancy cache at this point:

https://developers.google.com/web/fundamentals/instant-and-o...

Re: You probably don't need a single-page app

#208

Post by wreath » Sun, Feb 17, 2019, 5:41 PM UTC

syllable_studio wrote: post #195

I have experience building both SPA apps and server-side templated apps. They each have their strengths and weaknesses. Just as a SPA won't solve all your problems without any trade-offs, getting rid of a SPA framework also won't solve all your problems -- you'll probably need to re-invent some wheels and then discover that your new solutions are hard too. I think it's good to have a healthy dose of skepticism about…

> it's often just simpler to use a SPA framework in the first place.

Simpler or more convenient? I've yet to see a production-grade React setup (for example) that is simpler than having either vanilla JavaScript or even jQuery to achieve the same interaction. The amount of tooling required to do simple interactions does not justify the technology for most applications IMO.

Re: You probably don't need a single-page app

#209

Post by IanCal » Sun, Feb 17, 2019, 5:43 PM UTC

ryukafalz wrote: post #189

mattmanser wrote: post #181

Earlier quoted context omitted.

This is a load of nonsense. If you can't separate concerns in a hybrid MVC pattern, you'll be screwing it up just as much in an SPA. Plus you've got the extra layer of an API to maintain too making it even more complicated, and more likely to spaghettifi, not less.

>Plus you've got the extra layer of an API to maintain too On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.

Possibly, though your perfect API design may differ significantly from your perfect site structure. It feels reasonable to consider both and see it as a positive if the use cases work.

Re: You probably don't need a single-page app

#210

Post by save_ferris » Sun, Feb 17, 2019, 5:44 PM UTC

Novashi wrote: post #179

kissgyorgy wrote: post #162

Earlier quoted context omitted.

> I would note that generally server side templating is often a mish mash of business logic If you don't have good, experienced senior developers or they don't have discipline, yes. But that's true for any technology. Good developers have the knowledge for simple things like how to separate business logic from templates...

TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less. It would be nice if, given a task, we could teach people to choose the right approach in code the first time, but given we still have trouble recognizing good developers, the fast-paced churn of rewriting apps is a decent hedge until we figure out how to train the people we want. We seem to only want developers…

> TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less.

I disagree with this. De-prioritizing code quality because a rewrite is on the horizon is a great way to paint yourself into a very bad corner.

Imagine letting your codebase rot with the assumption you're going to rewrite it only to have your CEO walk in one day and completely shift priorities to build some new feature to land a new customer or appease a current one (a not-too-different scenario happened to me once.)

Priorities change all the time, and quality code grants the flexibility to adapt to changing priorities.