32

I've been doing web programming for a long time now, and somewhere, I lost track of why we are doing what we are doing today (or how did we come to do things this way)?

I started out with basic ASP web development, and very early on, display and business logic were mixed on the page. Client-side development varied wildly (VBScript, different flavors of JavaScript), and we had plenty of warning about server-side validations (and so I stayed away from client-side logic).

I then moved to ColdFusion for a while. ColdFusion was probably the first web development framework that separated display and business logic using their tags. It seemed very clear to me, but very verbose, and ColdFusion was not in high market demand, and so I moved on.

I then jumped on the ASP.NET band wagon and started using their MVC approach. I also realized Java seemed to be an ivory tower language of enterprise systems, and also tried their MVC approach. Later on, ASP.NET developed this MVVM design pattern, and Java (precisely, J2EE or JEE) also struggled and came out with its MVC2 approaches.

But today, what I have discovered is that backend programming is not where the excitement and progress is anymore. Also, server-side based MVC practices seem to be obsolete (do people really use JSTL anymore?). Today, in most projects that I am on, I found out that JavaScript frameworks and client-side development is where all the exciting and innovative progresses are being made.

Why has this movement from server to client-side development taken place? I did a simple line count of one of my JEE projects, and there are more lines of code in JavaScript than Java (excluding third-party libraries). I find that most backend development using programming languages such as Java or C# is simply to produce a REST-like interface, and that all the hard effort of display, visualization, data input/output, user interactions, etc... are being addressed via client-side framework like Angular, Backbone, Ember, Knockout, etc...

During the pre-jQuery era, I saw plenty of diagrams where there was a clear, conceptual line between the M, V, and C in MVC in n-tier development. Post-jQuery, where are these lines drawn? It seems MVC and MVVM are all right there in JavaScript code, client-side.

What I want to know is, why did we make such a transition (from the emphasis of server-side programming to client-side, from favoring compiled languages to scripting languages, from imperative to functional programming, all of these seem to have occurred simultaneously) and what problems did this transition/shift solve?

  • 8
    Because mobile has more network infrastructure in between and therefore highly affected by latency? A high latency means one must make fewer round-trips to the server-side (say, per second), and therefore more of the computation must happen client-side. That in turn motivates more computational power on the client-side. – rwong Nov 15 '14 at 6:17
  • 1
    If it takes X units of work to per page render (assuming no caching is possible), and you want N people to see it, N*X units of work have to take place. You can perform all N*X units of work, or you can have each of the N people perform X units of work. Why do work that your visitors are willing to perform? (But, as Robert Harvey answers, it's more complex than that, and things change over time.) – Joshua Taylor Nov 15 '14 at 13:26
  • 1
    I'm not a native english speaker, but maybe the title could be clarified? – bigstones Nov 16 '14 at 16:01
  • 1
    There is a progress in JavaScript? The language is still ES5 (11/2014). Most progress seems to be around trying not to use JavaScript directly: Dart, TypeScript, AtScript etc. – Den Nov 17 '14 at 10:23
  • 1
    Because distributed/mobile devices now have sufficient CPU power that they can do things locally that used to require the oomph of a large central server. – Kilian Foth Nov 28 '16 at 13:54
62

Shifting the computing load between the server and the client is a cyclical phenomenon, and has been so for quite some time.

When I was in community college the Personal Computer was just getting a head of steam. But Ethernet was not in widespread use yet, and nobody had a local area network. Back then, the college had a mainframe that handled student records and served as a platform for programming classes. The administration had terminals that were connected to the mainframe on a time sharing basis, but the students had to punch cards to get their programming assignments done, an arduous process. Eventually, they put in a lab where the students could sign up for time on a terminal, but it still took maybe a half hour or so to get your half-inch thick printout of errors. All of the processing work was done on the mainframe (the server).

But mainframes were expensive, so companies started putting up local area networks, and the processing load shifted from the server to the individual client machines, which were powerful enough to run individual word processing, spreadsheet and line of business applications, but not powerful enough to share their processing power with others. The server was a similar machine with similar capabilities (perhaps more memory and hard drive space), but was mostly used to share files. This was called Client/Server. Most of the processing had shifted to the client computers.

One of the drawbacks of doing all of the processing on the client machines was that you got locked into this perpetual cycle of software installation and upgrades, and all of the headaches that go with that. The programming model of these machines (event-based, code-behind user interfaces) encouraged the creation of messy, difficult to maintain programs (big balls of mud). Most end-users didn't have the skills to maintain their hardware and software properly, necessitating armies of IT maintenance personnel.

As the computers became increasingly more powerful, divisions of labor became possible. Now you could have file servers, database servers, web servers, print servers and so on. Each machine could be somewhat optimized for the task it was provided, and maintained by someone with the requisite expertise. Programs could be written that ran in the web browser, so client installations were no longer required. This was called Multi-Tier or n-Tier. Browsers were essentially used as dumb terminals, just like in the mainframe days, though the method of communicating with the server was more sophisticated, less proprietary, and based on interrupt mechanisms rather than time-sharing and polling. Processing had shifted back to the server(s).

However, web development came with a whole new set of headaches. Most line of business applications written for the browser were static forms and reports. There was very little interactivity available in the UI. Javascript hadn't found its second wind yet, and there were major problems with browser incompatibilities that discouraged its widespread adoption. However, things have gotten much better. HTML5 and CSS3 provide substantial new capabilities to the browser programming model, jQuery came out and helped a whole generation of programmers discover how useful Javascript could be. New front-end UI frameworks emerged. It became possible to write highly-interactive UI's in the browser, even complete games. Processing shifted back to the client again.

Today, you can buy processing power in the cloud, as much or as little as you like, and run programs on the server. I'd say we're now in a place where, as a software developer, you have lots of choices about where you can execute your processing power, both on the client and on the server.

  • 1
    As the computers became increasingly more powerful, divisions of labor became possible [...] you have lots of choices about where you can execute your processing power, both on the client and on the server. - I'd say these two points together make a great case for an equilibrium being reached between server and client: They are each suited to a particular task, and those tasks are now well defined and easily implemented. – Jess Telford Nov 24 '14 at 0:16
5

You seem to be mixing two very different concepts:

  1. Separating presentation and business logic (MVC) => increase maintainability
  2. Assigning execution to a node => increase efficiency

Back in the days Client/Server computing was often confused to imply the first because clients generally did not offer much computing power, as compared to servers. So it seemed natural to move the "heavy" business logic computation (M) to servers, while keeping the "light" view processing (V) to clients. In turn you had to implement some kind of arbitrator (C) to translate between the two.

With clients now easily featuring process prowess that once implied some expensive server hardware the lines have blurred as to where to execute business logic -- client-side or server-side. Really, the answer depends on your specific use case and your choice of trade-offs, e.g.:

  • client latency v.s. complexity: server-side processing keeps systems simpler because no code needs to be deployed/downloaded to the client, however it comes at the cost of client-side latency during computation.

  • complexity v.s. server load: client-side computing may increase system complexity but it may also help to reduce server load.

  • decentralized application resilience v.s. central execution: in a world of mobile app, it may be important to keep clients working despite a network disconnect. However, this comes at the cost of managing multiple deployed versions of business logic.

This is a non-exhaustive list of many trade-offs.

4

Because users have always wanted the same functionality, bells and whistles with their web apps (not just web sites) that they had with desktop apps. Making this all run in a browser (actually multiple browsers) isn't like the old days when you could link a VB form to a database with little code. This is easier to accomplish when you don't have to make trips back to the server.

most backend development using programming languages such as Java or C# is simply to produce a REST-like interface, and that all the hard effort of display, visualization, data input/output, user interactions, etc... are being addressed via client-side framework like Angular, Backbone, Ember, Knockout, etc...

Maybe the backend programming/services seems like the same old thing, but it's the heart of the application. The coding practices may be more efficient in these areas. The tools, languages, browsers and frameworks are still evolving, so the UI/UX is difficult to develop. They are the new things that the old ASP didn't have. If we could get away with user interfaces with simple forms and html tables, there wouldn't be much interest/hype in those areas either, but users want drag and drop, animations, transitions, pop-ups, etc.

2

Today, in most projects that I am on, I found out that JavaScript frameworks and client-side development is where all the exciting and innovative progresses are being made.

Why has this movement from server to client-side development taken place?

There are actually two questions here:

  1. Why is client-side programming where progress is happening?
  2. Why are applications written to run on the client rather than the server?

The two are actually distinct.

Why is client-side programming where progress is happening?

Because the runtime, environment and ecosystem have matured substantially over the past three years, and this has opened new niches that innovators have waited to exploit.

Front-end development used to be hard. You had to program for browsers - always a hostile environment - using the constrained features of ECMAScript 3, in an ecosystem that had no prior art or tooling for building thick-client applications. There were no module loaders. You couldn't handle dependencies properly. There was a paucity of linting tools. Frameworks were immature and front-end's poor reputation distanced innovators who could solve these problems.

As these factors have incrementally changed, they have created a critical mass for developing rich client applications swiftly and running them consistently.

In answer to your question, then, it is not so much that new front-end technologies have pushed progress forwards, so much as they have released bottlenecks and allowed clients to catch up with users' aspirations.

Why are applications written to run on the client rather than the server?

There are lots of proximate causes, but the most distinct of recent years is the rise of smartphones.

Smartphones make moderately-powerful computing cheap, ubiquitous and useful. They are owned by billions of people across the planet, and have essentially brought computing to the middle classes of emerging economies. But mobile networks are sluggish, patchy and constrained by geographical, engineering and political Hard Problems. In this environment, it's inevitable for applications to store state locally and patch data upwards reluctantly and in stateless operations.

How could it be any different? Imagine if your smartphone were just a dumb terminal. Every state mutation would have to be asynchronous and fallible. Every content load would cost precious cents. You would have to invest in enormous server farms with five-nines uptime. The computing costs would be incurred by you directly, so a sudden surge of popularity could actually tank your business.

Client-side applications allow you to handle state pertaining to the individual user in a fast, synchronous fashion. They let you offload your computing costs to your users. They let you get away with downtime and poor network connectivity. They make the server code so dumb that it can be cached in the network infrastructure itself - static HTML and JS files, or canned responses for mobile apps.

To put it in very broad terms: Client-side development exploits the low costs of mid-power personal computing and avoids the high costs of high-power centralised computing.

-1

You asked several questions, some of which have good answers already. A few have not yet had their answers:

What I want to know is, why did we make such a transition (from the emphasis of server-side programming to client-side, ... all of these seem to have occurred simultaneously) and what problems did this transition/shift solve?

Robert Harvey gave an excellent answer.

... from favoring compiled languages to scripting languages,

Scripting languages offer many advantages (also) over compiled languages, e.g.:

  • are easier to learn and use
  • eliminate compile time (faster development)
  • provide more features (higher-end application control)
  • allow quick changes to running code
  • etc.

... from imperative to functional programming,

Here's a good comparison, but I would sum it up by saying that in distributed software (think cloud computing), managing state changes (synchronization across many nodes) can be a huge problem. In functional programming, the need to deal with state changes is a lot lower.

  • Would love if the down-voter had the courage to say which part(s) of my answer(s) she didn't like? – Fuhrmanator Nov 19 '14 at 2:13
  • I can't tell why previous two voters down did that, but my reason is that this looks more like a comment to one of prior answers, rather tangentially related to the question asked (see How to Answer) – gnat Nov 29 '14 at 20:38
  • @gnat I appreciate the feedback. I cited the various parts of the question (namely compiled vs script and imperative vs functional) that weren't answered elsewhere. I've gotten 3 upvotes on this, so I can see it's a mixed reaction. – Fuhrmanator Nov 29 '14 at 23:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.