6 ms·

This is against the grain, but it is obvious to me that the way forward for web development is to rise above Javascript and simple DOM mangling, which is what m

This is against the grain, but it is obvious to me that the way forward for web development is to rise above Javascript and simple DOM mangling, which is what most of these popular tools assist with. Javascript does not scale complexity and manipulating DOM elements directly is both error-prone and a lousy programming paradigm. We need something in between that offers a sane development model and deals with the complexity and anachronism of the underlying platform. GWT cross-compilation is an excellent example. It has enabled the painless development of complex Javascript-based web UIs[1], with the tool support of any other software development project. This is what I'm going to look to for the future of web application development, not patchy solutions to the complete mess that is barebones Javascript development. For examples of what I have done with GWT: TeampostgreSQL (http://www.teampostgresql.com http://www.teampostgresql.com), a rich PostgreSQL web interface, and my HTML5 game engine (http://www.webworks.dk/enginetest http://www.webworks.dk/enginetest). EDIT: By the way, it is only a matter of time until we have complete canvas-based UI libraries, frameworks and tools suites akin to Flex (probably from Adobe, too). When that happens the web will really have arrived as a rich client platform. I would be very surprised if there isn't a few projects in this space nearing completion at this point, since the underlying technology is basically ready.

wahnfrieden 14y ago
Direct DOM manipulation should be a lot cleaner once we have shadow DOM, don't you think? That lets us add abstraction and encapsulation to the DOM.
cdent 14y ago
I _hate_ web apps/sites/services created with GWT. They result in a) overcomplicated UIs b) assets which are completely opaque. Which runs contrary to the promise of the web: simple stuff that anyone can learn from. I realize this is an old saw that the young turks of HN probably don't care much about, but it is damn sad.
- camus 14y ago
  the promise of the web is "build once , run everywhere" , not "read the source code, ripoff that work". Nobody cares how it is done. the web is a plateform , the only things that matters is that the software runs on that plateform, without the need of going native.
  - cdent 14y ago
    Is it churlish of me to respond with a simple "bollocks!" here? A great deal of people care how it is done.
skrebbel 14y ago
I feel you, but so far I haven't seen any such solution that isn't full of leaky abstractions. As far as I've come to understand, GWT is no exception. What's the point of a high level powerful tool if you need to understand the underlying technologies and the transformations to it well in order to use it?
- jebblue 14y ago
  >> What's the point of a high level powerful tool if you need to understand the underlying technologies and the transformations to it well in order to use it? What on earth are you talking about?
jarek-foksa 14y ago
Building UI libraries on top of canvas feels like reinventing the weel, HTML/SVG/CSS already provide you advanced APIs for accessability, text layout, theming and drawing. All you really need is a tiny abstraction layer.
- politician 14y ago
  But here's the thing: CSS is a stone soup of non-local, action-at-distance effects -- it's "goto" programming. HTML lacks decent layout primitives (border layout, grid layout) because it's a document-oriented abstraction. It's just really obnoxious to get a single screen application look working correctly on all browsers. So, I'd welcome a reimplementation of, say, WPF on canvas. Something that works without Microsoft's, Google's, and Mozilla's explicit blessing really is needed.
  - woah 14y ago
    CSS is not that hard. Many developers simply put off doing it at any cost, then throw together a messy unorganized stylesheet and blame the language. I'll agree with you on the layout shortcomings, such as using excessive floats etc. But once flexbox is fully implemented as a standard, this will become much easier.
    - praptak 14y ago
      > CSS is not that hard. It is not hard, it is just not fit for laying out UI because it is was not developed with this purpose in mind. CSS3/flexbox is an afterthought attempt to fix that.
ZoFreX 14y ago
I think there's quite a wide gulf between "direct DOM manipulation" and "use GWT". I've been using Backbone's views to make my JS more manageable, for example, and there are some nice MVVM frameworks out there that really help you build complex JS applications without it turning into spaghetti.
lopatin 14y ago
Ragarding your edit: A startup called famo.us(http://famo.us http://famo.us) is focusing on exactly this (canvas based UIs) however I'm not completely sold that this is the future. It's an awful lot of wheel reinventing. They're doing it in the name of solving performance for HTML5 apps and for creating apps with rich UIs which would be more similar to interfaces we see today in games rather than traditional DOM based UIs. However, I don't think there's a need for that, and ditching all HTML standards in order to reimplement them in the canvas sounds like a step backward for me.
- johnyzee 14y ago
  I need it specifically for games, building an interface on a canvas without even layout managers or mouse click aware components feels like the stone age, so I am in the market for a wheel actually. Though it does seem like a bit of a waste as the other poster also said.
  - 1123581321 14y ago
    I thought the menu pattern for canvas-based games is to use DOM elements and display them above canvas.
    - lopatin 14y ago
      That works fine to an extent, but sometimes you want your menus integrated with your game and have consistent graphics and animations and so on. I used dom elements for snaketron, but in hindsight I think it felt tacky (it might partly have been because I used Bootstrap). For most games, which are more complicated, I can imagine it would be a pain to maintain dom menus.
- malandrew 14y ago
  FYI, famo.us is not Canvas, it's DOM. IMHO, since AJAX and div-hell designs became commonplace, we've been needing to have a long overdue discussion about the right role of semantics in HTML. There definitely is a place, the <article> for example was a step in the right direction because it indirectly acknowledges that an html document is not really any longer a document, but in many cases is simply a collection of documents. Take Twitter for example. Each tweet is a document, but is twitter itself a document? no, it's an app. We still need standards and semantics and all the goodness of the DOM, but we need it for things on the web that are in fact still documents and not some chimera. At famo.us, we're focusing on turning the top level DOM elements into something compatible with the app approach that is capable of being made performant. However, we're not going to throw the baby out with the bathwater. DOM and the original ideas behind HTML are still valuable. It's just time to reassess the role of apps and how to make it so they can live in the same space as documents (i.e. the browser viewport), especially when they are ephemeral apps, because the "install" is dead. It's been usurped by the almighty hyperlink.
astral303 14y ago
There is no future in GWT. Even Google is running away from it and is working on Dart now. Having worked with GWT for some time, it's a subpar model. Perhaps it's a flawed execution of the concept, but it has extremely long compilation times, the development mode crawls (so developing with it is slow)--at least for a sizable project. Furthermore, it's not as easy to use external JS libraries (you have to create wrappers) and, worst of all, there just is not a vibrant community around it. For example, it's inexcusable for a 2012-era framework to not have a quality form validation library available. The other downside of GWT is that it's written in verbose Java, with plenty of non-DRY stuff. GWT compiler provides code generation for some things and the Maven plugin has code generation for others. In my opinion, when a framework, that advertises ease of client/server integration, asks you to create TWO same-but-slightly-different interfaces per one service to make remote calls, and does so with a straight face in the documentation, then you know that the authors are missing the point. (Oh and you have to define the new service in three places in two different files.) The point is that brevity of code and DRY are very important. When the authors don't champion this, there is little hope for the whole thing. GWT was a good idea when it was created, but it failed to evolve in the face of jQuery's competition. All you need is abstract away enough pain and complexity until things become manageable and it's easier to get the job done. This is what jQuery did by abstracting away browser differences. This is what other frameworks, such as Backbone.js, are doing at the next level.
- jebblue 14y ago
  >> There is no future in GWT. I think there is. This doesn't look like the site of a failing project: https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/ >> but it has extremely long compilation times, the development mode crawls When you go to create the deployment package it's slow. When doing development, which is most of the time, it's fast to me. I can change things in the client or server code, save and see the results instantly. >> it's inexcusable for a 2012-era framework to not have a quality form validation library available. http://code.google.com/p/gwt-validation/ http://code.google.com/p/gwt-validation/ >> The other downside of GWT is that it's written in verbose Java That is a huge, major win dude. Seriously. What else would we all program the web in? JavaScript? The language that has to be excused for all the weird things it does when you thought your code would do something different? >> ...Java, with plenty of non-DRY stuff. DRY is a principle, you can repeat yourself or not in any language you choose. I'd quote more and respond to more but most of your arguments are clearly in favor of JavaScript programming, it makes no sense to compare a Java to JavaScript technology to a simple JavaScript library (jQuery) because with jQuery I still have to program in the weird unpredictable, odd behavioral world of JavaScript.
natural219 14y ago
I agree with the gist or your post, but as others have pointed out, GWT is essentially depricated and really not the right direction to go. I think the angle that TypeScript is taking may prove to be more fruitful.
- jebblue 14y ago
  >> GWT is essentially depricated and really not the right direction to go. Where does it say that on the GWT site? https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/
  - pjmlp 14y ago
    At this years Google IO they hinted that GWT is going to be ported to Dart. How that will change GWT's future is anyone's guess.
    - johnyzee 14y ago
      http://www.dartlang.org/support/faq.html#future-for-GWT http://www.dartlang.org/support/faq.html#future-for-GWT "Dart and GWT both share the goal of enabling structured web programming. In fact, many of the same engineers who brought you GWT are working on Dart. We view Dart as an ambitious evolution of GWT's mission to make web apps better for end users, and we're optimistic about its potential. As Dart evolves and becomes ready for prime time, we anticipate working closely with the GWT developer community to explore Dart." "Meanwhile, rest assured that GWT will continue to be a productive and reliable way to build the most ambitious web apps—and even games like Angry Birds. Key projects within Google rely on GWT every day, and we plan to continue improving (and open-sourcing) GWT based on their real-world needs." I personally don't care what it's called, or even the language, as long as it builds on the strong foundation that has been laid with GWT.
      - jebblue 14y ago
        Ok thanks, so Google wants us to use their browser, their OS (Chromebook) their systems language Go, their web language Dart, I'm not sure where this is headed. An old expression about putting all ones eggs in one basket comes to mind.
Joeri 14y ago
The DOM is indeed too low-level. We need higher-level components, and the ability to develop custom components. We also need a way to firewall segments of a page, so we can reason about it at a higher level of abstraction. This technology is coming, it's called shadow dom ( http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ ). I've been developing a 100.000 line single page javascript app for the past few years. You can't build an app like that if you code at the level of dom elements. Encapsulation and abstraction is essential. Because the shadow dom didn't exist i used extjs as a crude alternative (extjs's component framework is really nice, but the dom structure it produces is ugly). However, with shadow dom I can imagine a way of writing javascript in the large without needing the heavy abstraction layer that extjs provides.
- noxryan 14y ago
  Have you tried using the Dojo/Dijit Framework at all? I have been using it for medium to large sized web applications recently. I break pages and components into dijit widgets and everything becomes separated very nicely. It has a similar declarative markup to the link you posted.
- deleted 14y ago
  [deleted]
rmason 14y ago
Or how about Flex itself as an independent open source Apache project? http://incubator.apache.org/flex/ http://incubator.apache.org/flex/

wahnfrieden 14y ago

Direct DOM manipulation should be a lot cleaner once we have shadow DOM, don't you think? That lets us add abstraction and encapsulation to the DOM.

cdent 14y ago

I _hate_ web apps/sites/services created with GWT. They result in a) overcomplicated UIs b) assets which are completely opaque. Which runs contrary to the promise of the web: simple stuff that anyone can learn from. I realize this is an old saw that the young turks of HN probably don't care much about, but it is damn sad.

camus 14y ago
the promise of the web is "build once , run everywhere" , not "read the source code, ripoff that work". Nobody cares how it is done. the web is a plateform , the only things that matters is that the software runs on that plateform, without the need of going native.
- cdent 14y ago
  Is it churlish of me to respond with a simple "bollocks!" here? A great deal of people care how it is done.

skrebbel 14y ago

I feel you, but so far I haven't seen any such solution that isn't full of leaky abstractions. As far as I've come to understand, GWT is no exception. What's the point of a high level powerful tool if you need to understand the underlying technologies and the transformations to it well in order to use it?

jebblue 14y ago
>> What's the point of a high level powerful tool if you need to understand the underlying technologies and the transformations to it well in order to use it? What on earth are you talking about?

jarek-foksa 14y ago

Building UI libraries on top of canvas feels like reinventing the weel, HTML/SVG/CSS already provide you advanced APIs for accessability, text layout, theming and drawing. All you really need is a tiny abstraction layer.

politician 14y ago
But here's the thing: CSS is a stone soup of non-local, action-at-distance effects -- it's "goto" programming. HTML lacks decent layout primitives (border layout, grid layout) because it's a document-oriented abstraction. It's just really obnoxious to get a single screen application look working correctly on all browsers. So, I'd welcome a reimplementation of, say, WPF on canvas. Something that works without Microsoft's, Google's, and Mozilla's explicit blessing really is needed.
- woah 14y ago
  CSS is not that hard. Many developers simply put off doing it at any cost, then throw together a messy unorganized stylesheet and blame the language. I'll agree with you on the layout shortcomings, such as using excessive floats etc. But once flexbox is fully implemented as a standard, this will become much easier.
  - praptak 14y ago
    > CSS is not that hard. It is not hard, it is just not fit for laying out UI because it is was not developed with this purpose in mind. CSS3/flexbox is an afterthought attempt to fix that.

ZoFreX 14y ago

I think there's quite a wide gulf between "direct DOM manipulation" and "use GWT". I've been using Backbone's views to make my JS more manageable, for example, and there are some nice MVVM frameworks out there that really help you build complex JS applications without it turning into spaghetti.

lopatin 14y ago

Ragarding your edit: A startup called famo.us(http://famo.us http://famo.us) is focusing on exactly this (canvas based UIs) however I'm not completely sold that this is the future. It's an awful lot of wheel reinventing. They're doing it in the name of solving performance for HTML5 apps and for creating apps with rich UIs which would be more similar to interfaces we see today in games rather than traditional DOM based UIs. However, I don't think there's a need for that, and ditching all HTML standards in order to reimplement them in the canvas sounds like a step backward for me.

johnyzee 14y ago
I need it specifically for games, building an interface on a canvas without even layout managers or mouse click aware components feels like the stone age, so I am in the market for a wheel actually. Though it does seem like a bit of a waste as the other poster also said.
- 1123581321 14y ago
  I thought the menu pattern for canvas-based games is to use DOM elements and display them above canvas.
  - lopatin 14y ago
    That works fine to an extent, but sometimes you want your menus integrated with your game and have consistent graphics and animations and so on. I used dom elements for snaketron, but in hindsight I think it felt tacky (it might partly have been because I used Bootstrap). For most games, which are more complicated, I can imagine it would be a pain to maintain dom menus.
malandrew 14y ago
FYI, famo.us is not Canvas, it's DOM. IMHO, since AJAX and div-hell designs became commonplace, we've been needing to have a long overdue discussion about the right role of semantics in HTML. There definitely is a place, the <article> for example was a step in the right direction because it indirectly acknowledges that an html document is not really any longer a document, but in many cases is simply a collection of documents. Take Twitter for example. Each tweet is a document, but is twitter itself a document? no, it's an app. We still need standards and semantics and all the goodness of the DOM, but we need it for things on the web that are in fact still documents and not some chimera. At famo.us, we're focusing on turning the top level DOM elements into something compatible with the app approach that is capable of being made performant. However, we're not going to throw the baby out with the bathwater. DOM and the original ideas behind HTML are still valuable. It's just time to reassess the role of apps and how to make it so they can live in the same space as documents (i.e. the browser viewport), especially when they are ephemeral apps, because the "install" is dead. It's been usurped by the almighty hyperlink.

astral303 14y ago

There is no future in GWT. Even Google is running away from it and is working on Dart now. Having worked with GWT for some time, it's a subpar model. Perhaps it's a flawed execution of the concept, but it has extremely long compilation times, the development mode crawls (so developing with it is slow)--at least for a sizable project. Furthermore, it's not as easy to use external JS libraries (you have to create wrappers) and, worst of all, there just is not a vibrant community around it. For example, it's inexcusable for a 2012-era framework to not have a quality form validation library available. The other downside of GWT is that it's written in verbose Java, with plenty of non-DRY stuff. GWT compiler provides code generation for some things and the Maven plugin has code generation for others. In my opinion, when a framework, that advertises ease of client/server integration, asks you to create TWO same-but-slightly-different interfaces per one service to make remote calls, and does so with a straight face in the documentation, then you know that the authors are missing the point. (Oh and you have to define the new service in three places in two different files.) The point is that brevity of code and DRY are very important. When the authors don't champion this, there is little hope for the whole thing. GWT was a good idea when it was created, but it failed to evolve in the face of jQuery's competition. All you need is abstract away enough pain and complexity until things become manageable and it's easier to get the job done. This is what jQuery did by abstracting away browser differences. This is what other frameworks, such as Backbone.js, are doing at the next level.

jebblue 14y ago
>> There is no future in GWT. I think there is. This doesn't look like the site of a failing project: https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/ >> but it has extremely long compilation times, the development mode crawls When you go to create the deployment package it's slow. When doing development, which is most of the time, it's fast to me. I can change things in the client or server code, save and see the results instantly. >> it's inexcusable for a 2012-era framework to not have a quality form validation library available. http://code.google.com/p/gwt-validation/ http://code.google.com/p/gwt-validation/ >> The other downside of GWT is that it's written in verbose Java That is a huge, major win dude. Seriously. What else would we all program the web in? JavaScript? The language that has to be excused for all the weird things it does when you thought your code would do something different? >> ...Java, with plenty of non-DRY stuff. DRY is a principle, you can repeat yourself or not in any language you choose. I'd quote more and respond to more but most of your arguments are clearly in favor of JavaScript programming, it makes no sense to compare a Java to JavaScript technology to a simple JavaScript library (jQuery) because with jQuery I still have to program in the weird unpredictable, odd behavioral world of JavaScript.

natural219 14y ago

I agree with the gist or your post, but as others have pointed out, GWT is essentially depricated and really not the right direction to go. I think the angle that TypeScript is taking may prove to be more fruitful.

jebblue 14y ago
>> GWT is essentially depricated and really not the right direction to go. Where does it say that on the GWT site? https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/
- pjmlp 14y ago
  At this years Google IO they hinted that GWT is going to be ported to Dart. How that will change GWT's future is anyone's guess.
  - johnyzee 14y ago
    http://www.dartlang.org/support/faq.html#future-for-GWT http://www.dartlang.org/support/faq.html#future-for-GWT "Dart and GWT both share the goal of enabling structured web programming. In fact, many of the same engineers who brought you GWT are working on Dart. We view Dart as an ambitious evolution of GWT's mission to make web apps better for end users, and we're optimistic about its potential. As Dart evolves and becomes ready for prime time, we anticipate working closely with the GWT developer community to explore Dart." "Meanwhile, rest assured that GWT will continue to be a productive and reliable way to build the most ambitious web apps—and even games like Angry Birds. Key projects within Google rely on GWT every day, and we plan to continue improving (and open-sourcing) GWT based on their real-world needs." I personally don't care what it's called, or even the language, as long as it builds on the strong foundation that has been laid with GWT.
    - jebblue 14y ago
      Ok thanks, so Google wants us to use their browser, their OS (Chromebook) their systems language Go, their web language Dart, I'm not sure where this is headed. An old expression about putting all ones eggs in one basket comes to mind.

Joeri 14y ago

The DOM is indeed too low-level. We need higher-level components, and the ability to develop custom components. We also need a way to firewall segments of a page, so we can reason about it at a higher level of abstraction. This technology is coming, it's called shadow dom ( http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ ). I've been developing a 100.000 line single page javascript app for the past few years. You can't build an app like that if you code at the level of dom elements. Encapsulation and abstraction is essential. Because the shadow dom didn't exist i used extjs as a crude alternative (extjs's component framework is really nice, but the dom structure it produces is ugly). However, with shadow dom I can imagine a way of writing javascript in the large without needing the heavy abstraction layer that extjs provides.

noxryan 14y ago
Have you tried using the Dojo/Dijit Framework at all? I have been using it for medium to large sized web applications recently. I break pages and components into dijit widgets and everything becomes separated very nicely. It has a similar declarative markup to the link you posted.
deleted 14y ago
[deleted]

rmason 14y ago

Or how about Flex itself as an independent open source Apache project? http://incubator.apache.org/flex/ http://incubator.apache.org/flex/