Hi Jeff, If it ever comes to be the situation that the only way I can do programming is on the web, then I'll waste the time to learn the current iteration of web programming. But life is currently not so dim or dreary, and doesn't look to be that way any time soon. (And if I am going to take the time to "read, read, read" on new programming ideas, it'll be on the Android (where there's a decent job market, and worthwhile development tools) or the iPhone (I've got one iPhone app out, but I'd like to learn more networking, and some of the newer technologies, not on a constantly changing "standards" body heavily influenced by Microsoft and Internet Explorer.) I have a finite supply of "learn" time, and I have thigns that, for me, are far better ways to spend it than reading W3C documents.
Let me put it another way: I have absolutely NO desire to be a "master Web applications developer". If I wanted to be one of those, I wouldn't be using GWT. I'd be rolling my own. I took a look at SpringToolsSuite and Spring Roo. Their documentation sucks, their tutorials are out of date, their integration with Eclipse is poor, and the support on the forums is weak. So, since I AM a good SQL developer, I said the heck with that, and rolled my own for my current project. And do not regret the choice at all. The difference is that I find SQL a lot more interesting than JavaScript. Look, I'm glad that there are people out there who WANT to dig into the arcana of web programming. I'm not one of them. I'm someone who wants to solve other problems. It was my impression that GWT exists to serve the people who want to solve those other problems, and don't want to have to dig in to that web BS (like worrying about IE vs. FF). If that IS GWT's purpose, then their documentation sucks, and is not in line with their purpose. If that ISN'T GWTs purpose, what is? Greg On Dec 7, 11:24 am, Jeff Schwartz <[email protected]> wrote: > Hi Greg, > > I have been in IT for a very long time. You see, I am what the youngins > sometimes refer to as an ol' fart :). As a matter of fact, I've been a > developer in one form or another for so long that everything else prior to > that seems to me to be prehistory - a vague sense of something there but not > having much substance (oh GOD, help me lol). > > My point is that as technologies advance I try to stay current and for those > technologies that I have or will chose to base a career on I've tried to > master them to the best of my ability. That means giving up lots of personal > time to read up on everything I can get my hands on. Why the story? Because > I am trying to convey to you that there are no shortcuts or free lunches. If > you want to be a master Web applications developer then you will have to > read and learn everything you can about Web development that you can get > your hands on. It is that simple, I am afraid. The benefits are obvious, as > the current limitations you perceive there to be in the GWT documents serve > to exemplify. > > I'm afraid that comparing Google to other companies, even if only for their > quality of documentation, isn't going to be very productive and will just > serve to frustrate you even more. Take the time and go and read, read, read, > and play with all the different things you do read up on. One day soon you > will have what can only be described as an epiphany, that moment when it all > gels and at that moment you will have a big smile on your face - a Kodak > moment! > > Jeff > > On Tue, Dec 7, 2010 at 12:08 PM, Greg Dougherty > <[email protected]>wrote: > > > > > > > If I knew JavaScript and DOM, or, for that matter, even WANTED to know > > > > JavaScript and DOM, I wouldn't be using GWT, I'd be writing the > > > > JavaScript myself. No? > > > > No. > > > > Abstractions do not work for these kind of things. > > > It's not a matter of abstractions, it's a matter of explanations. > > IMAO, the JavaDoc for a KeyPressEvent should tell you exactly what > > that event IS. And what's the difference between it and the other > > Key*Events. It shouldn't be that hard, after all the person writing > > the code had better know the answer to that question, no? > > > Google has detailed requirements for the format of any code submitted > > to be part of GWT. How about a requirement that the documentation > > attached to the code actually has to provide some value, too? > > > And I think you're confusing this post (about trying to figure out > > which event to use) with my other post (where the tutorial code for > > getting an enter key doesn't work). > > > The point of THIS thread is that the people writing "documentation" > > for a lot of the GWT routines seem to assume that everyone using GWT > > spends as much time reading W3C documentation as the doc writers do, > > and as such they end up writing documentation that is worthless until > > you go read the W3C docs (or come here and beg for information). The > > further point is that this is a bad assumption on their part, and that > > it would be good if they stopped writing docs that way. > > > Greg > > > On Dec 4, 6:11 am, Thomas Broyer <[email protected]> wrote: > > > On 3 déc, 20:50, Greg Dougherty <[email protected]> wrote: > > > > > Jeff, > > > > > Thank you. That' lets me know which one I want to use. > > > > > If I knew JavaScript and DOM, or, for that matter, even WANTED to know > > > > JavaScript and DOM, I wouldn't be using GWT, I'd be writing the > > > > JavaScript myself. No? > > > > No. > > > > Abstractions do not work for these kind of things. GWT is no different > > > from jQuery, Prototype.js and others in this respect: it tries to hide > > > browser discrepancies, but that doesn't mean you're freed from knowing > > > them (or least that they exist). > > > What GWT gives you that JavaScript doesn't is that it's Java, i.e. you > > > can reuse some code between your (Java) server and client, you benefit > > > from Java's static typing (which among other things make refactoring > > > efficient), you benefit from the tools from the Java world. > > > (don't put words in my mouth though: there are drawbacks to using Java > > > compared to JavaScript, they're two different languages, each with > > > their own strengths) > > > > > The whole point of using something like GWT is that it lets a Java > > > > programmer write a web app w/o having to learn all the crap that > > > > normal web app writers have to wade through. That's certainly why I > > > > spent the time and effort to learn GWT. For that matter, I presume > > > > that the people writing things like the KeyPressEventHandler DO know > > > > JavaScript and DOM. So, really, how hard is it for them to put that > > > > knowledge into the documentation? Isn't that what the documentation > > > > is THERE for? > > > > The problem is that key/char event is a real mess! > > > All browsers behave differently (though WebKit is really close to IE). > > > Different successive versions of a given browser don't behave the > > > same. The same version of a given browser behave different on > > > different platforms. > > > It's hard (if ever possible!) to build an API with a consistent > > > behavior. > > > See for instance, and amongst many: > >http://code.google.com/p/google-web-toolkit/issues/detail?id=72http:/... > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<google-web-toolkit%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. > > -- > *Jeff Schwartz* -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
