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

231–240 of 522 posts

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

#231

Post by Arkanosis »

oblib wrote: post #222

This article feels to me like complaining about making the simple difficult. Since I work alone I suppose I'm not up to speed on what defines a single page app but the apps I've been building with PouchDB, jQuery, and Bootstrap run in a single page. "Stateless requests Traditional web servers are built to be stateless. " True, but "apps" should be designed to be self-contained (i.e. all the user navigation is done wi…

> i.e. all the user navigation is done within the app UI, not the browser UI

Not sure if that's what you mean here, but when this breaks the “back”, “next”, “refresh”, “bookmark” or “share URL” features of my web browser (among others), I hate whoever has been responsible of the design as much as I've hated Flash in the past.

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

#232

Post by JamesBarney »

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…

So I could see an issue with someone writing business logic in a view and then someone else rewriting that business logic somewhere else slightly differently.

But I've seen the same thing happen in the SPA. Where one person calculates some value in an API method, another doesn't know about it and calculates it again slightly differently in a different method leading to app inconsistencies. And SPA's make it worse not better because it sometimes forces you to write a piece of domain logic twice, once for the browser and once serverside.

I honestly don't know what's wrong with accessing query strings or session information. But I think maybe the reason you've seen template code using global state is because the template code was just written earlier back before that information had really soaked into the entire development community.

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

#233

Post by jazzdog »

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…

I come from the .Net toolchain as well, no longer develop full-time, but write tools for my business as needed. I use Angular (6 or whatever). They talk to a .Net (core) server as little as possible. What I find is the iterative dev turnaround time, that cycle between find a bug - fix it - test it, is so much faster with angular than if server-side rendered. It's a joy. That same cycle on server side in .Net - change some .cs file and check that fix quickly - , slowly rather - a real pain. That alone drives the choice for me.

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

#234

Post by oblib »

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…

Wow... that is just insane.

I've been working alone for so long I've not had to deal with anything like that for years, but I'll offer this...

Doesn't matter, so don't let it matter to you.

When I worked for others I'd offer my opinion and advice and when it was ignored I'd do it their way every step of the way because it really does not matter. You get paid the same either way.

I'll add that because it didn't matter to me I ended up getting to work on some pretty cool stuff. Everyone knew I wouldn't whine about changing directions or being taken off a project and jumping on whatever they wanted so I was almost always the 1st choice to work on something new.

When that happened I was often able to influence the direction of the work.

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

#236

Post by petilon »

hesarenu wrote: post #223
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.

The point of React is components. Simple components to build complex apps. Dom diffing are just lower level concerns.

There are better ways to build components. The problem with React components is that they are only compatible with React. What if there was a way to build components in a better way, and what if those components were compatible with all current and future frameworks? There is a way to do that. Look up W3 Web Components specification. There's sample code here: https://github.com/wisercoder/uibuilder

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

#237

Post by quickthrower2 »

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…

The bank I used has gone from traditional to SPA style, and I wish they hadn't. There is a massive load time before I can even log in with some stupid animation, and they've reduced the exporting features. As a customer I have gained nothing. But I guess it keeps food on the table for some devs.

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

#238

Post by Fredej »

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…

It's funny how Google has been banging on about "just a few milliseconds of extra loadtime and your bounce-rate increases!" while in Gmail it's like they think the product is so good, people should be willing to wait 10 seconds to view their _mail_.

The reason I'm even reading this comment section is because I wanted something to do while waiting for Gmail to load.

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

#239

Post by pier25 »

I've been making SPAs for a couple of years now and I totally agree.

Not only the complexity of development is increased, but there is no real benefit for the vast majority of use cases.

I think there is merit in using an API though and clearly separating data from presentation.

What I've been doing lately is using Jekyll with Vue components for some in house projects. It works great.

Another option I've been trying out is doing SSR in JavaScript on Zeit Now monorepos. Haven't used it in a real project, but so far it's awesome. You can keep using all your front end knowledge, but render each route on the server. No more managing state (Redux, Vuex, etc) or router.

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

#240

Post by quickthrower2 »

danielovichdk wrote: post #90
cc81 wrote: post #64

Earlier quoted context omitted.

.NET is not that simple either, you are just used to it. Beginners will think it is confusing with .NET, .NET Core, .NET standard for example. There are many options in the front end sure but when you just pick something and learn it then it is not very difficult to get started. Just start with for example just React or Vue and don't add any state management. Create the apps with their CLI and follow the tutorials on…

I agree. Microsoft did a terrible job not having one framework for every path, like it did with the original .NET framework.

The naming could be better. I think .NET -> .NET Classic and .NET Core -> .NET would be better, and maybe .NET Standard -> .NET Specification.
Post reply on HN