Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-14 Thread 李白|字一日 
i would no say that java language would be slower than javascript.
but the java ecosystem  and its model made itself a very slow language.
slow to start up, memory consuming to have the vm run.
a time waiting to deploy.
and complicated framework to start.
and crazy xml configs.



2014-05-15 1:52 GMT+08:00 TreKing :

>
> On Wed, May 14, 2014 at 12:32 PM, 李白|字一日  wrote:
>
>> A fool don't look at the reality.
>>
>> as nodejs nowadays is popluar in server side programming,
>> the benefit is very obvious.
>>
>>
>> http://stackoverflow.com/questions/3723374/how-fast-is-javascript-compared-to-java
>>
>>
>> as kls  said:
>>
>>
>> http://stackoverflow.com/questions/3723374/how-fast-is-javascript-compared-to-java
>>
>
> It's extremely ironic that you say "A fool don't [sic] look at the
> reality", then link to a SO post where the accepted answer states: "The
> performance of an application has nothing to do with the language."
>
> Then you cherry pick ONE person's self-described ANECDOTE, to prove your
> point?
>
> Here, I'll cherry pick some anecdotes from THE SAME POST:
>
> "Hereare
>  some tests comparing Javascript (V8) and compiled Java, and they
> indicate that Java is generally faster1. "
>
> and
>
> "Java should still roundly trounce JavaScript due to integer vs. float
> math."
>
> and
>
> "Java, obviously."
>
> and
>
> "
> http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=java
>
> According to the above link JavaScript as reality stands now is much
> slower for almost everything."
> By your logic, since I've quoted more "pro Java" stories, Java wins!
>
> Your like the Fox News of this "debate". Passing off anecdotes,
> conjecture, and bias for facts. It's been a fun read at the very least, so
> thanks!
>
>
> -
> TreKing  - Chicago
> transit tracking app for Android-powered devices
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Android Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/android-developers/4UrtNOPympc/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-14 Thread 李白|字一日 
Yes And NO.
Yes: Javascript can be used to write applications.
Android is slow because of java and its vm, and it design model.
if Android using javascript technology,  and throw away java vm. the
running model will be differently.
the async technology is not only fast in server but also in browser side.

No: I don't think it is slow because of not using javascript. to speed up
android, C/C++ would be better choice.

Then why javascript?
1、Web integration, better sharing, and full stack development. browser
side, server side, mobile side.
it is a very good situation for both developers and enterprises.

2、Mature UI Technology
HTML5 and CSS3 can produce a very vivid UI Interaction nowadays, it is very
mature and well spread, it would greatly accelerate the process of
developing a new app and give a better foundation for other developers if
the project is opened. of cause this process is already on its way to
booming.
bootstrap, ionic, mobile angular ui, jquery mobile, etc. are very good
examples.

3、HTML5 based mobile side apps are very popular with technologies like
phonegap.

4、Mobile handset manufacturers are producing HTML5 Based handset now.
Ubuntu Mobile OS, FIREFOX etc.

5、performance is also a importance reason.
  although java may win in benchmark, but it can not win the reality. as i
have listed so many examples, you may understand what i mean by good
performance.

performance is not a big reason. but java and is system structure surely
slow down the performance of the whole android os.




2014-05-15 1:45 GMT+08:00 Kristopher Micinski :

> Your arguments don't make any sense at all anymore because all you're
> saying is: JavaScript can be used to write applications, Android sucks
> because it doesn't use JavaScript.
>
> Perhaps you should read FirefoxOS and learn to do some programming for
> that, and then direct future questions there.
>
> Kris
>
> On Wed, May 14, 2014 at 1:32 PM, 李白|字一日  wrote:
> > A fool don't look at the reality.
> >
> > as nodejs nowadays is popluar in server side programming,
> > the benefit is very obvious.
> >
> >
> http://stackoverflow.com/questions/3723374/how-fast-is-javascript-compared-to-java
> >
> >
> > as kls said:
> >
> >
> http://stackoverflow.com/questions/3723374/how-fast-is-javascript-compared-to-java
> >
> > """
> >
> > I only have an anecdote to add: I've recently reimplemented a Java calc
> > server (finance) in Javascript (nodejs v0.6.8). WRT development time, the
> > Javascript implementation was a breeze compared to the original Java
> > implementation with far fewer lines of code. It was a breath of fresh
> air,
> > really.
> >
> > The Javascript-based server is able to calc through 2.4k trades/sec
> whereas
> > the Java server handles 400+/sec on the same hardware using less memory.
> I
> > wouldn't attribute the speed increase to raw V8 vs. Java 7 performance
> but
> > rather to the implementation. The Javascript implementation uses far
> fewer
> > data structures, does an order of magnitude fewer method calls and takes
> a
> > more straight-forward and terse approach.
> >
> > Needless to say, I'm very happy with the performance of node.js. And
> this,
> > coming from someone who was Java only for many (9) years.
> >
> > """
> >
> >
> >
> >
> >
> > 2014-05-12 16:30 GMT+08:00 Doug :
> >
> >> Please, just stop.  You are arguing with a fool!
> >>
> >>
> >> On Sunday, May 11, 2014 10:30:22 PM UTC-7, Kristopher Micinski wrote:
> >>>
> >>> What are you even talking about: Any JavaScript program is also going
> >>> to have threads, too.
> >>>
> >>> You seem to be making this argument: Java has multiple threads, and
> >>> that makes the programs slow.
> >>>
> >>> It sounds like all of this is coming from a completely uneducated
> >>> viewpoint on systems design, but there are a number of
> >>> issues.
> >>>
> >>> Please understand, however, that all of the issues in Java carry over
> >>> (and worse) to JavaScript, you still need multiple threads, you still
> >>> need a garbage collector.
> >>>
> >>> Please also quit citing other Java products as evidence that it has
> >>> anything to do with Android.  Forget Java, android doesn't run Java.
> >>> Android runs Dalvik.  Which is completely different than Java.  You
> >>> can translate anything into Dalvik, people usually translate Java,
> >>> there's no reason you couldn't also translate anything else.
> >>>
> >>> Kris
> >>>
> >>>
> >>>
> >>> On Mon, May 12, 2014 at 1:22 AM, 李白|字一日  wrote:
> >>> > the slow comes not just from the loading of java based apps. but the
> >>> > java
> >>> > itself and the bad programming guidance, which uses too many threads
> >>> > and
> >>> > classes which take a lot space. and what even worse is you will
> >>> > sometimes
> >>> > have to do deep inheritance.
> >>> >
> >>> > it adds extra overheads to make itself run.
> >>> > these are ignored while benchmark.
> >>> >
> >>> > i am by no means expert in languages. but it is true that java is
> slow
> >>> > to
> >>> > what ever produ

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-14 Thread TreKing 
On Wed, May 14, 2014 at 12:32 PM, 李白|字一日  wrote:

> A fool don't look at the reality.
>
> as nodejs nowadays is popluar in server side programming,
> the benefit is very obvious.
>
>
> http://stackoverflow.com/questions/3723374/how-fast-is-javascript-compared-to-java
>
>
> as kls  said:
>
>
> http://stackoverflow.com/questions/3723374/how-fast-is-javascript-compared-to-java
>

It's extremely ironic that you say "A fool don't [sic] look at the
reality", then link to a SO post where the accepted answer states: "The
performance of an application has nothing to do with the language."

Then you cherry pick ONE person's self-described ANECDOTE, to prove your
point?

Here, I'll cherry pick some anecdotes from THE SAME POST:

"Hereare
some tests comparing Javascript (V8) and compiled Java, and they
indicate that Java is generally faster1. "

and

"Java should still roundly trounce JavaScript due to integer vs. float
math."

and

"Java, obviously."

and

"
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=java

According to the above link JavaScript as reality stands now is much slower
for almost everything."
By your logic, since I've quoted more "pro Java" stories, Java wins!

Your like the Fox News of this "debate". Passing off anecdotes, conjecture,
and bias for facts. It's been a fun read at the very least, so thanks!

-
TreKing  - Chicago
transit tracking app for Android-powered devices

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-14 Thread Kristopher Micinski 
Your arguments don't make any sense at all anymore because all you're
saying is: JavaScript can be used to write applications, Android sucks
because it doesn't use JavaScript.

Perhaps you should read FirefoxOS and learn to do some programming for
that, and then direct future questions there.

Kris

On Wed, May 14, 2014 at 1:32 PM, 李白|字一日  wrote:
> A fool don't look at the reality.
>
> as nodejs nowadays is popluar in server side programming,
> the benefit is very obvious.
>
> http://stackoverflow.com/questions/3723374/how-fast-is-javascript-compared-to-java
>
>
> as kls said:
>
> http://stackoverflow.com/questions/3723374/how-fast-is-javascript-compared-to-java
>
> """
>
> I only have an anecdote to add: I've recently reimplemented a Java calc
> server (finance) in Javascript (nodejs v0.6.8). WRT development time, the
> Javascript implementation was a breeze compared to the original Java
> implementation with far fewer lines of code. It was a breath of fresh air,
> really.
>
> The Javascript-based server is able to calc through 2.4k trades/sec whereas
> the Java server handles 400+/sec on the same hardware using less memory. I
> wouldn't attribute the speed increase to raw V8 vs. Java 7 performance but
> rather to the implementation. The Javascript implementation uses far fewer
> data structures, does an order of magnitude fewer method calls and takes a
> more straight-forward and terse approach.
>
> Needless to say, I'm very happy with the performance of node.js. And this,
> coming from someone who was Java only for many (9) years.
>
> """
>
>
>
>
>
> 2014-05-12 16:30 GMT+08:00 Doug :
>
>> Please, just stop.  You are arguing with a fool!
>>
>>
>> On Sunday, May 11, 2014 10:30:22 PM UTC-7, Kristopher Micinski wrote:
>>>
>>> What are you even talking about: Any JavaScript program is also going
>>> to have threads, too.
>>>
>>> You seem to be making this argument: Java has multiple threads, and
>>> that makes the programs slow.
>>>
>>> It sounds like all of this is coming from a completely uneducated
>>> viewpoint on systems design, but there are a number of
>>> issues.
>>>
>>> Please understand, however, that all of the issues in Java carry over
>>> (and worse) to JavaScript, you still need multiple threads, you still
>>> need a garbage collector.
>>>
>>> Please also quit citing other Java products as evidence that it has
>>> anything to do with Android.  Forget Java, android doesn't run Java.
>>> Android runs Dalvik.  Which is completely different than Java.  You
>>> can translate anything into Dalvik, people usually translate Java,
>>> there's no reason you couldn't also translate anything else.
>>>
>>> Kris
>>>
>>>
>>>
>>> On Mon, May 12, 2014 at 1:22 AM, 李白|字一日  wrote:
>>> > the slow comes not just from the loading of java based apps. but the
>>> > java
>>> > itself and the bad programming guidance, which uses too many threads
>>> > and
>>> > classes which take a lot space. and what even worse is you will
>>> > sometimes
>>> > have to do deep inheritance.
>>> >
>>> > it adds extra overheads to make itself run.
>>> > these are ignored while benchmark.
>>> >
>>> > i am by no means expert in languages. but it is true that java is slow
>>> > to
>>> > what ever products made by java.
>>> >
>>> > eclipse, android, j2me, netbeans, idea.
>>> > none of them are famous for their speed and memory saving.
>>> >
>>> >
>>> >
>>> >
>>> > 2014-05-12 11:22 GMT+08:00 bjv :
>>> >>
>>> >> Ugh! You don't get it and likely never will. There are so many things
>>> >> wrong with your assumptions/statements in all of these threads. It
>>> >> really
>>> >> isn't worth the time to debunk them all.
>>> >>
>>> >> But for what its worth, there is small overhead with respect to
>>> >> running
>>> >> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
>>> >> interpreted language. Outside of the various ASM-JS experiments, Your
>>> >> html5+JS likely will always be interpreted. In a broad comparison, it
>>> >> will
>>> >> almost always be slower. Your thinking that you get to share all those
>>> >> JS
>>> >> object goodies between various apps/components is in itself a cause
>>> >> for
>>> >> concern.
>>> >>
>>> >> In an effort to remove the Dalvik overhead on Android, the Android
>>> >> guys
>>> >> are now rolling out ART (a variant of llvm) that will transfer most of
>>> >> that
>>> >> overhead to installation time. At that point, Java isn't going to be
>>> >> much
>>> >> different than C++ from an execution perspective.
>>> >>
>>> >>
>>> >> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>>> >>>
>>> >>> if it is not, why should you go native with c/c++ based ndk
>>> >>> programming?
>>> >>>
>>> >>> it is surely related to the programming language.
>>> >>>
>>> >>> javascript 's speed acceleration is also related to the language and
>>> >>> its
>>> >>> optimization, which is almost always c/c++.
>>> >>>
>>> >>> i have never experienced the fast feeling of java technology both in
>>> >>> desktop or server side.
>

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-14 Thread 李白|字一日 
A fool don't look at the reality.

as nodejs nowadays is popluar in server side programming,
the benefit is very obvious.

http://stackoverflow.com/questions/3723374/how-fast-is-javascript-compared-to-java


as kls  said:

http://stackoverflow.com/questions/3723374/how-fast-is-javascript-compared-to-java

"""

I only have an anecdote to add: I've recently reimplemented a Java calc
server (finance) in Javascript (nodejs v0.6.8). WRT development time, the
Javascript implementation was a breeze compared to the original Java
implementation with far fewer lines of code. It was a breath of fresh air,
really.

The Javascript-based server is able to calc through 2.4k trades/sec whereas
the Java server handles 400+/sec on the same hardware using less memory. I
wouldn't attribute the speed increase to raw V8 vs. Java 7 performance but
rather to the implementation. The Javascript implementation uses far fewer
data structures, does an order of magnitude fewer method calls and takes a
more straight-forward and terse approach.

Needless to say, I'm very happy with the performance of node.js. And this,
coming from someone who was Java only for many (9) years.

"""





2014-05-12 16:30 GMT+08:00 Doug :

> Please, just stop.  You are arguing with a fool!
>
>
> On Sunday, May 11, 2014 10:30:22 PM UTC-7, Kristopher Micinski wrote:
>
>> What are you even talking about: Any JavaScript program is also going
>> to have threads, too.
>>
>> You seem to be making this argument: Java has multiple threads, and
>> that makes the programs slow.
>>
>> It sounds like all of this is coming from a completely uneducated
>> viewpoint on systems design, but there are a number of
>> issues.
>>
>> Please understand, however, that all of the issues in Java carry over
>> (and worse) to JavaScript, you still need multiple threads, you still
>> need a garbage collector.
>>
>> Please also quit citing other Java products as evidence that it has
>> anything to do with Android.  Forget Java, android doesn't run Java.
>> Android runs Dalvik.  Which is completely different than Java.  You
>> can translate anything into Dalvik, people usually translate Java,
>> there's no reason you couldn't also translate anything else.
>>
>> Kris
>>
>>
>>
>> On Mon, May 12, 2014 at 1:22 AM, 李白|字一日  wrote:
>> > the slow comes not just from the loading of java based apps. but the
>> java
>> > itself and the bad programming guidance, which uses too many threads
>> and
>> > classes which take a lot space. and what even worse is you will
>> sometimes
>> > have to do deep inheritance.
>> >
>> > it adds extra overheads to make itself run.
>> > these are ignored while benchmark.
>> >
>> > i am by no means expert in languages. but it is true that java is slow
>> to
>> > what ever products made by java.
>> >
>> > eclipse, android, j2me, netbeans, idea.
>> > none of them are famous for their speed and memory saving.
>> >
>> >
>> >
>> >
>> > 2014-05-12 11:22 GMT+08:00 bjv :
>> >>
>> >> Ugh! You don't get it and likely never will. There are so many things
>> >> wrong with your assumptions/statements in all of these threads. It
>> really
>> >> isn't worth the time to debunk them all.
>> >>
>> >> But for what its worth, there is small overhead with respect to
>> running
>> >> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
>> >> interpreted language. Outside of the various ASM-JS experiments, Your
>> >> html5+JS likely will always be interpreted. In a broad comparison, it
>> will
>> >> almost always be slower. Your thinking that you get to share all those
>> JS
>> >> object goodies between various apps/components is in itself a cause
>> for
>> >> concern.
>> >>
>> >> In an effort to remove the Dalvik overhead on Android, the Android
>> guys
>> >> are now rolling out ART (a variant of llvm) that will transfer most of
>> that
>> >> overhead to installation time. At that point, Java isn't going to be
>> much
>> >> different than C++ from an execution perspective.
>> >>
>> >>
>> >> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>> >>>
>> >>> if it is not, why should you go native with c/c++ based ndk
>> programming?
>> >>>
>> >>> it is surely related to the programming language.
>> >>>
>> >>> javascript 's speed acceleration is also related to the language and
>> its
>> >>> optimization, which is almost always c/c++.
>> >>>
>> >>> i have never experienced the fast feeling of java technology both in
>> >>> desktop or server side.
>> >>>
>> >>> i never experienced fast  feeling in android, eclipse, java ee, j2me.
>>  am
>> >>> i fooled?
>> >>>
>> >>> eclipse is famous for it's slow and memory consuming, though it is
>> the
>> >>> greatest  ide i ever used.
>> >>>
>> >>> javascript based ide, like local compiled c9.io is very fast and
>> >>> responsive, thought it is not that mature.
>> >>>
>> >>> why ? ? ?
>> >>>
>> >>> and if android ui design can be written directly in html + css, it
>> has
>> >>> all the flexibility

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-12 Thread Doug 
Please, just stop.  You are arguing with a fool!

On Sunday, May 11, 2014 10:30:22 PM UTC-7, Kristopher Micinski wrote:
>
> What are you even talking about: Any JavaScript program is also going 
> to have threads, too. 
>
> You seem to be making this argument: Java has multiple threads, and 
> that makes the programs slow. 
>
> It sounds like all of this is coming from a completely uneducated 
> viewpoint on systems design, but there are a number of 
> issues. 
>
> Please understand, however, that all of the issues in Java carry over 
> (and worse) to JavaScript, you still need multiple threads, you still 
> need a garbage collector. 
>
> Please also quit citing other Java products as evidence that it has 
> anything to do with Android.  Forget Java, android doesn't run Java. 
> Android runs Dalvik.  Which is completely different than Java.  You 
> can translate anything into Dalvik, people usually translate Java, 
> there's no reason you couldn't also translate anything else. 
>
> Kris 
>
>
>
> On Mon, May 12, 2014 at 1:22 AM, 李白|字一日 > 
> wrote: 
> > the slow comes not just from the loading of java based apps. but the 
> java 
> > itself and the bad programming guidance, which uses too many threads and 
> > classes which take a lot space. and what even worse is you will 
> sometimes 
> > have to do deep inheritance. 
> > 
> > it adds extra overheads to make itself run. 
> > these are ignored while benchmark. 
> > 
> > i am by no means expert in languages. but it is true that java is slow 
> to 
> > what ever products made by java. 
> > 
> > eclipse, android, j2me, netbeans, idea. 
> > none of them are famous for their speed and memory saving. 
> > 
> > 
> > 
> > 
> > 2014-05-12 11:22 GMT+08:00 bjv >: 
> >> 
> >> Ugh! You don't get it and likely never will. There are so many things 
> >> wrong with your assumptions/statements in all of these threads. It 
> really 
> >> isn't worth the time to debunk them all. 
> >> 
> >> But for what its worth, there is small overhead with respect to running 
> >> Java/Dalvik on Android. That said, it is mostly upfront. JS is an 
> >> interpreted language. Outside of the various ASM-JS experiments, Your 
> >> html5+JS likely will always be interpreted. In a broad comparison, it 
> will 
> >> almost always be slower. Your thinking that you get to share all those 
> JS 
> >> object goodies between various apps/components is in itself a cause for 
> >> concern. 
> >> 
> >> In an effort to remove the Dalvik overhead on Android, the Android guys 
> >> are now rolling out ART (a variant of llvm) that will transfer most of 
> that 
> >> overhead to installation time. At that point, Java isn't going to be 
> much 
> >> different than C++ from an execution perspective. 
> >> 
> >> 
> >> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote: 
> >>> 
> >>> if it is not, why should you go native with c/c++ based ndk 
> programming? 
> >>> 
> >>> it is surely related to the programming language. 
> >>> 
> >>> javascript 's speed acceleration is also related to the language and 
> its 
> >>> optimization, which is almost always c/c++. 
> >>> 
> >>> i have never experienced the fast feeling of java technology both in 
> >>> desktop or server side. 
> >>> 
> >>> i never experienced fast  feeling in android, eclipse, java ee, j2me. 
>  am 
> >>> i fooled? 
> >>> 
> >>> eclipse is famous for it's slow and memory consuming, though it is the 
> >>> greatest  ide i ever used. 
> >>> 
> >>> javascript based ide, like local compiled c9.io is very fast and 
> >>> responsive, thought it is not that mature. 
> >>> 
> >>> why ? ? ? 
> >>> 
> >>> and if android ui design can be written directly in html + css, it has 
> >>> all the flexibility css and html have now. If you know the web 
> technologies, 
> >>> you should know what i mean. 
> >>> 
> >>> it is meaningless to discuss about the languages' performance, but the 
> >>> trend is that javascript will play a more important role in server 
> side 
> >>> programming, hardware based programming and browser side programming. 
> >>> 
> >>> 
> >>> 2014-05-12 1:03 GMT+08:00 Colin M : 
> >>> 
>  I'll ignore the unqualified claim that the slowness of Android is due 
> to 
>  Java. 
>  
>  It sounds like your complaint is that you can't develop native apps 
> in 
>  your preferred language and that you're using an outdated claim about 
> Java 
>  to support your desire to change the current language of choice for 
> Android 
>  development. 
>  
>  The XML based components can all be done via code.  Do you have an 
>  example of how they are "far from flexible"?  There are many 
> limitations, 
>  but you are welcome to write your own custom Views to get around any 
>  limitations.  I have many of my own complaints about some of the UI 
> system, 
>  but I have no reason to believe the current state of things would be 
> faster 
>  or more flexible if it were in another language.  That's not the 
>

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-11 Thread 李白|字一日 
a global event based rendering machine plus HTML5 + javascrip + css Bundle
will surely be more faster. firefox os maybe an existing example.

it consumes less resources. while android is not.

http://propakistani.pk/2013/04/29/how-and-why-firefox-os-is-better-than-android-and-ios/


2014-05-12 13:52 GMT+08:00 李白|字一日 :

> you even don't know what javascript is .
> although javascript needs more than one threads to execute, but it is
> event based. in run time, it has no needs to create new thread.
>
> like epoll vs select in network io.
>
> the differences are obvious.
>
> java can't make it.
>
> the switch between ui thread to network thread is not needed in javascript.
>
> but it is a must in java.
>
> as to clear, i give some my opinions on why i like javascript and possibly
> be a fast language:
>
> 1、can be compiled to native when possible, requires no vm
> 2、event based
> 3、async executed
> 4、no more threading
> 5、no inheritance need.
> 6、object based, prototype based, native to have the ability to extends but
> require no new classes.
> 7、no classes to objects translation.
>
>
>
>
>
> 2014-05-12 13:30 GMT+08:00 Kristopher Micinski :
>
> What are you even talking about: Any JavaScript program is also going
>> to have threads, too.
>>
>> You seem to be making this argument: Java has multiple threads, and
>> that makes the programs slow.
>>
>> It sounds like all of this is coming from a completely uneducated
>> viewpoint on systems design, but there are a number of
>> issues.
>>
>> Please understand, however, that all of the issues in Java carry over
>> (and worse) to JavaScript, you still need multiple threads, you still
>> need a garbage collector.
>>
>> Please also quit citing other Java products as evidence that it has
>> anything to do with Android.  Forget Java, android doesn't run Java.
>> Android runs Dalvik.  Which is completely different than Java.  You
>> can translate anything into Dalvik, people usually translate Java,
>> there's no reason you couldn't also translate anything else.
>>
>> Kris
>>
>>
>>
>> On Mon, May 12, 2014 at 1:22 AM, 李白|字一日  wrote:
>> > the slow comes not just from the loading of java based apps. but the
>> java
>> > itself and the bad programming guidance, which uses too many threads and
>> > classes which take a lot space. and what even worse is you will
>> sometimes
>> > have to do deep inheritance.
>> >
>> > it adds extra overheads to make itself run.
>> > these are ignored while benchmark.
>> >
>> > i am by no means expert in languages. but it is true that java is slow
>> to
>> > what ever products made by java.
>> >
>> > eclipse, android, j2me, netbeans, idea.
>> > none of them are famous for their speed and memory saving.
>> >
>> >
>> >
>> >
>> > 2014-05-12 11:22 GMT+08:00 bjv :
>> >>
>> >> Ugh! You don't get it and likely never will. There are so many things
>> >> wrong with your assumptions/statements in all of these threads. It
>> really
>> >> isn't worth the time to debunk them all.
>> >>
>> >> But for what its worth, there is small overhead with respect to running
>> >> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
>> >> interpreted language. Outside of the various ASM-JS experiments, Your
>> >> html5+JS likely will always be interpreted. In a broad comparison, it
>> will
>> >> almost always be slower. Your thinking that you get to share all those
>> JS
>> >> object goodies between various apps/components is in itself a cause for
>> >> concern.
>> >>
>> >> In an effort to remove the Dalvik overhead on Android, the Android guys
>> >> are now rolling out ART (a variant of llvm) that will transfer most of
>> that
>> >> overhead to installation time. At that point, Java isn't going to be
>> much
>> >> different than C++ from an execution perspective.
>> >>
>> >>
>> >> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>> >>>
>> >>> if it is not, why should you go native with c/c++ based ndk
>> programming?
>> >>>
>> >>> it is surely related to the programming language.
>> >>>
>> >>> javascript 's speed acceleration is also related to the language and
>> its
>> >>> optimization, which is almost always c/c++.
>> >>>
>> >>> i have never experienced the fast feeling of java technology both in
>> >>> desktop or server side.
>> >>>
>> >>> i never experienced fast  feeling in android, eclipse, java ee, j2me.
>>  am
>> >>> i fooled?
>> >>>
>> >>> eclipse is famous for it's slow and memory consuming, though it is the
>> >>> greatest  ide i ever used.
>> >>>
>> >>> javascript based ide, like local compiled c9.io is very fast and
>> >>> responsive, thought it is not that mature.
>> >>>
>> >>> why ? ? ?
>> >>>
>> >>> and if android ui design can be written directly in html + css, it has
>> >>> all the flexibility css and html have now. If you know the web
>> technologies,
>> >>> you should know what i mean.
>> >>>
>> >>> it is meaningless to discuss about the languages' performance, but the
>> >>> trend is that javascript will play a more important r

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-11 Thread 李白|字一日 
you even don't know what javascript is .
although javascript needs more than one threads to execute, but it is event
based. in run time, it has no needs to create new thread.

like epoll vs select in network io.

the differences are obvious.

java can't make it.

the switch between ui thread to network thread is not needed in javascript.

but it is a must in java.

as to clear, i give some my opinions on why i like javascript and possibly
be a fast language:

1、can be compiled to native when possible, requires no vm
2、event based
3、async executed
4、no more threading
5、no inheritance need.
6、object based, prototype based, native to have the ability to extends but
require no new classes.
7、no classes to objects translation.





2014-05-12 13:30 GMT+08:00 Kristopher Micinski :

> What are you even talking about: Any JavaScript program is also going
> to have threads, too.
>
> You seem to be making this argument: Java has multiple threads, and
> that makes the programs slow.
>
> It sounds like all of this is coming from a completely uneducated
> viewpoint on systems design, but there are a number of
> issues.
>
> Please understand, however, that all of the issues in Java carry over
> (and worse) to JavaScript, you still need multiple threads, you still
> need a garbage collector.
>
> Please also quit citing other Java products as evidence that it has
> anything to do with Android.  Forget Java, android doesn't run Java.
> Android runs Dalvik.  Which is completely different than Java.  You
> can translate anything into Dalvik, people usually translate Java,
> there's no reason you couldn't also translate anything else.
>
> Kris
>
>
>
> On Mon, May 12, 2014 at 1:22 AM, 李白|字一日  wrote:
> > the slow comes not just from the loading of java based apps. but the java
> > itself and the bad programming guidance, which uses too many threads and
> > classes which take a lot space. and what even worse is you will sometimes
> > have to do deep inheritance.
> >
> > it adds extra overheads to make itself run.
> > these are ignored while benchmark.
> >
> > i am by no means expert in languages. but it is true that java is slow to
> > what ever products made by java.
> >
> > eclipse, android, j2me, netbeans, idea.
> > none of them are famous for their speed and memory saving.
> >
> >
> >
> >
> > 2014-05-12 11:22 GMT+08:00 bjv :
> >>
> >> Ugh! You don't get it and likely never will. There are so many things
> >> wrong with your assumptions/statements in all of these threads. It
> really
> >> isn't worth the time to debunk them all.
> >>
> >> But for what its worth, there is small overhead with respect to running
> >> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
> >> interpreted language. Outside of the various ASM-JS experiments, Your
> >> html5+JS likely will always be interpreted. In a broad comparison, it
> will
> >> almost always be slower. Your thinking that you get to share all those
> JS
> >> object goodies between various apps/components is in itself a cause for
> >> concern.
> >>
> >> In an effort to remove the Dalvik overhead on Android, the Android guys
> >> are now rolling out ART (a variant of llvm) that will transfer most of
> that
> >> overhead to installation time. At that point, Java isn't going to be
> much
> >> different than C++ from an execution perspective.
> >>
> >>
> >> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
> >>>
> >>> if it is not, why should you go native with c/c++ based ndk
> programming?
> >>>
> >>> it is surely related to the programming language.
> >>>
> >>> javascript 's speed acceleration is also related to the language and
> its
> >>> optimization, which is almost always c/c++.
> >>>
> >>> i have never experienced the fast feeling of java technology both in
> >>> desktop or server side.
> >>>
> >>> i never experienced fast  feeling in android, eclipse, java ee, j2me.
>  am
> >>> i fooled?
> >>>
> >>> eclipse is famous for it's slow and memory consuming, though it is the
> >>> greatest  ide i ever used.
> >>>
> >>> javascript based ide, like local compiled c9.io is very fast and
> >>> responsive, thought it is not that mature.
> >>>
> >>> why ? ? ?
> >>>
> >>> and if android ui design can be written directly in html + css, it has
> >>> all the flexibility css and html have now. If you know the web
> technologies,
> >>> you should know what i mean.
> >>>
> >>> it is meaningless to discuss about the languages' performance, but the
> >>> trend is that javascript will play a more important role in server side
> >>> programming, hardware based programming and browser side programming.
> >>>
> >>>
> >>> 2014-05-12 1:03 GMT+08:00 Colin M :
> >>>
>  I'll ignore the unqualified claim that the slowness of Android is due
> to
>  Java.
> 
>  It sounds like your complaint is that you can't develop native apps in
>  your preferred language and that you're using an outdated claim about
> Java
>  to support your desire to change the current language

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-11 Thread Kristopher Micinski 
What are you even talking about: Any JavaScript program is also going
to have threads, too.

You seem to be making this argument: Java has multiple threads, and
that makes the programs slow.

It sounds like all of this is coming from a completely uneducated
viewpoint on systems design, but there are a number of
issues.

Please understand, however, that all of the issues in Java carry over
(and worse) to JavaScript, you still need multiple threads, you still
need a garbage collector.

Please also quit citing other Java products as evidence that it has
anything to do with Android.  Forget Java, android doesn't run Java.
Android runs Dalvik.  Which is completely different than Java.  You
can translate anything into Dalvik, people usually translate Java,
there's no reason you couldn't also translate anything else.

Kris



On Mon, May 12, 2014 at 1:22 AM, 李白|字一日  wrote:
> the slow comes not just from the loading of java based apps. but the java
> itself and the bad programming guidance, which uses too many threads and
> classes which take a lot space. and what even worse is you will sometimes
> have to do deep inheritance.
>
> it adds extra overheads to make itself run.
> these are ignored while benchmark.
>
> i am by no means expert in languages. but it is true that java is slow to
> what ever products made by java.
>
> eclipse, android, j2me, netbeans, idea.
> none of them are famous for their speed and memory saving.
>
>
>
>
> 2014-05-12 11:22 GMT+08:00 bjv :
>>
>> Ugh! You don't get it and likely never will. There are so many things
>> wrong with your assumptions/statements in all of these threads. It really
>> isn't worth the time to debunk them all.
>>
>> But for what its worth, there is small overhead with respect to running
>> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
>> interpreted language. Outside of the various ASM-JS experiments, Your
>> html5+JS likely will always be interpreted. In a broad comparison, it will
>> almost always be slower. Your thinking that you get to share all those JS
>> object goodies between various apps/components is in itself a cause for
>> concern.
>>
>> In an effort to remove the Dalvik overhead on Android, the Android guys
>> are now rolling out ART (a variant of llvm) that will transfer most of that
>> overhead to installation time. At that point, Java isn't going to be much
>> different than C++ from an execution perspective.
>>
>>
>> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>>>
>>> if it is not, why should you go native with c/c++ based ndk programming?
>>>
>>> it is surely related to the programming language.
>>>
>>> javascript 's speed acceleration is also related to the language and its
>>> optimization, which is almost always c/c++.
>>>
>>> i have never experienced the fast feeling of java technology both in
>>> desktop or server side.
>>>
>>> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am
>>> i fooled?
>>>
>>> eclipse is famous for it's slow and memory consuming, though it is the
>>> greatest  ide i ever used.
>>>
>>> javascript based ide, like local compiled c9.io is very fast and
>>> responsive, thought it is not that mature.
>>>
>>> why ? ? ?
>>>
>>> and if android ui design can be written directly in html + css, it has
>>> all the flexibility css and html have now. If you know the web technologies,
>>> you should know what i mean.
>>>
>>> it is meaningless to discuss about the languages' performance, but the
>>> trend is that javascript will play a more important role in server side
>>> programming, hardware based programming and browser side programming.
>>>
>>>
>>> 2014-05-12 1:03 GMT+08:00 Colin M :
>>>
 I'll ignore the unqualified claim that the slowness of Android is due to
 Java.

 It sounds like your complaint is that you can't develop native apps in
 your preferred language and that you're using an outdated claim about Java
 to support your desire to change the current language of choice for Android
 development.

 The XML based components can all be done via code.  Do you have an
 example of how they are "far from flexible"?  There are many limitations,
 but you are welcome to write your own custom Views to get around any
 limitations.  I have many of my own complaints about some of the UI system,
 but I have no reason to believe the current state of things would be faster
 or more flexible if it were in another language.  That's not the thing
 limiting flexibility or causing speed issues, that's more about the
 implementations.  I've created and seen many fast and fluid and complex UIs
 on Android, but you sometimes have to do some real work to get them and 
 they
 don't always drop right out of the API in your lap :)  A better argument
 would be to single out issues with the UI libraries and talk about how to
 improve them.  This has little-to-nothing to do with implementation
 language.

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-11 Thread 李白|字一日 
the slow comes not just from the loading of java based apps. but the java
itself and the bad programming guidance, which uses too many threads and
classes which take a lot space. and what even worse is you will sometimes
have to do deep inheritance.

it adds extra overheads to make itself run.
these are ignored while benchmark.

i am by no means expert in languages. but it is true that java is slow to
what ever products made by java.

eclipse, android, j2me, netbeans, idea.
none of them are famous for their speed and memory saving.




2014-05-12 11:22 GMT+08:00 bjv :

> Ugh! You don't get it and likely never will. There are so many things
> wrong with your assumptions/statements in all of these threads. It really
> isn't worth the time to debunk them all.
>
> But for what its worth, there is small overhead with respect to running
> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
> interpreted language. Outside of the various ASM-JS experiments, Your
> html5+JS likely will always be interpreted. In a broad comparison, it will
> almost always be slower. Your thinking that you get to share all those JS
> object goodies between various apps/components is in itself a cause for
> concern.
>
> In an effort to remove the Dalvik overhead on Android, the Android guys
> are now rolling out ART (a variant of llvm) that will transfer most of that
> overhead to installation time. At that point, Java isn't going to be much
> different than C++ from an execution perspective.
>
>
> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>
>> if it is not, why should you go native with c/c++ based ndk programming?
>>
>> it is surely related to the programming language.
>>
>> javascript 's speed acceleration is also related to the language and its
>> optimization, which is almost always c/c++.
>>
>> i have never experienced the fast feeling of java technology both in
>> desktop or server side.
>>
>> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am
>> i fooled?
>>
>> eclipse is famous for it's slow and memory consuming, though it is the
>> greatest  ide i ever used.
>>
>> javascript based ide, like local compiled 
>> c9.iois
>>  very fast and responsive, thought it is not that mature.
>>
>> why ? ? ?
>>
>> and if android ui design can be written directly in html + css, it has
>> all the flexibility css and html have now. If you know the web
>> technologies, you should know what i mean.
>>
>> it is meaningless to discuss about the languages' performance, but the
>> trend is that javascript will play a more important role in server side
>> programming, hardware based programming and browser side programming.
>>
>>
>> 2014-05-12 1:03 GMT+08:00 Colin M :
>>
>> I'll ignore the unqualified claim that the slowness of Android is due to
>>> Java.
>>>
>>> It sounds like your complaint is that you can't develop native apps in
>>> your preferred language and that you're using an outdated claim about Java
>>> to support your desire to change the current language of choice for Android
>>> development.
>>>
>>> The XML based components can all be done via code.  Do you have an
>>> example of how they are "far from flexible"?  There are many limitations,
>>> but you are welcome to write your own custom Views to get around any
>>> limitations.  I have many of my own complaints about some of the UI system,
>>> but I have no reason to believe the current state of things would be faster
>>> or more flexible if it were in another language.  That's not the thing
>>> limiting flexibility or causing speed issues, that's more about the
>>> implementations.  I've created and seen many fast and fluid and complex UIs
>>> on Android, but you sometimes have to do some real work to get them and
>>> they don't always drop right out of the API in your lap :)  A better
>>> argument would be to single out issues with the UI libraries and talk about
>>> how to improve them.  This has little-to-nothing to do with implementation
>>> language.
>>>
>>> On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:

 Java-based Android is very slow and memory consuming.
 and the XML based UI components are far from flexible.

 if Android sdk provides an html5  + javascript alternative, it would
 greatly improve the android  app possibilities.

 as we have seen more and more popular apps are written by html, css and
 javascript.

 i think it is a good time to provide a javascript based SDK,

 with a standardized Android UI framework like Twitter's bootstrap,
 every web developer can develope his app with ease.

 the webkit and v8 are every mature to google.

 why should we stille using java? which is slow and  memory consuming?



>>  --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To po

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-11 Thread Kristopher Micinski 
I don't get your point: Java needs a runtime. JavaScript needs a
runtime.  Both of them need runtimes.  He never said Dalvik was
"slow," but everything can be optimized.  Does native code run faster
than interpreted / JIT code?  Probably.  The *exact same thing* is
going to be an issue with JavaScript.

So really, what is JS buying you that Java cannot?

I'm pretty sure you're just trolling at this point, since nobody can
seriously have this opinion if they know anything about VM or system
design.

Kris


On Mon, May 12, 2014 at 1:02 AM, 李白|字一日  wrote:
> in effect, you are making the acknowledgement that java is slow and fat not
> just because of the dalvik.
>
> even with ART, there is no evidence that Java will be more efficient, though
> there may be some improvement.
>
>
>
>
> 2014-05-12 11:22 GMT+08:00 bjv :
>>
>> Ugh! You don't get it and likely never will. There are so many things
>> wrong with your assumptions/statements in all of these threads. It really
>> isn't worth the time to debunk them all.
>>
>> But for what its worth, there is small overhead with respect to running
>> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
>> interpreted language. Outside of the various ASM-JS experiments, Your
>> html5+JS likely will always be interpreted. In a broad comparison, it will
>> almost always be slower. Your thinking that you get to share all those JS
>> object goodies between various apps/components is in itself a cause for
>> concern.
>>
>> In an effort to remove the Dalvik overhead on Android, the Android guys
>> are now rolling out ART (a variant of llvm) that will transfer most of that
>> overhead to installation time. At that point, Java isn't going to be much
>> different than C++ from an execution perspective.
>>
>>
>> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>>>
>>> if it is not, why should you go native with c/c++ based ndk programming?
>>>
>>> it is surely related to the programming language.
>>>
>>> javascript 's speed acceleration is also related to the language and its
>>> optimization, which is almost always c/c++.
>>>
>>> i have never experienced the fast feeling of java technology both in
>>> desktop or server side.
>>>
>>> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am
>>> i fooled?
>>>
>>> eclipse is famous for it's slow and memory consuming, though it is the
>>> greatest  ide i ever used.
>>>
>>> javascript based ide, like local compiled c9.io is very fast and
>>> responsive, thought it is not that mature.
>>>
>>> why ? ? ?
>>>
>>> and if android ui design can be written directly in html + css, it has
>>> all the flexibility css and html have now. If you know the web technologies,
>>> you should know what i mean.
>>>
>>> it is meaningless to discuss about the languages' performance, but the
>>> trend is that javascript will play a more important role in server side
>>> programming, hardware based programming and browser side programming.
>>>
>>>
>>> 2014-05-12 1:03 GMT+08:00 Colin M :
>>>
 I'll ignore the unqualified claim that the slowness of Android is due to
 Java.

 It sounds like your complaint is that you can't develop native apps in
 your preferred language and that you're using an outdated claim about Java
 to support your desire to change the current language of choice for Android
 development.

 The XML based components can all be done via code.  Do you have an
 example of how they are "far from flexible"?  There are many limitations,
 but you are welcome to write your own custom Views to get around any
 limitations.  I have many of my own complaints about some of the UI system,
 but I have no reason to believe the current state of things would be faster
 or more flexible if it were in another language.  That's not the thing
 limiting flexibility or causing speed issues, that's more about the
 implementations.  I've created and seen many fast and fluid and complex UIs
 on Android, but you sometimes have to do some real work to get them and 
 they
 don't always drop right out of the API in your lap :)  A better argument
 would be to single out issues with the UI libraries and talk about how to
 improve them.  This has little-to-nothing to do with implementation
 language.

 On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:
>
> Java-based Android is very slow and memory consuming.
> and the XML based UI components are far from flexible.
>
> if Android sdk provides an html5  + javascript alternative, it would
> greatly improve the android  app possibilities.
>
> as we have seen more and more popular apps are written by html, css and
> javascript.
>
> i think it is a good time to provide a javascript based SDK,
>
> with a standardized Android UI framework like Twitter's bootstrap,
> every web developer can develope his app with ease.
>
> the webkit and

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-11 Thread 李白|字一日 
in effect, you are making the acknowledgement that java is slow and fat not
just because of the dalvik.

even with ART, there is no evidence that Java will be more efficient,
though there may be some improvement.




2014-05-12 11:22 GMT+08:00 bjv :

> Ugh! You don't get it and likely never will. There are so many things
> wrong with your assumptions/statements in all of these threads. It really
> isn't worth the time to debunk them all.
>
> But for what its worth, there is small overhead with respect to running
> Java/Dalvik on Android. That said, it is mostly upfront. JS is an
> interpreted language. Outside of the various ASM-JS experiments, Your
> html5+JS likely will always be interpreted. In a broad comparison, it will
> almost always be slower. Your thinking that you get to share all those JS
> object goodies between various apps/components is in itself a cause for
> concern.
>
> In an effort to remove the Dalvik overhead on Android, the Android guys
> are now rolling out ART (a variant of llvm) that will transfer most of that
> overhead to installation time. At that point, Java isn't going to be much
> different than C++ from an execution perspective.
>
>
> On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>
>> if it is not, why should you go native with c/c++ based ndk programming?
>>
>> it is surely related to the programming language.
>>
>> javascript 's speed acceleration is also related to the language and its
>> optimization, which is almost always c/c++.
>>
>> i have never experienced the fast feeling of java technology both in
>> desktop or server side.
>>
>> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am
>> i fooled?
>>
>> eclipse is famous for it's slow and memory consuming, though it is the
>> greatest  ide i ever used.
>>
>> javascript based ide, like local compiled 
>> c9.iois
>>  very fast and responsive, thought it is not that mature.
>>
>> why ? ? ?
>>
>> and if android ui design can be written directly in html + css, it has
>> all the flexibility css and html have now. If you know the web
>> technologies, you should know what i mean.
>>
>> it is meaningless to discuss about the languages' performance, but the
>> trend is that javascript will play a more important role in server side
>> programming, hardware based programming and browser side programming.
>>
>>
>> 2014-05-12 1:03 GMT+08:00 Colin M :
>>
>> I'll ignore the unqualified claim that the slowness of Android is due to
>>> Java.
>>>
>>> It sounds like your complaint is that you can't develop native apps in
>>> your preferred language and that you're using an outdated claim about Java
>>> to support your desire to change the current language of choice for Android
>>> development.
>>>
>>> The XML based components can all be done via code.  Do you have an
>>> example of how they are "far from flexible"?  There are many limitations,
>>> but you are welcome to write your own custom Views to get around any
>>> limitations.  I have many of my own complaints about some of the UI system,
>>> but I have no reason to believe the current state of things would be faster
>>> or more flexible if it were in another language.  That's not the thing
>>> limiting flexibility or causing speed issues, that's more about the
>>> implementations.  I've created and seen many fast and fluid and complex UIs
>>> on Android, but you sometimes have to do some real work to get them and
>>> they don't always drop right out of the API in your lap :)  A better
>>> argument would be to single out issues with the UI libraries and talk about
>>> how to improve them.  This has little-to-nothing to do with implementation
>>> language.
>>>
>>> On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:

 Java-based Android is very slow and memory consuming.
 and the XML based UI components are far from flexible.

 if Android sdk provides an html5  + javascript alternative, it would
 greatly improve the android  app possibilities.

 as we have seen more and more popular apps are written by html, css and
 javascript.

 i think it is a good time to provide a javascript based SDK,

 with a standardized Android UI framework like Twitter's bootstrap,
 every web developer can develope his app with ease.

 the webkit and v8 are every mature to google.

 why should we stille using java? which is slow and  memory consuming?



>>  --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-11 Thread bjv 
Ugh! You don't get it and likely never will. There are so many things wrong 
with your assumptions/statements in all of these threads. It really isn't 
worth the time to debunk them all.

But for what its worth, there is small overhead with respect to running 
Java/Dalvik on Android. That said, it is mostly upfront. JS is an 
interpreted language. Outside of the various ASM-JS experiments, Your 
html5+JS likely will always be interpreted. In a broad comparison, it will 
almost always be slower. Your thinking that you get to share all those JS 
object goodies between various apps/components is in itself a cause for 
concern.

In an effort to remove the Dalvik overhead on Android, the Android guys are 
now rolling out ART (a variant of llvm) that will transfer most of that 
overhead to installation time. At that point, Java isn't going to be much 
different than C++ from an execution perspective.

On Sunday, May 11, 2014 1:41:41 PM UTC-5, 李白，字一日 wrote:
>
> if it is not, why should you go native with c/c++ based ndk programming?
>
> it is surely related to the programming language.
>
> javascript 's speed acceleration is also related to the language and its 
> optimization, which is almost always c/c++.
>
> i have never experienced the fast feeling of java technology both in 
> desktop or server side.
>
> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am 
> i fooled?
>
> eclipse is famous for it's slow and memory consuming, though it is the 
> greatest  ide i ever used. 
>
> javascript based ide, like local compiled 
> c9.iois
>  very fast and responsive, thought it is not that mature.
>
> why ? ? ?
>
> and if android ui design can be written directly in html + css, it has all 
> the flexibility css and html have now. If you know the web technologies, 
> you should know what i mean.
>
> it is meaningless to discuss about the languages' performance, but the 
> trend is that javascript will play a more important role in server side 
> programming, hardware based programming and browser side programming.
>
>
> 2014-05-12 1:03 GMT+08:00 Colin M >:
>
>> I'll ignore the unqualified claim that the slowness of Android is due to 
>> Java.
>>
>> It sounds like your complaint is that you can't develop native apps in 
>> your preferred language and that you're using an outdated claim about Java 
>> to support your desire to change the current language of choice for Android 
>> development.
>>
>> The XML based components can all be done via code.  Do you have an 
>> example of how they are "far from flexible"?  There are many limitations, 
>> but you are welcome to write your own custom Views to get around any 
>> limitations.  I have many of my own complaints about some of the UI system, 
>> but I have no reason to believe the current state of things would be faster 
>> or more flexible if it were in another language.  That's not the thing 
>> limiting flexibility or causing speed issues, that's more about the 
>> implementations.  I've created and seen many fast and fluid and complex UIs 
>> on Android, but you sometimes have to do some real work to get them and 
>> they don't always drop right out of the API in your lap :)  A better 
>> argument would be to single out issues with the UI libraries and talk about 
>> how to improve them.  This has little-to-nothing to do with implementation 
>> language.
>>
>> On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:
>>>
>>> Java-based Android is very slow and memory consuming.
>>> and the XML based UI components are far from flexible.
>>>
>>> if Android sdk provides an html5  + javascript alternative, it would 
>>> greatly improve the android  app possibilities.
>>>
>>> as we have seen more and more popular apps are written by html, css and 
>>> javascript.
>>>
>>> i think it is a good time to provide a javascript based SDK,
>>>
>>> with a standardized Android UI framework like Twitter's bootstrap, every 
>>> web developer can develope his app with ease.
>>>
>>> the webkit and v8 are every mature to google.
>>>
>>> why should we stille using java? which is slow and  memory consuming?
>>>
>>>
>>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-11 Thread Kristopher Micinski 
Everything you are saying here is

"I have heard Java is slow, and that's what is probably making Android
slow!  Here's an example of some things I think are slow because of
Java.  Now I'm going to apply this as evidence to the entire Android
platform to show why Java must be slow on it."

Please stop, this is 100% uninformed.

If you want to come back with any kind of solid performance numbers
reinforcing your points it might make sense, but it seems like all
you're doing is trying to say that Java is slow, and that somehow
JavaScript would be faster.  This really doesn't make any sense at
all, and it's silly to try to keep on arguing with absolutely no
empirical evidence to justify any of the claims you're making.

Kris


On Sun, May 11, 2014 at 2:41 PM, 李白|字一日  wrote:
> if it is not, why should you go native with c/c++ based ndk programming?
>
> it is surely related to the programming language.
>
> javascript 's speed acceleration is also related to the language and its
> optimization, which is almost always c/c++.
>
> i have never experienced the fast feeling of java technology both in desktop
> or server side.
>
> i never experienced fast  feeling in android, eclipse, java ee, j2me.  am i
> fooled?
>
> eclipse is famous for it's slow and memory consuming, though it is the
> greatest  ide i ever used.
>
> javascript based ide, like local compiled c9.io is very fast and responsive,
> thought it is not that mature.
>
> why ? ? ?
>
> and if android ui design can be written directly in html + css, it has all
> the flexibility css and html have now. If you know the web technologies, you
> should know what i mean.
>
> it is meaningless to discuss about the languages' performance, but the trend
> is that javascript will play a more important role in server side
> programming, hardware based programming and browser side programming.
>
>
> 2014-05-12 1:03 GMT+08:00 Colin M :
>>
>> I'll ignore the unqualified claim that the slowness of Android is due to
>> Java.
>>
>> It sounds like your complaint is that you can't develop native apps in
>> your preferred language and that you're using an outdated claim about Java
>> to support your desire to change the current language of choice for Android
>> development.
>>
>> The XML based components can all be done via code.  Do you have an example
>> of how they are "far from flexible"?  There are many limitations, but you
>> are welcome to write your own custom Views to get around any limitations.  I
>> have many of my own complaints about some of the UI system, but I have no
>> reason to believe the current state of things would be faster or more
>> flexible if it were in another language.  That's not the thing limiting
>> flexibility or causing speed issues, that's more about the implementations.
>> I've created and seen many fast and fluid and complex UIs on Android, but
>> you sometimes have to do some real work to get them and they don't always
>> drop right out of the API in your lap :)  A better argument would be to
>> single out issues with the UI libraries and talk about how to improve them.
>> This has little-to-nothing to do with implementation language.
>>
>> On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:
>>>
>>> Java-based Android is very slow and memory consuming.
>>> and the XML based UI components are far from flexible.
>>>
>>> if Android sdk provides an html5  + javascript alternative, it would
>>> greatly improve the android  app possibilities.
>>>
>>> as we have seen more and more popular apps are written by html, css and
>>> javascript.
>>>
>>> i think it is a good time to provide a javascript based SDK,
>>>
>>> with a standardized Android UI framework like Twitter's bootstrap, every
>>> web developer can develope his app with ease.
>>>
>>> the webkit and v8 are every mature to google.
>>>
>>> why should we stille using java? which is slow and  memory consuming?
>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to android-developers@googlegroups.com
>> To unsubscribe from this group, send email to
>> android-developers+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Android Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/android-developers/4UrtNOPympc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> android-developers+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+u

Re: [android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-11 Thread 李白|字一日 
if it is not, why should you go native with c/c++ based ndk programming?

it is surely related to the programming language.

javascript 's speed acceleration is also related to the language and its
optimization, which is almost always c/c++.

i have never experienced the fast feeling of java technology both in
desktop or server side.

i never experienced fast  feeling in android, eclipse, java ee, j2me.  am i
fooled?

eclipse is famous for it's slow and memory consuming, though it is the
greatest  ide i ever used.

javascript based ide, like local compiled c9.io is very fast and
responsive, thought it is not that mature.

why ? ? ?

and if android ui design can be written directly in html + css, it has all
the flexibility css and html have now. If you know the web technologies,
you should know what i mean.

it is meaningless to discuss about the languages' performance, but the
trend is that javascript will play a more important role in server side
programming, hardware based programming and browser side programming.


2014-05-12 1:03 GMT+08:00 Colin M :

> I'll ignore the unqualified claim that the slowness of Android is due to
> Java.
>
> It sounds like your complaint is that you can't develop native apps in
> your preferred language and that you're using an outdated claim about Java
> to support your desire to change the current language of choice for Android
> development.
>
> The XML based components can all be done via code.  Do you have an example
> of how they are "far from flexible"?  There are many limitations, but you
> are welcome to write your own custom Views to get around any limitations.
>  I have many of my own complaints about some of the UI system, but I have
> no reason to believe the current state of things would be faster or more
> flexible if it were in another language.  That's not the thing limiting
> flexibility or causing speed issues, that's more about the implementations.
>  I've created and seen many fast and fluid and complex UIs on Android, but
> you sometimes have to do some real work to get them and they don't always
> drop right out of the API in your lap :)  A better argument would be to
> single out issues with the UI libraries and talk about how to improve them.
>  This has little-to-nothing to do with implementation language.
>
> On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:
>>
>> Java-based Android is very slow and memory consuming.
>> and the XML based UI components are far from flexible.
>>
>> if Android sdk provides an html5  + javascript alternative, it would
>> greatly improve the android  app possibilities.
>>
>> as we have seen more and more popular apps are written by html, css and
>> javascript.
>>
>> i think it is a good time to provide a javascript based SDK,
>>
>> with a standardized Android UI framework like Twitter's bootstrap, every
>> web developer can develope his app with ease.
>>
>> the webkit and v8 are every mature to google.
>>
>> why should we stille using java? which is slow and  memory consuming?
>>
>>
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Android Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/android-developers/4UrtNOPympc/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: looking for HTML5 and javascript based sdk....

2014-05-11 Thread Colin M 
I'll ignore the unqualified claim that the slowness of Android is due to 
Java.

It sounds like your complaint is that you can't develop native apps in your 
preferred language and that you're using an outdated claim about Java to 
support your desire to change the current language of choice for Android 
development.

The XML based components can all be done via code.  Do you have an example 
of how they are "far from flexible"?  There are many limitations, but you 
are welcome to write your own custom Views to get around any limitations. 
 I have many of my own complaints about some of the UI system, but I have 
no reason to believe the current state of things would be faster or more 
flexible if it were in another language.  That's not the thing limiting 
flexibility or causing speed issues, that's more about the implementations. 
 I've created and seen many fast and fluid and complex UIs on Android, but 
you sometimes have to do some real work to get them and they don't always 
drop right out of the API in your lap :)  A better argument would be to 
single out issues with the UI libraries and talk about how to improve them. 
 This has little-to-nothing to do with implementation language.

On Saturday, May 10, 2014 10:50:44 AM UTC-7, 李白，字一日 wrote:
>
> Java-based Android is very slow and memory consuming.
> and the XML based UI components are far from flexible.
>
> if Android sdk provides an html5  + javascript alternative, it would 
> greatly improve the android  app possibilities.
>
> as we have seen more and more popular apps are written by html, css and 
> javascript.
>
> i think it is a good time to provide a javascript based SDK,
>
> with a standardized Android UI framework like Twitter's bootstrap, every 
> web developer can develope his app with ease.
>
> the webkit and v8 are every mature to google.
>
> why should we stille using java? which is slow and  memory consuming?
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.