Linked by Thom Holwerda on Thu 13th Sep 2012 20:00 UTC, submitted by MOS6510
Mozilla & Gecko clones "Over the past year and a half I've been spending more and more of my time working with Mozilla's latest project, Firefox OS. During that time I've fallen in love with the project and what it stands for, in ways that I've never experienced with a technology platform before." I'm not convinced just yet. I hope it succeeds, but I just doubt it actually will.
Thread beginning with comment 535008
To view parent comment, click here.
To read all comments associated with this story, please click here.
galvanash
Member since:
2006-01-25

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


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.

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.


Whats missing? I have a debug console. I can step through code. I can setup watches on variables. I can analyze objects and browse their properties. I can even fiddle with values at runtime and change code as I'm stepping through it...

Again, what is missing exactly? I think you are using the wrong tools...

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.


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 fact that JS is as fast as it is, is a testament to the immense skill of the engineers behind the JS engines.


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

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.


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

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


Yep. Pretty fundamental.

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 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 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 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...

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


Come on now... Its fun! Having to relearn everything every 3 years keeps you on your toes ;)

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.


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...

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


You talking about dynamic typing again I assume... Ive said enough on that I think.

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.


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.

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


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...

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.


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...

Reply Parent Score: 3

Alfman Member since:
2011-01-28

I think you two are getting overly hyped up over what is, at the end of the day, a matter of preference about which technologies you like better.

galvanash,
Yes, javascript promises to lower the barrier to entry for app development. But you've said alot of things I disagree with. 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.

In some languages, string concatenation and arithmetic addition are separate operators to help resolve the ambiguity, but javascript depends on inferred typing.
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.

Nelson,

You are right that no single language is good for everything. But you must accept that portability is very important and useful to many developers and users, they should be able to write once, run anywhere without needing to rewrite it again... You can dismiss portability for yourself, but it really doesn't make sense to dismiss the utility for others.

Edited 2012-09-14 06:41 UTC

Reply Parent Score: 4

galvanash Member since:
2006-01-25

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.


Exactly. I don't like languages that limit the number of states a variable may hold. And the types of errors that are actually caught by type checking at compile time are generally trivial typos and such.

That said, if you do proper unit testing (something you should be doing in either type of language) all the pros of static typing disappear - except for it being faster to compile. Hence why I said that is its only real strength.

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


a is a variable ;)

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


Most of the space stuff tends to use plain old C, which might be statically typed but it isn't strongly typed - which is arguably just as bad from an "avoiding errors" point of view...

Then again, I have read they use quite a bit of Python at JPL - Python isn't all that different from javascript fundamentally - both are dynamically typed. It sure is prettier though...

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


How does using prototypes instead of class make things slower and less error proof? Its just a different way to skin the cat - they both get the job done equally well if you understand the paradigm.

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


I don't consider prototyping a "substitute" for classes - it is the sane way to do it ;)

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


Agreed.

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.


Whether its javascript or some other language - it makes no sense to deliver an opaque intermediary language representation to a browser that is designed to render human readable markup. The human readable part is important for a multitude of reasons, and that includes the logic too...

Reply Parent Score: 2

Nelson Member since:
2005-11-29

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.

Reply Parent Score: 1

Nelson Member since:
2005-11-29


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.


That's true, and fine. I just don't see how its a counter point to excuse poor tooling.


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.


I don't particularly find that to be a win. Dynamic typing make code less readable at a glance, and especially in the case of JS leads to ridiculous decisions like the lack of an integer system.


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...


I think this is a good idea and would rock for JS. Default static typing with optional dynamic typing.



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


Well, I think that there are certain design issues in JavaScript that make it relatively harder to make fast. That's the crux of this argument.



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


I don't know man, as a developer, poor performance makes me sad.


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.


Code reuse greatly alleviates this. Its middle ground between two extremes. Not quite write once run anywhere, but not quite single stack either.



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...


I don't think its improving fast at all. The next improvements to the fundamental technologies are still years off. In the meantime, the deficiencies are unacceptable to me.


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...


Silverlight was never meant to replace the web, only augment it. Remember, HTML5 didn't exist at that time. The only way to write RIAs was using a plugin. Silverlight was the best at this.

It doesn't mean byte code is categorically bad for the web. Hell, the generated , minified, gunk that is JS on most sites is a lot less human readable.


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.


While good, you said it best, it lacks cohesiveness. For Knockout you need to select elements out of the tree and apply bindings and view models manually. There is no declarative databinding because markup can't be extended.

Its not really declarative then, its just a hack. The point is, its an app platform, not the web, you'll need a runtime anyway, so Mozilla used suboptimal tech for a really terrible reason. Developers should reject this crap.


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...


No they have not, because the markup hasn't been leveraged in doing so. JS has. Its not the same thing. Its perfectly reasonable to say HTML is terrible and inadequate, and say XAML is a lot better.



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...


XAML has been around since 2004. Its been used in WPF, Silverlight, Workflow Foundation, XPS, WinRT, Windows Embedded, the Xbox 360, etc

The key difference now is that its part of the Windows Division, not the Developer Division. Its gone from a dev platform to an inherent part of Windows, with all the legacy implications that it brings.

Reply Parent Score: 3