3 ms·

I've flipped-flopped back and forth several times over the last 15 years on the question of server-side vs. client-side view logic. I literally start each new p

I've flipped-flopped back and forth several times over the last 15 years on the question of server-side vs. client-side view logic. I literally start each new project with a new technical review and evaluation of this question. I'd have flipped permanently to client-side if the quality and consistency of the JS stacks were of the same quality as the server-side stacks (I use ASP.NET MVC). I know that it has been a rapidly evolving thing and hence the churn. But here's the thing - with software I've come to prefer intelligent design over Darwinian evolution. On the server-side we have intelligent design; on the client we have evolution. On the server, we have stability and a roadmap. On the client we don't. With that said, painting pages on the server to send down to the client just doesn't smell right anymore.

majewsky 10y ago
> With that said, painting pages on the server to send down to the client just doesn't smell right anymore. Can you elaborate on that?
- intrasight 10y ago
  By that I mean that we should have moved cleanly beyond that by now with no regrets. Certainly it comes from my time in the '80s and '90s developing "desktop" software (of course we didn't call it that)on Unix and Windows. There were user interface objects that had behaviour. Once we "got" that HTML and JavaScript could do similar, we make the browser into the new windowing system. But unlike the Windows and Unix desktops of old, which had "official" SDKs and libraries, it was the wild west. Fifteen years later it still is. If fifteen years ago you had said that one starts a new project by running a command-line script that would clutter your project with hundreds or thousands of tiny source files from sources unknown, we would have laughed at the absurdity.
flukus 10y ago
I've settled on a halfway point being my ideal. The server will render a "page" but knockout will take over and render the interactive parts before it's visible to the user. Applications then become a collection of tiny single page apps.

majewsky 10y ago

> With that said, painting pages on the server to send down to the client just doesn't smell right anymore. Can you elaborate on that?

intrasight 10y ago
By that I mean that we should have moved cleanly beyond that by now with no regrets. Certainly it comes from my time in the '80s and '90s developing "desktop" software (of course we didn't call it that)on Unix and Windows. There were user interface objects that had behaviour. Once we "got" that HTML and JavaScript could do similar, we make the browser into the new windowing system. But unlike the Windows and Unix desktops of old, which had "official" SDKs and libraries, it was the wild west. Fifteen years later it still is. If fifteen years ago you had said that one starts a new project by running a command-line script that would clutter your project with hundreds or thousands of tiny source files from sources unknown, we would have laughed at the absurdity.

flukus 10y ago

I've settled on a halfway point being my ideal. The server will render a "page" but knockout will take over and render the interactive parts before it's visible to the user. Applications then become a collection of tiny single page apps.