I've just come across this. These people have too much time on their hands. They implemented a text editor in Javascript. They implemented a text editor and UI framework based on the Canvas tag. From Scratch! It won't even run on Internet Explorer. And it looks like crap! Excuse me, but couldn't they just have used Java and run an Applet? While I have nothing against Javascript, it just seems like such a complete fucking waste of time.
Back in the 90ies, the hype was that Java in the browser would supplant Microsoft as the next Platform (with a capital P). Now it seems that Javascript is going to be the thing. Except with a weaker security model, no real modularity story, etc. I think a common runtime across platforms would be nice, but does it have to be Javascript in a Canvas? I want my Betamax back!
Showing posts with label java. Show all posts
Showing posts with label java. Show all posts
Thursday, February 19, 2009
Wednesday, June 11, 2008
Why Wicket Is Different
Eeelco Hillenius says it well on the Wicket mailing list:
That really sums up my experience, too: you can use the wildest components and just not care about how they are implemented.
Wicket supports private state for individual components, whereas the
traditional (REST) pattern assumes to take the state out (to string
based request parameters) and up to the request level. The big
difference is that without using a framework like Wicket, you can't
really create self contained components. You have to ensure that state
gets passed in any URL that is generated on a page, ensure the
parameters are properly scoped, have to worry about how to serialize
and de-serialize (from regular objects to strings and vice versa),
etc.
You can test this by creating a Struts app where you create a pageable
list. You'd append parameters for e.g. the page number and query to
every URL that passes back to the page, even if the link you are
constructing has nothing to do with the pageable list. Just the fact
that it is on the page means you have to pass the parameter. That by
itself is doable - though destroys encapsulation -; the problems
really start when you decide to move/ reuse the 'component' to/ in
another page, and when e.g. you add more things to the pass that need
to pass state like for instance tabs.
That really sums up my experience, too: you can use the wildest components and just not care about how they are implemented.
Thursday, April 05, 2007
Why Eclipse Is Pointing At Your Big Toe
Rob Williams complains that Eclipse plugins suck. Unfortunately he is right. Most plugins (and that includes some projects hosted at eclipse.org) don't come anywhere near the quality of the Eclipse SDK. Rob asks in a comment why the unwashed masses of plugin developers are allowed to shoot themselves (and the whole Eclipse install) in the foot. As usual, it seemed like a good idea at the time (an still may be).
One of the basic tenets of eclipse development is that there are no privileged clients. The idea at the time was to migrate all IBM dev tools onto a common platform. This would include web tools, c, cobol, you name it. It should be possible to write a state of the art tool for all these problem domains. At the same time, the platform should allow for all these tools to seamlessly integrate into the same workbench. It was felt that the platform would only end up with the appropriate degrees of freedom if the developers of the Eclipse SDK would themselves have to live by the same rules as all the "third party" plugin writers (a practice called "eating your own dogfood"). That meant that if the JDT or the update manager or whatever SDK plugin could plug in some functionality into the workbench, anybody else could do so, too. Voila a whole bunch of loaded guns conveniently pointed at your foot ;-)
One of the basic tenets of eclipse development is that there are no privileged clients. The idea at the time was to migrate all IBM dev tools onto a common platform. This would include web tools, c, cobol, you name it. It should be possible to write a state of the art tool for all these problem domains. At the same time, the platform should allow for all these tools to seamlessly integrate into the same workbench. It was felt that the platform would only end up with the appropriate degrees of freedom if the developers of the Eclipse SDK would themselves have to live by the same rules as all the "third party" plugin writers (a practice called "eating your own dogfood"). That meant that if the JDT or the update manager or whatever SDK plugin could plug in some functionality into the workbench, anybody else could do so, too. Voila a whole bunch of loaded guns conveniently pointed at your foot ;-)
Thursday, March 15, 2007
Why does JSF use JSP
I've been looking into JSF these last days. What I don't get about it is why they use JSP to create the component tree? If you write an internationalized application, you end up with zero, zip, kein HTML on your page. At that point, wouldn't we be better off just building the component tree in Java, with nice things like code assist and static type checks? Or am I just missing something here?
Wednesday, March 14, 2007
log4j must die!
Arghh, stuck in log4j hell once again:
log4j:WARN Please initialize the log4j system properly.
I would, if this fucking piece of shit actually told me any useful information, like where it was trying to load the configuration from.
log4j:WARN Please initialize the log4j system properly.
I would, if this fucking piece of shit actually told me any useful information, like where it was trying to load the configuration from.
Subscribe to:
Posts (Atom)