webOS Nation Forums
> webOS apps and software
> webOS development
>
This architecture looks like hack
1
2 3 4 5 6
...
Last
I think Palm really shoot themselves in the foot with this whole approach...
First the choice of JavaScript. Man, what was going through their mind there? Coding complex apps in JavaScript is royal PITA. If you ever coded something complex in JavaScript you know what I am talking about. If they've chosen Ruby or Python I could understand, and I bet people would love that much more and be more productive... And faster, phone is slow because it runs in browser and on JavaScript.
Then, they send us, developers, back to freaking 1990's so we have to code in Notepads and other plain text editors all without syntax checking, auto-complete and debugging. Serious time waster...
Next you have debug your app in the simulator for anything serious. It it appears that this is here to stay for some time according to Rough Cuts book. WOW, talk about pain.
I really looked forward to trying to develop something on Pre, but man this thing is just badly architected. If you study the code for internal apps you'll understand. Everything based on JavaScript and browser, you can see un-elegance of the whole solution...
JS is just ugly...
So with this SDK there are no serious games you can develop with it, you are stuck with ancient tools and unproductive process.
If you had time to look into the internals and how internal apps are developed what do you think?
Member:
johncc
at: 08:01 PM 06/28/2009
Are you talking about the leaked SDK package or that distributed by Palm?
Member:
mosdl
at: 08:34 PM 06/28/2009
I develop large
JS apps and you can easily write good code if you follow basic conventions. I've seen plenty of bad python code.
Debugging seems to be included (not working it seems) in the leaked sdk - firefox and webkit have built in
js debuggers, and the sdk is reusing the webkit one.
There are plenty of editors that can do auto-completion in javascript (eclipse for example) and syntax validation.
Plus that comment about developing in the "simulator" - why wouldn't you want to develop in a safe sandbox that can easily be restarted?
Member:
ADGrant
at: 08:41 PM 06/28/2009
Originally Posted by devexpert:
I really looked forward to trying to develop something on Pre, but man this thing is just badly architected. If you study the code for internal apps you'll understand. Everything based on JavaScript and browser, you can see un-elegance of the whole solution... JS is just ugly...
...
If you had time to look into the internals and how internal apps are developed what do you think?
I have to agree that Javascript is ugly and the architecture for Pre apps is a bit of a hack. They did it this way because it was cheap and easy, most of the underpinnings are open source.
I wish instead they had taken Android and added their new UI and Apps.
Originally Posted by mosdl:
I develop large JS apps and you can easily write good code if you follow basic conventions. I've seen plenty of bad python code.
Yeah but Ruby or Python would've been much better choice. JavaScript is simply not designed for hard-core development.
Originally Posted by mosdl:
Debugging seems to be included (not working it seems) in the leaked sdk - firefox and webkit have built in js debuggers, and the sdk is reusing the webkit one.
That applies ONLY if you do not use WebOS core stuff. But what are the apps that would NOT use it?
Originally Posted by mosdl:
There are plenty of editors that can do auto-completion in javascript (eclipse for example) and syntax validation.
I'd love to see that working nice with this SDK.
Originally Posted by mosdl:
Plus that comment about developing in the "simulator" - why wouldn't you want to develop in a safe sandbox that can easily be restarted?
Not developing,
debugging. If you use anything from core stuff you must debug in simulator. That is royal pain.
Here is tidbit from Rough Cuts:
Originally Posted by RoughCuts:
Most web applications can simply be loaded into a browser to run and debug, and webOS
apps can also be tested and debugged that way, too. However, you'll run into difficulty if
your application is using Mojo widgets or webOS services. And it's difficult to really test
your application without seeing it working within the webOS System UI and other
applications.
So you'll want to use the webOS Emulator with integrated JavaScript debugger and DOM
inspector. Unlike the other Palm Development Tools, the emulator is a full native
application on every platform and will be found in the Applications directory on MacOS
X and Linux or in the Programs directory on Windows XP/Vista.
How can really all this compete against say iPhone or even Android or BlackBerry? As platform it simply can't in my humble opinion. Time will tell.
Member:
bruba
at: 09:22 PM 06/28/2009
I think the SDK we have now is kinda targeted at web developers. The people who use notepad to write code and debug by checking the page in a browser.
They might've made the choice because the webdev community is enormous and they thought the hardcore could easily code in a less complex language.
Downside is, the apps you create with CSS,
JS, etc. are less dynamic because of static nature of web pages.
So the SDK is good for coding simple weblike apps, but bad for hardcore stuff like games.
A pretty good fit for a "web" OS, I think. Most people live on the web nowadays and don't use a lot of apps besides their browser. Most things people use on the web can be recreated in webOS. Social, multimedia, news, e-mail, etc.
But there will be people like you who want to go deeper and create something more complex. I'm not sure Palm will satisfy this need and how. They do seem to be working on some
graphics APIs.
Homebrew Developer:
GreenHex
at: 10:32 PM 06/28/2009
I thought I was the only person who was uncomfortable with the Javascript thing.
The whole architecture is aimed at de-mystifying and opening programming to the masses. Especially since most of the applications these days have to do with IM or "social" networking. The other major category of applications is database applications (lists and such). As demonstrated elsewhere (and posted in these forums), lots of games have been coded in Javascript.
In any case, it appears that there is a big adjustment required of people coming from, say, C, C++ or
VB. Added to that is the complexity of the MVC architecture.
.
Seriously, EVERYTHING is in Javascript? Even things like Google Maps and Pandora?
Certainly other things must be java, etc, right?
Member:
ADGrant
at: 10:45 PM 06/28/2009
Originally Posted by GreenHex:
In any case, it appears that the there is big adjustment required of people coming from, say, C, C++ or VB. Add to that is the complexity of the MVC architecture.
Or Java or Objective C. In other words all the app developers from the other smartphone platforms
Member:
bruba
at: 10:45 PM 06/28/2009
Originally Posted by devexpert:
Then, they send us, developers, back to freaking 1990's so we have to code in Notepads and other plain text editors all without syntax checking, auto-complete and debugging. Serious time waster...
In the webOS webcast on youtube, the guy talks about webOS plugins for popular text editors.
Member:
mosdl
at: 11:17 PM 06/28/2009
Originally Posted by devexpert:
Yeah but Ruby or Python would've been much better choice. JavaScript is simply not designed for hard-core development.
What does python have that Javascript doesn't that you so badly need?
I do remind you that Firefox's entire UI is javascript/xml and is quite hardcore...
Originally Posted by :
That applies ONLY if you do not use WebOS core stuff. But what are the apps that would NOT use it?
Not sure what that means. There is a separate debugging tool in the sdk that opens webkit with a
js debugger. Not sure what the complexity is.
I think people are confusing languages with platform capabilities - java/c doesn't allow anything dynamic when it comes to the UI, they are just programming languages. It's the apis that are provided to them that allow to do fancy effects and all.
Browsers already have a 2d canvas element - 2d drawing which allows for 2d games, with sprite scaling/etc built in and rendered in C (but called by
js). So once you add a 3d canvas with 3d apis, you can write games.
And all that is good enough to write fart apps just like on the iPhone!
Member:
Baryn
at: 11:59 PM 06/28/2009
If you don't know JavaScript, your time would be better spent learning it than making a thread which tries to hide that fact.
Homebrew Developer:
GreenHex
at: 12:39 AM 06/29/2009
It looks like Javascript coding is not easy for people who have adjusted to other (more structured) programming paradigms.
ignoring, for a moment the point made several posts up, that the entire user interface for foxpro is written in javascript and xml -- and is pretty heavy code, and pretty fast, and pretty functional, but let's ignore that.
So, let's assume that you can't do animation effects, graphics, and reasonable response and function in javascript.
Then go explain this:
World of Solitaire
and get back to me with that... OK ?
mean while, I'm going back to coding Pre apps.
Member:
nhavar
at: 01:41 AM 06/29/2009
JavaScript is becoming a more pervasive language and will continue to grow with the advent of HTML 5. JavaScript is everywhere, client and server with implementations that cover just about everything. You can't hit a page on the internet hardly without using
JS and the functionality is everything from simple redirects to full fledged web applications. Google, Yahoo, and MS all use HTML, CSS,
JS for their widget technology. IBM has a new iWidget format for mashups that's dependent on
JS for most the dynamic behavior and animations. OpenLazlo can run as either
JS/HTML/CSS or switch to flash if available. Tibco UI (General Interface) is
JS/XML/XSLT/XHTML/CSS and you can build full applications using their entirely web based IDE.
Flash is in essence ActionScript + XML. ActionScript and JavaScript are cousins both based off of ECMAScript which is the true standard. WebOS is designed to take advantage of HTML 5, which everyone is predicting as the "Flash Killer" because of the introduction of the Canvas tag which allows much richer graphics than previous VML implementations. You also have SVG+Javascript.
The biggest problem with
JS isn't the language, it's the individual interpretations of the expression of that language from the browser vendors. You could have similar problems with just about any language (example: trying to compile GCC apps depending on the platform you are on GCC versus and other lib versions, version of flash installed, version of PHP being used, JSTL library version/customization/code quality rules, etc.,.)
The benefit of
JS/CSS/HTML is that it's mature, well known, has a low threshold to entry (learning, tool cost, training cost), has ample examples, and is beginning to have tools as equally robust as those offered to C, Java, PHP developers (Aptana, Eclipse Web Tools).
I don't look at this as a hack solution or some half-arsed choice based solely on cost. I think this was a methodical look at the abundance of applications moving into the web space, the potentials of cloud computing, the continuing maturity of standard languages, as well as the eagerness of web developers to push the boundaries of the tools available to them and come up with stunning new ways of doing things.
Member:
TheMarco
at: 02:51 AM 06/29/2009
It's funny how all these 'real developers' always ***** about Javascript. The reason for this is that they don't understand Javascript. The natural reaction is then to downplay it as 'inferior' and 'not suitable for real development'. This is easier than admitting to be incapable of programming in the language.
Javascript is a real programming language and one can do real development in it. Small caveat is... you have to actually know Javascript (and xhtml and CSS as well for that matter).
I don't think its funny actually, I think its sad.
What we have here are 'old' vs 'new' developers just like what is going on with the 'old' vs 'new' media. Just because its not done they main way you know how doesn't make it 'bad' or 'slow'. If you actually know how to program with JavaScript and not just complain about it you will see the elegance and deep thought that went into designing the architecture of this platform. Its really easy to just expose your native APIs for the OS your running and tell everyone to get with the program. Its an entirely different thing to develop 2 separate programming layers to allow a much larger audience to use and develop on your platform. You talk a big game so lets see what your arguments are:
Originally Posted by :
First the choice of JavaScript...
Wow, thanks for backing up your argument with some sample code or actual examples. Not everyone thinks that JavaScript is the worst programming language ever. The Palm guys obviously liked it enough to build their ENTIRE UI on top of it. Here is a javascript snippit to send an alert message and a similar snippet in Objective-C, which do you think is easier and more developer friendly?
JS:[CODE]<script>
alert('Hello, world!');
</script>[/CODE] and Obj-C:[CODE]#import <stdio.h>
int main (int argc, const char *argv[])
{
printf ("Hello, world!\n");
return 0;
}
[/CODE]
So the
JS example is expressed in 1 line (including HTML, 3) and the Obj-C is in 7 lines. Welcome to the world of dynamic languages, please do get with the program. Your compilers and type based languages don't mean much here. If it really bugs you that much, plead your case to Palm. I'm sure you know way more about their platform and its potential then they do.
Next...
Originally Posted by :
Then, they send us, developers, back to freaking 1990's so we have to code in Notepads and other plain text editors all without syntax checking...
Ok, I can kinda see your point here, but I really don't think you have anything to do with the official early access program so how can you know for sure? We were leaked an incomplete SDK with virtually no docs and no support, perhaps it was people like you who Palm were worried about sending out a unfinished SDK to. Not to mention there is nothing stopping you from creating a eclipse plugin or textmate bundle for the SDK, the
JS APIs are all documented in the sample apps.
Next...
Originally Posted by :
Next you have debug your app in the simulator for anything serious...
Have you ever programmed anything in your life???? Do you debug in a flytrap? This is the most ridiculous statement I have ever seen coming from a supposed programmer. How else do you expect to make sure your app is working, pray to the Palm/ARM gods? There is an emulator for a reason. Get over yourself.
Next.
Originally Posted by :
... man this thing is just badly architected. If you study the code for internal apps you'll understand. Everything based on JavaScript and browser, you can see un-elegance of the whole solution... JS is just ugly...
No I can't really. Just because YOU don't understand whats going on here doesn't make it "badly architected[sic]". What makes a language ugly? If it was really that bad, I'm sure people would have stopped programming with it a LONG time ago, right around when flash came out for the browsers. That didn't happen, JavaScript is here to stay and it gets more powerful every day. Palm saw this happening and decided to forgo the normal 'formalities' with mobile device programming and move on to a better and easier system. I'm sorry if you are offended by their decision. No wait, I'm not.
-G01
Originally Posted by mglinski01:
Here is a javascript snippit to send an alert message and a similar snippet in Objective-C, which do you think is easier and more developer friendly?
JS:[CODE]alert('Hello, world!');[/CODE] and Obj-C:[CODE]#import <stdio.h>
int main (int argc, const char *argv[])
{
printf ("Hello, world!\n");
return 0;
}
[/CODE]
So the JS example is expressed in 1 line and the Obj-C is in 7 lines. Welcome to the world of dynamic languages, please do get with the program. Your compilers and type based languages don't mean much here. If it really bugs you that much, plead your case to Palm. I'm sure you know way more about their platform and its potential then they do.
Uh, you have to write a HTML wrapper around your
JS example there to work from a browser, or in a Pre app.
Furthermore, Objective-C *is* a dynamically typed programming language whereas C is not (there is a difference) dynamically typed.
I don't really have much of an opinion on this
JS-sucks-for-the-Pre thing, but I think a lot of traditional application developers would be comfortable in a traditional application programming language.
Sorry, Let me update my post to fix that example.
While I am not knocking the Obj-C guys - I do like the language a lot - It's just the same old story in a new cover. Any programmer worth his salt will know the difference between scripting(
JS, PHP, LUA) languages and compiled(C(++), Obj-C, Python, etc.) languages and the 'inherit' advantages for each. Whats happening here is that the scripting languages are becoming just as powerful as the compiled languages, and because of that we don't have to deal with the limitations inherit with compiled code. Why is that not a good thing?
-G01
Originally Posted by mglinski01:
I don't think its funny actually, I think its sad.
What we have here are 'old' vs 'new' developers just like what is going on with the 'old' vs 'new' media. Just because its not done they main way you know how doesn't make it 'bad' or 'slow'. If you actually know how to program with JavaScript and not just complain about it you will see the elegance and deep thought that went into designing the architecture of this platform.
You are making extremely big assumption there. I kicked *** in JavaScript 10 years ago when nobody even talked about AJAX I wrote exactly what is today called AJAX using IE 5 and XMLHTTP. So I am extremely familiar with
JS and have developed some very large apps with it.
And that is precisely the reason for my thinking. JavaScript is scripting, dynamic, weakly typed, prototype-based language. Scripting languages are designed to control applications, i.e. "glue" code to support apps and connected them together.
JS is not designed for building the applications. If you cannot see that from makeup of the JavaScript then...
Originally Posted by mglinski01:
Its really easy to just expose your native APIs for the OS your running and tell everyone to get with the program.
Umm not true.
JS does not expose native API
JS works to control native API. BIG difference.
Originally Posted by mglinski01:
You talk a big game so lets see what your arguments are:
Your
JS sample will not run as is. Debug it first ;-)
So same can be written cleaner in Ruby and Java would not look out of place either so whats your point?
Originally Posted by mglinski01:
Not everyone thinks that JavaScript is the worst programming language ever.
I do not think that either.
JS is fine language when used for things it is designed for. When taken out of that context it is ugly to code in.
Originally Posted by mglinski01:
The Palm guys obviously liked it enough to build their ENTIRE UI on top of it.
The Palm guys did not have time and resources to make proper choice for architecture of their platform so they settled. And they might have made this choice before Apple actually confirmed existence of native SDK. Remember Apple stance for over half a year was that we should write our apps as HTML/
JS so Palm might have copied that along with other things... We don't know....
Originally Posted by mglinski01:
So the JS example is expressed in 1 line (including HTML, 3) and the Obj-C is in 7 lines. Welcome to the world of dynamic languages, please do get with the program.
I mentioned Ruby and Python, not Objective C. I don't know why you keep bringing it up... But yeah it is much better choice for platform code than
JS.
Originally Posted by mglinski01:
Have you ever programmed anything in your life???? Do you debug in a flytrap?
I don't know what kind work you do, but have you heard of debug/edit/continue cycle? Probably not. Try debugging for example Ruby code in NetBeans or app in VS.NET and you'll understand.
1
2 3 4 5 6
...
Last
webOS Nation Forums
> webOS apps and software
> webOS development
>
This architecture looks like hack