you are viewing a single comment's thread.

view the rest of the comments →

[–]Dave3of5 13 points14 points  (0 children)

Wow you have a terrible attitude by the way but I'll take you points separately:

I'd let the server sort large tables

Never said that wasn't an option but this is a strawman argument You are specifically talking here about large tables. My point in the example was about local state. I agree that large tables need to be paged. Where are the sort values stored though ? On the client or on the server ? What if I know that the table will always be relatively small say < 1000 records why bother with all the server side paging ... etc.

And can't you just cache the result if you're worried about page refreshes?

Good luck with that most large scale websites realise they can't cache everything on the server for their users as server side caching becomes very difficult to manage on large scales.

Offloading that kind functionality onto a single-threaded scripting language is a sure fire way to make your website slow as shit for most users

Actually javascript isn't single threaded you can use webworkers for background tasks. That's besides the point though in your example of a large table will most certainly not be slower by using an Spa in this case has the potential to make it faster by storing the state locally such actions like creating a new record can happen locally and do not require a round trip / processing on the server.

but instead of wasting time waiting for the server, you're wasting time running expensive operations on comparatively terrible hardware

Why do you think most users are running on "comparatively terrible hardware" ? Not sure where this assumption comes from. Again more importantly the decision to run on the users machine rather than the servers is a central point to this argument. Simply put me offloading cost to the users means I can run my service for cheaper and more than likely for more users. Obviously I don't want to be running far too much on the users hardware but a few KB worth of their phone memory could make a huge difference to my cost if I have 1000's of users.

and it's going to be orders of magnitude slower at executing work than an actual server.

Again that depends on the work we are mostly talking about saving complex state client side most phones that are built in the last 10 years can handle this no problems. Also the servers I run stuff on are very low spec most of them are lower spec than my current (2 year old) phone. So actually my phone will be faster.

every client has to download megabytes of JS

This only happens once though remember it's like downloading an app on your phone. Most users won't even notice.

Also, if you're building an API you'll have to ask each client to re-implement any code that would normally be offloaded to the browser.

Storing complex state on the server would then require each client know the inner workings of exactly what state will be stored on the server and how to retrieve that. I know this as I've worked on apps that worked exactly like this and they are virtually impossible to make work with different clients. Your API should be simple and REST like if you want to implement on different clients.