A small share; my knowledge is limited, just a modest spur to induce others to come forward with valuable contributions.

Ajax

In 2003, I was in sixth grade. At that time, internet cafes were just emerging in the corners of small county towns. The Legend of Mir, Westward Journey Online, and other first-generation online games were all the rage. I gave the internet cafe owner two yuan, thinking I'd give it a try and register an account to play. Then for the next hour, I was stuck re-gis-ter-ing an ac-count.

At that time, the internet cafe had 512k bandwidth. While registering, I filled in a bunch of information, submitted, the page jumped, boom: "The information you filled in is incorrect, please refill." Then it jumped back to the registration page, and this loop repeated. I often think now: if AJAX had been widespread back then, I could have saved two yuan.

So what is AJAX?

First of all, AJAX is a technology. In past web interaction models, after a user clicked a button, such as a submit button, the user had to wait through a long data exchange with the server, during which the user couldn't do anything except light a cigarette. What AJAX does is, when sending a request to the server, we don't have to wait for the result; instead, we can do other things at the same time, and when the result arrives, we can come back and handle it.

In fact, AJAX technology was already implemented by Microsoft as early as 1998. However, it wasn't until February 2005, when Jesse James Garrett of Adaptive Path published the article "Ajax: A New Approach to Web Applications," and people read it and thought, "Oh, not bad, this is awesome," that AJAX became widely adopted on a large scale.

The emergence of AJAX greatly improved the user experience of the web. To this day, no matter how backward domestic IT development is, login and registration on all websites have implemented AJAX interaction. After users finish filling in information, they can know whether the submission succeeded without refreshing the page, and correct wherever the errors are.

In addition, AJAX, as a solution for separating front-end and back-end, has been adopted by most domestic companies that are not too low-level, and it has indirectly led to the decline of web scripting languages such as PHP.

jQuery

In early JavaScript programming, code efficiency was extremely low, especially in DOM manipulation. If a developer wanted to add an event to a button, they had to write a long, repetitive piece of code to get the button, then another long, repetitive piece of code to add the event. Although veterans would encapsulate common operations, for novices who couldn't encapsulate, this was undoubtedly a painful thing, especially when combined with all kinds of browser compatibility issues.

In 2006, with the purpose of saving rookies and letting them "do more", jQuery was born. The significance of jQuery's birth was, first, it made compatibility with IE6, 7, 8, and various browsers that carved up the market; second, it greatly simplified DOM operations and greatly improved development efficiency. jQuery was so popular that some front-end developers could only write jQuery and not native JavaScript. To this day, it's no exaggeration to say jQuery "write once, see everywhere."

Another significance of jQuery (in my opinion) is that it catalyzed people's interest in and exploration of the front-end. Compared to Linux, at a very low cost, you could write an effect that made a girl who knew nothing about programming say, "Oppa, you rock!" making people feel, "Oh (again), not bad, this is awesome." After that, numerous libraries and jQuery-based plugins sprang up like bamboo shoots after rain. The front-end industry was thriving and prosperous, and web development entered a new era.

Chrome

All martial arts under heaven come from Google. In the era of IE6, 7, 8, although Firefox was also slowly challenging IE's position, it was far inferior to the disruptive impact of Chrome, which Google began promoting in 2009. Chrome used Apple's open-source engine WebKit, with good design standards and market response; it promoted rapid browser iteration and made IE completely disappear in Windows 10.

The launch of the Chrome browser further simplified the threshold for getting started with front-end development. Its built-in debugging tools are easy to use and foolproof. We can easily view network status, loading order, perform breakpoint debugging, etc. At the same time, Google's plugin feature provides developers with great convenience.

At present, the latest version of Chrome has begun to use the Blink engine. In test versions, it can already track and debug CSS3 animations. Before I even imagined it, Chrome had already implemented it.

In one sentence: without Chrome, there would be no new China, and we would only be able to use Firefox.

GitHub

With the accelerating iteration of software projects, project version control tools have also evolved continuously, going through CVS, SVN, and GIT. So far, CVS has almost disappeared from the internet industry, SVN exists for file and document storage, and GIT, the version control tool created by Linux kernel inventor Linus, is now the standard for code versioning. GitHub, relying on Git, has become a community for developer team collaboration! As of January 2015, GitHub had more than ten million registered developers and tens of millions of open-source projects. Among these, Chinese developers grew the fastest on GitHub in 2014. You can find almost any code you want there... e.g., username..password..

OAUTH

The difference between OAuth1 or OAuth2 and previous authorization methods is that OAuth authorization does not allow third parties to touch the user's account information (such as username and password).
Background: In the most common service scenario, a user needs to use services from two different enterprises: log in and authenticate with Enterprise A to download content; then log in and authenticate with Enterprise B to upload content to Enterprise B's service, which is complex and time-consuming. Whether it's the user or enterprises A and B, they all want interoperable services. This creates the need to verify identity. The old username/password mechanism would give Enterprise A or B the permission to view or even modify the other party's user resources. In order to confirm identity and enable service interoperability, Google, Yahoo, and Microsoft took the lead in promoting the creation of OAuth 1.0. Later, OAuth 2.0 was a new plan by major internet companies based on HTTPS security.

At present, the most common application scenario is mainly authorization login, such as WeChat, QQ, Weibo, etc.

JSON

Although JSON is a standard that emerged as early as 2001, it was widely used only after 2008, after various AJAX applications, iPhone, and Android devices became popular. The old service systems were mostly enterprise-level, so XML was beneficial for Java-style enterprise-level service positioning. But for API services with traffic constraints and simple semantics, XML is bulky, redundant, hard to learn, and consumes bandwidth.

Last year, when I had just started working, the backend returned an array to me. Without any say in the matter, I struggled for a long time over whether to iterate over the array or convert it to JSON format.

The popularity of JSON, from another angle, reflects an advantage of web development: no matter whether your backend is Java, Ruby, PHP, or Python, as long as you give me an interface in JSON format, I can hold up the entire earth.

DJANGO&RAILS

Agile development broke the project R&D model. In the WEB 2.0 era after 2010, HTML5 prevailed, front-end work was separated out, and the advantages of web scripting like PHP were no longer so obvious, although it still had advantages in CMS and forum templates. The greatest advantage of Django and Rails is that they make it possible for an individual or a small team of two or three to implement a complete product. Take Instagram as an example: initially, two Python engineers used Django to quickly implement all server-side functions, and when user growth occurred, they separated out services with large traffic and large data volume.

Despite the cruel reality and Rails' decline day by day, it's only a matter of time whether IE8 or Rails disappears first, but the solutions it provided are still emulated by many younger generations. People will remember this brief bloom.

Bootstrap

In 2011, Twitter open-sourced a web GUI framework. jQuery handled the JavaScript compatibility across different browsers, while Bootstrap handled the CSS compatibility across different browsers. It got to the point where, as a back-end developer, you didn't need to understand CSS, didn't need a front-end developer, didn't need a designer; as long as you looked at Bootstrap's documentation, you could build a beautiful and graceful back-end management system. Similar common GUI frameworks include Zurb's Foundation and Google's Materialize. Baidu also once released a mobile framework called GMU.

For me personally, I don't like these GUI frameworks, even though they simplify CSS and achieve some cool effects, even though I've used them in projects, even though I don't want to admit I'm a "green tea" (hypocrite). The biggest shortcoming of these frameworks is that they are all the same. All pages look the same: the same nav, the same sidebar, the same forms, and even the same glow when you hover your mouse over them. It's like if I had three legs (though I do indeed have three legs), people would say I'm unique and my appearance makes their eyes light up. But if everyone had three legs, the web would lose its charm. Another shortcoming is bloat: a single CSS file uses over 100 KB of traffic, and most of its JS plugins depend on jQuery. Can you bear that?

Of course, the idea of grid-based HTML proposed to solve responsive design is still worth learning from.

The Popularity of IOS & ANDROID Systems

After 2009, the rapid development of iOS and Android led to the following changes in web development:
1. HTML5 was first implemented on mobile browsers. Android and iOS devices fully supported HTML5 and CSS3, accelerating the disappearance of IE.
2. Internet access happens anytime, anywhere. Mouse-click-oriented, content-heavy web pages became increasingly concise, and responsive design quickly became popular.
3. The interaction between apps and servers is mostly based on the HTTP protocol like web pages. The concepts of webapp and hybrid app were proposed.

Regarding webapp, here I'll briefly talk about the advantages of web compared to native.

• Cross-platform: the often-said "compile once, run anywhere."
• Installation-free: open the browser and use it.
• Rapid deployment: upgrades only require updating code on the server, unlike client apps which need version updates.
• Hyperlinks: can interconnect with other websites and can be indexed by search engines.

Sounds impressive, but these advantages don’t hold up under scrutiny. First, users of different systems have different habits: iOS users are used to the back button in the top-left corner, while Android users are used to it at the bottom of the screen. The product manager asks, so where should it be placed? Hehe, I don’t know. Second, I once saw a survey report asking users whether they prefer using a client or the web.

Far more users prefer the client over the web. Ask me what I like, I also prefer the client. Ask me why, I feel it gives me a sense of security, and version updates make me feel great and give me a sense of presence, letting me know I haven’t been forgotten by the world, letting me know your product is being updated and that you care about me. Also, hyperlinks... why would a client need SEO? And that’s not all; web apps have a bunch of other drawbacks. The biggest one is the lack of GPU acceleration. Implementing a somewhat complex animation is a real pain for the browser. Secondly, web pages are single-threaded; loading the DOM blocks JavaScript, resulting in lag. Lag leads to annoyance, annoyance leads to closing the page, and the user count drops by one.

Hybrid is different. A hybrid app means a mixed native application that places frequently updated pages as web content on a remote server for updates. This is a reliable solution. BAT has many cases, such as the JS SDK released by WeChat, Baidu Mobile, and the Android version of the Taobao client.

Of course, there are many pitfalls here. If I get the chance, I’ll tell you about the pitfalls I’ve stepped into.

NodeJS

I was torn for a while over whether Node belongs to the front-end domain. I think it does.

Solving high concurrency has always been a topic backend engineers love to discuss. For example, in our real-time monitoring system, in theory each connection spawns a new thread, and each new thread may need 2 MB of supporting memory. On a system with 8 GB RAM, the theoretical maximum number of concurrent connections is 4,000 users. As the number of users grows, we want the monitoring program to support more users, which means adding more servers. Of course, this increases business costs, especially server costs. Besides rising costs, there is also a technical issue: users may use different servers for each request, so any shared resources must be shared across all servers. At this point, the technology hits a bottleneck. Node was originally born to solve this problem. Node’s solution is to change the way connections are made to the server. Instead of generating a new OS thread for each connection and allocating supporting memory for it, each connection emits an event that runs within the Node engine’s process.

Node.js is a server-side language. In the enclosure movement of separating front-end and back-end, it is a powerful weapon for the front-end. At the same time, it provides a large number of programmable tools for front-end automation (grunt, bower, gulp, etc.). Taobao and Baidu have always been enthusiastic about Node.js, so naturally I think this is a trend. Last year, Meituan established a Meituan Hotel team and chose Node as the back-end language, taking over most of the back-end work. I wonder: with front-end JS plus Node plus the requirement for UI skills, should front-end engineers now be called full-end engineers?

BIG DATA

Big data is probably the hottest term of the past few years. A bunch of my classmates, upon hearing that data mining pays an annual salary of 300,000, went howling off to work on databases.
Most of the time, when we talk about big data, we are actually talking about data mining, data analysis, intelligent recommendation, real-time analysis, etc., under massive amounts of data. Different companies have different technical solutions. I’ll only list two successful domestic cases:
• JD.com’s personalized e-commerce, with scenarios including dimensions such as behavior, preferences, location, time, and friendship relationships; recommending different products to different users; and different users seeing different product rankings in search...
• Baidu Maps’ Dongguan 8-hour migration map; Baidu Search’s smart reminders
• 360 Mobile Guard’s phone number anti-harassment feature selects the 1,000 numbers most relevant to the user from the 256 million marked phone numbers based on the user’s region, identity, and harassment trends, and writes them into a 10k text file on the user’s phone, so as to provide anti-harassment without connecting to the internet or performing any network interaction.

HTML5+CSS3

This is a term that has been talked to death in recent years. Everyone is talking about HTML5; if you ask them what HTML5 is, they can’t explain it clearly. It’s just cool, just flashy, just cool and flashy.

In my view, HTML5 is just a thing made real by repeated hearsay. It attracts far more attention than the functionality it provides. HTML5 merely provides some new APIs, just like an app upgrading from 1.0 to 2.0 adding a “People Nearby” feature. Moreover, its APIs are only testing the waters on mobile. On the PC side, due to compatibility issues, it has never been officially accepted. PC-side development is still based on HTML 4.0 + CSS 2 with progressive enhancement. As for CSS3, its most-watched animation feature is also something Flash has already left behind.

The rapid development of mobile has catalyzed the development of HTML5, and the development of HTML5 has in turn pushed browsers toward standardization.

On this path to standardization, WeChat has played an indispensable role. Pages such as “1024”, “Encircling the Neurotic Cat”, “Taobao Decade”, and “LEXUS NX”, which incorporate a large number of HTML5+CSS3 elements, are impressive.

In addition, Microsoft abandoned the IE codename and developed Edge. Browsers from various manufacturers are continuously standardizing, the HTML5 draft has been finalized, and the ES6 draft is continuously being implemented and improved. The road ahead for front-end looks like a broad, open road, and I am full of anticipation.

Future

3D browser games? WebOS? Virtual reality?

Finally, with the improvement of user hardware performance, increasingly greater network bandwidth, sensor systems, Retina, and the growing maturity of WebGL technology, plus the booming development of O2O, will the above become reality?

Source: http://www.cnblogs.com/sussski/p/4634595.html