Glitter and poverty GWT (or why I do not believe in Dart part 2)

One of the most discussed topics on Habré was Google's announcement about creating a new Dart language, which claims to completely replace Javascript.
For Google, this is not the first project of this kind. Since 2006, there is the Google Web Toolkit , which allows you to create web applications entirely in Java. For example, Adwords and Google Wave work on it.
But, despite the beautiful promises and very serious, especially by the standards of 2006, the possibilities, the GWT never took off. Yes, the project is supported and developed, but the developer community has not developed. There are few third-party components, they are not supported, it is difficult to find programmers who are familiar with the system.
Virtually all the “darts” of the Dart language that Google now advertises have already been implemented in Webtoolkit. In this article I want to analyze the advantages and disadvantages of GWT in an attempt to look at the muddy outlines of the future Dart.

Targets and goals

From the point of view of the programmer, to create modern web applications one has to use a whole zoo of technologies: HTML, CSS and Javascript for the client part; SQL, PHP, and often some Smarty type template engine for server side; data travels over the network using XML, JSON, or some kind of bike.

This is a classic Unix-way: for each work area applies its own tool. This approach provides tremendous flexibility. If you don’t like a particular tool, you can replace it with another one: PHP for Python, SQL for NoSQL, HTML for Flash.

The flip side of the coin is that all these tools are very different. They have not just a different syntax, they have fundamentally different paradigms. Programmers need years to master each of them. For the web this is too long.
')
The second problem is the inevitable duplication of code. For example, if somewhere you need to ask a user for a date (say, departure), you should use a regular input text field and then check the entered value. First, you need to make sure that it is generally a date, not; DROP TABLE, and second, that it lies in some near future. These checks have to be done three times: in the client part (usability), server (security) and in the database (integrity). And if the database in most cases checks everything automatically, then checks in the server and client parts will have to be written independently, and taking into account the locales, this is not a trivial task. As a result, you will get two functions that do the same thing, but you cannot use one of the other, or at least just copy them.

GWT, like Dart, is designed to solve these problems. In the case of GWT, only Java and a small piece of CSS, which is responsible only for fonts and colors (but not for the location of elements), remain from the entire zoo. Everything else is either hidden in the depths of the libraries, or used at the level of a standard stub (HTML with a single div, into which the entire interface will be programmatically inserted later).

In addition to the zoo technology, there is also a zoo of browsers headed by IE. Even now, when processing a banal keypress event (onkeypress), in javascript it is necessary to check the browser version, because different browsers call this function differently. Then, in 2006, I had to use a huge amount of crutches just to make the page look more or less the same. GWT beautifully solved this problem.

How it worked

The entire GWT project was written in the same environment and in the same language - warm tube Java with MVC and patterns. It was almost full-fledged Java in the sense that almost the entire standard library was emulated, but of course it was impossible to transfer all the code from the desktop application. Google even released a special build of the Eclipse editor in which everything, including debugging, worked out of the box.

On the server side, everything looked like regular Java Server Pages with GWT libraries connected. But since JSP-hosting still needed to be found, one way or another I had to figure out the settings of this entire enterprise. However, the server part could be created on anything, but all the advantages of a single language were, of course, lost.

The client part was compiled from Java to Javascript, and for each browser, its own file was compiled and dynamically loaded. This avoided a lot of browser revisions and generally worked very well.

HTML itself has not been used. Theoretically, you could create your own HTML page and then programmatically insert controls into the right places, but still the mainstream was to create a fully dynamic interface entirely in Java. There were even semi-working graphical editors that allow you to draw the interface with a mouse almost like in the .Net form editor or Delphi there. The location and size of the elements were set programmatically, the CSS remained only fonts, colors and small ruches such as rounded corners.

In general, in theory, everything looked very cool.

Practice

In practice, it was not so rosy.

In the automatically created interface elements, a terry table layout was used. Any rectangular block generated a single-cell table. The panel (the union of several blocks) was represented by a table with a single row or column. The dialog box was a jumble of nested panels. The output was a porridge from tables of a rather large degree of nesting, which was almost impossible to figure out. Browsers also chewed on the resulting giant DOM without much joy.

I am absolutely not a supporter of semantic layout, I understand that it was only possible to use tables on the tables in order to implement the programmatic generation of HTML from the standpoint of the classic OOP, and even so that it works the same in all versions of IE, and even in 2006. However, what happened in the GWT - it just slowed down. It still slows down, even in Chrome, even on modern processors, even on pages with only hundreds of widgets.

It was also not very easy to put your own HTML and feed it with GWT in practice. This is not jQuery, where you can easily manipulate the DOM and generate your HTML as you see fit. You could, in theory, save a couple of upper levels of tables, but completely abandon them - in any way. The worst of all was the interaction of GWT and native Javascript.

In theory, GWT supports JSNI - something a la assembly language inserts in C, only with Javascript as an assembler. But it works only in one direction. That is, you can call some external js library from GWT without any problems. But on the contrary ... Why are there javascript, it’s trite to hang up your onclick on an html element to intercept it in GWT - such shamanism was not described in the manual and, it seems, was not provided by the developers at all. It was possible to do it, but with the help of Javascript tricks, not GWT.

Guglovtsy tried to completely bridge all differences browsers, but still to the end of this could not. There remained (at least in version 2.2, I didn’t work anymore) some subtle points that even in javascript refer to “shamanism”, such as prohibiting the selection of text with a blurred mouse click. But this is nagging.

Conceptual issues

Admittedly, in general, the GWT worked. Maybe in some places slowly, maybe somewhere clumsily and not completely, but it worked. His main problem is that the notorious development rate of large applications on the GWT was much lower than on the standard technology zoo. And if the problems of the previous section Dart solves, then problems with the speed of development - no.

All programming paradigms - classical OOP, prototype, procedural, relational, functional - are all Turing-complete and allow to solve the same class of problems. To say that OOP is the best paradigm is like saying "I am a lamer." The whole question is which paradigm allows you to quickly solve a specific task.

Java, and with it all the classic OOP, is based on the idea of ​​separating classes and the actual objects - instances of a class. This is suitable for all business applications that need to handle millions of lines of invoices, payments, balances in warehouses, and so on. There are relatively few classes, but a lot of objects.

In the web, everything is wrong. On one page you have only one login form, one shopping cart, one current user and one “pay loot” button. To make a separate class for each of these elements and then create one copy of each class ... but why? Practice shows that most often it is simply not necessary to separate classes and objects on the web.

Ok, the follower of the Gang of Four will say, but what will happen when the second “loot” button is needed, but with mother-of-pearl buttons? In Javascript, everything will be exactly like this: the second button, created according to the prototype of the first, but with buttons. In the classical OOP there will be a separate class, but this is half the problem; the main thing is to refactor with highlighting the interface and writing a heap of code that does nothing at all, but simply maintains the structure of the classes. And all this is due to static typing, which does not allow simply using “mother-of-pearl” button instead of “just buttons”.

I have been writing for four years on GWT, and I can confidently say that duck typing is better than static typing for the web. And it affects only the speed of compilation, and not the speed of code execution.

GWT was made by true fans of the classic PLO, not allowing any deviations from the Holy Patterns. If someone decided that it is impossible to use inline-style elements, then it is impossible and the point. There is no such function - to change the style, and there will not be; do everything with CSS classes. In general, of course, in most cases, inline styles should not really be used, but how, for example, do you implement animation? Create 20 classes of the form .opacity03 {opacity: 0.3}?

Damn, in GWT there is a Grid type component (a table type control element in which cells can be edited) in which your MVC is fully implemented. In the visual control ... If you need to make a 2x3 label, you need to describe the model, the container, and the list goes on. Lines so on 200 code :)

If the same team did Dart ... well, I don't know. Now it's not 2006, Javascript has gotten stronger, ottakanilsya and overgrown with libraries of jQuery level. I do not see any reason for which Dart "shoot." Despite the power of Google.