Why do code-bases in n-tier development have an equal amount of, if not more, JavaScript code now?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.