On 2010-12-16, at 12:36, Raju Bitter wrote: > I'm looking for the 10 best reasons to use LZX instead of JavaScript > when building rich browser and mobile applications.
I can't give you a list, but thanks for starting this discussion. Hopefully others will chime in with their favorite OL feature. My personal favorite is the (still evolving) presentation type system, which I think will be a very important tool. > 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? The initial idea, to use standards where standards are good and powerful and to extend when the standards lacked, still applies IMO. The ascendancy of JSON over XML is a fine thing (just as XML over SOAP), and we have a path for that (through presentation types, as you have seen in my recent mail). I don't foresee the use of XML for declarative programming being supplanted by Javascript, unless someone can come up with something more clever than simply transcribing the XML to JSON. I believe OL is still alone in supporting constraints, mixins, and now presentation types, which are power tools that let the power user develop and evolve their applications rapidly and efficiently. These power tools have the potential to give you a jump on your competitors, if used correctly. > The results of this discussion will be summed up in a blog post on the > LZX language, which I plan to publish in January 2011, and will be > part of future presentations on OL as part of the KamiJS project. I'm > specifically interested in what the OL team thinks the language will > look like in 12-18 months from now. What are your visions for LZX, and > how are you planning to better promote the language? And what would > you have to say regarding > > - 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. > - 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. > - AS3 runtimes and debugging - getting rid of the dependency on the > SWF8 runtime to detect errors (the more Flash 10 /10.x APIs are used, > the less is the approach to test with SWF8 to get a better > understanding of what's wrong within your code valid - since the app > won't compile). That's especially true for any SWC libraries you > include. Not sure what you are asking here. We do plan to phase out swf8 support, because it seems no longer necessary. The compile-time error detection of swf10 seems more powerful to me than the run-time detection we shoe-horned into swf8. If there is something missing, I would be interested to hear about it. > But I'm not only interested in the OL teams opinion, but especially > interested in what OpenLaszlo adopters with at least 6 months in OL > coding experience think of the language. What do you like about LZX at > the moment, and what should be improved? > > Any input and comments are very welcome. > > Raju
