Web开发的发展史（Full stack web development）

Over the next few months, I plan to write a series of posts about full-stack web development. This first post is a rough, but sufficiently accurate guide to how web applications have evolved over the last 15 or so years – and I’ll end with the set of technologies I plan to write-about over the next few  months.

In the good old days, we had simple web pages (with animated gifs!). Apple, that paragon of beautiful design, had a website that looked like this:

Things were simple back then – often, the developer would administer the web server (often his only machine), and he would write HTML pages and place it in a folder (/www) on his server machine. These HTML pages would then be served when a browser requested the page…

But there was a problem – you could only get static content. What if you wanted your visitors to see how many other people had visited this web-site (remember those spinning visitor count images?!). Or what if you wanted people to fill out a form with their name and email address? That was when you turned to CGI and Perl scripts – simple code that often was run by the web server itself, and that could interface with the file-system or databases.

But organizing code in CGI/Perl scripts was rough. CGI didn’t scale well (a new process for each request), was often insecure (accessed the file system / environment variables), and it didnt provide any structured way of building dynamic applications. Things got confusing for a few years (till about 2005) – there was Java Server Pages (JSP), Microsoft’s ASP and then there was PHP! I like to think of the reference architecture at this time as being IIS & ASP.NET – you could build scalable, secure applications, and development was quite easy with Visual Studio.

Things got interesting though once we had AJAX (2005) – till now, web servers mostly sent back an entire page or document. AJAX allowed for JavaScript code on the client side to request for a fragment of a page – and then dynamically (i.e – without going back to the server) refresh a part of the page (by updating the document in the browser – called DOM, or document object model).

What was sent back was still HTML, but the code on the browser could stick in this HTML fragment inline to the current page. This meant that web apps could be more responsive (I believe that this was when we really had a web-app, instead of a web-page). Google’s GMail and Google Maps were the killer demos for AJAX, and suddenly, everyone was using AJAX to refresh a portion of the page.

For a couple of years, things were all about AJAX, using the existing technologies on the server. And then, in about 2007, there was a new kid on the block – Ruby on Rails, from 37signals. The “5 minute blog” demo for Ruby on Rails took the developer world by storm, and suddenly everyone was talking about Rails! What made Rails different was that there was a prescribed way to lay out your web application – using a development pattern that had been commonly used in desktop applications, but that had been forgotten in the move to web apps. This was Model (data) – View (templates) – Controller (business logic). Rails was opinionated – “this is the way to do it”, had lots of plugins and made building web apps sane once again.

Between 2007 and 2010, there were 3 developments that prompted another change:

The first was the rise of smart phones and mobile apps. Now, as was often the case, many applications had a web version and a mobile phone app for it. However, the server was sending back HTML pages – not something the mobile phone app could consume. So, you needed structured data from the server, not HTML.

The second development was the rise of jQuery – a JavaScript library that became really popular and made it easy to build very dynamic, beautiful web applications – and that made AJAX easy!

The third development was the release of nodejs – for the first time, you could have high performance JavaScript on the server, thus potentially ending the nightmare of having “client side developers” who knew HTML/JavaScript and “server side developers” who knew .NET/C#/Ruby.

This was a good architecture – but we could re-use the learnings on the client side to simplify the spaghetti of jQuery code that was happening on the client side. What was needed was an “opinionated” way to assemble HTML pages on the client from data that was fetched from the server – similar in spirit to Rails. So, in the last 2 years, we’ve had  number of frameworks that simplify the client side development – Backbone, Ember, Derby and Meteor – and my favorite one, AngularJS.

So, this is where we are today – and my reference architecture is mongodb for the database server,node/express as the web/application server, AngularJS on the client side (along with Bootstrap for styling). I find that this architecture allows me to build web services really quickly that can have a client interface build fast using AngularJS, and then one can start development of mobile apps against the service using PhoneGap or native mobile development tools.

Over the next several weeks, I’ll have posts on each of these: MongoDB, Node/ExpressJS, JSON and REST interfaces, AngularJS, Testing with Karma & mocha and Bootstrap for styling pages.

web开发分享 转自 http://act2.me/full-stack-web-development/