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

251–260 of 522 posts

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

#251

Post by jamespollack »

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.

have you not used a client-side router in like 5 years? you just plug one in and BAM browserHistory, etc.

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

#252

Post by jamespollack »

bwilliams wrote: post #152
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. That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end. > 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/serverless ser…

> That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end.

What? The previous poster said coupling frontend / server tightly will result in crash of both if there is a server bug. Your response is that a bug in an unattached API could happen? Of course a bug in your API could crash your API. But at least then it's just your API that's crashed, not the (thousand) servers you're using to serve the front end and every device using them.

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

#253

Post by hesarenu »

petilon wrote: post #236
hesarenu wrote: post #223

Earlier quoted context omitted.

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

So another library. From the examples i am not impressed. Web-component are not panacea. For me reactjs is still the best frontend framework out there.

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

#254

Post by Spivak »

LaGrange wrote: post #213
cfv wrote: post #119

You probably don't need a single-page app, right up to the point where it's a business requirement and you have to translate a GB worth of convoluted JSPs into one because the client likes smoothness in their flows, continuous saving, and all those nicely choreographed state transitions you just cannot get without having a framework hijack the History and File APIs from the browser's paws. Yes, a nice state machine-l…

> smoothness in their flows ...what? > continuous saving No problem. > and all those nicely choreographed state transitions Learn to say "no." It works wonders whenever people tell you that your aircraft has to go under water now.

It's difficult to tell the person who's writing your paycheck "this is totally possible I just don't like it and so won't do it."

Like if you're doing SSR you could at least use something like turbooinks to implement state transitions.

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

#255

Post by jamespollack »

trimbo wrote: post #115
petilon wrote: post #47

I couldn't disagree with this article more. Developing SPAs is easier than server-render applications. The problem is React, Redux, and other such libs make this more complicated than necessary. React is all about surgically making the smallest possible change in the DOM to refresh the page. But is that really needed? Most of the time it is not. Why not re-render the whole page? This is what happens in the case of se…

> Developing SPAs is easier than server-render applications. Not sure about "easier". I'm a backend person so take this with a grain of salt but, to me, nothing on the web is easier than doing everything server side. All of your code can be in one language (plus a template) and the same build. Consider what it takes to make a change in each model. In an SPA with one of the frameworks mentioned, it requires several ch…

I think that "I'm a backend person" says it all -- most of the people in this thread are probably not JS natives or front-end natives. All of the complaints about JS fatigue, or not knowing how to use client-side routing are because you've done things differently on the backend. Is it such a surprise that front-end frameworks and tools make more sense to people who actually enjoy and have experience working on the frontend?

If you provide an API schema, with a SPA the whole frontend can be developed separately of ever touching backend code. Okay, so you changed the name of model.thing to model.anotherThing - quick change in the reducer that is consuming that end point and call it a day.

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

#256

Post by tedunangst »

tyingq wrote: post #158
AnIdiotOnTheNet wrote: post #88

Earlier quoted context omitted.

> I can spot Qt a mile away. A lot of the visuals look wrong and a lot of the controls don't behave right. You mean it has no respect for your native toolkit... just like the web?

"just like the web" How true is that? I was under the impression that for Android and iOS, Chrome used the native widgets for most things.

How many SPAs use native controls with minimal styling?

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

#257

Post by jamespollack »

pmlnr wrote: post #23
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

...? "Most of the world is fine with whale oil lamps, who needs electricity"

Try a really good interactive article from the New York Times. You'll have a much more impactful experience than if you read a blurb about the same thing on your RSS reader.

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

#258

Post by yawaramin »

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…

There's also a hidden 'mobile webapp' version: https://mail.google.com/mail/mu/mp/167/?mui=ca#tl/Inbox

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

#259

Post by brazzy »

amoitnga wrote: post #226
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…

> 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

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

#260

Post by jamespollack »

burlesona wrote: post #147
johnchristopher wrote: post #51

> Gulp, CoffeeScript, BackboneJS, and SASS, all of which have been superseded by newer tools. Avoid the Javascript fatigue by not relying so much on Javascript! What ? These are all javascript things, right ?

That was his point. The rails stuff he learned five years ago is all still considered good practice, but the JavaScript stuff he learned (listed above) is now considered antique.

So... people who hate learning should use SSR?

Once you've used grunt, using gulp is not a big logical jump. Then to webpack. Whatever, they're just build scripts! Roll your own shell scripts if you want! A day to learn them, or a lifetime of being a hater.

Post reply on HN