Web based tools and languages don't even work properly for the web nowadays.

JS for example is bloaty, inadequate

and people try to make it do things it was never designed to do

HTML is a MARKUP LANGUAGE, it is meant to do layout, framing, formatting, etc of a DOCUMENT.

So why would it be a good idea to build an entire mobile operating system around this?

I find the situation to be better than it ever has been to be honest. It is certainly better than it was 10 years ago.

How? Why? It has it's warts, no doubt about that, but honestly I find it to be a wonderfully useful language. It is also extremely powerful and expressive - it is just tied up in an unfortunate straight-jacket of C-like syntax. Sure it can be ugly, but it works - and it works well.

Anyway, that is becoming less and less of an issue because it is (for better or worse) becoming quite common as intermediary language for other languages to target (GWT, CoffeScript, etc.)

That is more of a people problem than a language problem... It happens with all languages, just more so with popular ones.

The same reason many modern GUI layout tools use markup-like systems (XAML, Glade, XUL, etc.) - you need to do layout, framing, formatting, etc in any GUI...

Relative to other languages, it is still in the stone age. Better than 10years ago isn't really an excuse. Web tooling is pathetic.

Besides the warts, it is inherently difficult to make fast. Making something which is almost axiomatically slow the bed rock of web technology is foolish.

Its barely palatable on the web, do not push it into the app space where there are much higher expectations. People have come to expect the web to be a sub optimal experience.

Use a real intermediary language. Don't shoe horn JavaScript into that position.

You know things are bad when a selling point of JS is "Its good because its so ugly others hide it as much as possible"

XAML is for marking up applications. It has a 1:1 mapping to the .NET object model. Glade is closer to XAML than it is to HTML.

Just because they're all markup doesn't mean they're all the same. HTML is almost comically bad at marking up applications.

The HTML layout model is a mish mash of 100 bad ideas.

I was talking about web development in general - not comparing to other languages... Besides - it makes no sense at all to mix metaphors like that, languages themselves have next to nothing to do with development as a whole - it is just a small cog in the machine.

And web development tooling is great imo - some people just don't like having 500+ options to choose from I guess... There doesn't have to be a "one true way" answer to every problem.

That is categorically false - you have no idea what you are talking about. Modern JS engines are extremely performant - in fact much more impressively so when you consider they have to work directly from human readable source code. Sure, compared to C, Java, and C# they have weak spots - but those are compiled languages (or at the least they do byte code compilation) - and even then it is usually only a factor or 3 slower...

Compared to other straight-up runtime interpreted languages? Extremely competitive, often greatly superior. I do not know where you get the idea that it is slow...

Regardless, it is a stupid argument anyway. Languages are not fast or slow - interpreters and compilers and binary executables are - and they can be quite easily improved without changing a language. Even then, it makes little difference in the grand scheme of things. There are things JS is extremely good at (async programming being one of them) and some things it isn't (low level byte manipulation, etc.) The same arguments apply to any language. It isn't all about how fast it goes at the end of the day.

Yes, the web is a sub-optimal experience. For lots of reasons - design by committee feature sets, incompatibilities, etc. etc. No argument. Its also constantly changing and a challenge to keep up with. But people overlook what it buys you...

Sure, it is much easier to write a C# app targeting .NET, or a java app targeting a JRE... The fact is neither of those will ever be universal.

There are 3 major mobile platforms - Windows Phone, Android, and iOS. They have 3 completely incompatible development frameworks, but they can all run HTML5 apps quite well... So can desktops (any OS), so can just about anything with a chip in it. HTML5 makes up for its shortcomings by being deployable almost anywhere - and not in the "run anywhere" fairytale land of Java where it is a figurative statement - I mean really deployable anywhere.

Makes perfect sense to me to cut out the middleman and build a mobile OS designed with HTML5 apps as a 1st class citizen... You can turn up you nose at it all you want - I'll still have a job in 10 years

If what you want is a human readable IM language, It is as good as any other. If you want byte code then we are talking about two different things... Byte code will never fly on the internet (been tried - failed terribly -at least twice)...

I didn't say that was a selling point - just pointing out reality. Syntax isn't everything - CoffeScript and JavaScript are in fact the same language semantically, the only difference is syntax - and CoffeeScript is quite lovely to look at. Syntax can be fixed quite easily, and it eventually will be.

The point is that semantically javascript is a great language for its current use case - which is wiring up logic to GUIs. [\q]

Mine is that its not the best, or anything close.

[q]
Your arguing about the semantics of the markup language... What does any markup language need? A fast parser, a good interpreter, a layout and rendering engine....

And yet it is still around after 20 years, and becomes more and more ubiquitous as time goes by. It changes when it needs to. Things like XAML will be a faded memory in 5 years or so...

Comparatively is the only way to go about such things, since the argument is that JS+HTML is god awful choice for app development.

The tooling state is laughable, compared to C#, there is no comparison when it comes to things like debugging. Hats off to the JS support in Blend and Visual Studio, and those developers are wizards, but its still comparatively terrible.

You say "fast despite inherent limitations" (non static typing leading to stupid design and compile time assumptions, no byte code compilation, etc) and I say "slow because of inherent limitations". Its two sides of the same coin.

The fact that JS is as fast as it is, is a testament to the immense skill of the engineers behind the JS engines.

Actually, no. JS has some uniquely JS features which make it slower than it should be. Namely, is type system makes it difficult to do type based optimizations at JIT level. Sure you can do cool type inferencing, but you quickly run across an even more limited time budget than traditional JIT compilers.

Here we come to a fundamental disagreement. I categorically reject the notion that write once run anywhere is desirable.

I didn't buy it when Java said it, andi don't buy it now. It leads to a poor and confusing user experience.

I believe in code sharing between mobile apps by using common back ends with native front ends. On the web, I'm cool with JS and HTML. Let the web be the web. But for Christ's sake, let apps be apps.

I wouldve offed myself years ago if I had to deal with web technology.

I'm interested to the instances where its failed, but ultimately, this is a discussion about HTML and JS for use as a fundamental app platform.

Syntax and peformance are separate things. Only in JS, things are slow because of the syntax.

They are used differently. HTML defines structure. XAML is a declarative way to instantiate .NET objects. It can easily be extended to do whatever you want, it can map to arbitrary .NET objects.

You can't really do that in HTML, which is a shame, because it'd be a tremendous improvement alone. You're stuck with awkward solutions which is funny because it makes your code less declarative.

Besides, XAML has the concept of controls, events, properties, data binding, static methods, etc.

Just because XAML is markup, and HTML is markup.. doesn't make HTML good because XAML is good.

You're aware XAML is a key part of the Windows 8 app platform, right? You're aware that the XAML team is part of the Windows Division, right?

XAML going anywhere is a Pipedream. It'll be on 800 million devices in a years time.

So far what's really lacking are devices compatible with conventional (non Android) Linux stack. Samsung's devices for Tizen didn't come out yet to address this.

But at the end of the day it is all about the money, so the customer gets what s/he asks for.

May I ask a very silly, naive question? Is there any real, organized marketing push behind this, or is it just a bunch of geeks hobbying around.

var t0=new Date().getTime();
var count=10000;
var x=0;
var coords=new Array(count);
var coord_i = null;
var coord_j = null;

for(var i=0; i < count; i++) {
coords[ i ] = [ i,i,i ];
}

for(var j=0; j < count; j++) {
coord_j = coords[j];
for(var i=0; i < count; i++) {
coord_i = coords[ i ];
coord_i[0]=(coord_i[0]+coord_j[1]) * .5;
coord_i[1]=(coord_i[1]+coord_j[2]) * .5;
coord_i[2]=(coord_i[2]+coord_j[0]) * .5;
}
}

for(var i=0; i < count; i++) {
x+=coords[ i ][0]+coords[ i ][1]+coords[ i ][2];
}

var t1=new Date().getTime();
document.getElementById("out").innerHTML=x + ' ' + (t1-t0) + ' ';

Like static typing...it does have a use (though whether you benefit from it is a different matter), it explicitly limits the number of states a variable may hold and helps catch errors at compile time.

var a = x.foo() + 'x'; // what is a?

For this reason, I'd argue javascript is a poor choice for mission critical applications like those at NASA.

There are more problems, like the inability to define proper "classes", which make javascript both slower and less error proof.

Again, maybe you prefer not to use classes and find the prototype substitute good enough for you.

But whether it's an enhancement or restriction of the language depends on your point of view - it's a matter of opinion.

Also, we've build other languages on top of javascript because browsers don't give us much choice, not because it particularly makes sense to do so otherwise.

Did you know that browsers will soon support a whole lot more than just SMS.

May be, but it doesn't seem that anyone besides Samsung is going to release any devices.

I said web development... as in JS as it applies to web development is better than it was 10 years ago. There is no comparison there, because there is nothing to compare it to.

Whatever though - I get your point.

Now you getting into religious arguments Personally, I would argue that static typing is just a compiler optimization - it isn't a language feature. Its a stupid design decision because its primary purpose is to make compilers faster - it isn't about developer productivity at all. Its about forcing developers to manually disclose things that a computer can easily figure out at runtime.

To each their own on that one - I use 7 or 8 languages routinely, about half statically typed and the other half dynamic. I prefer dynamic any day of the week, I don't like having to put training wheels on my code.

Ill give MS credit for allowing the CLR to do it either way though - if they didnt' allow dynamic typing the number of languages running on it would have stopped at 1...

The exact same thing can be said about C# or Java. Time, money, and good engineering can turn a weakness into a strength...

Again - "features" that exist to make compilers happy and developers sad don't interest me much...

I would argue that the user experience depends more on the developer than the tools used. Ill even concede it is much easier to create a consistent user experience when using a full stack application development framework - as long as you are only targeting that single stack. I often care more about how many screens I can reach - and it is far easier to spend the time and write a good UI in HTML5 that you can deploy everywhere. It depends of course - it isn't good for everything - but that doesn't make it bad.

I do too for the most part. I'm pragmatic - sometimes it is easier that way to get a good result. But I find I choose that route less and less often because the JS/HTML approach is improving so much. I'm not religious about it - I just think saying it is crap and nonviable is extremely short-sighted...

Um.. Java. Flash. Silverlight for the most part too. Im not saying they are dead for app development, but they are all dead for general purpose web development...

Look at meteor. Or angularjs. Or knockout. Or about 20 other up and coming declarative frameworks. Same thing... That is my point - HTML eventually adopts anything worth doing. It might not be quite as elegant and refined as XAML, but in the long run it won't matter because it doesn't need yet-another-runtime in order to work.

Markup is markup. XAML is not good because of the markup language - it is good for the reasons you stated above - which are features of the runtime. Most of the same features can (and have been) applied to HTML/JS...

800 million devices with a 2-3 year lifespan... Well see how it goes. I'm actually a fan of Windows 8 - Im not knocking it at all. My point was what they call XAML now will likely be replaced with the-next-new-paradigm in the next 10 years or so. There is always something better around the corner - things like XAML fade away - remember OWL, MFC, etc. Web technologies evolve and adapt...

Because Firefox OS is constructed using HTML, JavaScript and CSS it means you only need basic Web development skills to reach in and completely change the device experience. You could literally change one line of CSS and completely change the way the icons on the homescreen look, or re-write some core JavaScript files that handle phone-calls.

Just to be clear, this example did NOT measure script parsing overhead, which was mere milliseconds on my machine and an acceptable one-time cost. What was slow was the run time inside the loop - several seconds in each case. I'm baffled why you're claiming 90% of the execution time is due to "parsing, compilation, etc"? Obviously we can't be talking about the same thing.

There are several ways we could have eliminated the objects, but given that they were what I was measuring the overhead of this would have defeated the point.

It makes perfect sense. I'm not in the business of caring about what lazy developers prefer. Anyone using HTML/JS to write run anywhere app is pretty much the worst kind of developer I know.

Wake up, developers. At one point, people were more principled than this.

function dostuff() {
var i=9999;
var coords=new Array(i+1);
var ci,cj;

console.profile();
while(--i) {
coords[ i ] = (i + i) / 2;
coords[ i ] = (coords[ i ] + i) / 2;
coords[ i ] = (coords[ i ] + i) / 2;
}
console.profileEnd();
}

I was actually very disappointed with AMD when they told the world they were going to extend the life of x86 with a 64bit variant of it. I sincerely thought that we would be migrated to better architectures by now if AMD hadn't anchored us right back to the x86 platform [...] The whole architecture is shrouded in subtle legacy designs.

I wouldn't want the stagnation that is happening in the x86 platform to extend to ARM SoCs. If it weren't for AMD, we would all be stuck with a 32-bit ISA on x86, with an overly costly and less than optimal upgrade path to Itanium. Unfortunately we've lost the 3rd party chipset market on x86 due to having too few CPU players.

I'm very principled... One of my first principles is that I don't believe that development is the process of becoming attached at the hip to a particular vendor's idea of the right way to do things. HTML/JS might not be perfect, but it has one very significant feature that no other development platform has - no one company is steering the boat.

And since you want to resort to name calling... What is being content to slop up Microsoft or Apple's latest dog food for the sake of it making things easier for you? That sounds pretty lazy to me.

My development platform is the world - yours is just the latest gadget fad...

Nelson,

You don't have to care about my opinion, but can you read your own post in context and tell me it's not pure arrogance?

http://www.osnews.com/thread?535086

You allude to principals, however you've failed to lay them out in the course of this discussion. We've highlighted a shortcoming shared by many native platforms, but instead of acknowledging the truth in that, you resorted to Ad Hominem attacks against all web developers. Regardless of what you think of my opinion, you should at least redact that post since it can't possibly be true; some of the best developers in existence will use HTML/JS despite its shortcomings BECAUSE they want to reach the largest audience.

Well Nelson, here you are using an HTML news &amp; discussion board, what happened to your principals? You're obviously not a hypocrite, so where's the link to the native version of osnews since I'd like to give it a try!

My point being that the web does have it's uses, and even if some of us prefer native apps (including myself btw), we have to admit that they fail to reach as wide an audience as exists on the web.

Instead of denying the benefits of portability, we'd be better off making native frameworks MORE portable so that they could run anywhere without regards to OS/platform. Go ahead and disagree with my opinion, but for gods sake drop the more-principled-than-thou talk.