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

241–250 of 522 posts

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

#241

Post by oblib »

Arkanosis wrote: post #231
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.

I'll offer the distinction is rather you're using a "web site" or a "web app".

A web site should never break your browser. A web app should be able to run in "Full Screen" mode without needing to use the web browser UI.

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

#242

Post by [deleted] »

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.

[deleted]

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

#243

Post by Figs »

Twirrim wrote: post #79
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…

With gmail: Move your mouse pointer down to the lower right corner of the tab. Do a forced refresh (Ctrl+f5) and you'll see some text pop up while it's loading, one of which is a link to a basic HTML version of the site. Click on it and you're back to what appears to be almost the original gmail interface. Up the top of the page you'll see an option to make it default. It's super fast. Almost absurdly so, compared to…

Instead of trying to quickly click the link, it's easier to just turn JS off and refresh GMail. You'll be prompted to either turn JS on or switch to Basic HTML. (You can make it the default after that, as described.)

I did this a while back, and the only real issue I've had with it is that there doesn't seem to be an equivalent to the "Check mail now" action for imported email accounts. (The 'refresh' link annoyingly does not trigger this action.)

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

#244

Post by Illniyar »

ozim wrote: post #93

I don't get 'SEO for free' argument. You don't SEO application, you SEO landing page and you don't want crawlers to crawl your app.

Not quite. Lot's of applications have SEO for their main content. Social networks (reddit, twitter), marketplaces, shopping sites (some shops, like nike's, are quite complicated js-wise), forums (stackoverflow for instance)

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

#245

Post by quickthrower2 »

nabla9 wrote: post #91
bzalasky wrote: post #81

The answer to whether a single-page app is appropriate for a given project needs to consider product requirements, team structure and available resources. Libraries like React are awesome for breaking down complex (or even not so complex) UIs into story sized chunks that can be tackled by different engineers or even different teams. This is one of the biggest reasons to consider using them, IMO. Even in the case of r…

If the team structure is the problem, you should disband the team and rearrange the structure so that it produces the result what you want. Trying to fit your product to the existing organization is not a good idea. Conway's law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

In theory, but you'd need Steve Jobs or Elon Musk level of clout to get that to happen. You'd need to be at the top of the organisation and pulling the puppet strings. Might be OK in a startup, but unlikely in a medium to large sized firm.

There will be people who need to make you fail or they are out of a job - they'll care more about keeping their job and paying their mortgage than you do about SPA architecture (unless you are at the top and have the vision as to why what you are doing matters.).

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

#248

Post by taude »

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…

Our team has found the balance by making a bunch of smaller, individual SPAs that make up our whole application. We follow some SPA designs, but have them more modular, and glued together by a bunch of delivery pages. We kind of get the best of both worlds, plus there's some pages and content that just render better on the server, and delivered faster through caching...

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

#249

Post by scarface74 »

hombre_fatal wrote: post #227
scarface74 wrote: post #57

Earlier quoted context omitted.

I would rather change a page if and when it is needed by a new feature than over engineer up front.

Well, the thing is that you don't know if you're "over engineering" up front. That's the whole challenge. And rewriting down the road because of the wrong gamble can be very costly. Make the wrong bet enough times and you'll see that it's not over-engineering but just engineering for changing requirements. A classic example is thinking it will be simpler to avoid React and use a few .show()/.hide() toggles. Simple at…

Exactly. You don’t know what you will need. It’s the classic concept of YAGNI and emergent design.

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

#250

Post by BlackFly »

I used to feel that way, then I met a one javascript developer in particular who really made me see it differently. I won't get into those here, I just want to tone down the "probably don't need" into a "don't necessarily need".

As a predominant back end developer, I do feel that the complaints from the article are due to inexperience or misunderstanding:

1. stateless requests: You don't have to cache any state by default, just like server side. You start caching to improve performance and caching is always one of the big 2 problems of computer science. Don't cache if you don't have to: stateless has benefits.

2. Reinvent browser features: use your framework! This is a solved problem. I am not sure what the Angular or React solutions are but with vue just use the vue router.

3. More mature tools: backend suffers from this as well, I know a lot of mid level software engineers that are always chasing the latest fads. Microservices, containers, serverless, etc. The biggest issue I had when I tried to do serious frontend development is just not being aware of the tooling and how it works.

4. SEO: Google can crawl your webapp: https://searchengineland.com/tested-googlebot-crawls-javascr..., I would prefer if the person making the claim (that an SPA does not get crawled) would be the one providing the evidence...

Don't get me wrong though. Sometimes an SPA is the wrong choice but it would be hard for me to say if that is usually, rarely or a toss up.

I think many places that go from server-side rendered to client-side rendered SPAs do not hire a bunch of front end experts when they do so. Then people experience a bunch of problems because of the fact I point out in 3: lack of awareness of the ecosystem. On the other hand, there sure are a lot of diva developers who don't like working with old technology (for example, PHP), and this probably causes a lot of the front end framework churn. Just like picking up a new language, it takes time to produce idiomatic code. Of course, for a new framework it takes time for the idioms to develop...

Post reply on HN