July/August 2018 issue of acmqueue The July/August issue of acmqueue is out now
Subscribers and ACM Professional members login here



Web Development

  Download PDF version of this article PDF

Error 526 Ray ID: 46ded029efac1888 • 2018-10-22 20:46:24 UTC

Invalid SSL certificate

You

Browser

Working
Newark

Cloudflare

Working
deliverybot.acm.org

Host

Error

What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.

acmqueue

Originally published in Queue vol. 7, no. 6
see this item in the ACM Digital Library


Tweet



Related:

Pete Hunt, Paul O'Shannessy, Dave Smith, Terry Coatta - React: Facebook's Functional Turn on Writing JavaScript
A discussion with Pete Hunt, Paul O'Shannessy, Dave Smith and Terry Coatta


Eric Schrock - Debugging AJAX in Production
Lacking proper browser support, what steps can we take to debug production AJAX code?


Jeff Norwalk - Case Study: Making the Move to AJAX
What a software-as-a-service provider learned from using an AJAX framework for RIA development



Comments

(newest first)

Stephen S | Tue, 13 Oct 2009 13:11:50 UTC

"In fact, that is not the way you work in GWT at all. You spend most of your time in GWTs hosted mode, which allows you to run and debug your Java code in a normal Java debugger (for example, Eclipse), just as youre accustomed to doing. Only when the application is written and debugged do you need actually to compile it into JavaScript. Thus, everyones reflexive fear of never being able to understand and debug the compiled JavaScript proves to be unfounded."

The team I worked on implementing an enterprise application in GWT (1.4 then) didn't find this to be true at all. While at first we spent most of our time in hosted mode we eventually started getting bit by subtle bugs that would only present themselves in the compiled javascript code including the performance issues that would be masked as compiled javascript running in IE6 runs very differently than the java being executed in hosted mode. Since these issues only presented themselves once the compiled javascript it meant working in the browser to figure out what was going on.

This presented a situation where you have a team of java developers with little to no experience in javascript trying to decipher the thousands of lines of generated javascript code and research debugging/profiling tools that could be run against ie6. All of this happening very late in a release.


Sakuraba | Thu, 23 Jul 2009 09:23:34 UTC

Very nice summary. Working with GWT for almost 2 years now, I can say that the only thing that holds me back is the fact that the GWT team is aiming at producing solutions that work really well at a very low level. They dont give you a lot of "high level abstractions" for free, you have to be a UI-Patterns (Model-View-Presenter, etc) expert to write a large codebase that remains maintainable and most importantly testable.

The widget set and the "default look" are a little minimal, too. They rewrote Google Adwords with GWT which looks really nice, which means you can write good looking apps with it, you just need CSS and design skills, which forced a lot of developers into third party widget libraries. Those libraries are either a wrapper around traditional javascript or implemented with GWTs DOM abstractions. Those libraries dont have the same amount of 'perfection' associated with them, so you will inherit the same problems as with traditional web applications even though you are working with GWT.

For a better adoption of GWT, I think the focus of the GWT team should shift away from trying to optimize the tiny small bits (like inlining math calculations or rewriting the JS "this" reference into a smaller variable to save some bytes) and focus on real world problems that make web development so cumbersome. That includes e.g. a complete abstraction of browser-specific layouting, additional widgets with a "Store"-like API, to declaratively describe e.g. the contents of a datasource for widgets.

A part of GWTs mission statement is that the "parts of GWT must be independently useful", which means that you should be able to add the e.g. I18N-module to your project, but if you dont want/need to, you should not "pay" for the existence of that module, it should not stand in your way. This principle is great and there is a need to add standard solutions (a GWT-application-framework, a default eventbus, the store-api described above, etc) for real world problems that every web-developer faces.

Dear GWT-team, thank you for your wonderful work, but the above is what we need next to really effectively use GWT. You should not have to become a UI-Patterns-magician first, writing horribly untestable code on the way, to create great, large GWT-applications.


Dan Billings | Wed, 22 Jul 2009 22:16:59 UTC

Very nice summary Bruce. GWT is going to be a major contender in the future, when everyone appreciates its power!


Bill Braasch | Wed, 22 Jul 2009 16:22:31 UTC

GWT is a work in process. I think it's a pretty good work in process. We use it to animate JSON data with declarative programming in the open source itemscript project (itemscript.org).

Thus began the age of compiled javascripts. Microsoft's next generation office project claims to be the 'largest javascript' ever written. They should run it through the GWT compiler, use code-splitting to optimize the packaging, read 'the story of my compile' (a new feature) and weep for the browsers that bear the burden of poorly written but well-intentioned javascript.

The road leads to a lean programming model where the interface designers drag and script widgets, bind them to data and publish an iteration, little aware of the technical components that are being optimized in their own iterations. Decoupling the iterations will increase the flow of solutions.

GWT is still young, has good ideas and a product to support (Google Wave). We like the compiler a lot. It makes the code smaller. We'd like it to make the code even smaller. Code-splitting and "story of your compile" and oophm are the wrenches for that. Turns out YMMV when writing boatloads of Javascript. Slow=death.


Rusco | Wed, 22 Jul 2009 15:31:27 UTC

If Google Engineers would invest all their brainpower in a decent cross browser XForms Engine we could get the same results as with GWT, but with only 20 % of the effort of a GWT Project.

The truth is still to be revealed !


Armchair Pundit | Wed, 22 Jul 2009 11:16:18 UTC

GWT certainly makes sense for some usage patterns for web-apps.

However, it does come along with some leaky abstractions and quirks, more details here:

http://ptrthomas.wordpress.com/2008/09/04/wicket-and-gwt-compared-with-code/


Leave this field empty

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.