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

341–350 of 522 posts

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

#341

Post by jordache »

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…

your anecdotal story doesn't highlight deficiencies with SPA. You only talked about the pains associated with rebuilding apps with different technology to achieve feature parity.

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

#342

Post by arbie »

clessg wrote: post #230

Personally, I'm very interested in the possibility of Phoenix LiveView giving us the best of both worlds: https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...

> As an application developer, you don’t need to write a single line of JavaScript to create these kinds of experiences. You can write and test all your code in a single language: Elixir.

Now you have two problems.

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

#343

Post by armandososa »

ivanhoe wrote: post #316
brazzy wrote: post #259

Earlier quoted context omitted.

You overlooked this part: > 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

You simply trade back-end frameworks complexities for the front-end framework complexities. With the right architecture there is no huge difference IMO, just of course you also need to upgrade your teams so that they can handle a lot more tasks on the front-end than with SSRs (and you'll probably need less back-end devs)

Also, on the majority of SPA frameworks you have the notion of components which makes making the UI a lot simpler than with traditional SSR abstractions (templating and partials are not sufficient).

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

#344

Post by mnm1 »

skinnyarms wrote: post #127

How about build-time rendering? Server-Side rendering tightly couples your front-end to your application server. Scaling the site means scaling up that application server. A bug in one "page" of the app can cause the whole application server to go down. If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/server…

> A bug in one "page" of the app can cause the whole application server to go down.

Maybe if you're using node or some other single threaded server like that but this isn't true for multithreaded or multiprocess servers. It might be an argument against node but it's not an argument against server side rendering. Also, it's irrelevant how pages are rendered or what you're architecture is if a bug brings down the whole server--either way your app doesn't work.

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

#345

Post by armandososa »

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.

How would you make it "even more complicated, and more likely to spaghettifi" to maintain an API than having to maintain a rich UI. Now that's a load of nonsense, or at least very misguided hyperbole.

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

#346

Post by dwaltrip »

ldiracdelta wrote: post #267
dwaltrip wrote: post #194

Earlier quoted context omitted.

You switched from a C# or Python backend to node.js so that you can render React on the server, correct? Or are you doing something fancy to serve react.js rendered contents from a non-js backend? I agree that the hybrid approach of both server-side templates and SPA-controlled content looks difficult.

Personally, I don't use node.js as a backend. I normally use Django REST Framework (DRF). I may do server-side rendering of the client using express, still calling back into DRF for the data. The important piece for me is that I don't like the idea of generating a page in one language and then mutating the UI on the client side with another language. I just use one language for the whole UI.

Thanks for sharing, that is an interesting setup.

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

#347

Post by sirsuki »

brazzy wrote: post #259
amoitnga wrote: post #226

Earlier quoted context omitted.

> 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. This doesn't seem like a problem of "MVC vs SPA". The same problem would occur if you were ordered to rebuild 12 apps written in Rails ( or whatever full-stack MVC framework) in a different one, like Django, for examp…

You overlooked this part: > 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

Is there any possibility that the added complexity is a symptom of the framework in use and not a general problem with ALL frameworks? I know I've experienced many projects and found server side rendering more complex then client side when using frameworks like Ember.js.

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

#348

Post by anonyfox »

Having developed with nodejs since v0.4, went through jquery => backbone => angular (1) => ember => vue => react, written stuff in several incarnations of javascript (including coffee and typescript), used build tooling from grunt to webpack and customized browserify, even built stuff with meteor... i can‘t bear it any longer.

Actually now we are full circle again. Files that mix css/template/logic with FOTM syntax, add some database calls during SSR and you have basically PHP. Just more complicated tooling. Deploy your frontend on S3 and its similar to FTP to Apache Servers, except you can‘t update just individual files. Run your backend on AWS lambda and you have stateless backends like ... PHP, but with cloud vendor lock-in. State Management like „Flux“ that poorly resembles state machines on top of JS shortcomings.

I am personally switching completely to elixir/phoenix to do anything web-related and can solve things cleanly within minutes. Also when Phoenix LiveView finally arrives, it could be groundbreaking and replace many usecases of modern SPAs.

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

#349

Post by nicoburns »

dkarl wrote: post #278
kyledrake wrote: post #67

Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big…

I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design. It was nice and would still be nice if browser caching meant a site still worked well over a bad connection. But you can be browsing around a "static" site and hit the back button and be stuck staring at an empty or partly rendered page waiting f…

You could also run server-rendering with a service worker. There's nothing about a service worker that means it only works with SPAs. It basically just gives you control over caching behaviour...

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

#350

Post by dimgl »

danielovichdk wrote: post #28

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…

You mean ludicrous?

`node_modules` directory topping 60+ mb means nothing when the final product is an optimized bundle or a `node` process loaded in memory. A large majority of developers don't care about this because they're just looking to get actual work done... not sure why you're trying to "fix this".

I'm also not sure what you're talking about when it comes to unclean code and complicated tooling. The tooling is dead simple... much simpler than the NuGet/IIS/OWIN nightmare that is C# development.

I think you're very close minded and you'll likely be stuck in .NET land forever. And that's okay if that's what you like or if it's what gets you a paycheck. But to completely dismiss this ecosystem as if it's not productive... it's just a sign of naiveté. Good luck.

Post reply on HN