Hacker News Reader

Comment by cliveowen | Hacker News Reader

I wonder if there'll ever be an alternative to Javascript. I'm not talking about those things that eventually get translated to Javascript, I'm talking about a native platform well thought-through and based on a typed language that isn't a mess. Yeah, I know: it's not Javascript that's broken, it's the DOM. I'd argue that both should be replaced by something else, otherwise the future will be 90% native mobile apps, which isn't a bad prospect if you can afford to develop and iterate for two different leading platforms.

View on HN

>Yeah, I know: it's not Javascript that's broken, it's the DOM.

No, JavaScript itself is a ridiculous language. Every time I have to deal with it I grit my teeth. Right now I'm dealing with dates. Luckily JS has a built in Date class! Which, of course, does nearly nothing. If you call "getDay" you get a zero indexed number representing the day of the week. So since there's no formatting functions to print out dates, how do you get the month-day number? Oh, right, you call getDate...

If I didn't know better I would think this abomination were created by someone who thought the secret of PHP's success was being horribly defined.

Try this: date.toLocaleDateString("en-US", {month: "numeric", day: "numeric"});

I want a specific format to our proprietary systems. In C# I can just say "date.Format("dd.MM.YYYY")" or what ever I want.

Granted that's a bit tidier than doing this in JS:

var myProprietaryDateFunction = function(dt) { return dt.getDate()+'.'+dt.getMonth()+'.'+dt.getFullYear(); };

But in JS, you can pass that function around like a village bicycle -when I think back to my C# days, it makes me wonder how I ever did without functions as first class objects and a slew of other really great things about JS. A lot of those things are brainbangers at first, to be sure - but when you finally grasp them (for me, at least) you start to see that the things that make JS "ugly" to the novice are the same things that make it powerful and elegant in the hands of a master. To each his own - and there are things I do really miss about C# from time to time... but for me, I am all too happy trade the tidier date.Format() for the more powerful underlying functional constructs any day.

when I think back to my C# days, it makes me wonder how I ever did without functions as first class objects and a slew of other really great things about JS.

C# has delegates, events, lambda function, properties and async function as language constructs. This is as "first class" as it gets. It also has LINQ.

You forgot to add 1 to dt.getMonth(), because months index 0-11 :)

(and be careful not to accidentally concatenate that 1 instead of add)

uh, this won't have leading zeroes like DD.MM.YYYY format would have

The mistake, perhaps, is that people (us) are trying to shoe horn an application into a Document object model - its in the name for christ sakes! Document! Not application object model!

Not just the DOM, HTTP as well. We're shoehorning state into a stateless system, and inventing new crap like WebSockets to overcome limitations of a system designed for document retrieval. The web has turned into the biggest hack ever.

Bigger than x86? I doubt it. It's fine for things to evolve: so long as the complexity is compartmentalised we can forget about it and move on with our lives.

Like how TCP is a hacked-together impression of reliable transfer over an unreliable medium?

Nothing wrong with layering approaches, but the problem is knowing where to place the borders in order to give clarity at every level.

I don't see the point of websockets, why not just let the browser make normal outbound TCP connections?

I think the main points WebSocket vs. unrestricted TCP sockets is:

1. Support for a browser-appropriate security model (origin-based)

2. Not requiring extra work to pass through HTTP-friendly (and everything-else-hostile) firewalls.

I assume you would apply the same origin policy to the connections.

The firewall point is good, although I don't understand why you would want to block general TCP connections but not websock.

A lot of corporate environments prevent you from connecting to anything but port 80 and 443. Websockets is the only way for you to multiplex your tcp-like connections over port 80.

Right, but I assume they block those other ports for a reason. What is different about websocket that makes that reason no longer apply?

Because: we want a message-based protocol, and we want to make it (comparatively) hard to launch a DDOS attack using visitors to a website.

This!

Document = application interface. It's a great way to abstract the back end from the front end. Unless of course you mush your business logic in with your interface code.

Objective-C is really nice. I don't like Apple, but their development tools are actually fairly good, and the whole API in iOS is, if not necessarily a beautiful piece of engineering (which is subjective), at least thoroughly-documented and easy enough to learn and use. Android is terribly documented and very messy to develop on.

But yeah, it sucks that you can't do cross-platform development unless you like to be tied to a web platforms, which tends to result in inferior user experience.

http://www.xamarin.com compiles C# to native apps for Android, iOS and Windows Phone.

Your best bet on Android is to download the source and use that as your documentation.

> Android is terribly documented and very messy to develop on.

I keep hearing this FUD, but I have no idea where it's coming from. I've never had any problems with the Android documentation. The most annoying part of Android development is probably Eclipse, but I'd rather have a resource intensive IDE that's cross platform than one that only runs on OS X.

In fact, the Android platform has some amazing opportunities for those who are willing to look past the mainstream views on it. Because it's ignored by so many companies/developers, all you have to do is pick an iOS app that is popular and clone it - you are pretty much guaranteed to get lots of users.

>> "The most annoying part of Android development is probably Eclipse"

Hopefully Android Studio[1] will be the solution to that problem.

>> "I keep hearing this FUD, but I have no idea where it's coming from. I've never had any problems with the Android documentation."

I don't think the Android documentation is bad but I find iOS documentation much better. It might just be because I'm more used to the iOS docs (5 years experience vs. 1 year on Android).

[1] http://developer.android.com/sdk/installing/studio.html

Coming from a world of Java (Java SE of no particular platform and Android), I find the iOS documentation surprisingly hard to navigate. In the Java world, it's common for documentation on a class to contain at least a page of introductory material to the class including its purpose, its function, major caveats, some example code, etc. The iOS documentation splits all of that up between Getting Started articles, the class documentation, and separately-downloadable sample code projects. It's all there if you know where to look, but it's inconveniently spread out.

Maybe it is just because I've more experience with iOS documentation that I find it superior then.

> I keep hearing this FUD, but I have no idea where it's coming from. I've never had any problems with the Android documentation.

Let's take just one example from literally hundreds that are scattered all over the API reference alone. The delete() method in SQLiteDatabase -- arguably, a mature part of the Android API, considering it's been there ever since version 1 and is something that almost every application uses. Here: https://developer.android.com/reference/android/database/sql..., java.lang.String, java.lang.String[])

The method takes three arguments, but only two are documented. The description of the whereClause states that "Passing null will delete all rows", while the function description says "To remove all rows and get a count pass "1" ass the whereClause". I presume the difference between the two cases is that passing null as the whereClause will delete all rows without giving a count of how many, but that's really poor taste in describing what the function returns.

This simply isn't ok. It's barely enough for internal use, where you'd probably Skype the guy who wrote it, ask for clarification, and kindly ask that they fix it when/if they have time (or you fix it yourself if possible), but this is very far away from what you want from a serious framework. Let's not even stick iOS here. Look at Qt -- which optimistically would have, what, 10% of the users Android has, and a lot fewer developers -- and their documentation is at the very least complete.

Edit:

> The most annoying part of Android development is probably Eclipse, but I'd rather have a resource intensive IDE that's cross platform than one that only runs on OS X

It's definitely Eclipse, but in its description don't forget "unstable" and "still lacking a decent UI builder".

Dart ( http://www.dartlang.org ) is a attempt by Google. Of course, probably no browser except Chrome (and Opera?) will ever have the Dart VM built-in, but Dart also compiles to javascript for those other browsers.

An issue with Dart is it does not support IE 8. IE 8 still ships with Windows 7 and it is quite popular.

It's not reasonable to throw away all IE 8 traffic just to get Dart's features.

Does Dart support Chrome version 2 [0] or Firefox 3.0.8[1]? Since IE8 stems from that age, March 2009[2]

[0] https://en.wikipedia.org/wiki/Google_Chrome#Release_history [1] http://en.wikipedia.org/wiki/Firefox_release_history [2] http://en.wikipedia.org/wiki/Internet_Explorer_8

It's not reasonable to support an outdated browser version with an inferior Javascript engine, or to single out Internet Explorer as a browser for which older versions should still be supported, imho.

(disclaimer: I'm building a webapp that has to work in IE 8)

I wouldn't mind if Dart didn't support older versions of Chrome or Firefox because that's just much different than IE 8.

Most people who are running IE 8 are random non-technical folks who are using the browser that came with their OS. They don't even know what "internet explorer" is.

There are probably a small sub-set of people who have Firefox 3.x because their brother's uncle's nephew installed it once like 5 years ago but I honestly don't mind losing these people as potential customers because it's such a ridiculously small %. I also feel like these are the type of people who would be more than capable of upgrading if they kept seeing messages like "your browser is old as time itself, upgrade or find someone who knows how to do it for you!" through friend/family assistance.

I can't justify throwing away almost 10% (IE 8) market share for Dart and the idea of supporting multiple versions of the app is just too much work for too little return.

IE8 usage is under 8% so it's possible for some people/organizations to stop supporting it. In another year, I would expect market share to be under 5%.

http://gs.statcounter.com/#browser_version-ww-daily-20130615...

IE10 has more usage. Hopefully, Win 8.1 is successful for Microsoft and XP usage drops significantly.

There can be many markets where IE usage is much higher than the worldwide average. My previous job had IE as a whole with ~60% share. You can't just decide to ditch a browser because of averages, you need to look at your own data.

Corporate Intranet: within epsilon of 100% IE 8, at the moment. My current job and the last one always had some outdated version of Internet Exploder as the desktop standard (which I ignored for running anything other than in-house junk -- no way I'm taking MSIE out into the wild)

Absolutely. Write in whatever language you like, compile to asm.js - that way you're running in the browser, at about half native speed.

__at about half native speed.__

Which may well the right trade off for many apps.

Asm.js is not an alternative to JavaScript, though. It is JavaScript, just a really mangled and ugly subset of it.

cliveowen was clearly talking about "an alternative to Javascript" and "not [...] those things that eventually get translated to Javascript". Anything targeting Asm.js is merely targeting JavaScript.

The "half native speed" claim is quite dubious, at best. Even if it were realistic, that's still quite a horrible decrease in performance relative to native code. It's not as bad as the typically much worse disparity, but it's still not good at all.

Talk about JavaScript being replaced wholesale should be regarded as therapy. Therapy to dull the realisation that JavaScript is now immortal because it gained such massive reach and entrenchment. It's the web counterpart to C the immortal.

"Write in whatever language you want" - For languages that need a VM (most garbage collected languages for example) you would need to port the VM to asm.js. That's a job in itself. Then when a user hits your site they would need to upload all the asm.js for the VM at least the first time (think about that on a sketchy mobile connection). On top of that the performance of C++ to asm.js is about half native. The performance of e.g. a ruby interpreter running in a VM that was ported to asm.js could be a long way off native. The performance of e.g. Ruby might be acceptable on a server where you can throw more horsepower at it. But on a client? Client code is the most performance critical there is. The user expects instant feedback when they swype. Even if there was a native Ruby VM (for example) on the client it still might not meet your performance requirements not to mind one that runs in asm.js. It was the movement back to the server side with web programming that enabled the diversity of language use in the 90s. On the client the same old restrictions apply i.e. we would need something to make those VM's faster than their native versions, not slower.

Asm.js is a non-starter for most of the high-level languages out there due to its lack of GC.

What's wrong with the DOM? (Sorry if this is a stupid question)

Nothing wrong. But i guess DOM manipulation can be painfull sometimes. But if you are going to develop a web app you'll have to use the dom.

Crockford has some very interesting things to say about it:

http://yuiblog.com/blog/2006/10/20/video-crockford-domtheory...

What's wrong is what the DOM is and what it isn't. The DOM is the Document Object Model data structure along with the parametrized routines that operate on that data structure. It exposes every way in which the apparent simplicity of XML is far from the reality. Then the operations that it provides do little to manage the complexity. They are only relatively "primitive" operations, like getters and setters for the data structure, plus a few things like "getElementsByTagName". That gets a set of elements from which you then should or must exclude what you don't want. If you want a convenient wrapper for the DOM API, you have to find or build one.

I don't necessarily disagree with you that there are problems with the DOM API. However, would you rather that higher level APIs were designed by standards committees, or would you rather they were worked on and "de facto" standardized in the wild - the situation we have now. The situation we have now is a case of worse is better I think.

Google were planning to do some interesting experiments with JS and the DOM - they're hinted at in the Blink announcements but can't remember seeing any more about them yet

I develop applications that skip the browser(s) and HTML. But it's not totally cross platform. But then again I don't develop for Joe Public most of the time either....

Isn't this the objective of Dart?

Reply on news.ycombinator.com