Thanks for the first great comment, Tucker. I knew you'd be the first to answer my question. A more detailed reponse later. :-)
On Thu, Dec 16, 2010 at 7:29 PM, P T Withington <[email protected]> wrote: > 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 > >
