4 ms·

This is exactly why I've always been puzzled by the urge to move more and more logic to the frontend. In backend development you have a choice of many mature la

This is exactly why I've always been puzzled by the urge to move more and more logic to the frontend. In backend development you have a choice of many mature languages, tools and frameworks which are fairly sane. I'll take that environment as the foundation of a web application any day and apply the mania of client-side javascript to it selectively in cases where we need to minimize server roundtrips.

jaredklewis 10y ago
I think it mainly comes from the fact that web applications are becoming more interactive. If you are going to implement photoshop in the browser, there's going to be a lot of client side logic. Before, web development was more like, "fill in this form and when you're ready hit submit and we'll check it." Now people are implementing word processors and music libraries.
- apatters 10y ago
  That's very true, there are web apps where "cases where we need to minimize server roundtrips" are the default case. For these situations it makes sense to run a lot of the logic on the client. However it seems like this has been taken way too far -- I run into a fair share of developers out there who look at basically any proposed web app and say, "Oh yeah, this needs to be a SPA built with React." Why? "Because it's better" and then a rattling off of generic reasons that SPA and doing everything client-side are superior. This is basically the modern version of the Lisp fanboy, they find a good hammer they want to work with more and now everything they see is a nail. These are often the younger guys who have not yet seen this pattern carry itself out over a generation or two of developers -- if there's any reason why tech ageism is amazingly dumb it's this one imo (have the guy on your team who's graduated past the fanboy stage make your tool, platform and framework choices, you will save far more than the premium that you have to pay him).
dozzie 10y ago
> [...] I've always been puzzled by the urge to move more and more logic to the frontend. Moreover, we've already had applications written in client-database architecture, and it was nowhere near pretty. Fortunately they died long ago, but unfortunately they're resurrected now again.
dspillett 10y ago
> why I've always been puzzled by the urge to move more and more logic to the frontend. This is usually about a mix of scalability, responsiveness, and partition resilience; with the level of importance of those being dependent on the application. * Scale: if the client makes fewer request of the server(s) then you have reduced server and network requirements. As server resources get cheaper (and the cheap options more reliable) that side of things is becoming less important, but the network requirements extend far beyond you and almost all the way to the user (see the following two points) who might have a very slow connection at times. * Responsiveness: the more that you can do client side the quicker your application will feel to the user, even if there is a delay in updates actually hitting the global view you can make it look/feel instantaneous (though you do start to have more problems wrt conflict management when people are collaborating). Have a look at the different methods online games (where real responsiveness and the appearance of instant iteration are vital) manage this. * Partition resilience: if the client can keep working for a while without needing to talk to other hosts, perhaps queuing updates for reply when communication is restored, your application can keep functioning if there is an issue at your end (glitch at your server provider perhaps) or the user's (on mobile and temporarily in a radio blackspot?) or in between (i.e. a routing issue between ISPs). Even partial resilience is better than none: even if I can't see other people's updates until I'm back in a good signal area, if the app calmly tells me so but allows me to continue to add my work and review already locally cached information I can continue to work (or play!) in a way that wouldn't be possible if more of the logic were server-side.
- MustardTiger 10y ago
  >This is usually about a mix of scalability, responsiveness, and partition resilience; with the level of importance of those being dependent on the application. I have never seen anyone make those arguments. I've seen people vaguely reference them in a hand wavey "I don't understand this but google facebook I am right" way. But that's as close as it gets. It is usually about following trends.
  - dspillett 10y ago
    In some cases it may be about following trends. But this particular trend started from an effort to push things client-side for good reasons that are vital, or at least useful, to many projects. It being trendy doesn't necessarily mean it is wrong! Don't be so fast to dismiss something because to don't immediately see/understand the benefit. There is often some confusion between "mobile first" and "offline first" - the two overlap considerably but being a good mobile app doesn't absolutely necessitate being able to operate offline and offline capability does not require or imply an app will be usable on mobile (it may be to large and/or fiddly in terms of UI on a small screen, not practical to use in a touch manner, or too demanding of CPU and memory resources). Some of the hand-wavey-ness is people who know they are driving for "mobile first" and think that means they have to drive for "offline first" without really understanding the benefits & implications of that.
emodendroket 10y ago
The reason for doing that is that you can deliver experiences that are impossible if you do everything in the backend.
fulafel 10y ago
Network performance increases and reliability have taken a step back due to the shfit to wireless, and client devices have become more powerful relative to servers. If the 1995-2005 trends had continued, by now internet services would be served by 15 GHz servers and low-latency 1-10 gigabit networks.
fulafel 10y ago
What are the current best systems that generate rich data models and runnable processing rules from the backend?

jaredklewis 10y ago

I think it mainly comes from the fact that web applications are becoming more interactive. If you are going to implement photoshop in the browser, there's going to be a lot of client side logic. Before, web development was more like, "fill in this form and when you're ready hit submit and we'll check it." Now people are implementing word processors and music libraries.

apatters 10y ago
That's very true, there are web apps where "cases where we need to minimize server roundtrips" are the default case. For these situations it makes sense to run a lot of the logic on the client. However it seems like this has been taken way too far -- I run into a fair share of developers out there who look at basically any proposed web app and say, "Oh yeah, this needs to be a SPA built with React." Why? "Because it's better" and then a rattling off of generic reasons that SPA and doing everything client-side are superior. This is basically the modern version of the Lisp fanboy, they find a good hammer they want to work with more and now everything they see is a nail. These are often the younger guys who have not yet seen this pattern carry itself out over a generation or two of developers -- if there's any reason why tech ageism is amazingly dumb it's this one imo (have the guy on your team who's graduated past the fanboy stage make your tool, platform and framework choices, you will save far more than the premium that you have to pay him).

dozzie 10y ago

> [...] I've always been puzzled by the urge to move more and more logic to the frontend. Moreover, we've already had applications written in client-database architecture, and it was nowhere near pretty. Fortunately they died long ago, but unfortunately they're resurrected now again.

dspillett 10y ago

> why I've always been puzzled by the urge to move more and more logic to the frontend. This is usually about a mix of scalability, responsiveness, and partition resilience; with the level of importance of those being dependent on the application. * Scale: if the client makes fewer request of the server(s) then you have reduced server and network requirements. As server resources get cheaper (and the cheap options more reliable) that side of things is becoming less important, but the network requirements extend far beyond you and almost all the way to the user (see the following two points) who might have a very slow connection at times. * Responsiveness: the more that you can do client side the quicker your application will feel to the user, even if there is a delay in updates actually hitting the global view you can make it look/feel instantaneous (though you do start to have more problems wrt conflict management when people are collaborating). Have a look at the different methods online games (where real responsiveness and the appearance of instant iteration are vital) manage this. * Partition resilience: if the client can keep working for a while without needing to talk to other hosts, perhaps queuing updates for reply when communication is restored, your application can keep functioning if there is an issue at your end (glitch at your server provider perhaps) or the user's (on mobile and temporarily in a radio blackspot?) or in between (i.e. a routing issue between ISPs). Even partial resilience is better than none: even if I can't see other people's updates until I'm back in a good signal area, if the app calmly tells me so but allows me to continue to add my work and review already locally cached information I can continue to work (or play!) in a way that wouldn't be possible if more of the logic were server-side.

MustardTiger 10y ago
>This is usually about a mix of scalability, responsiveness, and partition resilience; with the level of importance of those being dependent on the application. I have never seen anyone make those arguments. I've seen people vaguely reference them in a hand wavey "I don't understand this but google facebook I am right" way. But that's as close as it gets. It is usually about following trends.
- dspillett 10y ago
  In some cases it may be about following trends. But this particular trend started from an effort to push things client-side for good reasons that are vital, or at least useful, to many projects. It being trendy doesn't necessarily mean it is wrong! Don't be so fast to dismiss something because to don't immediately see/understand the benefit. There is often some confusion between "mobile first" and "offline first" - the two overlap considerably but being a good mobile app doesn't absolutely necessitate being able to operate offline and offline capability does not require or imply an app will be usable on mobile (it may be to large and/or fiddly in terms of UI on a small screen, not practical to use in a touch manner, or too demanding of CPU and memory resources). Some of the hand-wavey-ness is people who know they are driving for "mobile first" and think that means they have to drive for "offline first" without really understanding the benefits & implications of that.

emodendroket 10y ago

The reason for doing that is that you can deliver experiences that are impossible if you do everything in the backend.

fulafel 10y ago

Network performance increases and reliability have taken a step back due to the shfit to wireless, and client devices have become more powerful relative to servers. If the 1995-2005 trends had continued, by now internet services would be served by 15 GHz servers and low-latency 1-10 gigabit networks.

fulafel 10y ago

What are the current best systems that generate rich data models and runnable processing rules from the backend?