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

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

#21

Post by alexandernst » Sun, Feb 17, 2019, 2:56 PM UTC

The main problem with SSR is that the moment you want to do something a little bit outside of the-happy-path of your framework o choice, you're knee deep into sh.

Let me give you the simplest possible example. A form with multi-dependant inputs: you select an option from a dropdown, and depending of the choice you made, you see another dropdown with some options, or maybe an entire new set of inputs. Maybe there is a button that will open a popup with another form, dynamically generated based on what you choose. Or maybe there is data you must dynamically fetch from the server, based on some combination of actions that the user did.

You can play the ".show()" and ".hide()" game with plain JS, but if you have more than 5 inputs, I promise you, you'll be really sorry for choosing that method.

You can also "inject" somehow any SPA just into that particular view in your project, but then you'll be already dealing with the cons of both SPA and SSR. It doesn't pay off.

I have been doing all types of FE and BE development, and what has given me the best results is making the BE a REST API and doing the rendering on the frontend.

Just my 2 cents.

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

#22

Post by tyingq » Sun, Feb 17, 2019, 2:56 PM UTC

IloveHN84 wrote: post #18

tyingq wrote: post #8

I'm more interested in the future of "you probably don't need a native app" . It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.

Native will always be the best solution... Because it's native.

Technically best doesn't always win the market. I'd love not writing 3 versions of every piece of functionality.

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

#23

Post by pmlnr » Sun, Feb 17, 2019, 2:56 PM UTC

ttty wrote: post #2

Normally you'll always need to add something interactive, therefore js. To do that with server side rendering you'll couple the client side to the server side. For example the server has to send a tag with a class name that the client also is aware of that. Therefore you have 1 component, where half is on server side and half of on client side, which in my opinion is not maintainable.

> Normally you'll always need to add something interactive

Especially in news, articles, longreads, right? /s

Most of the internet content would be perfectly fine without interaction, or with ordinary, oldschool POST forms

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

#24

Post by patientplatypus » Sun, Feb 17, 2019, 2:57 PM UTC

maxencecornet wrote: post #15

patientplatypus wrote: post #12

This feels like clickbait, but just as an aside there's nothing that says you can't do server side rendering and react. Next.js is what I'm using on my current project and it's server side out of the box. So you have text rendered in source like you would with a traditional server side app with the benefits of SPA. So at least one of his nitpicks sounds like he didn't do his homework.

Of course you can use server side rendering with Next.js,but it adds some work/complexity With a server rendered website, you don't have to do anything

I mean, not really? When you want a new page you create a react component in the "/pages" directory. "/pages/hello/index.js" routes to "mysite.com/hello", and "/pages/hello/there/world/index.js" routes to "mysite.com/hello/there/world". The pages are served from a node.js site. The newest version (8) comes with lambda rendering but you don't have to use it if you don't want.

This is pretty simple to reason about honestly.

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

#25

Post by the8472 » Sun, Feb 17, 2019, 2:57 PM UTC

tyingq wrote: post #8

I'm more interested in the future of "you probably don't need a native app" . It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.

Resource consumption will be worse, doubly so when they make an app out of the SPA via electron&co.

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

#26

Post by save_ferris » Sun, Feb 17, 2019, 2:58 PM UTC

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 announcement, our productivity has diminished dramatically since so much of our time is now focused on re-working functionality that already exists into an SPA, and it's completely unnecessary. Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks, and we're definitely going to make mistakes along the way that we weren't making before.

It drives me crazy to think that some exec came up with SPA-ing everything as a sales pitch to clients, when 99.9% of our clients have no idea what an SPA is. And the amount of money being spent on turning already-working apps into SPAs is astronomical.

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

#27

Post by pmlnr » Sun, Feb 17, 2019, 2:58 PM UTC

IloveHN84 wrote: post #18

tyingq wrote: post #8

I'm more interested in the future of "you probably don't need a native app" . It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.

Native will always be the best solution... Because it's native.

Except when all your content comes through the pipe, in which case native is just a glorified iframe.

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

#28

Post by danielovichdk » Sun, Feb 17, 2019, 3:00 PM UTC

I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla.

Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked.

The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris.

I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer.

Good luck fixing that. I'd rather keep my code and tooling simple and clean.

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

#29

Post by save_ferris » Sun, Feb 17, 2019, 3:00 PM UTC

alexandernst wrote: post #21

The main problem with SSR is that the moment you want to do something a little bit outside of the-happy-path of your framework o choice, you're knee deep into sh . Let me give you the simplest possible example. A form with multi-dependant inputs: you select an option from a dropdown, and depending of the choice you made, you see another dropdown with some options, or maybe an entire new set of inputs. Maybe there is…

This is where the hybrid approach they mention in the article really shines. Embed front end frameworks where you need it, and stick to SSR where you don't. It doesn't have to be a binary choice.

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

#30

Post by wrestlerman » Sun, Feb 17, 2019, 3:00 PM UTC

I have the same opinion. Building SPA is f* hard and time-consuming. But it depends. If you know how to build SPA fast, then, by all means, go that route. (As a solo dev or small team)

I use Rails, but Rails views are a disaster. You can use a lot of different patterns/gems, but still, logic is highly coupled with the view layer. Personally, I like Phoenix approach with templates + views. But still writing script tags makes me cringe a little bit.

But I wouldn't discourage people from using SPAs, though. If you are gonna have a lot of buttons, modals, different tables, charts, forms and stuff like that, I would go SPA. Or first serverside -> SPA. Especially, when you are working in the team, it's so much easier to tell one person to craft this json api and another to craft this design with a consumer for the json api.

That become long... in short: if you have a small team or solo go server side 99%. If you have a big team or app that's gonna be very heavy UI -> go full spa or go server(mvp) -> spa