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