Tucker, it has been some time but I still want to respond to your mail. My response is not only discussing the LZX language, but - again - the general setup of OpenLaszlo as an open source project. Especially John Resig's blog post "How could YUI3 improve its image compared to jQuery, MooTools, etc.?" is very interesting, and should give the Laszlo management some food for thinking. But let's start with LZX:
1) Presentation type system >> Why are we coding in LZX? What was the initial idea behind creating >> the language, and is the initial idea of LZX (XML + JS + XPath ...) >> still valid in times of a web world which seems to be more and more >> influenced by JavaScript? What does the general of adoption of JSON >> instead of XML in web services mean for LZX? > My personal favorite is the (still evolving) presentation type system, > which I think will be a very important tool. I agree, but you have to show people what's so powerful about it. If no-one knows about it, people don't care. 2) Coding in LZX/JS, driving adoption of OpenLaszlo and LZX/LZS >> - official support for coding classes in JS (which means: the next >> minor update of OL will not break my existing class code) > Not sure what you are asking here. We support class-based development > in both LZX and LZS. The latter is an extension of JS based on the proposed > ES4 standard (which never came to fruition). We continue to track ES > standards > and have every intention of supporting our class-based development going > forward. > We hope that ES6 will include the "traits" proposal, because we believe that > will > allow a much more efficient implementation of our classes in ES-based > platforms. Google for "openlaszlo+lzs": Do you find any page teaching you LZS, and how it can be used in the context of LZX - to script classes, mixins, etc? Check the developer guide chapter on scriptiong: http://www.openlaszlo.org/lps4.9/docs/developers/tutorials/scripting-tutorial.html Another quote: "Lack of documentation. No matter how wonderful your library is and how intelligent its design, if you're the only one who understands it, it doesn't do any good. Documentation means not just auto generated API references, but also annotated examples and in-depth tutorials. You need all three to make sure your library can be easily adopted." http://www.codinghorror.com/blog/2007/01/if-it-isnt-documented-it-doesnt-exist.html A few good devs know the power of LZX with OpenLaszlo 4.2+, and how it can help you build some of the most advanced browser based apps. But more people need to know that. 3) LZX language changes >> - generally less changes in LZX! There are so many changes to the >> language in the past 3 years, that it makes the LZX the most >> "unstable" language to use in all of my IT projects. The fact that the >> Laszlo has full control over the LZX language makes the language a >> target to syntax changes directly related to the next release of >> Laszlo Webtop, which is not good for the language in general, I >> believe. > > This is a choice you have to make. You can pick a language that will never > change, you could develop in Objective-C or Java, or you can pick a language > that is evolving to be more powerful. You always have the choice also of > sticking with an earlier revision, just as many people are still programming > in PHP4... > > The advantage that OL has is that it is a small community, not bound by a > standards > committee, so can evolve and adapt to be the best development language you > have > access to. > > Nevertheless, we do not make changes to the language willy-nilly, and we do > not make > changes just to support Laszlo. We always request community input when > making changes > to the language. When we have made changes, we have maintained > back-compatibility > whenever practical. When we make breaking changes, they have almost always > been to > repair warts in the language that were the source of confusion and bugs. > > It _is_ true that at the beginning the language was built to support Laszlo. > Because the language was designed "as it went along", there _are_ places > where the design is less than ideal. I don't feel anyone is well-served by > preserving design flaws. I don't want to see the language become stagnant. > "The more successful the language is, the greater the cost of changing it. You have greater re-education costs and you have the potential costs of disruption which, as you become bigger, become unacceptable. When you're really successful, you need to be extremely cautious in any changes that you make. Whereas if you haven't made it yet, you have a lot more freedom in changing it around." That's not me, but Douglas Crockford (in "Coders at Work"). With the size of the community around 2006/2007, changes were painful (the feedback from people trying to migrate 3.x apps to 4.0 wasn't very positive, as I remember). Now the number of people/companies using OpenLaszlo is so low, that's it's not maybe not that painful. It's a fantastic feature to be able to upgrade old OpenLaszlo apps to the latest version (since 2003). But it puts a burden on the language as well. I believe that Laszlo has to revise the process of introducing changes to the language, to have a slightly more formal process where partners and the community can have a saying in what will be implemented in the future. More on that under 5) OpenLaszlo's image... 4) OpenLaszlo & code generation -> the power of code generation, but the need for better tools (IDE, debugger) Code generation is powerful, but adds a lot complexity to a platform. As an OpenLaszlo developer you are confronted with these problems, and they tend to be a lot more complex than what you have with pure JavaScript or ActionScript coding. Again, quoting Crockford: "As far as GWT goes, and other transforming things, I'm really pragmatic. This environment is so hard to work in - if you can find something that works, then great. I'm fearful of using it myself because I worry about the abstraction leakage. If there's a problem in your Java code or in GWT or in what it produces on the other side, you may or may not have a place to stand to deal with it. Particularly if you took the approach that you can afford to be completely ignorant about JavaScript because the language is hidden from you. Then you're going to be in a world of hurt if anything goes wrong." I love the code generation feature, but I've experienced the complexity as well. That has happened to me and many other with the introduction of the SWF9/SWF10 runtime. The DHTML runtime is less problematic (good JavaScript debuggers are available now), but you might have to deal with the LFC classes or the generated JavaScript code of your application. If I run into an DHTML LFC problem, I used a formatted version of the JavaScript LFC code to make debugging easier, in combination with a debugger like Firebug. ActionScript3 is a whole different thing. Using Flash Builder (or none-Adobe IDEs), the LFC SWC and the LFC10 AS3 classes, you can debug your apps if you run into ActionScript problems, but OpenLaszlo as a platform doesn't give us the necessary tools (like in the case of GWT) to step through source code and inspect the generated AS3 code. Check this section from the GWT Docs: http://code.google.com/webtoolkit/doc/1.6/DevGuideCompilingAndDebugging.html#DevGuideHostedMode "Anytime you edit, run, and debug applications from a Java integrated development environment (IDE), you are working in hosted mode. When an application is running in hosted mode, the Java Virtual Machine (JVM) is actually executing the application code as compiled Java bytecode, using GWT plumbing to automate an embedded browser window. This means that the debugging facilities of your IDE are available to debug both your client-side GWT code and any server-side Java code as well. By remaining in this traditional "code-test-debug" cycle, hosted mode is by far the most productive way to develop your application quickly." For OpenLaszlo, we currently have only the ability to step through the generated code spit out by the OpenLaszlo compiler. The joy of using the LZX language comes at the price of increased complexity, which will be beyond what most standard web developer will be willing to handle (e.g. debugging ActionScript code, they don't even know!). Here is where we need better tool support, I don't believe that enough people at Laszlo understand how much of the value of the main platform is reduced by not having state-of-the-art tool support for OpenLaszlo development. Having an IDE with step-through-debugger (at least for HTML5), inclusion of the LFC classes (read-only) into LZX projects (as you had in the IDE Laszlo had been working on in 2008), would make life for LZX developers (especially larger teams and novices) A LOT easier. 5) OpenLaszlo's image... Besides the LZX programming language: How could OpenLaszlo improve its image compared to jQuery, MooTools, etc. Well, first read John Resig post on the YUI3. Some of what's said here is true for OpenLaszlo as well: http://www.quora.com/How-could-YUI3-improve-its-image-compared-to-jQuery-MooTools-etc/answer/John-Resig?srid=5i2 "The YUI project has always had the advantage of having a large number of paid, full-time, contributors to the project. As far as I can tell it's always had more paid, full-time, contributors than any other JavaScript library. This is awesome and it's benefited the library as a whole. However it can also be crippling. Yahoo completely controls the direction and destiny of YUI. This should not be the case - YUI should be split off from Yahoo and become its own, separate, Open Source project." Same is true for OpenLaszlo: Few open source RIA/Ajax platforms have received as much funding in the past years as OpenLaszlo did. But with the same problem as YUI, totally dependent on the company funding the development: Laszlo "The success of jQuery has largely been due to the feedback and help that we've gotten from the community that we've fostered. Right now the code base and contribution model that's speak to that." Since 2007, the message sent out by Laszlo to the community sounded a lot like: "We don't care about you, and we don't need you!" I could have used some other words here, but I'll try to be nice. At the same time, I've heard enough complaints that adopters of OpenLaszlo (in the enterprise world) don't contribute back to the project. Well, maybe the next quote from John Resig will explain that: "Now the problem thus far is that much of the community surrounding YUI has been manufactured - or heavily controlled by Yahoo. This should not be the case - the community should be run by the community itself. If Yahoo stopped promoting YUI then community members should be willing and capable of stepping up to help. If they're not then there are larger problems at play - well beyond things that can be fixed through adjustments in the structure of the project. Setting up a non-profit foundation for YUI that holds 100% of the copyright and assets for YUI would be a very important step towards building goodwill with the larger development community (especially if non-Yahoo contributors are invited in and made to help run the project)." Exactly what I've been telling the OpenLaszlo team and Laszlo for the past year. I believe that LZX is a powerful and fun language, and there is still the need for a technology like OpenLaszlo. The class system (although I really dislike the deep class hierarchy for the current component set), mixins, cross-runtime debugger integrated into your app, animation system, new CSS styling features, HTML5 support - that's all great stuff. But I'd still be interested in hearing from other community members. - Raju
