Who invented gwt

Indeed, if you are considering giving your classes back to the project, remember that it is of paramount importance for the Emulated JRE that each class included follows the very same semantics of the original Java JRE.

This ensures that anyone can recompile Java code into JavaScript and trust that they will get the expected results. Always make sure your code is thoroughly tested before giving it back to the community.

To be an effective tool for production of real-world web applications, GWT must allow developers to interact easily with the underlying platform. That is, the browser and the DOM. For instance, using syntax features unique to the GWT compiler, you can write the following Java code:.

An example of where this layer comes into play can be found in the context of UI composition. The only difference is that, in this case, the underlying system is the browser and DOM. Starting with version 2. The full specification of JsInterop is still in progress, and the latest updates can only be tried out by compiling the source from the GWT repository.

But it is already clear that this is this the new direction that will allow GWT to keep up with evolving web platforms. One ongoing project taking advantage of JsInterop is the recently released gwt-polymer-elements , which makes all the Iron and Paper elements from Polymer available to GWT. What is interesting in this library is that the developers do not need to generate the Java API by hand. The project uses gwt-api-generator to generate most of the interfaces directly by parsing the Polymer library and the JSDoc annotations.

This makes it easy to keep the bindings up to date. I use GWT daily in my work as a developer and consultant, but mostly I love GWT because it lets me push the limits of browser capabilities and show that modern web applications can be as powerful as desktop applications. If you are in the region, I hope you will come and meet some of the core developers, and learn about all the opportunities to be part of the evolution of this amazing toolkit.

Subscription implies consent to our privacy policy. Thank you! Check out your inbox to confirm your invite. Engineering All Blogs Icon Chevron. Filter by. View all results. Web Front-end. Author Alberto Mancini. JavaScript front-ends with the power of Java apps? Yes, you too can have it all, with GWT! World-class articles, delivered weekly. Sign Me Up Subscription implies consent to our privacy policy.

Next to the idea of using the browser as the basis for the user's experience, the most current term related to modern application development is Cloud Computing. This idea reflects the concept of sharing resources over the web, on demand, instead of each user having a private, limited pool of resources.

In this view, software is considered a "service" the acronym SAAS, which stands for "Software as a Service," is often used and a resource similar to more "tangible" ones as hardware. As an aside, the vulnerability of some operating systems, most notably Windows, to viruses, worms, and similar attacks, has given a push to the idea of using a simple, secure, machine and storing everything "on the web," letting the cloud administrators deal with hackers and program infections.

The main requirements for such an architecture involve reliable services and software, delivered through specific data centers, and running on unspecified servers; for the user, the web provides an access to a cloud of resources. For GWT applications, your applications are basically destined from the ground up to be used "in the cloud" because of the standard restrictions imposed by browsers. Distributing an application over the web, accessing it from anywhere, and having your data stored in a basically unknown place are all characteristics of any applications you might write.

The trend toward Cloud Computing has even spawned a new concept: the "Death of the Desktop. If this were true, it could be great for GWT developers, but things are a bit different. Even if you are enamored with the latest netbooks or high-powered cellphones, you should accept that working all the time with minimal screens isn't the way that things can get done at a company. And for gaming or graphic-intense usages, small machines aren't so hot either; they may do, however, for business-oriented applications.

In any case, GWT can help you because you can use its layout facilities and CSS styling to produce applications for just about any device out there. Also, remove the rosy glasses for an instant. Cloud computing offers several advantages and GWT applications can be considered to be right in the middle of that concept but also presents problems, so you need to plan accordingly. Aside from the obvious difficulty of dealing with possibly flaky web connections, security and compatibility can be stumbling blocks.

On the other hand, scalability is well handled; there are plenty of large sites, with hundreds or thousands of servers, proving that web applications can scale well. The important point is, with or without desktops, GWT provides some ways around these kind of problems, and we'll study this in upcoming chapters. I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time. Pearson Education, Inc.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies. To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:. For inquiries and questions, we collect the inquiry or question, together with name, contact details email address, phone number and mailing address and any other additional information voluntarily submitted to us through a Contact Us form or an email.

We use this information to address the inquiry and respond to the question. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes. Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing.

Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law. If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information informit.

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature. We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

I've dabbled a bit in GWT, and from my experiences, it's a pain. Of course, I have a strong mental association with anything Java to pain Moodle already has a system for internationalization that works well with its PHP internationalization system.

Unless GWT's system can fit in well with Moodle's PHP internationalization, then this would be a disadvantage at worst, and neutral at best. Somewhat interesting, but JavaScript is already a high-level language, and browsers already do a lot of optimizing. Without seeing any hard numbers, I have doubts as to how much of a difference optimization at that stage would make.

If something more sophisticated is needed, I would think that something like RequireJS would be sufficient. As for OOP, JavaScript's paradigm is certainly different from Java's, but it's a matter of opinion as to which one is better than the other. In fact, in some ways e. I don't know much about GWT's particular mechanisms, but things that can help performance are good. I think that if Moodle were to spend the effort to switch to anything different it would be jQuery the main advantage there being popularity and familiarity.

I have considerable Java experience dating from its invention including commercial experience with GWT. There are too many reasons to list why Moodle should not adopt this technology. However as Hubert says there are good reasons for moving to JQuery, and top of the list for me are popularity and familiarity.

I'm sorry, but I don't feel that there are many good reasons to adopt jQuery and replace the YUI loader within core. There is a plan to include a copy of jQuery in Moodle and provide a loading mechanism for it's use either an appropriate local plugin, or more likely directly within core , but it will categorically not be used by anything within core Moodle.

Additionally, it's extremely likely that any supported use of jQuery in third-party plugins will be required to make use of the YUI loader syntax.

This is because jQuery has no loading mechanism of it's own and is very good at stepping on it's own toes if it is included multiple times within the same page.

The most important resource for Moodle is developer time. I agree that developer time is a very big concern, but trying to ensure compatability across a wide range of server environments with different plugin configurations on every installation is, in my opinion, a bigger concern. As I mentioned, jQuery will be included in core soon hopefully for 2. Although there may be more developers familiar with jQuery than YUI, in reality there are not that many differences in use of the two it's all JavaScript after all.

Since 2. The core documentation for YUI is really very good the documentation systems were completely rewritten about 18 months ago. Sorry, I didn't mean to suggest that you meant to replace YUI, though this was hinted at by Hubert in the post you replied to. I find YUI and JQuery to be sufficiently different that they might as well be in unrelated programming languages let alone libraries.

I have tried a few times but it has defeated me. I am sure I will have another go at some point in the future. I am actively working to improve our YUI documentation so if there is anything specific that you have been struggling with, it would be great to know more about what and perhaps I can try and include documentation on this, or links to appropriate documentation perhaps send me a private message to avoid filling this thread with unrelated content though. Marcus " I simply cannot afford the time to become adequatly familiar with YUI.

Same for me. For the record, I'm not saying that Moodle should move to jQuery and I didn't mean to reopen that debate. I was just saying that if Moodle were ever to spend effort to switch from one library to another, IMHO jQuery would be the most likely candidate. I strongly suspect that GWT will not be utilised within moodle core.

It is of course up to individual plugin developers as to whether they want to use GWT to generate any of their own code, though I feel it is unlikely.

As you mention, Moodle uses the YUI JavaScript library and framework and I would say it is more than just a library of components as it provides a framework for building, loading, and utilising components, as well as components themselves. YUI already provides some libraries for server interoperation on the client side , though it favours json as a language structure over XML. The Y.