> I believe that within 2 years JavaScript will be much more advanced than 
> Flash/Flex.
> They will still have powerful tools for the creative people, web agencies, 
> designers, etc.
> Flash is very valuable, it's not a bad technology.

Reading between the lines I think you are saying that Adobe will not be
important as an application platform builder.
And it does seem likely if developers are given the same power within the
browser.

But can we trust that all browsers will work the same?

Back in the days when I used to do dhtml there were 2 platforms.
Netscape Navigator and Internet Explorer. And soon enough there was a
standard organisation standardizing the features between them. But the big
challange was that they never were compatible.
And from this fact the Ajax frameworks rose.

So the question I have is that will there be a future where browsers are
going to be compatible?
Or do the AJAX frameworks have still a future by being the middleman
tackling the differences?
One standard, one browser would be best for us developers (if it is not
controlled by an evil and greedy company).
But I can't see what has changed in the business world.

Maybe google has become so dominant that their browser engine will rule over
others.
Nah...it's not that big yet.
Apple and google might be initially friendly with each other but how about
in the future (knowing Apple's focus on proprietary technologies).

Summa summarum:
Currently laszlo's only differentiator from other AJAX frameworks is that it
supports also flash.
Is this good or will this make laszlo just too slow and difficult to
implement properly?
And what does this extra layer of abstraction do to performance?

And if dhtml and actionscript converge someday, then what use do we have for
laszlo?
Why not then just write directly on that platform?
Higher level api and convenience libraries might be one argument.
But if dhtml and actionscript converge then laszlo has all other ajax
frameworks as competitor.

Could somebody please give me a good reason to use laszlo!?! :-)

- rami

2010/1/26 Raju Bitter <[email protected]>

> On Tue, Jan 26, 2010 at 12:48 AM, Rami Ojares <[email protected]>
> wrote:
> > Raju, what do you need the API compatibility for?
> >
> >> With the increasing focus on Ajax/DHTML
> >
> > Focus by whom?
>
> If you look at some of the largest companies with activity in the RIA
> space - like Apple and Google - we can clearly see a trend towards
> powerful, desktop like apps being built based on open standards. Most
> apps are Ajax/JavaScript apps, with some impressive features, apps
> like GoogleApps, the mobile version of gmail for iPhone using HTML5
> features, mobile.me which is built using the Sproutcore framework,
> then the whole Chrome OS stuff.
>
> All of that is driven by an incredible innovation speed in the browser
> space, with desktop and mobile browsers - more powerful than ever:
> Hardware accelerated JS engines, advanced animation using CSS, offline
> functionality, local storage and all the new features. And in many
> application areas (mobile iPhone apps, mobile Android apps, Chrome
> apps, TV set-top-box apps) you can be sure that all your users have a
> modern browser and can use the powerful features within them. And
> that's one of the reasons that people can afford to use those
> innovative features in production, like the HTML5 stuff Google uses in
> the mobile Gmail app: http://mashable.com/2009/02/19/html5-gmail/
>
> OpenLaszlo is one of the few RIA frameworks with multiple runtimes,
> and the only one delivering an almost Flash like UI quality for
> JavaScript/DHTML. And OpenLaszlo can afford to adopt some new APIs
> since there's a Flash backup for older browsers. If you position the
> technology like that, you got a clear USP.
>
> >
> > Did I understand correctly, Raju, that you would like to see flash
> runtime
> > dropped?
> > Or did you mean that API's of laszlo need to converge with the W3C dhtml
> > APIs?
> No, but take an example: http://jira.openlaszlo.org/jira/browse/LPP-8458
> Drag and drop from desktop into the browser. If we implement that for
> DHTML, shouldn't that work for the SWF runtime as well? What if we
> have features like that in OpenLaszlo, and they only work for one
> runtime. That wouldn't be good!
>
> Laszlo and the OpenLaszlo team will do what they need to do to be
> successful as a company. As an external person I can't and don't want
> to tell them how to lead the OpenLaszlo project. But if I start
> working on features, I want to have an idea of how they best should be
> implemented - based on what's technically possible.
>
> One of the technical problems I see is the fact that certain new APIs
> are accessible directly out of JavaScript, but not out of LZX. I don't
> want to do any extra work to encapsulate any call to browser APIs by
> using lz.Browser.callJS() or similar constructs. It should be easier
> to use standard JavaScript API calls inside the SWF runtime for
> OpenLaszlo.
>
> >> Call me a nut, but I have some vain hope that swfN and HTMLn will
> >> eventually converge and we won't > have to waste engineering cycles
> making
> >> them look the same.
> >
> > I hope this would come true. It would be good for the business,
> developers,
> > everybody.
> > But, but, but ... I think that the powers that be, have decided that
> Adobe
> > can not be given advantage.
> > That's what we saw happening with ECMAScript 4th edition crash landing.
> >
> > See, there is a risk that Flash would become the de facto Web application
> > platform.
> > Browser would be just a container for flash platform (and practically
> > everybody would have it ... hey 97% already do).
> > Without a doubt Flash is much more advanced than dhtml. You can do games
> > with Flash.
> > Surely that means that you can do business applications with it (although
> > the convenience libraries might be missing).
>
> I believe that within 2 years JavaScript will be much more advanced
> than Flash/Flex. There are way more engineers working JavaScript
> engines than there are working on the Flash Player. Adobe is not that
> big, and they had to lay off a considerable number of people in the
> past 3 years. With Google, Apple, Nokia, Opera, and many other
> companies working on JavaScript technology, there's no way that Adobe
> is going to win the race. They will still have powerful tools for the
> creative people, web agencies, designers, etc.
>
> > The issue is, on which future does one bet?
> >
> > If Microsoft et al. win the game the penetration of flash drops before
> the
> > developing world have time to pick up on flash.
> > In the other event people start writing their applications on Flash and
> > Adobe wins.
> > This of course requires open sourcing flash (which Adobe is desparately
> > trying to do with great reluctance).
> > Because it means cutting off your cash cows in the risky hope of having a
> > bigger future.
>
> Silverlight is successful in some areas, but as a web technology for
> everyone it's not a good technology. Friends of mine build a whole
> complex video composing and sharing app with Silverlight and had to
> rebuilt it with Flex, since 50% of the customers had problems
> installing Silverlight on their Window machines. It's still very
> successful in the .NET community for building powerful intranet apps.
>
> > This brings me to the question, what is the role of laszlo in all of
> this?
> > Is it the platform for those who do not have the courage to bet on a
> horse?
> >
> > Now comes today's hard fact:
> > You always bet on a horse, whether you think so or not.
> >
> > To me it seems that the starting point of laszlo was:
> > "Let's do a way better Ajax platform by using flash instead of dhtml."
> >
> > Maybe because of Adobe's setback in getting the approval from the
> > establishment Laszlo has (wisely & cowardly I might add)
> > also started to support dhtml and reinvented it's value proposition:
> > "Can't choose between dhtml and flash? Use Laszlo."
> >
> > Now the first value proposition became harder to realize, namely:
> > "Want to develop more 'cinematic' webapps than your partner? Choose
> Laszlo."
> > Because now you had to make it work on dhtml too and that kind of defeats
> > the initial purpose.
> >
> > I think Raju is questioning the second value proposition.
> > He says that with the advent of dhtml 5 it also becomes dupious.
>
> Not exactly: Flash is very valuable, it's not a bad technology. Now
> that we can do very similar things in JavaScript compared to what's
> possible in Flash OpenLaszlo makes even more sense. As an engineer and
> software developer, I want to be able to use one good language to
> build both Flash multimedia and video apps as well as Ajax/JavaScript
> apps without having to use a different language. Other framework like
> Cappuccino Web Framework use a similar approach of coding in a custom
> language (Objective-J) and compiling/converting that code into
> JavaScript. Look a 280slides, it's one of the most impressive RIAs I
> knows - and doesn't feel like an Ajax app! http://280slides.com/
>
> For OpenLaszlo, there are 2 things which I'd like to see happening:
> 1) Redesign of the components to use the cool new features HTML5/CSS3
> features (CSS style for gradient, drop shadow, line style - getting
> rid of the image assets based on PNG/SWF); that would enable us to
> scale components as well (something you can do in Flex). Look at the
> JQuery theme gallery, we can do that for both Flash and DHTML with
> OpenLaszlo, and skinning of apps would be so much easier!
> http://jqueryui.com/themeroller/#themeGallery
>
> 2) Have a way to use normal JavaScript API calls inside an OpenLaszlo
> app compiled into SWF. I don't like the syntax for making calls out of
> LZX into JavaScript, it's not comfortable to do that
>
> > So what would be laszlo's new value proposition?
> >
> > If I could choose I would say let's go back to flash only and bet on that
> > horse.
> > But then again I am a compulsive loser.
> > I am fooled by constant delusions of a better future.
> > And that's why I always end up betting on the losing horse.
> >
> > I would have developed everything with Java but Java could not succeed
> with
> > the penetration issue.
> > Hey maybe I should develop with java....@#* penetration I am doing
> business
> > apps here.
> > At this point comes the enhancement of the 2nd value proposition:
> > "Can't choose between dhtml, flash, java fx or silverlight? Have a
> laszlo."
> >
> > But most likely this will choke on it's own pomposity.
> > Can be realized only on paper.
> >
> > I think that the open source community should embrace flash platform if
> it
> > were to be completely open sourced.
> > If Adobe does not do it flash is dead.
> > But then you have these nerds in the linux community who are hard headed
> > fundamentalist (inflexible and stupid).
> > Saying "my way or high way" secretly crying out the pain of being sent
> > packing on the highway...
> >
> > With the triumph of one technology over a committee monster, reason and
> > science would have a victory over bureaucracy.
> > And that is always good for the developers.
> >
> > Remember SQL, brothers in arms?
> > Now there you have a committee monster.
> >
> > Oh, but I got lost in the maze of my own thoughts.
> >
> > Greetings from Amsterdam,
> > Rami
> >
> > 25.1.2010 21:52, P T Withington kirjoitti:
> >
> > Call me a nut, but I have some vain hope that swfN and HTMLn will
> eventually
> > converge and we won't have to waste engineering cycles making them look
> the
> > same.  Instead we can spend our engineering cycles raising the level of
> > abstraction in OpenLaszlo making it a more powerful language than the
> > underlying runtimes so that you can solve complex problems without
> worrying
> > about gritty details.
> >
> >
> > In the short term, we need to strike a balance between exposing only the
> > lowest common denominator features and locking applications into only one
> > platform.  I think we have done a fairly good job of this so far, mostly
> > because we have been driven by what the OL programmer needs, not by just
> > implementing the next cool thing and exposing every knob and dial at the
> OL
> > API.
> >
> >
> > We do try very hard to follow standards where possible.  But if forced to
> > make a choice between a /de facto/ (proprietary) standard like SWF and a
> > draft (but open) standard like HTML5, I would choose the open standard.
> >
> >
> > That said, we are not against building on standards where necessary, to
> make
> > OpenLaszlo a more powerful tool.  We adopted (and extended) the as3 class
> > extensions to Javascript before they were accepted into Javascript.  Now
> the
> > Javascript standards bodies are starting to revisit the topic of classes
> in
> > Javascript.  We may find ourselves out on a limb, but we should be able
> to
> > adapt -- we've done it before!
> >
> >
> > On 2010-01-25, at 15:20, Raju Bitter wrote:
> >
> > With the increasing focus on Ajax/DHTML - going in hand with nice new
> HTML5
> > features - the evolving W3C standards are going to have a strong
> influence
> > on the LZX APIs in future versions of OpenLaszlo. Until now SWFx and
> AS2/3
> > have been the runtime providing many more features for OpenLaszlo than
> the
> > browsers' JS engines. That's changing right now, and the question is: How
> is
> > OpenLaszlo going to incorporate the HTML5 APIs into LZX? Take Flash
> > SharedObject
> > (
> https://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/net/SharedObject.html
> )
> > and W3C WebStorage (http://www.w3.org/TR/webstorage/) as an example: How
> are
> > we going to create APIs providing those features across runtimes?
> >
> >
> > If there similar functionalities in SWFx and HTML5/W3C standards, are we
> > going to create a common API for - using the example of local storage -
> > key-value pairs in DHTML using WebStorage, and duplicating that behavior
> in
> > SWFx using SharedObject functionality? Or is the focus going to be on
> open
> > standard based features which will be accessible from within SWFs through
> > SWF->JavaScript calls?
> >
> >
> > A powerful feature would be the capability to define the runtime
> environment
> > for a method/script as an attribute to the method or script. Imagine code
> > like this inside a SWFx runtime app:
> >
> >  <method name="storeNote" runtime="javascript" args="id,title,body">
> >
> >    // Some JavaScript code using the WebStorage API to store a note
> >    // This method would be turned into a JavaScript function inside the
> > browser
> >    //  Any call to this method would be passed from the SWF app to the JS
> > function
> >
> >  </method>
> >
> > If the same app is compiled as DHTML, passing of method calls would not
> be
> > necessary. I'd be interested in hearing what you think, or what your
> ideas
> > are for OL apps using many of the new JS/HTML5/W3C features.
> >
> >
> > - Raju
> >
>

Reply via email to