Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You probably don't need a single-page app

journal.plausible.io

Post reply on HN
Print view View original

181–190 of 522 posts

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

#181

Post by mattmanser »

marktangotango wrote: post #136
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…

I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all. Compared to client side rendering discrete web requests with minimal templates; you usually get much better…

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.

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

#182

Post by s_y_n_t_a_x »

s_y_n_t_a_x wrote: post #148
petilon wrote: post #124

Earlier quoted context omitted.

Then you aren't benefiting from React at all. The point of React is DOM diffing, which you trigger using setState method.

When you change the props of a component it re-renders. Just because you use pure functions doesn't mean you don't get DOM diffing, that's silly.

To reply to your last comment, each project is different, and if you just want a few things on a page, sure use a small lib like what you suggested. But at a certain point you start reinventing the wheel and no other developer will be able to jump into it. You need a framework for large projects with a team and potential future members.

React isn't complicated, you're making out to be.

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

#183

Post by Scarbutt »

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…

Not contradicting you, but how did you evaluated that the SPA is not bringing any value to the customers? It may make work harder for you, it may cost more, but maybe that cost is rightfully justified from a business perspective.

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

#184

Post by sbov »

dangoor wrote: post #142
marktangotango wrote: post #136

Earlier quoted context omitted.

I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all. Compared to client side rendering discrete web requests with minimal templates; you usually get much better…

This separation of concerns is also good if you have both a web app and native mobile app. The server side ideally puts forth an API useful for both;

Our controllers use APIs. This was common before SPAs became all the rage.

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

#185

Post by save_ferris »

marktangotango wrote: post #136
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…

I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all. Compared to client side rendering discrete web requests with minimal templates; you usually get much better…

I completely agree that a big part of this conversation falls on ensuring code quality is maintained over time, regardless of the architecture you choose.

Fortunately, I inherited a set of pretty well-maintained SSR rails apps, and they've been pretty straightforward to continue working on (with a couple of exceptions).

The single biggest disadvantage I see with front end apps is that comprehending state management via redux and co. is so complicated, and so, so easy to get wrong.

I can tell a coworker to refactor a smelly ERB view and extract out a new template, presenter, whatever. But redux still causes us problems that require refactors months later. It still feels way more cumbersome than being diligent about keeping controller/presenter/template logic clean. We're also far more competent rails developers than we are modern UI developers, and that definitely factors into our productivity.

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

#186

Post by nik736 »

zokier wrote: post #113

This is a tangent, but is Github really still mostly ssr? It sure feels more spa-like these days, full with their own loading bar.

Funny that even Software Engineers can't tell the difference between spa and ssr. How are clients supposed to benefit from spa...

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

#187

Post by matchagaucho »

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.

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

#188

Post by pjc50 »

beachy wrote: post #153
marktangotango wrote: post #136

Earlier quoted context omitted.

I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all. Compared to client side rendering discrete web requests with minimal templates; you usually get much better…

It doesn't often happen because of Conway's law - that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them. But in many organizations the same people…

IMO it's one of the long-term failures of web architecture for CRUD that there isn't a unified solution for this; not only should they be the same team but they should be in the same repo, quite possibly in the same language, and the number of places a field has to be defined should be as small as possible. Let the machine sort out separation of concerns and what code goes where. Learn something from dBase and FoxPro.

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

#189

Post by ryukafalz »

mattmanser wrote: post #181
marktangotango wrote: post #136

Earlier quoted context omitted.

I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all. Compared to client side rendering discrete web requests with minimal templates; you usually get much better…

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.

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

#190

Post by jhall1468 »

criddell wrote: post #177
tyingq wrote: post #22

Earlier quoted context omitted.

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

I'm sure it's nice for you, but users like me aren't happy that every mouse move and page load is cataloged and studied and shared with partners. At least with a native app I can add a firewall rule to restrict it's ability to use the internet.

Users like you represent a tiny, tiny minority. The majority of people couldn't care less about google tracking their mouse movements.
Post reply on HN