What is OpenLaszlo, and What is it Good For? 196
SimHacker writes to share an article he wrote recently that tries to answer the question; What is OpenLaszlo, and What is it Good For? From the article: "OpenLaszlo is an open source platform for developing user friendly web based applications, which work identically across all popular browsers and platforms (Windows, Mac, Linux, IE, Firefox, Safari, etc). It's ideal for presenting and editing raw XML data generated by PHP and other web services."
Security? (Score:3, Insightful)
The solution is for the OpenLaszlo Server or PHP to act as a proxy for other servers.
Isn't there a reason for that? I would like to see something that specifically addresses the security issues here...
Dumbing Down? (Score:2, Insightful)
Re:HUH! Yeah, absolutely nothing, listen to me (Score:5, Insightful)
> The results (at least, with me as the creator) support every browser that at least basically conforms to the W3 standards.
What do you want, a gold star? Why is this site full of programmers who discount new tools to add to the toolbox out of hand? Lazlo is pretty neat. I was a distributed web application programmer for a long time (FreeBSD, CORBA), now I write games for consoles like the PS2
Re: I don't mean to troll... (Score:4, Insightful)
Dumbing down IT programming (and IT in general) has been a huge trend throughout the industry for years. I remember teaching Fortune 100 financial analysts Visual Basic and how to hook up to an Oracle stock database we built and they were on cloud nine. Later our secretaries setup and maintained our department's homepage - it was great and really represented a milestone in our company as well as a symbolic milestone within IT.
The future of IT is all about dumbing down so technology just becomes a part of everyday life - not some uber-geeky medium that takes years to master. Letting 'normal' folks develop and support websites moves content from an IT shop to the business folks where it belongs!
Re:I don't mean to troll... (Score:5, Insightful)
All of these frameworks and libraries and doohickies come about for a simple reason: web application programming is too complicated. Given the relatively simple functionality being designed, coding an (even non-AJAX) webapp is a pain in the ass involving a mostly stateless system running 4 or 5 languages. The techniques for getting around this problem are relatively cookie cutter, and we really should no more be coding them by hand than we should be rolling our own printf every time we write a terminal utility.
There's more creativity and action in interactive online software than ever before, and it's nothing but a good thing.
Re:OpenLaszlo's potential goes beyond the web (Score:3, Insightful)
Other then that the same idea though. If you don't want to tell some of your customers to go away because they chose a different browser or a different operating system then you then you should use a technology that is supported by everybody.
Re:Dumbing Down? (Score:4, Insightful)
I'm the guy that uses vi because I could never guess how to make notepad do the simplest things one could imagine. Like indenting a function, showing code with syntax highlight or moving to the start of the next block.
Those things that every programmer does all the time and are so simple in vi and so impossible to do in notepad.
Re:From a year long coder in Laszlo (Score:5, Insightful)
Laszlo's code is not tied completely to an actual final renderpath... ie. while currently your only option is flash, as can be seen on their homepage, they have a working DHTML output that works as well... and the idea is that the code you write is independant of what output it finally has.
We code in Laszlo's mixture of XML and Javascript, and it compiles that to Flash for rendering. The final output may be in a browser, may be on a phone, or whatever.
- If you're writing to the API, how tied to it are you? With a rederkit, you can quickly make changes from a web-browser to a PDA, with the components taking care of the display issues. Is display migration an issue?
OK, so we're writing our own 'renderkit' if you will... we're using a modification of the Visual Proxy methodology [javaworld.com] and as such our final display objects can be changed and modified based on what it's rendering to. But we do use a number of the inbuilt Laszlo visual components (windows, buttons, sliders and the like)... but as they render in flash, anything you can run flash on, they'll run on.
- How is performance? I've always found the examples on OpenLazlo to be slow, limitted, and not seem to be very useful in the real world.
Performance is always something that we battle with, but we're trying to manipulate hundreds of linked visual objects onscreen at one time, with many calculations running in the background. You have to be tricky here and there, but you can do some amazing things. Basically, the limitations are not really a result of Laszlo as such, but the fact that you're running an app within a web browser, and you always have to be conscious of that. The more you use it though, the more you learn the tricks to get a great user experience... I would hate to be trying to do this in DHTML.
- How much time have you spend on the UI versus other techniques (e.g. DHTML/AJAX)? If longer with Lazlo, do your customers see your UI as value-added? Does it reduce your time from working on the core business-logic?
(First up... this is AJAX, very much so it's Asynchronous Javascript and XML)
We spend a fair amount of time on the UI, but only because the main thrust of our app is presenting a whole lot of data in a visual way that the users can interact with in different ways to any other applications in this space... so it's a large portion of the appeal of this app. That it's targetted at the Marketing teams of companies means that it should be easy to use and appealing to work with, hence the flash interface.
We have coded other PHP/Javascript/DB applications for clients (we have one being finished up at present), and while they're nice to work with etc. And do take less time to initially code they have a number of drawbacks:
* Maintenance is harder as writing directly for HTML output means trying to be cross-browser friendly, which results in solutions for each of the major browsers. Flash means it just works the same, full stop.
* It looks the same. While you can do some pretty great things with DHTML etc. It's all still pretty web browser looking, you're tied to that due to limitations of what you can do, and performance issues if you stray too far from the simple. Flash allows you to have nice transitions, animation of key things, fluid interface interactions etc. Plus it's can be very different visually if you so wish.
* As for the time we can spend on Business Logic vs Interface. As in this space we are coding in an OO language, and can create nice class seperation and encapsulation, we can completely split off our business logic from our presentation code. This makes ongoing maintenance of either side of that equation
Re:I don't mean to troll... (Score:3, Insightful)
Right. So let's pile on another language to solve this problem. It would be really cool, hip, and exciting, and will be the grand mother of all abstractions, solving all our problems by providing a consistent, smooth interface into all sorts of technologies, ensuring that:
1) Debugging a language change from version x.4.1 to x.4.2 is damned near impossible,
2) Doing any kind of performance tuning is laughable,
3) Forces you to write things in such an abstract way that you can't take full advantages of the tools you do have available,
4) Sounds "enterprisey".
As a language, it will take other languages (like flash, dhtml, xml, sql, asm) and compile them. It will be glorious! (as soon as all the bugs are worked out)
I say we should give this new meta-meta-meta language the name "Laszlo"!
Re:Nope (Score:3, Insightful)
Kid, you are completely missing the point. Go back and read the fucking article [donhopkins.com]. OpenLaszlo is a high level XML/JavaScript based language that COMPILES into SWF, and now also COMPILES into DHTML/JavaScript. It's INDEPENDENT of Flash, because it targets other runtimes, including browsers WITHOUT the Flash plug-in.
Your misunderstanding is like complaining that C++ locks you into 68000 machine language, because the first version of CGG initially targeted 68k. C++ is a (moderately) high level language that can be compiled to many different platforms. GCC in no way dependent on the 68000 processor, and it doesn't directly expose any 68000 specific features, so code you write in C++ can compile to any processor that the compiler supports. Do you see the analogy?
To take the analogy a bit further, Cygnus made their money by supporting GCC and porting it to other platforms like the Sony Playstation, in many cases paid for by the developers of the platforms themselves. Laszlo Systems uses a similar open source model, developing OpenLaszlo applications like Laszlo Mail for big corporate customers like Earthlink, and enhancing OpenLaszlo to support popular platforms like DHTML and the latest version of Flash.
On the other hand, FLEX is like a proprietary version of GCC that only compiles code written in a non-portable platform-specific language that only runs on one vendor's processor, and the code you write is by design NOT portable to any other platform, and you're NOT allowed to look at or modify the compiler source code, NOR modify it to support other platforms. And that's a lot less useful than an open source platform independent language like OpenLaszlo. FLEX is a textbook example of vendor lock-in [wikipedia.org], because it's purposefully design so it doesn't support any other platform than Flash.
Adobe has a long track record of using vendor lock-in to tie customers into their products, and then quietly dropping their support for products without warning developers that they're about to have the rug pulled out from under them. Case in point: SVG. The SVG generated by Adobe's tools only works in Adobe's SVG viewer, and do you really think SVG has a future at Adobe, now that they've bought Macromedia and moved onto Flash? Adobe was the main company propping up SVG, just because they were fighting against Macromedia Flash, and that's over now. The fat lady has sung, and SVG is dead.
-Don