When did Javascript become a serious language?

Dave Smith dave at thesmithfam.org
Mon Dec 9 10:24:58 MST 2013


I read that back in 2007, and I was surprised at the time, but he was right.

—Dave

On Dec 9, 2013, at 9:19 AM, Mike Moore <blowmage at gmail.com> wrote:

> Anyone remember this?
> 
> http://steve-yegge.blogspot.com/2007/02/next-big-language.html
> 
> 
> On Sun, Dec 8, 2013 at 9:06 PM, Dave Smith <dave at thesmithfam.org> wrote:
> 
>> Yes indeed. The evolution of JavaScript from red-headed stepchild to its
>> present state has been a surprising journey.
>> 
>> I predict a day in the not-too-distant future where JavaScript will become
>> the assembly language (or byte code) of the web, both client side and
>> server side. We’re already seeing languages that compile to JavaScript,
>> like CoffeeScript and TypeScript. Browsers have some really impressive
>> interpreters and JITs. I predict that developers of the future will say,
>> “You actually *wrote* JavaScript? You’re hard core”.
>> 
>> —Dave
>> 
>> On Dec 7, 2013, at 5:37 PM, S. Dale Morrey <sdalemorrey at gmail.com> wrote:
>> 
>>> I've been working on a sparetime project for a few weeks and had
>> something
>>> mostly coded up in Java, then realized that perhaps I was trying to
>>> re-invent the wheel so I googled for a library to do the heavy lifting
>> for
>>> me.
>>> 
>>> Imagine my surprise when many of my queries for xyz java library started
>>> returning xyz javascript library.
>>> 
>>> Just for fun I decided to look at the effort involved in remaking my
>>> prototype in Javascript using node.js and some helper libraries.
>>> 
>>> When I found that 90+ % of my prototype was available as library
>> functions
>>> and it was more or less a matter of gluing them together.  I decided to
>> go
>>> ahead and just give it a try in js.
>>> 
>>> Now don't get me wrong.  I'm hardly a javascript noob.  I was writing
>>> Ajax-like website helpers scripts before we ever coined the terms Comet
>> or
>>> Ajax.  Nevertheless I've always viewed it as a tool for making shiny bits
>>> and/or using it as a scripting language for controlling other programs.
>> In
>>> other words I've always seen it as being firmly as part of the view
>>> component.  I never really viewed it as something for serious
>> computational
>>> workloads.  Until now.
>>> 
>>> I finished both prototypes to the same level.  With my curiosity piqued I
>>> decided to let them both rip on separate instances in the same AWS
>>> availability zone, same EC2 machine types (t1.micro).
>>> 
>>> The job is just to hash words from a dictionary list (I'm making a
>> personal
>>> rainbow table) using a few different hashing algorithms after which I
>> will
>>> be doing an analysis with map reduce but neither the the map reduce nor
>>> analysis steps are included in this part.  This is just a feed generation
>>> step.
>>> 
>>> I just wanted to test raw hashing power in this case.
>>> I added a loop counter to the main loop and put in stopwatch function to
>>> ensure identical runtimes.
>>> 
>>> Here are my results after 2 minutes of runtime...
>>> Java 7 J2SE           :  1,000,079
>>> Node.js Javascript   :  1,548,103
>>> 
>>> The numbers represent how many times it made it through the final loop
>>> where it would normally have written out a csv. Thus there were several
>>> steps.  Read a fixed list, them run SHA256, Scrypt and Ripe-MD160 on each
>>> unit. There was no output step so as to rule out filesystem access times.
>>> 
>>> This isn't meant to be a head to head comparison.
>>> 
>>> The Node.js version is (to the best of my knowledge) single threaded and
>>> the Java version is running on a thread per core model (even though the
>>> test box is 1.5 cores).  Looking back, going with thread per core may
>> have
>>> gimped the Java version because of list contention, and/or context
>>> switching penalties so I do doubt the numbers here are anything
>> resembling
>>> final.  In fact I ran it for 5 - 10 - 15 and 30 mins as well and once JIT
>>> kicked in and moved some stuff to metal, Java slightly matched (at 15
>> mins)
>>> and slightly exceeded (at 30 mins) Javascript.
>>> 
>>> Javascript just trucked along at the same rate during similar intervals.
>>> 
>>> The point is, When the heck did Javascript become suitable for something
>>> that's so computationally heavy?  A 50% performance improvement over Java
>>> in a short interval, especially when I have not done anything to
>>> intentionally gimp the Java version, tells me this is not the Javascript
>> I
>>> used to know.
>>> 
>>> It also showed me something about my own internal biases.
>>> I find it odd how my thinking has evolved over time.
>>> 
>>> I used to be a computer programmer who had a good/decent familiarity
>> with a
>>> broad range of languages and I would always try to select the best tool
>> for
>>> the job taking into account the cost of developer time vs cpu time.
>>> 
>>> Over the past 4 or 5 years I've been so heavy into Java (because that's
>>> what employers want), that I think I may have evolved into a Java
>>> programmer.
>>> 
>>> This experience has shown me that it might be time to broaden my horizons
>>> and again embrace the "right tool for the right job" approach I used to
>>> have, rather than the Swiss Army Chainsaw habits I've picked up from
>>> programming in Java.
>>> 
>>> So what do you think?  Have you looked at any languages for purposes you
>>> had previously disregarded?  What were your thoughts?
>>> 
>>> /*
>>> PLUG: http://plug.org, #utah on irc.freenode.net
>>> Unsubscribe: http://plug.org/mailman/options/plug
>>> Don't fear the penguin.
>>> */
>>> 
>> 
>> 
>> /*
>> PLUG: http://plug.org, #utah on irc.freenode.net
>> Unsubscribe: http://plug.org/mailman/options/plug
>> Don't fear the penguin.
>> */
>> 
> 
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
> 



More information about the PLUG mailing list