Debate: Is Ajax technology about to decline?

Ajax

In Meng's November 21 blog (http://blog.csdn.net/myan/archive/2006/11/21/1402346.aspx), he said he was amazed at Microsoft's newly launched Interface development tool expression, And it predicts that the interface development technology based on web standards (usually Xhtml+css+javascript) will soon decline. Meng predicts: "No more than 2008 years at the latest, with Ria technologies such as WPF, Flash (Apollo), more and more Web applications will deploy both traditional Web pages and the new Ria UI." ”

For this prediction, some of my friends and I think Meng is too optimistic. I predict that, at least until 2010, web-standard interface development technology will still be the mainstream of web interface development, and these technologies are the epitome of Ajax. Ajax technology has grown significantly in the last two years and is still in the process of rapid development, and it is too early to assert that Ajax technology is about to decline.

To be sure, from a purely technical point of view, we have long thought that xul/xaml a class of technologies that use XML to describe interface components and layouts must be the development trend of web interface development technology. The consortium set up a working group this year to unify several interface description languages, such as XUL, XAML, and Mxml, into a standard format (http://www.w3.org/2006/appformats/). So we think there is no big problem with the trend that Meng teachers see. From a purely technical point of view, future Web interface development will certainly evolve into this technology.

However, it is important to see the trend, but we still need to solve a lot of practical problems. I am here to ask a few questions to discuss with you.

The first question is: How fast will this trend become reality?

The development and evolution of technology are often a long-term process. Object-oriented development replaces the process development, Java replaces C + +, and Ruby gradually replaces Java is a long-term process. The 2 years predicted by teacher Meng and the 4 years I predicted seem to be a little different, but the action we're going to take at this stage really has a big impact.

Even as Meng, it is true that this is a trend of technological development. We must pay for tomorrow and the day after. It is likely to be costly to pay for things that will happen prematurely. This is similar to stocks, experienced players will be the most appropriate time to start. Early start, too late to start, will suffer losses. Before this trend becomes reality, do we wait for Communism to happen? I don't think waiting is a positive attitude.

The second question is: What are the advantages of Ajax?

I don't think Meng has fully seen the advantages of Ajax. Meng said: "Yesterday I was saying that Ajax is a transition technology, did not expect a few hours later to be confirmed." "Technically, any technology can be called a transition technology, but it doesn't hinder the use of this technology to create value for users," he said. Meng only sees the inefficient side of using web-standard interface development technology development. But how many of the developers who do interface development in China really understand the web standards? According to the author's experience, the use of complete CSS layout, the structure of the page, performance, behavior of three parts of the separation, pay attention to the various parts of the page reuse. After a period of accumulation, the interface development based on the Web Standard can achieve the more ideal development efficiency. And with the use of Dojo, Scriptaculous, Yui and other mature Ajax component library, but also can further improve the development efficiency of the interface. In the author's opinion, the problems affecting the development efficiency are mainly two aspects:

1 Web interface developers do not fully understand web standards.
2 Web interface developers have not tried to develop a modular approach.
Compared to other technologies, Ajax has the greatest advantage of these three points:

1 Ajax is a completely web-based technology, and all the technologies used by AJAX are real web standards.
2 AJAX applications can be deployed to almost every desktop computer without hindrance.
3 The cost of development and deployment of AJAX applications is low.
For the first advantage, one might argue that standards are not important. For example, EJB 2.x is a standard, and now is not the same as abandoned it? But these two standards are not comparable. The EJB standard was not tested by development practice at the time of its introduction, and was seriously disconnected from development practice. Web standards, however, have been accumulated from development practices. Ajax is based on the Web standards are the first to have a very mature application and successful business case before the formation of standards. Web standards are the way they are today, and they stand the test of history. As with the TCP/IP standard, it will continue for a long time.

The second advantage is actually derived from the first advantage. In the late 90, with the relentless efforts of the Web Standards Organization and the consortium, the browser war ended, and browsers pledged to support true web standards. Today's support comes to fruition when the fruit is born with a new technology called Ajax. It is because today all the major browsers have been able to support web standards (usually Xhtml+css+javascript), and almost all desktop computers have some sort of mainstream browser installed (IE, Firefox/mozilla, Opera, Safari, etc.), so AJAX applications can be deployed painlessly to almost any desktop computer. Although today's different browsers are slightly ambiguous about some parts of the Web Standard, there is a slight difference in implementation. But as long as development is based on a mature component library, these differences can be minimized and will not be an obstacle to development.

If I want to build an E-commerce site in two or three years, I can only deploy to millions of user machines with a XAML render engine (rather than almost all desktop computers like Ajax). Unless my brain breaks down, I won't make that choice. For Internet-oriented applications, development based on real web standards and evolving with the development of web standards and their browsers is an inevitable choice to achieve maximum commercial benefits.

The fact that AJAX applications can be deployed on almost every desktop computer is an ideal country that all other technologies have dreamed up for years. Another realistic option is that the scope of the Flash Ui,flash deployment has already reached a level sufficient for large-scale applications. For practical business reasons, I will not choose to build our application based on XAML for a few years, unless its deployment reaches a certain threshold and one day becomes a true Web standard.

The third advantage is that almost all of the tools needed to develop AJAX applications are open source and free, so you don't have to pay to buy expensive development tools. In fact, the development of a simple AJAX application, a mainstream browser, plus a text editor is enough. As long as the code you develop is high enough, the deployment of AJAX applications can achieve a full 0 cost.

The third question is: is the development technology based on browser and web standards bound to decline?

One of the major differences between me and Meng is that I don't think the development technology based on browser and web standards will necessarily decline. In fact, as early as 3 years ago, when I tried to design our architecture and develop our applications based on XMLHttpRequest, many people had predicted that the development of +javascript based on HTML (or XHTML) would soon decline, I don't understand how much I'm passionate about JavaScript. But a few years later, this kind of development technology not only has not declined, but has produced the exuberant vigor. Is this the last gasps before its demise or demise? At least not in my opinion, but with its intrinsic regularity. It is because of the advantages of this development technology that I have mentioned above that almost all Web users today use this technology. A technology that is widely used by a large number of users is bound to evolve without the possibility of a rapid decline. The fact that XAML ultimately replaces Ajax is not a purely technical consideration, but a migration of the entire Web application ecosystem. Today more than 90% (my conservative estimate) of Web applications are based on Web-standard interface development technology, it is not serious to say that this technology will inevitably decline within two years. It is not easy to rely on a few big companies such as Microsoft to reverse this long-standing natural formation.

So in my opinion, this kind of development technology will continue to develop and progress, naturally evolve to some new web standards (such as XHTML 2.0, CSS 3.0, JavaScript 2.0). Its vitality will be lasting new, I dare to play this bet with anyone, at least until 2010, this technology will still be the mainstream of web development technology. Of course, at that time, XAML may also be developed into the mainstream of web development technology, so there will be a blossoming situation. This is not a zero-sum game, there will only be a winner, everyone else will lose, the winner-take-all situation I do not think it will appear.

The fourth question is: Is it impossible to get "the understanding of this generation of web technologies and systems" If you learn ajax in depth?

Meng said: "How many of the Web developers we talk about today are betting their putting on understanding this generation of web technologies and systems?"

This sentence is very misleading, it seems that in-depth learning Ajax can not be "this generation of web technology and system understanding." At least based on my personal experience, in-depth learning of Ajax can help us better access to "this generation of web technology and system understanding." I have translated Ajax in action, AJAX practices and best practices this year and will introduce Ajax design Patterns from Taiwan. These books have made me amazed at the level of web developers abroad, and have greatly deepened my understanding of this generation of web technologies and systems.

Meng also said: "Not that they spend most of their daily work on the interface development, even if many people are proud of the so-called" large load Web site architecture, will be with the rise of the RIA and a huge change. A large number of page states will be moved forward to the client, and the Web server will rearrange the resources in a completely new perspective, becoming a truly Web services collection. The old knowledge and experience quickly devalued, new opportunities emerged quickly, some people sank, some people floated up, and history again.

I'm sure Meng didn't delve into the architecture of AJAX applications, so that "a lot of page state will move forward to the client, and the Web server will rearrange the resources with a new perspective and become a truly Web services collection." "is completely contradictory to Ajax. Unlike the revolutionary predictions of Meng, a big open dahe, I don't think technology has ever progressed in this way. Technology progress is a natural slow evolution process, object-oriented gradually replace the process-oriented, Java gradually replace C + +, Ruby gradually replaced Java, there is a great inheritance in the relationship. The description of some technology as the "Born Stone Monkey Monkey King", I think is not serious, but also did not do in-depth study of the embodiment. I don't think that the knowledge accumulated in traditional Web development technologies will soon depreciate. As long as oneself with the times, and constantly add new nutrition, "large load Web site architecture" experience is always a valuable practical experience. Ajax technology, is the most traditional Web development team to the era of RIA migration of the most natural choice path.

The fifth question is: Is it impossible for programmers to do interface development? Is this the bottleneck of web application development efficiency?

Meng teacher said: "Because today's web development, designers are basically just to solve the page layout and picture effects of the design, and a large number of dynamic interface effects need to be completed by developers." The Expression + Visual Studio model separates the "interface portion of user interaction" from "background business logic". With a flash-like approach, designers can develop a user interface like video games. ”

I do Java development, if I as a technology leader, my team will have these division of labor:

1 Business logic developers, using frameworks such as Java and spring for development.
2 Interface Logic developers, responsible for view development, proficient in Freemarker, XHTML, CSS, JavaScript and other technologies.
3 Art, is responsible for making pictures, for the page style and color to provide guidance, with Photoshop design page style, to the interface logic developers to produce.
By the interface logic developers to make the page, the production of the page must meet my requirements. For example, a completely CSS based layout is displayed on a variety of mainstream browsers, and so on. In my case, the business logic developer and the interface logic developer do not exist who is the highest and lowest, and the salary is basically the same level. Meng believes that programmers should not be able to make pages in the web-based development process, which is a wrong view. Whether or not a programmer makes a page is not a bottleneck in development efficiency. If a programmer is proficient in these techniques, he can quickly develop beautiful pages. Especially in the case of paying attention to the xhtml/css/javascript of each part of the page, after accumulating a year, many things to be developed are similar. Meng teachers believe that a complete division of labor can achieve maximum development efficiency, this is a fantasy. Why is web development from the very clear layering of Java EE into a hierarchy that is not very clear in ror? Software development is not a pipelined production. The Division of labor should be appropriate, the division of labor is too thin, the cost of communication between different levels will rise rapidly. This goes back to the proposition in the myth of Man's moon: The main cost lies in the cost of communication. Rely on meticulous division of labor to reduce the quality of development personnel requirements, to achieve pipelining production, the creation of a large number of software blue-collar, which in itself is a fantasy. Ruby's approach to solving the problem is different, and Ruby's idea is to raise the level of abstraction so that a developer can afford to develop more features.

Turn from: http://searchwebservices.techtarget.com.cn/comment/469/2691469_3.shtml