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

Your single-page app is now a polyfill

itnext.io

Post reply on HN
Print view View original

151–160 of 164 posts

Re: Your single-page app is now a polyfill

#151

Post by pier25 »

dspillett wrote: post #148
pier25 wrote: post #63

Earlier quoted context omitted.

> People are impatient and expect everything on three computer to be as fast as the faster things on it. Anything slow can feel like there is something wrong. True, but an SPA doesn't really solve that either. You still have to make a request to the API and wait for it just like you have to wait for some HTML. The only difference is with an SPA you can show a spinner to the user. Also, on an SPA, the initial hit of J…

An SPA, if properly designed, can help interactive use significantly though, compared to full page reloads. You may pay for the reduction in interactive latency with an upfront loading cost, but when comparing to desktop applications that is often not too bad anyway (Excel doesn't load immediately on most PCs, games of any modern design generally don't either). People are more willing to wait a second or few initiall…

I agree, but it really depends on the context and if it is really properly designed (which takes a lot of effort).

Personally I don't mind waiting a couple of seconds for Gmail to load, but I hate to load that much for Twitter which is also an SPA. Not sure what the psychology is there.

Re: Your single-page app is now a polyfill

#152

Post by pier25 »

maxthegeek1 wrote: post #132
pier25 wrote: post #60

Earlier quoted context omitted.

> SPAs allow for highly interactive interfaces with custom components, drag & drop, audio etc. None of the features you listed require an SPA. Other than page transitions you can have any UI sophistication on an MPA. > This is possible, of course, but it will either be lost every time the server is restarted, or it will need to stored in the database. Which is why there are caching databases like Redis to solve this.

Serverside caching with e.g. doesn't help with network latency.

It does when the server has to communicate with distant services/databases.

Also an SPA doesn't alleviate network latency either between the browser and the API.

Re: Your single-page app is now a polyfill

#153

Post by Justsignedup »

Quarrelsome wrote: post #73
Justsignedup wrote: post #55

My reasons for SPAs has always been complex behaviors on the app and state persistence is a PITA if you don't end up with a nice MVVC on the front-end. Not saying not possible to make complex pages without SPAs, but there are some things that are harder, and some that are easier. Personally I love writing SPAs, I find that I end up making less complex code which ends up being easier to maintain. Not counting by the n…

The sort of garbage we ended up doing prior to SPAs justify SPAs. Writing a server to dynamically create a HTML page that also includes first pass content as well as potentially dynamic javascript to make the page interactive in "later passes" is just an ugly mix of client side execution and server side execution in one spot. The application just feels a lot more consistent when the client is just pulling data instea…

There are techniques for controlling complexity there, and often you can make a single-page react page which will encapsulate complex behaviors.

Often a mix of the two helps. But you end up having one set of code managing the static page, and another for the api-based interactions. and then once you have api-based stuff product asks to add on a feature and a feature until you have mutliple SPAs. :P

Code reuse is a big reason too, why write 10 different SPAs for one site, when you can write 1 SPA with a ton of code/tool re-use.

I always end up taking 1 SPA and make 2-4 different SPAs out of it, each facing a different set of users, with different security/look requirements, but all underpinned by the exact same technology.

So much headaches saved.

Just to make it clear:

- I agree that SPAs didn't come out of developers being idiots, but rather because the shit we had to do before SPAs was craaaaaaaaaaazy. Jesus I remember the old jquery things. And before jquery... shiver...

- I think SPAs are definitely not a one-tool-for-all-problems kind of thing.

- Interestingly enough, SPAs can be a one-tool-for-all-problems kind of thing with SSR, that's what linkedin does. LI is an SPA with the ability to behave like a non-SPA via isomorphism.

Re: Your single-page app is now a polyfill

#154

Post by Justsignedup »

WillPostForFood wrote: post #80
Justsignedup wrote: post #55

My reasons for SPAs has always been complex behaviors on the app and state persistence is a PITA if you don't end up with a nice MVVC on the front-end. Not saying not possible to make complex pages without SPAs, but there are some things that are harder, and some that are easier. Personally I love writing SPAs, I find that I end up making less complex code which ends up being easier to maintain. Not counting by the n…

These are good reasons, but notice they are all about improving the experience for the developer, not the user.

I mean isn't that what ruby on rails is? RoR's minimum response time is WAY slower than most other frameworks. Getting a ruby on rails page rendering in under 100ms is work, while other frameworks getting it under 50ms isn't much effort at all.

Tradeoffs everywhere. If I needed to serve my pages to an area where downloading 1mb would take a minute and that was my core demographic, I will be making very different choices in tech than what most people have to write for.

Re: Your single-page app is now a polyfill

#155

Post by nawgz »

jiofih wrote: post #147
nawgz wrote: post #136

Earlier quoted context omitted.

I think my biggest complaint about what you've written here is that you just shunt these "complexities" you wield against SPA to the back-end and then gloss over them. I strongly disagree that "formatting database data into a JSON string is not significantly less CPU intensive than formatting it into an HTML string" - business logic is always the most expensive code to inject. This means you're either, again, not rea…

Nothing stops you from loading all of those graphs in the initial HTML payload if you want to, and then displaying them without a round trip to the server. These things are not exclusive, you don’t need to go all-in with a client-side framework to achieve basic interactivity (like tabs).

This is such a silly thought. I have to have a server which has to be capable of transforming data to valid HTML snippets which are aware of the context they'll be put into, a client which is capable of listening to clicks and then putting some data or snippets in some context it has to be aware of, and I have round-trips for everything even though I have a stateful client, and it's best if that stateful client is an orchestrator for remote systems which can somehow inject interactivity into my stateful client.

It's spaghetti architecture and I don't see what the gain is. Why do my servers need to know how to describe my layout!?

Re: Your single-page app is now a polyfill

#156

Post by nawgz »

manigandham wrote: post #143
nawgz wrote: post #142

Earlier quoted context omitted.

>Anything that actually changes the data requires a server roundtrip I mean, of course, but clearly I've outlined a situation where you can easily prefetch some objects to have an instant user experience. These are plentiful. Additionally, you enable responsiveness in other ways server rendering can't accomplish with an SPA. You can display loading status of async resources, you can optimistically display changes so…

Where's the prefetching? The table loads with the page. Loading it after with JS will only go slower. > "server rendering can't accomplish with an SPA" Again, you don't need a SPA to have some interactive DOM manipulation. Nobody is saying everything requires fresh HTML from the server, but something like jQuery Datatables will give you 99.99% of instant client features while working with server-rendered tables. htmx…

> What's with the extremes?

I'm not the one speaking in extremes. This is a quote:

> The point is that it's faster and simpler to just have the server render the entire HTML and replace that

That's childish analysis.

Re: Your single-page app is now a polyfill

#157

Post by manigandham »

nawgz wrote: post #156
manigandham wrote: post #143

Earlier quoted context omitted.

Where's the prefetching? The table loads with the page. Loading it after with JS will only go slower. > "server rendering can't accomplish with an SPA" Again, you don't need a SPA to have some interactive DOM manipulation. Nobody is saying everything requires fresh HTML from the server, but something like jQuery Datatables will give you 99.99% of instant client features while working with server-rendered tables. htmx…

> What's with the extremes? I'm not the one speaking in extremes. This is a quote: > The point is that it's faster and simpler to just have the server render the entire HTML and replace that That's childish analysis.

Yes, I said that in the context of this thread, specifically the GP post that said:

> "a large html table rendered on the server into the DOM directly was orders of magnitude faster "

Ignoring all context and calling this a "childish analysis" does nothing to further your arguments, and is yet another example of your comments going to the extremes.

You show a dogmatic support of SPAs without any consideration for the repeated statements that they are overused and not fit for the majority of the interactivity that people use them for. If you refuse to accept this than there's nothing more to discuss.

Re: Your single-page app is now a polyfill

#158

Post by jelling »

obilgic wrote: post #2

off-topic: how/why is medium still around with their very aggressive techniques? They started as a minimalist blogging platform, and once they acquired the content, they started putting paywalls in front of their users' content.

I don’t subscribe to Medium yet but I started using Apple News because the ad-driven model has led to publisher pages that are near unreadable / terrible UX. So I won’t be surprised if Medium is successful.

Re: Your single-page app is now a polyfill

#159

Post by jiofih »

nawgz wrote: post #155
jiofih wrote: post #147

Earlier quoted context omitted.

Nothing stops you from loading all of those graphs in the initial HTML payload if you want to, and then displaying them without a round trip to the server. These things are not exclusive, you don’t need to go all-in with a client-side framework to achieve basic interactivity (like tabs).

This is such a silly thought. I have to have a server which has to be capable of transforming data to valid HTML snippets which are aware of the context they'll be put into, a client which is capable of listening to clicks and then putting some data or snippets in some context it has to be aware of, and I have round-trips for everything even though I have a stateful client, and it's best if that stateful client is an…

You are not listening. You don’t need round trips. The same way your SPA receives its initial data from the server, you can send it as HTML (hidden) and just use JS to switch between the views. And there is nothing special about “understanding layout” on the server, you can run the exact same rendering code in the server with node. I’m not going to bother mentioning streaming html / progressive rendering, SEO, caching, semantic content or accessibility since you obviously won’t care much for that.

We’ve been doing this on the web for over two decades now. Tell me about spaghetti architecture once you work on a real world project using React.

Re: Your single-page app is now a polyfill

#160

Post by mattmanser »

nawgz wrote: post #156
manigandham wrote: post #143

Earlier quoted context omitted.

Where's the prefetching? The table loads with the page. Loading it after with JS will only go slower. > "server rendering can't accomplish with an SPA" Again, you don't need a SPA to have some interactive DOM manipulation. Nobody is saying everything requires fresh HTML from the server, but something like jQuery Datatables will give you 99.99% of instant client features while working with server-rendered tables. htmx…

> What's with the extremes? I'm not the one speaking in extremes. This is a quote: > The point is that it's faster and simpler to just have the server render the entire HTML and replace that That's childish analysis.

Seriously, you don't really seem to know what you're talking about.

You can do it either way, and your particular example is a really poor reason to have a SPA.

As multiple people are trying to tell you.

Post reply on HN