Is Google Web Toolkit really important?

Google Web Toolkit has attracted the attention of countless web programmers around the world, because it promises to make Ajax web development easier. But what advantages does it have? What's more, how much do we need it?

This is a denial of voice-first, as a developer and framework architect, I found Google Web Toolkit (GWT) very charming. It is a great piece of software that talented people can make. However, the problem is: in the field of enterprise software development, this attraction does not seem to play a major role. I mean, the customized software contains hundreds of use cases, which have extremely complex interactive business and GUI logic. This kind of software is very important for most programmers because it will be involved in their work. This kind of software is also the type of Web application development I will discuss below.

First, let's summarize the innovations that GWT brings to the (Java) web development group, including the following:

• A Java-to-JavaScript compiler implemented using the java. Lang API-although this idea is great, it is indeed not innovative. Because at least one of the above solutions (j2s) already provide similar features, in fact, they also provide more advanced JavaScript generation features.
• A window Component Library allows you to build a user interface (UI) without using HTML ). This is similar to the functions in dojo and is almost the same as j2s/Ria. In addition, some server-side frameworks can provide the same functions (such as echo2 and wings)
• A Remote Procedure Call (RPC) implementation over the HTTP protocol, which can be implemented through DWR on other protocols.
• A container that allows debugging applications in Java. In fact, j2s does not need this function because it can interpret SWT/rcp code and automatically run as a desktop application.
• At the beginning of the project, the script was inspired by Ruby on Rails (at least similar ).

Therefore, Google is primarily stuck in this serious problem: Re-implementing all these available projects. Of course, you can argue that they are better implemented, easier to use, and more documented code (this is usually the key to a project's success and failure ). However, since they are enough to re-implement countless other projects, why not re-implement the Eclipse project? Moreover, why don't they use the rich client platform (RCP) or the rich Internet application (RIA) Stack?

My answer to this question is very simple-Google wants to solve their own problems. To understand GWT, we first need to understand the motivation for Google to create it. Google does not do commercial software-they do desktop software, and then put them on the web (such as Gmail, base, spreadsheet, and calendar ). These software contains fewer use cases, and the use cases are usually complex and need to be responded.

Google needs a way to develop new web applications, which should be:

• 1. highly responsive
• 2. Rapid Development
• 3. Charming

The second obstacle is that if you want to achieve high response on the web, you must adopt a lot of fast solutions, and worse, you need to adopt different fast solutions for different browsers. This makes the development cost of Ajax applications much higher than that of common applications.

To address this problem, a significant solution is to encapsulate these fast solutions and put them behind the simple interface. There is also a less significant solution: using a large number of integrated development environments (IDE) and debuggers to encapsulate the quick solution into a static type language. Then, avoid using JavaScript in your application. Therefore, GWT is the best solution for rapid development of Ajax desktop applications. In addition, GWT can run on mainstream browsers and only requires a few tests.

But what should the remaining developers do (especially those who write large commercial applications )? My point is: If GWT is not 100% purely based on JavaScript, it will be a great view technology. The problem with HTML and JavaScript is: at present, there are at least four large-scale incompatible platform implementation mechanisms. What we are discussing is: a language that can be used with four virtual machines, and it can be loosely coupled with the standard developed later-James Gosling's nightmare.

Web is widely used in commercial applications. One of the main reasons is: it is based on Java's commitment to running a program everywhere (because the web platform is much simpler than Java and has less dependencies on the client environment ). In addition, the Web can also provide us with these possible features: easy to mix and match, integration, re-design, and so on. However, JavaScript makes this promise meaningless, because there are:

• Restrictions on script Scale
• Restrictions on script storage consumption
• Restrictions on script running time
• Cross-Domain access restriction
• Many other types of restrictions, program defects, and incompatibility are suffering web programmers.

All of this means that you can only encapsulate so much-sooner or later, some "Perseverance" bugs will flash up, or, using the standard toolkit, you may do more work, but now, you also need a quick JavaScript solution. In fact, I can almost make sure that in all applications that are large enough and complex, this phenomenon will soon emerge (I mean a bug like memory overflow, they are almost impossible to be debugged on the platform ). Indeed, for applications, HTML and HTTP have never been meaningless, and their role is to share information between scientists. Soon, technologies represented by dynamic Dom, CSS, XML, and other acronyms will be applied to these applications. Although they can be used, they do not match-you can use them, but it cannot go far.

Now, let's end the discussion on Ajax and switch to the application itself. A typical large enterprise application has different user interface requirements, not just a typical desktop interface. There are many large and complex workflows in the graphic user interface (GUI) of commercial applications. However, a small portion of such workflows need to be highly responsive (typically, some queries or searches ). Moreover, by using HTML and adding some browser-independent JavaScript, these requirements are easily met. In fact, if we investigate the needs of commercial users, we can understand that the software they need is:

• Meet their needs
• Fast development and reasonable price
• Do not bind with independent developers or partners
• Easy to integrate with other software

Through the above analysis, we can find the software that brings these benefits to the business world, not those that do not use Ajax. In the Web framework, the first thing we need to satisfy is high response and integration-maybe this is one of the reasons why struts is so popular (the main process of using struts is to solve a lot of legacy code ). In addition, if there is any difference between Ajax, it is: increasing the difficulty of integration and reducing productivity.

But does this mean that I will always advertise simple web applications? Of course, no! I just think that it is unacceptable for commercial clients to simulate desktops Based on IE. If a general GUI platform is ready, I will be the first person to conduct the test. Make eclipse's rich client platform (RCP) more perfect or compile Java applications on Adobe Flash (at least a stable platform), or even run aveon on Linux. It just gave me some tasks-so that I could write Java code with less trouble than Web applications, so I could work without barriers.

Therefore, Will Google Web Toolkit be crucial in the next few years? I certainly hope it is not, because it will mean that we must build next-generation applications on essentially destructive platforms. In addition, whether or not I am biased, I hope to see a better platform release in the first ten years of the 21st century.