Go The history of Web development

This article was transferred because it could have a general understanding of Web requests.

The following is transferred from: http://www.open-open.com/news/view/19ed96a

English Original: Full stack web Development

----------------------------Split Line-------------------------------------------

Over the next few months, I'm going to write a series of articles about complete Web development. This first article is sketchy, but it also gives a good overview of how Web applications have evolved over the previous 15 years or more. And in the end, I will cover the relevant technologies that have been written during this time.

In the good old days, we used simple Web pages (including animated GIF images!). )。 As a paragon of fine design, Apple has a website like this:

At the time, Web development was relatively simple, and developers often went to operate the Web server (mostly his own), and he would write some HTML pages down to the server-specified folder (/WWW). These HTML pages are used when the browser requests the page.

The problem arises, and you can only get static content. If you want visitors to see how many other visitors have visited this site (do you remember those rotating pictures of statistics traffic?!). ), or if you want visitors to fill out such a form with a name and email address? It turns to CGI and Perl scripts, runs a short code on the Web server side, and interacts with the file system or database.

At that time, the organization Cgi/perl such script code was too confusing. CGI scalability is not too good (often a new process is allocated for each request), nor is it too secure (directly using a file system or environment variable), nor does it provide a structured way to construct dynamic applications. It's been confusing for years, until around 2005, when Java Server Pages (JSP), Microsoft's ASP, and php! I like to compare the reference architectures of the time to IIS and ASP. You can quickly build a scalable and secure application with Visual Studio.

Until then, the Web server would probably return the entire page or document, but the advent of AJAX (2005) had made things interesting. AJAX allows a client's JavaScript script to provide a request service for a local page, and then dynamically refresh some of the pages without going back to the server-that is, updating the Document object in the browser, often called the DOM, or the Document Object model.

Although HTML is still returned from the server side, the code on the browser can embed the HTML fragment into the current page. This means that the response of the Web application can be faster, when we actually replace the Web page with a Web application. Google's GMail and Google Maps were the killer products of AJAX at the time. Then local refreshes with AJAX are springing up.

Over the next few years, AJAX became the focus, but the old technology was still used on the server side. Probably in 2007, 37signals disclosed its members –ruby on Rails. The presentation of the Ruby on Rails 5-minute build blog completely conquered the world's developers. Overnight, so the focus is all about rails! Rails differs in designing your Web application in a defined way, using a development model that has been developed extensively in desktop applications but not moved to a Web application. This pattern is called pattern (data)-View (template)-Controller (business logic). Rails emphasizes that "this is the way to do this" and makes building Web applications more robust through many plugins.

During the 2007-2010, 3 development trends emerged:

The first is the trend of smartphones and mobile apps. Often, many applications have both Web and mobile applications. Nonetheless, the server still returns HTML pages, not other mobile apps that can recognize them. Therefore, you need to return the structured data to replace the HTML.

A second development trend is jQuery. This is a very popular JavaScript library that makes it easy to build dynamic, wonderful Web applications, even ajax!

A third trend is the release of node. js. This is the first time you can use JavaScript to develop high-performance service-side programs, which may end up "client developers" to know Html/javascript, "server developers" to know. Net/c#/ruby such a nightmare.

While this is a good architecture, we can reuse some of the gains on the client side to simplify the jQuery code that once happened in the spaghetti like the client. Like the Rails spirit, we need to get the data from the server in a defined way, and then wrap the client's HTML page. So over the next 2 years, there have been many frameworks for simplifying client development, such as Backbone,ember,derby and Meteor, and of course my favorites, AngularJS.

So that's what we see today, and the reference architectures that I'm going to talk about, MongoDB as a database server, node/express as a Web application server, clients using AngularJS, and Bootstrap style. I found this architecture to allow me to quickly build Web services and AngularJS-based client interfaces, and even to develop mobile applications like other services such as PHONEGAP or other native mobile development tools.

Over the next few weeks, I will post articles explaining these components, including: Mongodb,node/expressjs,json and REST interfaces, Angularjs,karma-mocha testing and Bootstrap style pages.

Bole Online-Grasshopper
Link: http://blog.jobbole.com/45169/