GWT does not use dynamic code generation. The javascript that is emitted by GWT's java-to-javascript compiler is generated at build-time...in the same way that x86 code is generated by gcc at build time.
Moreover, the code that is generated is not source code, which is the context in which most people use the rule of thumb that you imply. Rather, the generated code is, in essence, object code: you're not intended to read it or modify it. It's just deployed and executed, plain and simple.
The GWT project that I have under my belt (mentioned elsewhere in this discussion) was the second version of the system. The first version was done in JSF. Ditching JSF in favor of GWT was a decision that I'm so glad we made. The component model in JSF has big dreams, but it feels like it was designed by a committee who never bothered to use it to see how it feels.
GWT, on the other hand, is raw power, and the component model is simple and elegant. If given the choice to write a custom JSF component or a custom GWT component (using their Composite pattern) I would choose the latter in a heartbeat.
I think a lot of people take a casual look at GWT's RPC mechanism and walk away with the assumption that their back-end has to be done in java. My project happened to use a java backend, and the stuff you get "for free" with their RPC mechanism is really nice but there's no reason you can't use an ordinary JSON service written in you're favorite backend.
It's like taking a quick glance at a swiss army knife, noticing the cork screw, and tossing it aside saying "meh, you need a bottle of wine to use this".
I've used GWT to develop a pretty sophisticated server-side piece of a vertical market product. I approached GWT with much of the same trepidation as you have expressed. In the end I just had to "let go" and think of Javascript as an assembly language. (After all, I've been ignoring assembly language all these years, why not ignore Javascript?)
Now that our product is in a mature phase, and looking back at what we've built, I'm amazed by the brilliant design tradeoffs chosen by the GWT team at Google. Kudos.
The generated Javascript ended up being very easy to debug, and exceedingly lightweight. Since the source language is static, the compiler is able to leave out every feature that you didn't use. Their "Pay As You Go" philosophy actually works.
The only major caveat that comes to mind is that GWT shines for "web apps" more than for "web sites", which may account for why the submitter isn't seeing GWT "in the wild". It's important for sites to be spiderable, and you get the most leverage out of GWT when you're building an all-in-one-page DHTML rich-client application, not a site. It's still useful for sites, but then you'd be hunting squirrels with a bazooka.
No doubt. That's one of the many mod options over at plastic.com that I wish were available here. (The others being: clever, succinct, scholarly, compelling, irrelevant, disingenuous, incoherent, and obnoxious.)
It's unfortunate that you were moderated a 'troll', when it's obvious that you're correct on this. Agile methods predated Web 2.0, and it's tragic that the latter movement is somehow getting credit, in this article, for the former. What's next? Is Web 2.0 going to get credit for OO?
I thought it was worth adding that you can still view the source of DHTML-based applications. It may not be as easy to interpret, but it's still there.
Moreover, with tools like WebKit's DOM Inspector and Firefox's FireBug you can crawl the dom as it exists at any given moment. So you've actually gained abilities, not lost them.
Listing AJAX and GWT separately in the writeup is redundant, since the latter is just one way of implementing DHTML applications.
There's nothing about DHTML apps that prevents the creation of sites where you can directly navigate to specific content. In the case of GWT apps, for example, the browser's history mechanism is fully functional, and specific content within a GWT application is typcially referenced by anchors at the end of the URL. Those same URLs can, of course, be used for both bookmarking and direct navigation to that content. It isn't spiderable, but that's a different issue.
I am a bit uncomfortable with DHTML apps being lumped-in with the likes of Flash and Silverlight. At least they're based on public & open specs, and have multiple competing implementations.
an LLVM bytecode program, unlike a java bytecode program or CLR bytecode program, makes no assumptions about the presence of a runtime. An ordinary C program could have an LLVM bc representation that gets JIT compiled to x86 at launch time (and cached on disk between executions) so that the end result should be about the same as an x86 representation. Including, interestingly, the amount of space it takes up on disk: despite being an SSA IR with full type information, it's very space-efficient.
So such a future would not be nearly as dismal as a JVM/CLR bytecode future would be.
With respect to memory, my first thought is that this inflated price may be offset somewhat by the different requirements between the operating systems. Microsoft's official recommendation for Vista Home Premium / Business / Ultimate is 1GB, with a common belief among users that 4GB may be the "sweet spot". Compare that to Leopard, which has an official minimum recommendation of 512MB, and any new machine that you buy ships by default with 2GB, which seems to be Leopard's "sweet spot".
My gut feeling is that something even better than the current fat binaries is on the way in. Perhaps not in Snow Leopard, but surely in the release after. The essential piece, LLVM, is already under Leopard's OpenGL stack, and is almost certainly under OpenCL (and perhaps Grand Central Dispatch). LLVM is the real star of the show, and I'm surprised that it hasn't gotten one mention in this thread. The long-term implications are mind-boggling.
Expect to see "BC 0xC0DE" magic numbers in a future release. I'll bet my first born.
Amory Lovins, in his excellent TED Talk on Winning the Oil Endgame, makes an argument that weight savings need not lead to descreased safety. An example that he cites is a hand-built McLaren that has a couple of woven carbon-composite cones in the front that absorb the energy of a crash. Well worth a listen.
Of course, it must be all about shame.
It couldn't possibly be the case that after several long cycles of innovation it might be a good idea to hold the APIs constant and merely refactor, fix, & profile. Me fail software engineering? That's unpossible,
I'd like to add another aspect in which the IBM of the day was very different from the Apple of today: IBM was an enormous, lumbering bureaucracy and never could manage to put all of its wood behind one arrow. The Apple of today would never make a mere token effort to push its operating system, whilst simultaneously selling Windows boxen hand over fist, undermining the former.
IBM is a different case. With OS/2, they had a difficult time building a healthy base of 3rd party applications written specifically to OS/2's unique APIs, and the corresponding developer mindshare that comes with it. Many who ran OS/2 ran Windows applications on it.
Apple already has a vibrant development community, and it's only going to grow as developers use Cocoa Touch. (Every such developer gets direct experience with XCode, Objective-C, and a foundational intersection of the APIs in MacOS X.
I do not buy your argument that Apple's position today is anything like IBM's position with OS/2.
Maybe we'll get a new song when the blight eradicates the Cavendish. The one you're refering to was written during the demise of the Gros Michel:
"(Some of the shortages during that time entered the fabric of popular culture; the 1923 musical hit ÃâYes! We Have No BananasÃâ is said to have been written after songwriters Frank Silver and Irving Cohn were denied in an attempt to purchase their favorite fruit by a syntactically colorful, out-of-stock neighborhood grocer.)"
More correctly, it's a nice way to spin a Safari-on-Windows flaw.
On MacOS X, downloaded files are flagged and a dialog box is presented when the user first attempts to open said file. Perhaps that mechanism must be in MacOS X itself and not Safari.
It looks like Apple's just going to have to add some Windows-specific code to make up for this security feature it was getting from the platform prior to being ported.
Slashdot Mirror
dynamic code generation is evil
GWT does not use dynamic code generation. The javascript that is emitted by GWT's java-to-javascript compiler is generated at build-time...in the same way that x86 code is generated by gcc at build time.
Moreover, the code that is generated is not source code, which is the context in which most people use the rule of thumb that you imply. Rather, the generated code is, in essence, object code: you're not intended to read it or modify it. It's just deployed and executed, plain and simple.
The GWT project that I have under my belt (mentioned elsewhere in this discussion) was the second version of the system. The first version was done in JSF. Ditching JSF in favor of GWT was a decision that I'm so glad we made. The component model in JSF has big dreams, but it feels like it was designed by a committee who never bothered to use it to see how it feels.
GWT, on the other hand, is raw power, and the component model is simple and elegant. If given the choice to write a custom JSF component or a custom GWT component (using their Composite pattern) I would choose the latter in a heartbeat.
I think a lot of people take a casual look at GWT's RPC mechanism and walk away with the assumption that their back-end has to be done in java. My project happened to use a java backend, and the stuff you get "for free" with their RPC mechanism is really nice but there's no reason you can't use an ordinary JSON service written in you're favorite backend.
It's like taking a quick glance at a swiss army knife, noticing the cork screw, and tossing it aside saying "meh, you need a bottle of wine to use this".
I've used GWT to develop a pretty sophisticated server-side piece of a vertical market product. I approached GWT with much of the same trepidation as you have expressed. In the end I just had to "let go" and think of Javascript as an assembly language. (After all, I've been ignoring assembly language all these years, why not ignore Javascript?)
Now that our product is in a mature phase, and looking back at what we've built, I'm amazed by the brilliant design tradeoffs chosen by the GWT team at Google. Kudos.
The generated Javascript ended up being very easy to debug, and exceedingly lightweight. Since the source language is static, the compiler is able to leave out every feature that you didn't use. Their "Pay As You Go" philosophy actually works.
The only major caveat that comes to mind is that GWT shines for "web apps" more than for "web sites", which may account for why the submitter isn't seeing GWT "in the wild". It's important for sites to be spiderable, and you get the most leverage out of GWT when you're building an all-in-one-page DHTML rich-client application, not a site. It's still useful for sites, but then you'd be hunting squirrels with a bazooka.
But that can be fun, too.
No doubt. That's one of the many mod options over at plastic.com that I wish were available here. (The others being: clever, succinct, scholarly, compelling, irrelevant, disingenuous, incoherent, and obnoxious.)
It's unfortunate that you were moderated a 'troll', when it's obvious that you're correct on this. Agile methods predated Web 2.0, and it's tragic that the latter movement is somehow getting credit, in this article, for the former. What's next? Is Web 2.0 going to get credit for OO?
There's at least one notable example where a napkin drawing caused a stonhenge monument to be in danger of being crushed by a dwarf.
I thought it was worth adding that you can still view the source of DHTML-based applications. It may not be as easy to interpret, but it's still there.
Moreover, with tools like WebKit's DOM Inspector and Firefox's FireBug you can crawl the dom as it exists at any given moment. So you've actually gained abilities, not lost them.
Listing AJAX and GWT separately in the writeup is redundant, since the latter is just one way of implementing DHTML applications.
There's nothing about DHTML apps that prevents the creation of sites where you can directly navigate to specific content. In the case of GWT apps, for example, the browser's history mechanism is fully functional, and specific content within a GWT application is typcially referenced by anchors at the end of the URL. Those same URLs can, of course, be used for both bookmarking and direct navigation to that content. It isn't spiderable, but that's a different issue.
I am a bit uncomfortable with DHTML apps being lumped-in with the likes of Flash and Silverlight. At least they're based on public & open specs, and have multiple competing implementations.
an LLVM bytecode program, unlike a java bytecode program or CLR bytecode program, makes no assumptions about the presence of a runtime. An ordinary C program could have an LLVM bc representation that gets JIT compiled to x86 at launch time (and cached on disk between executions) so that the end result should be about the same as an x86 representation. Including, interestingly, the amount of space it takes up on disk: despite being an SSA IR with full type information, it's very space-efficient.
So such a future would not be nearly as dismal as a JVM/CLR bytecode future would be.
I'm going to go out on a limb and guess that they're putting the velocities into a frame of reference that more people can appreciate.
With respect to memory, my first thought is that this inflated price may be offset somewhat by the different requirements between the operating systems. Microsoft's official recommendation for Vista Home Premium / Business / Ultimate is 1GB, with a common belief among users that 4GB may be the "sweet spot". Compare that to Leopard, which has an official minimum recommendation of 512MB, and any new machine that you buy ships by default with 2GB, which seems to be Leopard's "sweet spot".
Ooh, what a fun game...let me try:
How to make a Boeing 747
- start with a long tin can
- put wings and engines on it
- put some chairs in it
- you're done
Is the universal binary on it's way out?
My gut feeling is that something even better than the current fat binaries is on the way in. Perhaps not in Snow Leopard, but surely in the release after. The essential piece, LLVM, is already under Leopard's OpenGL stack, and is almost certainly under OpenCL (and perhaps Grand Central Dispatch). LLVM is the real star of the show, and I'm surprised that it hasn't gotten one mention in this thread. The long-term implications are mind-boggling.
Expect to see "BC 0xC0DE" magic numbers in a future release. I'll bet my first born.
The problem is that I can also use that technology on my big heavy SUV and it will STILL have the weight advantage.
Maybe not. You'll have more crash energy to absorb in your case, because you have more mass.
Amory Lovins, in his excellent TED Talk on Winning the Oil Endgame, makes an argument that weight savings need not lead to descreased safety. An example that he cites is a hand-built McLaren that has a couple of woven carbon-composite cones in the front that absorb the energy of a crash. Well worth a listen.
Now
Of course, it must be all about shame. It couldn't possibly be the case that after several long cycles of innovation it might be a good idea to hold the APIs constant and merely refactor, fix, & profile. Me fail software engineering? That's unpossible,
I'd like to add another aspect in which the IBM of the day was very different from the Apple of today: IBM was an enormous, lumbering bureaucracy and never could manage to put all of its wood behind one arrow. The Apple of today would never make a mere token effort to push its operating system, whilst simultaneously selling Windows boxen hand over fist, undermining the former.
IBM is a different case. With OS/2, they had a difficult time building a healthy base of 3rd party applications written specifically to OS/2's unique APIs, and the corresponding developer mindshare that comes with it. Many who ran OS/2 ran Windows applications on it. Apple already has a vibrant development community, and it's only going to grow as developers use Cocoa Touch. (Every such developer gets direct experience with XCode, Objective-C, and a foundational intersection of the APIs in MacOS X. I do not buy your argument that Apple's position today is anything like IBM's position with OS/2.
Not yet. That, too, is just a part of the pre-WWDC rumor-mill frenzy.
Maybe we'll get a new song when the blight eradicates the Cavendish. The one you're refering to was written during the demise of the Gros Michel:
"(Some of the shortages during that time entered the fabric of popular culture; the 1923 musical hit ÃâYes! We Have No BananasÃâ is said to have been written after songwriters Frank Silver and Irving Cohn were denied in an attempt to purchase their favorite fruit by a syntactically colorful, out-of-stock neighborhood grocer.)"
More correctly, it's a nice way to spin a Safari-on-Windows flaw. On MacOS X, downloaded files are flagged and a dialog box is presented when the user first attempts to open said file. Perhaps that mechanism must be in MacOS X itself and not Safari. It looks like Apple's just going to have to add some Windows-specific code to make up for this security feature it was getting from the platform prior to being ported.
It's all machine language down at the bottom. So what's your point?
s/"with the speed of the blades"/"with the speed of the turbine"/