4 ms·
Or how about http://code.google.com/webtoolkit http://code.google.com/webtoolkit
by phenylene 19y ago
Or how about http://code.google.com/webtoolkit http://code.google.com/webtoolkit
- palish 19y agoJava?
- phenylene 19y agoI hear you. I haven't written any Java code, but I recognize that my opinion was not formed by modern experiences: I was woefully unimpressed with the insanely slow craplets of the late '90s (and Paul Graham's mentions of Java in his essays didn't help improve my opinion of it either ;). Still, I'd be willing to believe that there are far more skilled Java programmers than there are skilled Javascripters, and something like GWT could only help the move to the web for many applications, especially if it truly helps to bypass the browser compatibility issues, not to mention far simpler testing and debugging.
- natrius 19y agoI'm surprised that you're the first person to point this out. That's the first thing I thought of when I read this: "But then somebody you've never heard of, some bratty Y Combinator startup, maybe, is gaining ridiculous traction selling NewSDK, which combines a great portable programming language that compiles to JavaScript, and even better, a huge Ajaxy library that includes all kinds of clever interop features." No, it won't be some bratty Y Combinator startup. It'll be Google (but the Facebook/Twitter integration features won't be there, mainly because they're silly). Even when GWT matures into the world-dominating SDK Joel speaks of, I still won't use it. To paraphrase jwz: Some people, when confronted with a problem, think, "I know, I'll use Java." Now they have two problems. I'm waiting for someone to generate Javascript from Java through GWT from Javascript through Rhino. I wonder if that's possible...
- jsjenkins168 19y agoYes, it should be possible. BUT you need to make sure Rhino restricts the Java classes being to those core classes in the GWT JRE Emulation library: http://code.google.com/webtoolkit/documentation/jre.html http://code.google.com/webtoolkit/documentation/jre.html Then you would want to wrap the other GWT classes. Mainly what you would be interested in is the RPC libraries so you can directly send Java data types over the wire to the server using GWTs serialization/deserialization routines. You dont know how nice it is to not have to deal with complex XML parsing until you've actually experienced it. Its heaven on earth compared to manual Ajax programming. Oh and the debugging... I shouldn't even have to explain the merit of this to an experienced Ajax developer. Using Rhino for this seems kinda pointless though when you could just write it directly in Java. I find it ridiculous how some hackers have such an aversion to coding Java. I think if people took the time to learn GWT they would quickly discover what kind of competitive advantage it brings when building complex web applications (web applications, not simply web pages). Yes, it is verbose, but once you get the hang of it its very intuitive. Why cant it be some Y Combinator startup who builds what Joel describes? GWT in the hands of a small team can build web applications that compete with Googles. If you dont believe me, then I challenge you to give it a try and see for yourself. Just dont give up too quickly; the learning curve is a bit steep.
- sbraford 19y agoI haven't taken a look at GWT but I know of at least one ex-Googler that was trying to do a startup in Java/GWT and was hitting some major roadblocks/slowness of dev speed; they've since switched to RoR. I also worked on SproutIt's Mailroom app, which is about 80% of the functionality of GMail, implemented by 2 dudes (one backend, one part-time front-end) over the course of a year (also in Ruby on Rails). Sprout's since released their toolkit, called SproutCore, but its docs are still a bit sketchy. My $.02 -- too much of the plumbing for web 2.0 takes place on the server, which is why time to market on the server-side has been so important over the past few years. With Prototype, MooTools, YUI, etc. a lot of the fancy front-end tools can be bolted on after the fact. Also -- how many apps fit the mold of a 100% full-screen AJAX app? Email, spreadsheet, word processing, calendar... what else? Reading news, surfing blogs (outside of an RSS reader), googling for information, etc. do not fit the mold of a 100% AJAX app.
- jsjenkins168 19y agoYou will definitely be very slow in building stuff initially, if you have not used GWT before. Much slower than using RoR. Unless maybe you've done lots of SWT/Swing programming, then you will at least have a general understanding on how to layout stuff graphically and use event listeners. Everything in GWT is treated as AJAX app, in that all RPC's are asynchronous. But all GWT apps dont have to be "100% full screen". You have the freedom to do whatever you want visually, including wrapping JS libraries for animation, drag drop, etc (which I've done with my current project). In theory, you could write everything in native javascript and then just wrap it using GWT's JSNI functionality. Then you can use GWT for debugging and reliable RPC's. Or if you have your own server side JSON XML parsing for an existing Ajax framework, simply adapt your client side XML parsing to use GWT's XML libraries. Then everything is type safe and can be debugged and unit tested. You can also refactor your JS more easily this way, and everything is more modular. Bottom line is GWT is very flexible. It is designed this way so it can be integrated with existing JS projects. That being said, I agree with your comment about not everything fits the mold of an Ajax app. Like if you are not building a web application. Rails will be faster and more immediately gratifying in most situations.