TSS Article: Hard times for JavaFX ?
6 views
Skip to first unread message
Jan Goyvaerts
Nov 24, 2009, 6:24:03 AM11/24/09
to java...@googlegroups.com
I was wondering who read this brief article and especially the comments to it. Do you people agree to the general idea of the comments that JavaFX is a failure asking to be happening ? Personally, I believe it's the greatest thing that's happening since Java came out. (Which was also said to be sluggish btw...)
Casper Bang
Nov 24, 2009, 7:17:56 AM11/24/09
to The Java Posse
Yes, that is the general consensus outside Sun I think- far too little
and too late. I may be biased by seeing JavaFX steal the precious few
resources Sun have away from everything else, when clearly going up
against Adobe and Microsoft is a long shot by any measure. On top of
that, Google is not exactly resting on its laurels but keeps pushing
the limit for a rich browser experience - without the need of a
secondary runtime container. If you notice, many RIA technology
reviews don't even mention JavaFX at all. I might have felt
differently if JavaFX was targeted as a JavaNG rather than this narrow
applet version 2.0 technology in a whole new and unfamiliar syntax.
Also check what google trends has to say about it:
http://www.google.com/trends?q=silverlight%2C+flex%2C+javafx%2C+gwt
/Casper
On Nov 24, 12:24 pm, Jan Goyvaerts <java.arti...@gmail.com> wrote:
> I was wondering who read this brief article and especially the comments to
> it. Do you people agree to the general idea of the comments that JavaFX is a
> failure asking to be happening ? Personally, I believe it's the greatest
> thing that's happening since Java came out. (Which was also said to be
> sluggish btw...)
>
> http://www.theserverside.com/news/thread.tss?thread_id=58536&utm_sour...)
and too late. I may be biased by seeing JavaFX steal the precious few
resources Sun have away from everything else, when clearly going up
against Adobe and Microsoft is a long shot by any measure. On top of
that, Google is not exactly resting on its laurels but keeps pushing
the limit for a rich browser experience - without the need of a
secondary runtime container. If you notice, many RIA technology
reviews don't even mention JavaFX at all. I might have felt
differently if JavaFX was targeted as a JavaNG rather than this narrow
applet version 2.0 technology in a whole new and unfamiliar syntax.
Also check what google trends has to say about it:
http://www.google.com/trends?q=silverlight%2C+flex%2C+javafx%2C+gwt
/Casper
On Nov 24, 12:24 pm, Jan Goyvaerts <java.arti...@gmail.com> wrote:
> I was wondering who read this brief article and especially the comments to
> it. Do you people agree to the general idea of the comments that JavaFX is a
> failure asking to be happening ? Personally, I believe it's the greatest
> thing that's happening since Java came out. (Which was also said to be
> sluggish btw...)
>
Jess Holle
Nov 24, 2009, 7:25:04 AM11/24/09
to java...@googlegroups.com
Technically I'd say JavaFX is pretty cool stuff. If Sun's layoffs
didn't set it back too awfully it should be much cooler around the end
of the year.
In terms of the market momentum/inertia, etc, I'd say it has an uphill
battle.
That said, I'd put some of the "it's doomed" comments in the wishful
thinking category. Why? Because those making them have invested
heavily in other technologies in this space and want the technology
they've already invested in to dominate so they don't have to invest
time and energy into learning anything else. Thus they really wish
JavaFX would go away -- and do so as quickly as possible. You can see
similar comments with similar motivations in many technology/product
spaces from those using the dominating product, e.g. from Eclipse
devotees regarding NetBeans, Windows users to users of other OS's, etc.
Now these folk may be right, unfortunately, but I think their comments
have a lot to do with their desire for a simple market dominated by the
technology they already know than anything else.
Overall I don't see JavaFX taking up huge market share in the short
term, but I believe it will at least carve out a niche for itself --
unless the EU mess drags the Sun/Oracle merger long enough to completely
kill Sun before Oracle can complete the merger.
Of course I like to see the underdog shake up and diversify markets that
are dominated by only a player or two, so maybe I'm just optimistic :-)
--
Jess Holle
> <http://www.theserverside.com/news/thread.tss?thread_id=58536&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+techtarget/tsscom/home+%28TheServerSide.com:+Your+Enterprise+Java+Community%29>
didn't set it back too awfully it should be much cooler around the end
of the year.
In terms of the market momentum/inertia, etc, I'd say it has an uphill
battle.
That said, I'd put some of the "it's doomed" comments in the wishful
thinking category. Why? Because those making them have invested
heavily in other technologies in this space and want the technology
they've already invested in to dominate so they don't have to invest
time and energy into learning anything else. Thus they really wish
JavaFX would go away -- and do so as quickly as possible. You can see
similar comments with similar motivations in many technology/product
spaces from those using the dominating product, e.g. from Eclipse
devotees regarding NetBeans, Windows users to users of other OS's, etc.
Now these folk may be right, unfortunately, but I think their comments
have a lot to do with their desire for a simple market dominated by the
technology they already know than anything else.
Overall I don't see JavaFX taking up huge market share in the short
term, but I believe it will at least carve out a niche for itself --
unless the EU mess drags the Sun/Oracle merger long enough to completely
kill Sun before Oracle can complete the merger.
Of course I like to see the underdog shake up and diversify markets that
are dominated by only a player or two, so maybe I'm just optimistic :-)
--
Jess Holle
Simon Brocklehurst
Nov 24, 2009, 3:36:01 PM11/24/09
to The Java Posse
I don't think it's a failure. The truth is that JavaFX Script is a
really productive and fun way to build rich client software. However,
there are some big questions marks over the technology at the moment.
These include:
- Apparent slippage in the JavaFX release schedule: JavaFX 1.3 (Soma)
was originally supposed to be an end-of-year 2009 release - now it may
be Feb 2010; Prism (the all new high-performance JavaFX graphics
system) was originally supposed to be part of the 1.3 release, now
it's pushed back to the summer.
- JavaFX applets in the browser are currently unusable on both Windows
and Mac OS X due to horrific rendering bugs (even leaving aside the
multiple-dialog box install procedure). With Java 7 slipping from
Feb 2010 to Sept 2010, it might be the best part of a year before the
applet situation improves (bbut hoping it's not a plug-in issue as
much as a JavaFX issue that's fixed in 1.3)
- Features having to be cut, even to make the delayed release
schedule. For example, the integrated 2-D/3-D scene graph was
originally supposed to be part of the 1.3 release, but now the scope
has been reduced to take out rendering 3-D objects.
- Poor performance with large scene graphs. This is promised to go
away with Prism - originally, it would have just been a few weeks
ago. Now it's probably at least six months away (see above).
- Neither a full complement of controls, nor interactive tooling
available to make building high-quality UIs fast and easy.
- Apparently zero momentum behind JavaFX Mobile. While Adobe is
signing up partners left, right and center for Flash on mobile, the
number of announcements relating to JavaFX have been conspicuous by
their absence.
- No easy deployment for standalone applications; and no way
incorporating JavaFX components inside a Swing app.
All of the above make it impossible to justify using JavaFX for real-
world projects except in a very limited set of circumstances; even for
those people (like me) that really want to see the technology succeed;
and most people won't even touch it yet because they think: it's so
far away from being useful; and they can't build on existing Swing
investments.
Future milestones will be: the Soma release; the Prism release; the
tooling product releases; and the Java 7 release. Hopefully the
technology will become a viable choice at one of these milestones
(i.e. within the next year), otherwise, I suspect there really will be
some problems for JavaFX.
The other thing that shouldn't be overlooked is that while Sun was
probably too small to take on Adobe and Microsoft in the RIA platform
battle, Oracle most certainly isn't too small. If Oracle wants to
make JavaFX the number one RIA platform, it certainly has the
resources to do so. I really hope Oracle delivers on the idea of
increasing investment in JavaFX to: first make it usable in the real
world; and second accelerate development to start bringing in time
lines, rather than have them keep being pushed out.
really productive and fun way to build rich client software. However,
there are some big questions marks over the technology at the moment.
These include:
- Apparent slippage in the JavaFX release schedule: JavaFX 1.3 (Soma)
was originally supposed to be an end-of-year 2009 release - now it may
be Feb 2010; Prism (the all new high-performance JavaFX graphics
system) was originally supposed to be part of the 1.3 release, now
it's pushed back to the summer.
- JavaFX applets in the browser are currently unusable on both Windows
and Mac OS X due to horrific rendering bugs (even leaving aside the
multiple-dialog box install procedure). With Java 7 slipping from
Feb 2010 to Sept 2010, it might be the best part of a year before the
applet situation improves (bbut hoping it's not a plug-in issue as
much as a JavaFX issue that's fixed in 1.3)
- Features having to be cut, even to make the delayed release
schedule. For example, the integrated 2-D/3-D scene graph was
originally supposed to be part of the 1.3 release, but now the scope
has been reduced to take out rendering 3-D objects.
- Poor performance with large scene graphs. This is promised to go
away with Prism - originally, it would have just been a few weeks
ago. Now it's probably at least six months away (see above).
- Neither a full complement of controls, nor interactive tooling
available to make building high-quality UIs fast and easy.
- Apparently zero momentum behind JavaFX Mobile. While Adobe is
signing up partners left, right and center for Flash on mobile, the
number of announcements relating to JavaFX have been conspicuous by
their absence.
- No easy deployment for standalone applications; and no way
incorporating JavaFX components inside a Swing app.
All of the above make it impossible to justify using JavaFX for real-
world projects except in a very limited set of circumstances; even for
those people (like me) that really want to see the technology succeed;
and most people won't even touch it yet because they think: it's so
far away from being useful; and they can't build on existing Swing
investments.
Future milestones will be: the Soma release; the Prism release; the
tooling product releases; and the Java 7 release. Hopefully the
technology will become a viable choice at one of these milestones
(i.e. within the next year), otherwise, I suspect there really will be
some problems for JavaFX.
The other thing that shouldn't be overlooked is that while Sun was
probably too small to take on Adobe and Microsoft in the RIA platform
battle, Oracle most certainly isn't too small. If Oracle wants to
make JavaFX the number one RIA platform, it certainly has the
resources to do so. I really hope Oracle delivers on the idea of
increasing investment in JavaFX to: first make it usable in the real
world; and second accelerate development to start bringing in time
lines, rather than have them keep being pushed out.
Chas Emerick
Nov 25, 2009, 8:09:16 PM11/25/09
to The Java Posse
This is a pretty comprehensive rundown of the issues today.
More puzzling to me than the technical stumbles/holes/blind spots (key
for me being no integration path with Swing for the legacy crowd & no
on-ramp for alternative JVM languages for the bleeding-edge crowd) is
that it's never been clear IMO what space JavaFX is supposed to occupy
in Sun/Oracle's ideal world.
If it's for building shiny baubles (which seems to be the case given
*all* of the demos and examples I've ever seen), then it's been doomed
from the start by Flex and AIR.
If it's for building mobile applications, then my goodness, how is it
possible that Google beat Sun to market with a critical mass of
(essentially) JVM-powered smartphones?
If it's for building "real" applications (and there's no indication
that that's the case), then it's been doomed from the start by not
carrying along the huge population of folks building on Swing, the
NetBeans RCP, and the Eclipse RCP (not to mention the licensing
decision to disallow redistribution of the JavaFX runtime). This is
where I've seen the most promise for JavaFX, as there's plenty of room
in the Flex/Air/Silverlight dogfight for another player, but there's
so much wrong with the runtime, language, and approach (or lack
thereof) to the existing ecosystem that it's hard to see things ever
improving.
For my money, give me Swing2, fix the applet/deployment experience,
and fix the license/redistribution issues, and we'd be on that in a
second.
I really hate being such a pessimist at this point, but I don't see
much room for hope -- short of a more pragmatic approach coming out of
Oracle.
Cheers,
- Chas
More puzzling to me than the technical stumbles/holes/blind spots (key
for me being no integration path with Swing for the legacy crowd & no
on-ramp for alternative JVM languages for the bleeding-edge crowd) is
that it's never been clear IMO what space JavaFX is supposed to occupy
in Sun/Oracle's ideal world.
If it's for building shiny baubles (which seems to be the case given
*all* of the demos and examples I've ever seen), then it's been doomed
from the start by Flex and AIR.
If it's for building mobile applications, then my goodness, how is it
possible that Google beat Sun to market with a critical mass of
(essentially) JVM-powered smartphones?
If it's for building "real" applications (and there's no indication
that that's the case), then it's been doomed from the start by not
carrying along the huge population of folks building on Swing, the
NetBeans RCP, and the Eclipse RCP (not to mention the licensing
decision to disallow redistribution of the JavaFX runtime). This is
where I've seen the most promise for JavaFX, as there's plenty of room
in the Flex/Air/Silverlight dogfight for another player, but there's
so much wrong with the runtime, language, and approach (or lack
thereof) to the existing ecosystem that it's hard to see things ever
improving.
For my money, give me Swing2, fix the applet/deployment experience,
and fix the license/redistribution issues, and we'd be on that in a
second.
I really hate being such a pessimist at this point, but I don't see
much room for hope -- short of a more pragmatic approach coming out of
Oracle.
Cheers,
- Chas
opinali
Nov 25, 2009, 7:49:30 PM11/25/09
to The Java Posse
Just some fixes:
On Nov 24, 6:36 pm, Simon Brocklehurst <si...@psynixis.com> wrote:
>
> - JavaFX applets in the browser are currently unusable on both Windows
> and Mac OS X due to horrific rendering bugs (even leaving aside the
> multiple-dialog box install procedure). With Java 7 slipping from
> Feb 2010 to Sept 2010, it might be the best part of a year before the
> applet situation improves (bbut hoping it's not a plug-in issue as
> much as a JavaFX issue that's fixed in 1.3)
There is no dependency on JDK 7. Check out JDK 6u18ea, it's a massive
update focused on JavaFX and JavaStore requirements (including tons of
backporting from any JDK7 enhancements that can help).
> - Poor performance with large scene graphs. This is promised to go
> away with Prism - originally, it would have just been a few weeks
> ago. Now it's probably at least six months away (see above).
This issue (scene graph scalability) was mostly fixed in 1.2. Most
remaining issues are bad performance to update the scene graph, but
these are being addressed in 1.3 even without Prism. Prism will bring
further improvements and enable new features (e.g. Saffron) but AFAIK
mostly in other areas, and 1.3 will have a quite good share of
performance optimizations, from animation/graphics to massively
enhanced binding (compiled bind). Right now, performance is really not
an important issue - I see JavaFX beating the competition in most
things, except codecs.
A+
Osvaldo
On Nov 24, 6:36 pm, Simon Brocklehurst <si...@psynixis.com> wrote:
>
> - JavaFX applets in the browser are currently unusable on both Windows
> and Mac OS X due to horrific rendering bugs (even leaving aside the
> multiple-dialog box install procedure). With Java 7 slipping from
> Feb 2010 to Sept 2010, it might be the best part of a year before the
> applet situation improves (bbut hoping it's not a plug-in issue as
> much as a JavaFX issue that's fixed in 1.3)
update focused on JavaFX and JavaStore requirements (including tons of
backporting from any JDK7 enhancements that can help).
> - Poor performance with large scene graphs. This is promised to go
> away with Prism - originally, it would have just been a few weeks
> ago. Now it's probably at least six months away (see above).
remaining issues are bad performance to update the scene graph, but
these are being addressed in 1.3 even without Prism. Prism will bring
further improvements and enable new features (e.g. Saffron) but AFAIK
mostly in other areas, and 1.3 will have a quite good share of
performance optimizations, from animation/graphics to massively
enhanced binding (compiled bind). Right now, performance is really not
an important issue - I see JavaFX beating the competition in most
things, except codecs.
A+
Osvaldo
Jess Holle
Nov 26, 2009, 9:30:08 AM11/26/09
to java...@googlegroups.com
Chas Emerick wrote:
> For my money, give me Swing2, fix the applet/deployment experience,
> and fix the license/redistribution issues, and we'd be on that in a
> second.
>
I concur that one of the most interesting spaces is that which would be
> For my money, give me Swing2, fix the applet/deployment experience,
> and fix the license/redistribution issues, and we'd be on that in a
> second.
>
logically occupied by a "Swing2". I'd be "okay" with this being JavaFX,
but JavaFX has a lot of gaps in that direction. Chasing the "bauble"
app direction seems just plain silly -- but, hey, I'm an enterprise app guy.
--
Jess Holle
Casper Bang
Nov 26, 2009, 10:25:29 AM11/26/09
to The Java Posse
While Tor seems to hint at things to come, this is the water-tank
chatter I've picked up:
1) They needed something "sexy" a la Flex.
2) There should be an eventual revenue model through tools.
3) It should not be hampered by usual compatibility roadblocks.
It feels like a game of catching up SUN could never win, considering
the competitors aren't exactly idling either.
I suppose I couldn't care less, except for 3 years now other things
have suffered (SwingLabs, SAF and even Java itself).
/Casper
chatter I've picked up:
1) They needed something "sexy" a la Flex.
2) There should be an eventual revenue model through tools.
3) It should not be hampered by usual compatibility roadblocks.
It feels like a game of catching up SUN could never win, considering
the competitors aren't exactly idling either.
I suppose I couldn't care less, except for 3 years now other things
have suffered (SwingLabs, SAF and even Java itself).
/Casper
Jess Holle
Nov 26, 2009, 10:43:25 AM11/26/09
to java...@googlegroups.com
I have to agree here.
I don't dislike JavaFX -- I wish it the best and would love to see it really become usable for the rest of us (e.g. for us enterprise app authors).
Still, it seems like rather than fight the good, hard fight to improve Java with its huge and hugely diverse community and often contrary interests, Sun has chosen to run off and start something new and unencumbered by all of this baggage. That's fine and good, but Sun's limited resources have made this far too much an either-or proposition. I'd love to see JavaFX *and* huge strides in (carefully but surely) evolving Java, e.g. getting Java 7 out in a timely fashion with closures, etc, all done right. Sun just does not have the resources for all of this, though.
This all brings me back to the Sun-Oracle merger and the EU blockage thereof. We need Sun to have Oracle's resources to keep all Java and JavaFX progress from stalling (or to restart it in areas in which it has stalled) -- and we need this ASAP. Sure the EU may be helping SAP in part here, but overall I think they're helping Microsoft more than anyone and it's really a shame.
Casper Bang wrote:
I don't dislike JavaFX -- I wish it the best and would love to see it really become usable for the rest of us (e.g. for us enterprise app authors).
Still, it seems like rather than fight the good, hard fight to improve Java with its huge and hugely diverse community and often contrary interests, Sun has chosen to run off and start something new and unencumbered by all of this baggage. That's fine and good, but Sun's limited resources have made this far too much an either-or proposition. I'd love to see JavaFX *and* huge strides in (carefully but surely) evolving Java, e.g. getting Java 7 out in a timely fashion with closures, etc, all done right. Sun just does not have the resources for all of this, though.
This all brings me back to the Sun-Oracle merger and the EU blockage thereof. We need Sun to have Oracle's resources to keep all Java and JavaFX progress from stalling (or to restart it in areas in which it has stalled) -- and we need this ASAP. Sure the EU may be helping SAP in part here, but overall I think they're helping Microsoft more than anyone and it's really a shame.
Casper Bang wrote:
-- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to java...@googlegroups.com. To unsubscribe from this group, send email to javaposse+...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Chas Emerick
Nov 26, 2009, 10:00:09 PM11/26/09
to The Java Posse
Oh, I hope the theory isn't as hare-brained as all that. "Sexy" is
driven by designers and other "creatives", who live and breath Adobe
tools, and have been doing so for the better part of two decades (or,
their entire lives, whichever is shorter! ;-) Trying to squeeze into
that space would require *massive* resources, plus a finger on the
heartbeat of that community, things that Sun surely doesn't have.
- Chas
driven by designers and other "creatives", who live and breath Adobe
tools, and have been doing so for the better part of two decades (or,
their entire lives, whichever is shorter! ;-) Trying to squeeze into
that space would require *massive* resources, plus a finger on the
heartbeat of that community, things that Sun surely doesn't have.
- Chas
Simon Brocklehurst
Nov 27, 2009, 6:23:03 AM11/27/09
to The Java Posse
On Nov 26, 12:49 am, opinali <opin...@gmail.com> wrote:
> Just some fixes:
> There is no dependency on JDK 7. Check out JDK 6u18ea, it's a massive
> update focused on JavaFX and JavaStore requirements (including tons of
> backporting from any JDK7 enhancements that can help).
6u18ea. I'm hoping that the applet rendering problems are due to
JavaFX bugs; and that they'll be resolved in JavaFX 1.3.
opinali
Nov 27, 2009, 7:53:21 AM11/27/09
to The Java Posse
XRender, and that's specific to X11. All other client-side
improvements are being developed first in JDK 6u1x and then forward-
ported to JDK7; btw, beta-addicted enthusiasts should NOT test/
benchmark JavaFX on top of any build of JDK7 because it doesn't yet
have parity with 6u1x (IIRC, the last alignment was to 6u14, they
still have to port most later enhancements, especially all of 6u18,
and 6u18 only ships in January so that port may have to wait until
JDK7-M7).
I didn't notice any severe rendering issue in a long time, but maybe
it's just some limitation of my testing (tested apps, systems or
browsers), care to provide some info or link? (Google didn't help) But
I see a steady stream of Java2D/AWT/plugin2/JAWS bugs in the 6u1x
builds, so I guess yes, we may depend on a better JRE6 and I hope that
6u18 will finally fulfill the promises from 6u10.
On a related note, reconsidering Mark Hamilton's announcements at
devoxx - he hinted that Jigsaw is a bigger improvement that previously
expected: any package (not just the JRE's) will benefit from CDS-like
optimizatiosn like install-time bytecode verification / prelinking and
faster classloading and sharing; may even include JIT caching / AOT
compilation (a la .NET NGEN-compiled assemblies) - this means that
JRE7 may bring very significant startup-time and code footprint
improvements. (Low-hanging Jigsaw fruit, like several refactorings
that reduce unnecessary classloading of some APIs, are already being
ported into 6u18.) So yes, perhaps JDK7 is also very important in the
long term, to enable medium-to-large-scale Java[FX] applets.
A+
Osvaldo
Simon Brocklehurst
Nov 27, 2009, 8:27:17 AM11/27/09
to The Java Posse
On Nov 27, 12:53 pm, opinali <opin...@gmail.com> wrote:
> On 27 nov, 09:23, Simon Brocklehurst <si...@psynixis.com> wrote:
> I didn't notice any severe rendering issue in a long time, but maybe
> it's just some limitation of my testing (tested apps, systems or
> browsers), care to provide some info or link?
http://www.psynixis.com/blog/2009/09/04/testing-javafx-applet-deployment/
If you read through the comments on the post, you'll notice lots of
people refer to painting artifacts when the web-page is scrolled (just
search for the word "scroll"). To reproduce, simply scroll the page
up and down fast so that the applet is moved on and off the screen.
You'll likely see bits of the applet being painted above and below
where it should be (lots of people see this on Mac OS X and on
Windows). This same behavior can also be seen in quite a few of the
demo applets on JavaFX.com.
.
opinali
Nov 27, 2009, 12:14:56 PM11/27/09
to The Java Posse
On 27 nov, 11:27, Simon Brocklehurst <si...@psynixis.com> wrote:
> On Nov 27, 12:53 pm, opinali <opin...@gmail.com> wrote:
>
> > On 27 nov, 09:23, Simon Brocklehurst <si...@psynixis.com> wrote:
> > I didn't notice any severe rendering issue in a long time, but maybe
> > it's just some limitation of my testing (tested apps, systems or
> > browsers), care to provide some info or link?
>
> Check out this post on my blog - "Testing JavaFX Applet Deployment"
>
> http://www.psynixis.com/blog/2009/09/04/testing-javafx-applet-deploym...
> On Nov 27, 12:53 pm, opinali <opin...@gmail.com> wrote:
>
> > On 27 nov, 09:23, Simon Brocklehurst <si...@psynixis.com> wrote:
> > I didn't notice any severe rendering issue in a long time, but maybe
> > it's just some limitation of my testing (tested apps, systems or
> > browsers), care to provide some info or link?
>
> Check out this post on my blog - "Testing JavaFX Applet Deployment"
>
>
> If you read through the comments on the post, you'll notice lots of
> people refer to painting artifacts when the web-page is scrolled (just
> search for the word "scroll"). To reproduce, simply scroll the page
> up and down fast so that the applet is moved on and off the screen.
> You'll likely see bits of the applet being painted above and below
> where it should be (lots of people see this on Mac OS X and on
> Windows). This same behavior can also be seen in quite a few of the
> demo applets on JavaFX.com.
I have actually read and replied to that blog, remember now. :-) 2,5
> If you read through the comments on the post, you'll notice lots of
> people refer to painting artifacts when the web-page is scrolled (just
> search for the word "scroll"). To reproduce, simply scroll the page
> up and down fast so that the applet is moved on and off the screen.
> You'll likely see bits of the applet being painted above and below
> where it should be (lots of people see this on Mac OS X and on
> Windows). This same behavior can also be seen in quite a few of the
> demo applets on JavaFX.com.
months ago I observed that I'd sometimes have a page cropping issue.
Didn't happen now, but I tested with newer stuff (JavaFX 1.2.1, JRE
6u18ea-b05, Firefox 3.6-beta4 & IE8, Vista SP2, NVidia Quadro FX1700,
latest drivers and patches of everything). Perfect behavior. No
scrolling artifact either now or then, in your applet or in a couple
javafx.com samples that I tested, even after frenetically scrolling
the page. Perhaps I'm just lucky, such bugs are often system-specific
(video drivers etc.).
A+
Osvaldo
Simon Brocklehurst
Nov 27, 2009, 1:51:14 PM11/27/09
to The Java Posse
On Nov 27, 5:14 pm, opinali <opin...@gmail.com> wrote:
> I have actually read and replied to that blog, remember now. :-) 2,5
> months ago I observed that I'd sometimes have a page cropping issue.
> Didn't happen now, but I tested with newer stuff (JavaFX 1.2.1, JRE
> 6u18ea-b05, Firefox 3.6-beta4 & IE8, Vista SP2, NVidia Quadro FX1700,
> latest drivers and patches of everything). Perfect behavior. No
> scrolling artifact either now or then, in your applet or in a couple
> javafx.com samples that I tested, even after frenetically scrolling
> the page. Perhaps I'm just lucky, such bugs are often system-specific
> (video drivers etc.).
>
scrolling artifacts appear to be gone. The page-cropping bug is still
there for me in Firefox tho'; and in Firefox a new issue appeared -
the mouse scroll wheel stops working when a new page with a JavaFX
applet is loaded.
Not sure if this is a good thing or not. If we have to wait 'til the
world upgrades to the latest (or even beta) versions of browsers to
get rid of these kind of bugs, then that's a *multi-year wait* before
people can choose JavaFX. Hopefully, the Java/JavaFX team will find a
way of making the technology work correctly in older versions of
browsers.
Josh McDonald
Nov 29, 2009, 8:27:23 PM11/29/09
to java...@googlegroups.com
Here's where I add my rants :) Firstly, I'll let you know my biases: I *really* want JavaFX to get better, and I want it to succeed. I've been hacking Flex full time for a couple of years now, but I'm from a Java background with Flash experience.
A few things would make JavaFX "crush it" as it were:
1) Open the scenegraph to other JVM languages. We need to be able to use the existing widgets in Java/Scala/Rhino/Whatever, and we need to be able to build first-class scene graph citizens using these other languages as well. FX Script by design is lacking too much to be the only language for a complex program. This is important because of #2:
2) Stop with the applet. Seriously. The browser plugin war is over, Adobe won. Years ago. And before Java 7 is ready and modularised, Google will have gotten V8 and (Canvas||a replacement for Canvas) up to par. It's just more important to them than Java 7 and FX are to Sun (which is not how it should be IMO), they have more money, and they've built a nest of hackers where even @dhanji isn't (always) the smartest guy in the room. The JVM is *awesome*, but Tamarin is good enough for the browser. Which leads me to:
3) Start competing with AIR and desktop WPF instead. There is currently no way to build cross-platform *useful* desktop apps that don't make people want to gouge out there eyes. AIR is currently nothing but a delivery platform for apps that should be run signed in a browser with elevated privilege. AIR 2 which has recently gone into beta is going to change that, but it's still a long way behind the JVM, and I have a feeling its release is being delayed with Builder 4, which last I checked is slipping. There's an incredible window of opportunity here for Snoracle.
4) Send trucks of money/coke/che guevara shirts to the guys at the EU, and git-er-done.
5) Work with people like me who know RIAs. Get them on-team advocates, help them build new *interesting* components, in multiple languages, and help them get demos and applications and blogs out there.
JavaFX can still be a contender, but the window is narrowing.
-Josh
--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."
Josh 'G-Funk' McDonald
- jo...@joshmcdonald.info
- http://twitter.com/sophistifunk
- http://flex.joshmcdonald.info/
A few things would make JavaFX "crush it" as it were:
1) Open the scenegraph to other JVM languages. We need to be able to use the existing widgets in Java/Scala/Rhino/Whatever, and we need to be able to build first-class scene graph citizens using these other languages as well. FX Script by design is lacking too much to be the only language for a complex program. This is important because of #2:
2) Stop with the applet. Seriously. The browser plugin war is over, Adobe won. Years ago. And before Java 7 is ready and modularised, Google will have gotten V8 and (Canvas||a replacement for Canvas) up to par. It's just more important to them than Java 7 and FX are to Sun (which is not how it should be IMO), they have more money, and they've built a nest of hackers where even @dhanji isn't (always) the smartest guy in the room. The JVM is *awesome*, but Tamarin is good enough for the browser. Which leads me to:
3) Start competing with AIR and desktop WPF instead. There is currently no way to build cross-platform *useful* desktop apps that don't make people want to gouge out there eyes. AIR is currently nothing but a delivery platform for apps that should be run signed in a browser with elevated privilege. AIR 2 which has recently gone into beta is going to change that, but it's still a long way behind the JVM, and I have a feeling its release is being delayed with Builder 4, which last I checked is slipping. There's an incredible window of opportunity here for Snoracle.
4) Send trucks of money/coke/che guevara shirts to the guys at the EU, and git-er-done.
5) Work with people like me who know RIAs. Get them on-team advocates, help them build new *interesting* components, in multiple languages, and help them get demos and applications and blogs out there.
JavaFX can still be a contender, but the window is narrowing.
-Josh
2009/11/28 Simon Brocklehurst <si...@psynixis.com>
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."
Josh 'G-Funk' McDonald
- jo...@joshmcdonald.info
- http://twitter.com/sophistifunk
- http://flex.joshmcdonald.info/
Steven Herod
Nov 29, 2009, 9:45:58 PM11/29/09
to The Java Posse
Well said Josh.
> > javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> > .
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/javaposse?hl=en.
>
> --
> "Therefore, send not to know For whom the bell tolls. It tolls for thee."
>
> Josh 'G-Funk' McDonald
> - j...@joshmcdonald.info
> >http://groups.google.com/group/javaposse?hl=en.
>
> --
> "Therefore, send not to know For whom the bell tolls. It tolls for thee."
>
> Josh 'G-Funk' McDonald
Simon Brocklehurst
Nov 30, 2009, 7:04:06 AM11/30/09
to The Java Posse
On Nov 30, 1:27 am, Josh McDonald <j...@joshmcdonald.info> wrote:
> 2) Stop with the applet. Seriously. The browser plugin war is over, Adobe
> won. Years ago. And before Java 7 is ready and modularised, Google will have
> gotten V8 and (Canvas||a replacement for Canvas) up to par. It's just more
> important to them than Java 7 and FX are to Sun (which is not how it should
> be IMO), they have more money, and they've built a nest of hackers where
> even @dhanji isn't (always) the smartest guy in the room. The JVM is
> *awesome*, but Tamarin is good enough for the browser.
already lost. Personally, I hope not - I think JavaScript is a poor
choice of language for building sophisticated browser-based
applications. *If* it is lost, though, the consequences are serious,
because it will restrict every non-browser RIA platform to a pretty
small niche. That's because close to 100% of people have already
decided they want 80% of the computer systems they access via a
desktop computer to run inside a browser,
Jess Holle
Nov 30, 2009, 7:15:08 AM11/30/09
to java...@googlegroups.com
Agreed.
It could well be that the sweet spot for JavaFX is outside the browser, but if the inside the browser angle is not solidly covered, then I think JavaFX will be relegated to a small niche which will shrink over time.
--
Jess Holle
It could well be that the sweet spot for JavaFX is outside the browser, but if the inside the browser angle is not solidly covered, then I think JavaFX will be relegated to a small niche which will shrink over time.
--
Jess Holle
Casper Bang
Nov 30, 2009, 7:56:23 AM11/30/09
to The Java Posse
People are no longer programming directly in JavaScript though, but
abstractions on top a la jQuery and GWT which shields the developer
from most of the ugliness. Google has proven time and again how they
perceive JavaScript as nothing less than a universal machine layer
opening the door for universal access (computers, phones, picture
frames etc.). I think Sun missed that opportunity when NetScape made
JavaScript the de-facto language over Java.
/Casper
abstractions on top a la jQuery and GWT which shields the developer
from most of the ugliness. Google has proven time and again how they
perceive JavaScript as nothing less than a universal machine layer
opening the door for universal access (computers, phones, picture
frames etc.). I think Sun missed that opportunity when NetScape made
JavaScript the de-facto language over Java.
/Casper
Mark Volkmann
Nov 30, 2009, 8:43:46 AM11/30/09
to java...@googlegroups.com
On Mon, Nov 30, 2009 at 6:04 AM, Simon Brocklehurst <si...@psynixis.com> wrote:
>
> I think JavaScript is a poor
> choice of language for building sophisticated browser-based
> applications.
I used to think that until recently. Two things changed my opinion.
>
> I think JavaScript is a poor
> choice of language for building sophisticated browser-based
> applications.
1) I read "JavaScript - The Good Parts" by Douglas Crockford
2) I learned about jQuery.
Now I feel like there is no reason to avoid building web apps using
just HTML, CSS, JavaScript and jQuery. You can easily make RESTful
calls to get data from a server. No web app framework is needed.
jQuery is really nice for building RIAs.
--
R. Mark Volkmann
Object Computing, Inc.
Mark Volkmann
Nov 30, 2009, 8:50:45 AM11/30/09
to java...@googlegroups.com
On Mon, Nov 30, 2009 at 6:56 AM, Casper Bang <caspe...@gmail.com> wrote:
> People are no longer programming directly in JavaScript though, but
> abstractions on top a la jQuery and GWT which shields the developer
> from most of the ugliness.
jQuery developers code directly in JavaScript, but don't code directly
> People are no longer programming directly in JavaScript though, but
> abstractions on top a la jQuery and GWT which shields the developer
> from most of the ugliness.
to the DOM API. I contend that if you stick to "The Good Parts",
JavaScript isn't ugly.
Simon Brocklehurst
Nov 30, 2009, 9:32:48 AM11/30/09
to The Java Posse
On Nov 30, 1:43 pm, Mark Volkmann <r.mark.volkm...@gmail.com> wrote:
> I used to think that until recently.
based approaches to developing web apps running in the browser (like
JQuery or GWT) are, in the end, the best available choices for
building web apps (compared to Flash/Flex, Silverlight, Java/JavaFX).
When I said it was a poor choice, what I meant was that the
development process is old-fashioned, clunky and error-prone (IMO).
That means it's hard to get really high-quality results when building
a complex application (from a development point of view) compared to
using some other technologies e.g. those based on the .NET or Java
platforms.
I believe there's plenty of room left for innovation when it comes to
technology platforms for creating browser-based apps. IMO, no-one has
a good solution yet.
Casper Bang
Nov 30, 2009, 9:36:57 AM11/30/09
to The Java Posse
Yeah true, but JavaScript is so powerful that you get the illusion
it's another language. I'd add "jQuery in Action" and "RESTful Web
Services" to you book recommendation - it makes programming web stuff
in Java fun again.
/Casper
On Nov 30, 2:50 pm, Mark Volkmann <r.mark.volkm...@gmail.com> wrote:
it's another language. I'd add "jQuery in Action" and "RESTful Web
Services" to you book recommendation - it makes programming web stuff
in Java fun again.
/Casper
On Nov 30, 2:50 pm, Mark Volkmann <r.mark.volkm...@gmail.com> wrote:
Mark Volkmann
Nov 30, 2009, 9:37:14 AM11/30/09
to java...@googlegroups.com
an automated deployment process. I set up mine so that every time I
deploy my web app it looks for JavaScript source files that have been
modified since the last deploy. It runs jslint on those and the deploy
fails if any issues are reported. That has saved me a lot of debugging
time. Still, as you say, there is room for improvement.
opinali
Nov 30, 2009, 1:31:06 PM11/30/09
to The Java Posse
Unfortunately, JavaScript (plus its DOM interface with the outside
world) is a pretty poor choice for such UVM role.
First, with its dynamic typing, prototype-based structure, it's one of
the hardest languages to optimize and even next-gen JITs like V8/TM/
Nitro will not compete with Java (even with HotSpot Client) any time
soon (or with Silverlight's CLR, for that matter). JS apps only look
fast when they are thin layers over non-JS services like DOM, WebGL,
canvas/video/audio support, etc. or when the network is the bottleneck
(gmail, maps, etc.) so the user accepts delays as something natural.
Any app that depends on a large amount of JS code, or contains
complex, CPU-bound JS algorithms, will be a fiasco for many years to
come. In the old times we'd just say "yeah whatever, let's just wait
the next couple Moore's Law doublings of CPU speed", but these are the
new times and CPUs are not getting faster in any significant speed, so
until somebody comes up with a magic parallelization framework,
language speed will matter a lot.
Second, JS/web apps still lacks very important features. While the
next round of progressive-rock-browsers will implement such things as
accelerated 3D, I'm still waiting for such simple delicacies as
support for custom right-button menus, drag&drop, clipboard
integration, etc. There's also the hard reality of MSIE lagging as
much as they can get away with, to support these latest enhancements,
because Microsofts agenda with Silverlight competes radically with the
pure-web RIA. Now MS is talking IE9 which should have a JIT-compiled
JS VM with decent performance, plus some HTML5 support. But this only
means that IE9, in late 2010 or 2011, will be as good as the state-of-
the-art of 2008 (at best). And many corps are still dragging their
feet with IE6; it's clear to me that pushing a plugin (that is
compatible with old IEs) is less hard than pushing the latest
browsers.
If Java applets/JAWS (with or without JavaFX) fail, I
world) is a pretty poor choice for such UVM role.
First, with its dynamic typing, prototype-based structure, it's one of
the hardest languages to optimize and even next-gen JITs like V8/TM/
Nitro will not compete with Java (even with HotSpot Client) any time
soon (or with Silverlight's CLR, for that matter). JS apps only look
fast when they are thin layers over non-JS services like DOM, WebGL,
canvas/video/audio support, etc. or when the network is the bottleneck
(gmail, maps, etc.) so the user accepts delays as something natural.
Any app that depends on a large amount of JS code, or contains
complex, CPU-bound JS algorithms, will be a fiasco for many years to
come. In the old times we'd just say "yeah whatever, let's just wait
the next couple Moore's Law doublings of CPU speed", but these are the
new times and CPUs are not getting faster in any significant speed, so
until somebody comes up with a magic parallelization framework,
language speed will matter a lot.
Second, JS/web apps still lacks very important features. While the
next round of progressive-rock-browsers will implement such things as
accelerated 3D, I'm still waiting for such simple delicacies as
support for custom right-button menus, drag&drop, clipboard
integration, etc. There's also the hard reality of MSIE lagging as
much as they can get away with, to support these latest enhancements,
because Microsofts agenda with Silverlight competes radically with the
pure-web RIA. Now MS is talking IE9 which should have a JIT-compiled
JS VM with decent performance, plus some HTML5 support. But this only
means that IE9, in late 2010 or 2011, will be as good as the state-of-
the-art of 2008 (at best). And many corps are still dragging their
feet with IE6; it's clear to me that pushing a plugin (that is
compatible with old IEs) is less hard than pushing the latest
browsers.
If Java applets/JAWS (with or without JavaFX) fail, I
opinali
Nov 30, 2009, 1:39:23 PM11/30/09
to The Java Posse
Sorry fro the broken post (ironically, something that NEVER happened
to me with a real mail client - I'm using Google Groups' web
client...)
If Java applets/JAWS (with or without JavaFX) fail, I'm afraid that
the winner will be either Flash or Silverlight, not the W3C-backed
web. It's probably right that many people would gladly move 80% of
their apps inside a browser. But the browser is not up to the task,
and I don't think it will be at least with the next batch of HTML5
gizmos. The window of opportunity is wide open for "external" RIA
technologies and will be for a few years still.
A+
Osvaldo
to me with a real mail client - I'm using Google Groups' web
client...)
If Java applets/JAWS (with or without JavaFX) fail, I'm afraid that
the winner will be either Flash or Silverlight, not the W3C-backed
web. It's probably right that many people would gladly move 80% of
their apps inside a browser. But the browser is not up to the task,
and I don't think it will be at least with the next batch of HTML5
gizmos. The window of opportunity is wide open for "external" RIA
technologies and will be for a few years still.
A+
Osvaldo
Mohamed Bana
Nov 30, 2009, 2:06:14 PM11/30/09
to java...@googlegroups.com
comments inline.
—Mohamed
On Mon, Nov 30, 2009 at 2:32 PM, Simon Brocklehurst <si...@psynixis.com> wrote:
Sorry, I don't think I was clear in my meaning. I think JavaScript-
On Nov 30, 1:43 pm, Mark Volkmann <r.mark.volkm...@gmail.com> wrote:
> I used to think that until recently.
based approaches to developing web apps running in the browser (like
JQuery or GWT) are, in the end, the best available choices for
building web apps (compared to Flash/Flex, Silverlight, Java/JavaFX).
How well can GWT handle a large data-set displayed in a spreadsheet like format? In this regard, Silverlight is exceptional. The 'DataGrid' is very good performance wise.
When I said it was a poor choice, what I meant was that the
development process is old-fashioned, clunky and error-prone (IMO).
That means it's hard to get really high-quality results when building
a complex application (from a development point of view) compared to
using some other technologies e.g. those based on the .NET or Java
platforms.
I believe there's plenty of room left for innovation when it comes to
technology platforms for creating browser-based apps. IMO, no-one has
a good solution yet.
If no one has a good solution, what would you say is the best?
Mark Volkmann
Nov 30, 2009, 2:57:13 PM11/30/09
to java...@googlegroups.com
On Mon, Nov 30, 2009 at 12:31 PM, opinali <opi...@gmail.com> wrote:
> Unfortunately, JavaScript (plus its DOM interface with the outside
> world) is a pretty poor choice for such UVM role.
Yeah, everybody complains about the DOM. I'm not suggesting coding to
> Unfortunately, JavaScript (plus its DOM interface with the outside
> world) is a pretty poor choice for such UVM role.
that though. You really have to experience a library like jQuery to
appreciate how much better it is than coding to the DOM.
> First, with its dynamic typing, prototype-based structure, it's one of
> the hardest languages to optimize and even next-gen JITs like V8/TM/
> Nitro will not compete with Java (even with HotSpot Client) any time
> soon (or with Silverlight's CLR, for that matter). JS apps only look
> fast when they are thin layers over non-JS services like DOM, WebGL,
> canvas/video/audio support, etc. or when the network is the bottleneck
> (gmail, maps, etc.) so the user accepts delays as something natural.
> Any app that depends on a large amount of JS code, or contains
> complex, CPU-bound JS algorithms, will be a fiasco for many years to
> come. In the old times we'd just say "yeah whatever, let's just wait
> the next couple Moore's Law doublings of CPU speed", but these are the
> new times and CPUs are not getting faster in any significant speed, so
> until somebody comes up with a magic parallelization framework,
> language speed will matter a lot.
All other code can be in the language of your choosing and run on the
server. The user interface code can easily access it with RESTful
requests.
> Second, JS/web apps still lacks very important features. While the
> next round of progressive-rock-browsers will implement such things as
> accelerated 3D, I'm still waiting for such simple delicacies as
> support for custom right-button menus, drag&drop, clipboard
> integration, etc. There's also the hard reality of MSIE lagging as
> much as they can get away with, to support these latest enhancements,
> because Microsofts agenda with Silverlight competes radically with the
> pure-web RIA. Now MS is talking IE9 which should have a JIT-compiled
> JS VM with decent performance, plus some HTML5 support. But this only
> means that IE9, in late 2010 or 2011, will be as good as the state-of-
> the-art of 2008 (at best). And many corps are still dragging their
> feet with IE6; it's clear to me that pushing a plugin (that is
> compatible with old IEs) is less hard than pushing the latest
> browsers.
just addressing developing web applications for the browsers we have
today. I know you can create impressive web interfaces today with Flex
and Silverlight. My point is that those aren't necessary for many web
UIs. jQuery can accomplish much of what they do.
> --
>
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
>
>
>
--
>
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
>
>
>
--
Simon Brocklehurst
Nov 30, 2009, 3:27:42 PM11/30/09
to The Java Posse
On Nov 30, 7:06 pm, Mohamed Bana <moha...@bana.org.uk> wrote:
> If no one has a good solution, what would you say is the best?
1.A robust, frictionless deployment mechanism. That is: the user
visits a web page; the app runs instantly. No installing anything. No
problems with the app not running or otherwise appearing to be broken.
2. Killer development tools that make it super-fast to develop high-
quality apps, and super-easy to maintain it
3. A programming language that isn't a pain in the ass
4. Not even an attempt at trying to lock people in to expensively
licensed server-side technologies
No-one offers all of the above, for all categories of browser app.
The answer to the "which is best" question depends on: what kind of
app you're building; who the users are; and what your budget is. If
point #1, above, is the most important to you, then you're going to
lean towards JavaScript or perhaps Flash. If points #2 and #3 are the
most important to you, then you might choose Silverlight or Java. If
point #4 is important, you might choose JavaScript or Java.
Dominic Mitchell
Dec 1, 2009, 5:46:46 AM12/1/09
to javaposse
On Mon, Nov 30, 2009 at 2:37 PM, Mark Volkmann <r.mark....@gmail.com> wrote:
Ah ... I can see that. One thing I recommend is making jslint part of
an automated deployment process. I set up mine so that every time I
deploy my web app it looks for JavaScript source files that have been
modified since the last deploy. It runs jslint on those and the deploy
fails if any issues are reported. That has saved me a lot of debugging
time. Still, as you say, there is room for improvement.
Plug, plug:
http://code.google.com/p/jslint4java/
It's just a small wrapper that lets you run jslint as part of an ant build, or from the command line. I've found it quite handy in past jobs.
-Dom
opinali
Dec 1, 2009, 7:01:14 AM12/1/09
to The Java Posse
On 30 nov, 17:57, Mark Volkmann <r.mark.volkm...@gmail.com> wrote:
HTML and will gladly adopt GWT, jQuery (I've used it briefly), JSF or
ANYTHING that shields me from the horror that is "web programming"). I
was talking about performance. Any "Universal VM" must contain
efficient runtime components - bytecode, core APIs, GC/threads/etc. -
so higher-level languages/toolkits can target it. The DOM is a very
heavyweight component. Laying sophisticated libraries like jQuery on
top of it, won't make it any faster. Even high-performance components
like canvas, video and WebGL (that are fast because their
implementation is mostly a native binding to accelerated codecs and
graphic pipelines) will suffer a lot if they must be driven by massive
amounts of DOM objects and/or JavaScript code.
> What I'm suggesting is coding only the user interface in JavaScript.
> All other code can be in the language of your choosing and run on the
> server. The user interface code can easily access it with RESTful
> requests.
This is fine for client-server like apps, I agree that this covers
most corporative apps.
> On Mon, Nov 30, 2009 at 12:31 PM, opinali <opin...@gmail.com> wrote:
> > Unfortunately, JavaScript (plus its DOM interface with the outside
> > world) is a pretty poor choice for such UVM role.
>
> Yeah, everybody complains about the DOM. I'm not suggesting coding to
> that though. You really have to experience a library like jQuery to
> appreciate how much better it is than coding to the DOM.
I was not talking about programming convenience (though I hate JS/DOM/
> > Unfortunately, JavaScript (plus its DOM interface with the outside
> > world) is a pretty poor choice for such UVM role.
>
> Yeah, everybody complains about the DOM. I'm not suggesting coding to
> that though. You really have to experience a library like jQuery to
> appreciate how much better it is than coding to the DOM.
HTML and will gladly adopt GWT, jQuery (I've used it briefly), JSF or
ANYTHING that shields me from the horror that is "web programming"). I
was talking about performance. Any "Universal VM" must contain
efficient runtime components - bytecode, core APIs, GC/threads/etc. -
so higher-level languages/toolkits can target it. The DOM is a very
heavyweight component. Laying sophisticated libraries like jQuery on
top of it, won't make it any faster. Even high-performance components
like canvas, video and WebGL (that are fast because their
implementation is mostly a native binding to accelerated codecs and
graphic pipelines) will suffer a lot if they must be driven by massive
amounts of DOM objects and/or JavaScript code.
> What I'm suggesting is coding only the user interface in JavaScript.
> All other code can be in the language of your choosing and run on the
> server. The user interface code can easily access it with RESTful
> requests.
most corporative apps.
Reply all
Reply to author
Forward
0 new messages