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 >
