hayley 365


always hating on javascript

20 Jan 2014

2014-01-20 12:29:06 -0600

I'm procrastinating.

What I'm supposed to be working on is figuring out authentication systems, which will be the first big hurdle in the process of getting comfortable with the idea of having a pay-for app.

But no.

What I'd like to work on is building something in Opal or Dart. The problem is that I'm enough of a beginner that there's going to be a lot of aimless faffing about, which I suppose is somewhat redundant.

I haven't touched Dart since before it went stable, and I haven't touched Opal at all. I just recently discovered it. Actually, I think I might have known about it before, but didn't realize how mature it was. Or perhaps it wasn't anywhere near as mature the first time that I heard about it.

why I hate JavaScript

Playing with Python recently, and just experience in general, has really driven home something I didn't realize much before about why I hated JavaScript.

I knew I hated the syntax. Ruby and Python are so much more to my style. CoffeeScript is a hell of an improvement. But something that's become more and more clear recently is that the syntax is only a part of it.

Having a sane standard library is the other part.

JavaScript can't ever really improve

The fundamental problem with JavaScript is that everyone is so bloody concerned about breaking backwards compatibility. so nothing ever truly moves forward.

Fundamentally broken APIs never get fixed. People are hesistant to use new features for fear that user's browsers won't support them.

Now the second one isn't so bad because you can always write a shim or whatever, but here it is, what, 15 years later and we're still stuck with a horrible standard library for handling dates.

// today is January 20th, 2014
now = new Date()
// 114 - seriously? Wasn't Y2K enough of a pending threat in 1995 for
// Brendan Eich to be a little bit concerned about it?
// 2014 - that's a little better but getYear() should be the one to return this
// 0 - in JavaScript, months are zero-indexed, days aren't and years aren't, just months
// 1 - WTF? Because obviously when I think about what a `getDay()` function should
// return, I immediately think about things like a zero-indexed
// Sunday to Saturday based number
// 20 - oh, okay, but when I think of `getDate()` I think of what `toString()` returns

Compare that to say Ruby, which isn't anywhere near insane.

now = Time.now
# 20 - exactly what you'd expect
# 1 - exactly what you'd expect
# 2014 - am I making my point yet?

I never ever look at JavaScript code and think, "wow, how elegant". Or "that's exactly how I'd expect things to work".

And the thing is, I don't know about Ruby's early days. Maybe it had similarly bizarre choices on returning zero-indexed things in places where everything else returns one-indexed. Or perhaps its method names were similarly bizarre in the early days.

But the huge fundamental difference is that Ruby can make backwards incompatible changes because the programmer gets to decide when they do the upgrade. They don't have to worry about whether their users' browsers will be upgraded or not because it all gets decided in the programmer's development environment.

Of course, the same is true for Python and yet they appear to still be having problems getting people to make the switch to 3.0, so I guess this principle of "I can upgrade when I want" sometimes works out a little too well.

So on the subject of standard libraries, from what I've seen, Dart is much more sane. Their date library has appropriately named methods that do exactly what you'd expect.

However, I think for now, I should try Opal.

Just in trying to write this post, I discovered that Dart apparently still has problems for me which is basically issues centered around getting started.

I've got a half completed Dart project (that was a rewrite from JS), but I never did get it posted officially anywhere because I could never figure out the build process (and as always, there were a thousand necessary (and easier) things tugging at my attention, so it never got completed).

I'm also not crazy about the fact that the Dart experience seems to be largely based on using the official DartEditor. I played with the WebStorm trial and always felt like a second class citizen when I tried to do anything in Dart. And given that I couldn't even figure out how to build my stupid project, Vim was a complete non-starter for me (I do 95% of my coding in Vim).

And despite Dart supposedly having a REPL since October 2nd, I have no idea where it is. I seriously could not actually find it. The announcement blog post just says "When paused at a Dart breakpoint, expressions entered in the console now support full Dart expression syntax". I tried the developer console in Chromium. It didn't like the examples. I tried hunting around in the Dart Editor for a console. I never fricken found it.

And I love REPLs. I love being able to experiment. And I also love just being able to write code adhoc without having to commit every bloody thing to a file.

So, in Opal, you don't have a true REPL as far as I can tell (though the Try Opal section on the Opal home page runs fast enough that you can use it somewhat as a REPL). And of course, since Opal seems to be aiming for parity with Ruby, a lot of things you could pull off in pry will apply.

And as for the build process, I haven't been through it yet, but I've seen the documentation and it actually looks to make sense, so I don't think I'll have a problem.

The huge bit though is that their official homepage is built in Middleman, so I've got a real life example of how I can go about integrating it into my own Middleman projects (Middleman is what like 90% of my Ruby projects end up getting built with).

I have some concerns about Opal though about how I'd go about using it with existing JavaScript libraries. I mean, it somewhat seems that, unless someone's written a wrapper around an existing library, that you'd lose a lot of the usefulness of Opal because you'd still end up having to throw raw Javascript code in to get things to work.

I don't know though. I guess it's why I should just try it and find out.

I also wonder about things like tree shaking. Like with Dart, apparently they remove all of the unnecessary code. As far as I know, Opal does not have that. I don't know yet what size of JS, Opal produces. Perhaps, I'll consider the trade-off in size to be worth it. And hey, maybe Opal will introduce tree shaking at some point.

So I think I've got today's task figured out. I'll put together a bare Middleman/Opal project. I'll figure out what it would take to go from a generic Middleman project to having Opal code integrated in.

And then I'll also get to find out what's the smallest Opal -> JS file that can be generated.

Let's do this!