
Elbowing JavaScript out - ljoshua
http://blog.ikura.co/posts/elbowing-js-out.html
======
jordanlev
I feel like I'm in a bizarro world reading this "interview"... they're just
describing web sites before "web 2.0" (around when Google Maps, Prototype,
jQuery etc. came along), but talking about it as if it's a new thing.

Maybe I'm missing the joke, except none of the comments here on HN seem to
give any indication that anyone is aware that you can build websites without
javascript (and in fact that's how most websites were built, and some still
are). Everyone's talking like "in the beginning, there was javascript... but
now we have these new things called HTML and CSS which let you finally get
away from it!"

~~~
underwater
The article is specifically talking about web apps, not web sites. This
usually assumes interactivity based on user interaction, which JavaScript
certainly makes easier.

I don't know the specifics of the web app in question. But from the interview
it sounds like a case of replacing fixation on one tool with another. For
example she describes server generated HTML as a "pristine state."

No, JavaScript shouldn't be used for everything. But sometimes it is better
than trying to abuse other technologies to do things they shouldn't do.

~~~
roywiggins
The "basic HTML" version of GMail still exists, it barely uses Javascript[1].
That counts as a webapp, right? That's how email "apps" worked on the internet
for a decade before the one-page-app became feasible and popular.

It looks like crap by current standards, but it works just fine. I wouldn't
call its scriptlessness an "abuse" by any means- that's just how it used to be
done.

[1] there's a little bit that handles time zones, I think, but that's it...
oh, and autocomplete and some alerts to catch you navigating away from an
unsaved draft, that sort of thing.

~~~
tyingq
There's also a framebuster, and onclick handlers for the search button.

------
drewpc
I think I understand that this article was trying to represent an interview of
someone who is successfully creating complex web applications without JS, but
it was written as though all of the readers already understand how to do this.
Where's the "why" and "how" behind this? What's the advantage of leaving out
JS? How do I do client-side interaction without it (the interview seems to
imply that we do everything server-side)? I don't see the actual
argument...just an interview. Too bad, because I think that this is a very
important discussion in the industry today.

~~~
cpeterso
For example, the article references "OTP" but doesn't define it. Is this
Erlang's OTP? Apparently it is because Cowboy is an Erlang HTTP server.

~~~
moron4hire
OTP means Online Transaction Processing. It's a fancy name for "no caching, no
data warehouse, we do everything live."

------
hhsnopek
(Not using javascript) This is a terrible move, consider this:

Your web stack has many moving parts that can be adjusted on both client and
server side. Now from what I'm getting from the article, all my websites are
server side apps. This means I must run a server that I need to factor in
scaling and performance. I need to know what my bottleneck is, which will
likely end up being what I'm rendering at almost live time. Now consider that
we use a client-side application which only lives in the browser and contacts
an API to confirm authorization to x, y or z. We not only decreased the load
time of the site, but also allow everything to be done on their machine and
not my server. My bottleneck becomes the my clientside logic and then the CDN
I'm ruining my site thru. Mind you I can now have my CDN cache my site because
everything is done on the client.

There might be problems and flaws with javascript, but disregarding a language
just because of the server side pattern isn't right.

I'd like to see some implementations you've done that are better alternatives
to using javascript.

~~~
Roboprog
This, minus the CDN - using compression and static file caching headers, only
- is how we are handling a major app upgrade (pretty much a rewrite) at work.

Of course, I flip flopped from hating Javascript to really liking it about 10
years ago. Now after having done most of my work in JS (plus Angular 1) the
last year, I can't stand working in Java any more. So much blah blah blah to
do _anything_ on the server (since Java is mandated). I'll save the Java rant
for another day.

Personally, I find that maintaining state about "workflow" in an actual data
entry app is MUCH easier in a fat client than trying to preserve state while
entire pages bounce back and forth between client and server. Webflows
(Spring/JSF)? Therein lies madness...

And it is pretty cool that our server app has simply became a pile of REST
services with default client app resources bundled in. We already prototyped
an integration with another system a few months ago that demoed very well.

~~~
PaulHoule
Sometimes CDNs seem like a scam to me.

I have been building "insanely fast" apps based on HTTP/2 and everything
local. My experience is that every DNS lookup you add is a chance for
somebody's web browser to go out to lunch for an unbounded interval. (Back
when we got DSL in my neck of the woods, web browsing often was slower on DSL
than dialup because the DNS service was so bad.)

As for the back end it is a matter of having a framework that works.

Unfortunately Sun, Microsoft and most legacy vendors have a history of hiring
systems programmers instead of application programmers to develop frameworks,
so the average back end framework is seriously flawed. For instance, Web Forms
in .NET were a great idea, but had the fatal flaw that they did not work in an
MVC environment where you might want to load a different template depending on
the outcome of form processing.

Instead of fixing this, they build a new MVC framework that didn't learn from
the mistakes of the last framework...

------
beaker52
"Don't use JavaScript if you don't have to." Sound advice

But the article subject seems quite proudly dogmatic about avoiding it
altogether but then goes ahead and scores this major own goal:

 _> Regarding worst hack. That’s a hard one. In one of my javascript-free
projects, I couldn’t figure out how to embed a realtime graph. In the end, I
went with a 3rd party API solution, who probably do use javascript on their
end..._

This realtime graph is the only clue that this interview wasn't conducted in
the mid-2000s.

Edit: Are we being trolled?
[https://en.wikipedia.org/wiki/Amygdala](https://en.wikipedia.org/wiki/Amygdala)

~~~
roywiggins
Plus, there's a pretty easy way to do a realtime graph without javascript. You
just embed it in an iframe; the iframe page needs a meta refresh tag for every
few seconds.

Or abuse GIFs:

[https://github.com/jbochi/gifstreaming](https://github.com/jbochi/gifstreaming)

------
brlewis
_The page loads, then, afterward, you tell some scripts in the footer to
observe the presentation in this pristine state, then to go around and mess
about with it._

This is why with React-style views[1] I feel like I'm finally learning how to
write web applications. The DOM is always in a pristine state.

[1] Specifically I'm using Mithril, but the architecture is the same in React,
and similar now in Ember.

~~~
nvader
I just wanted to echo this sentiment. I also had a similar "aha" moment when a
colleague introduce me to React, whereas prior to that I had invariably hacked
interfaces together with very ad-hoc jQuery code. Since backend code is my
bread and butter, my intuitions never had a chance to develop beyond "this
feels error-prone and wrong" on their own.

Further paralleling your own journey, I now reach for Mithril first too, and I
can't recommend it enough.

------
supernintendo
Judging from Ikura's web page as well as the lack of Internet presence and
name of the interviewee here (Amy G. Dala... Get it, amygdala?), I'm inclined
to think this interview is fake.

In any case, I've noticed a tendency to conflate JavaScript with what I'll
call "JavaScript abuse". I'm guilty of JavaScript abuse and I'm sure many of
you are as well. But to attribute this to any programming language, regardless
of bad parts, is the sort of blame-shifting we should try to avoid as
developers. "Never use X" might be a solution to a problem but it won't
necessarily guide you to good design patterns.

We've all heard the old adage "use the right tool for the job" but its just as
important to do a good job with the tools you have. It's possible to write
pages that use CSS and JavaScript to enhance your users' experience while also
being small and rendering perfectly in Lynx. If you're having so much trouble
with JavaScript that you eschew it completely, maybe there was an issue with
how you approached the problem rather than with the language itself.

~~~
_greim_
If a tool encourages bad habits, it is in some sense the tool's fault. On the
other hand, overuse of JavaScript isn't encouraged by JavaScript-the-language
so much as by how it fits into the overall web platform.

It was an interesting point about SPAs being partially a symptom of god-awful
slow backends, fake article or not.

------
masswerk
I'm coding JS now professionally for 20 years (so, quite from the beginning)
and I love the language.

That said, I think, current frameworks are, with all due respect, rather over-
engineered. – A tool chain consisting of at least 8 items, a multiline CLI
command to compile a hello world that comes at a mere 19.500 lines of code?
(Some may remember when early Java versions were made fun of for a 2MB hello
world object code.) I would love to see JS back in its core domain which is /
has been (choose your own) real-time interaction. I dare say, we haven't seen
much of this lately, at least not in creative and novel ways.

~~~
gedrap
But maybe it comes down to the fact that many developers simply like over
engineered solutions and sprinkle some complexity to often boring problems?
Not saying that it's always the case but surely many of us can recollect
related stories :)

~~~
masswerk
For me, its more about the frameworks shoving between you and the presentation
layer. It's not realtime and interactive anymore (rather about packed and
delayed update/repaint cycles). Consider what could be done alone using the
canvas 2d-context with the current API. There isn't a visual thing that
couldn't be done with this. Some may remember the creative wealth of CD-ROMs
in the 1990s – we may have all of this, but better. Instead, it seems more
about a glorified mark down presentation layer. We really could do better.

P.S.: Maybe, this is just an old man's rant about the old days like when
PostScript was all written by hand and typo came in stars. But I'm really
underwhelmed by the state of creativity on the web.

------
binarymax
From what I gathered, the gripe is not with the JavaScript language itself,
but the "thick-client" web app.

The thick vs thin client trend cycle has already happened twice. When your
network and servers are fast enough so everything can happen on the backend,
it becomes a philosophical debate.

~~~
PaulHoule
It's not just that.

It's possible to write a thick client which is reasonably lean, but to do that
you have to plan and be careful about your dependencies. Most people aren't,
and that is why it can be a 30MB load for some apps that could be done in a
300kb load.

Back end apps can be made insanely efficient in terms of how much data they
transmit (lean HTML, lean SVG, etc.) and how fast they process data. You are
forced into the model of "user clicks, send back one update" which has
limitations, but also has the advantage that you don't get the massive number
of round trips that happen in thick apps that are not carefully engineered.

------
shoemai
If I'm on reddit and had to reload the page for every upvote/downvote, comment
expand/collapse, show more comments, and reply the ux would be significantly
worse. And thats not even a site that has that much user interaction.

~~~
roywiggins
You can do async upvoting without Javascript if you abuse a GET request loaded
in an iframe. Comment collapse can be done if you abuse CSS and checkboxes.

These aren't really GOOD ideas, but someone who really, really doesn't want to
use Javascript has options.

------
ebbv
This seems to me like someone realizing they've been using JS in really
terrible ways and trying to stop that by just forcing themselves to not use JS
at all. It's not JS's fault that people use it in terrible ways.

One page web apps aren't inherently bad, and neither are sites that don't use
JS. It depends on what you're trying to accomplish. You can write a bad site
with JS you can write a bad site with no JS.

I think the problem that this developer's "No JS" approach is forcing her to
solve is the problem of not thinking through your architecture enough. By
saying "I will not use JS", she is forcing herself to put more thought into
how things are implemented and that's always going to result in something
better than if you just slap something together.

But I think it's a mistake to think that JS is the problem.

~~~
Roboprog
If you, or more likely, your organization, does NOT want to learn / use
Javascript, then this probably IS the way to go.

Not my cup of tea, but for many real world organizations, they have to
restrict the scope of what the group will do to avoid chaos. Yes, this makes
me sad, but it is what it is.

------
azag0
To me as someone who writes a simple web app in Flask from time to time, web
with and without JS feels like two orthogonal approaches. Without JS, you're
just wrapping your data on the server in some nice html and sending it to
render. With JS, you're building a client-side app that is using your server
API to get the data and render it.

~~~
bobwaycott
As someone who writes complicated apps with Flask from time to time, I like
the approach of using JS merely to request a resource, rendered by the server,
and replaced wholesale on the DOM.

------
larrykubin
"I have been wanting to try building a complex webapp that uses nothing but a
backend, CSS, HTML5 for a really, really, really, long while"

Coincidentally, I am going in the opposite direction after having written many
Python/PHP apps with only a little JavaScript. I noticed on my current project
I was writing less backend Python code. Last night I decided I'm going to try
building a complex "serverless" webapp using only Firebase and more JavaScript
than I typically write.

------
gedrap
Why be on the extreme? [0]

Programming is very, very often about the balance.

I can understand some frustration with thick clients - including the fact that
there are so many frameworks being released now and it's hard to decide what
to use.

But at the same time, taking extreme approaches can be and is hurting the
users. For example, Ajax requests (is there a way to do it without JS? Doubt
it but who knows) can actually significantly improve the user experience.
Imagine if the whole comments thread on HN reloaded every time you wanted to
vote on a comment. That wouldn't be great. Tools such as google docs wouldn't
even exist, really.

That being said, amount of JS at HN looks pretty great to me. Not much point
to use it for posting replies (just open in new tab), but really helps with
the voting. I'd rather take this approach than avoiding JS just for the sake
of it.

[0] Except just out of curiosity, but they were talking about client work in
the post so let's continue with it.

~~~
mooseburger
Now that you mention Ajax, I don't see where HN does ajax when voting. The
only javascript on the page is for hiding the vote icon after voting.

~~~
gedrap
It's conventional way of doing it, but:

var ping = new Image(); ping.src = node.href;

Technically, it might not be called ajax but the point is the same.

------
badusername
Could someone link to examples of her work? The article reads as if it's more
of a fashionable contrarianism, mostly for the sake of it. I would like to
experience her work in detail tho. Sadly, a clever name like 'Amy G Dala'
fools google and doesn't turn up anything.

~~~
balls187
Is the interviewee a real person? My interpretation (based on the name) was
that it was a fictitious interview to make a point.

Completely offtopic, Amygdala was the boss that gave me the most trouble in
Bloodborne.
[https://www.youtube.com/watch?v=Njmz1MbwOiM](https://www.youtube.com/watch?v=Njmz1MbwOiM)

------
WalterSear
There are many reasons I would welcome an alternative to javascript on the
front end, but sophomoric contrarianism isn't one.

------
jameslk
I'd really be curious what the end result looks like from a UX perspective. A
full page reload for everything seems a bit crazy. Perhaps these clients of
hers didn't care so much about the experience?

------
ldehaan
more people complaining about a language they don't understand, js should be
more like y language is something I've been hearing for years. it's inane and
shows a deep lack of understanding of programming languages specifically, and
how computers work in general.

I have been writing apps in all js for years now, there are issues with the
language as there are with all languages. over all if you spend the time to
learn it, don't use pre processors, and stick to the known patterns for js
development you will have zero issues with the language.

the bugs I run into nowadays are usually related to parsing incoming data that
is not formatted logically for best use in js. it is best to get your js
objects as flat as you can on the server side before sending them up to be
iterated over in your frontend app.

most of the applications I build are data heavy with charts and such. I
routinely get 100ms or better load times on huge amounts of data because if
you do it right, JS is really fast and flexible.

my wife is a designer and I've learned that CSS used correctly with js is all
you need. if you can't do the graphics with CSS then js is fine, but do all
the work on your Dom object before injecting it into the Dom.

read JavaScript the good parts by Douglas Crockford

~~~
Roboprog
CSS? Now _that 's_ hard.

I love both the dynamic and functional aspects of Javascript. See my comment
elsewhere about currying as a frequent substitute for constructors/setters,
abstract base classes and AOP.

------
drubio
It's pointless to be a contrarian on JavaScript. It's here to stay, but it
does appear there's a big push to be able to write something other than plain
JavaScript (that produces JavaScript) to bring more sanity to the development
process.

That Microsoft is pushing a superset that produces JavaScript
([https://www.typescriptlang.org/](https://www.typescriptlang.org/)) and
Google is also behind Dart
([https://www.dartlang.org/](https://www.dartlang.org/)) that produces
JavaScript, should say a lot about JavaScript's stickiness.

I actually find it amazing all the effort that has gone into TypeScript and
Dart, which just produces more JavaScript, instead of creating a new language
from scratch. It really looks like even Microsoft and Google prefer to deal
with JavaScript 'as is' going with language supersets and languages that
output more JavaScript than launching a new language.

In a few years JavaScript will most likely be the 'bytecode' of the web, you
won't have to use directly, but it will just be there, produced by higher
level stuff like TypeScript or Dart that produces JavaScript.

~~~
Roboprog
Hope that works for you (GWT sure didn't)

I'll be just a wee bit contrarian on this, as I started out in my career using
a more or less dynamic language in the mid 80s (despite being schooled in
Pascal and later, C, which deserves its own discussion).

"Better type-checks interestingly found only just a few bugs" \-
[https://jaxenter.com/angularjs-interview-
angular-2-typescrip...](https://jaxenter.com/angularjs-interview-
angular-2-typescript-and-a-release-date-123674.html)

I greatly appreciate the brevity of the JS code itself, though I do freely
litter my code with JSDoc (or JavaDoc, on the back end) comments. Short code,
long comments. Please, WWW entities, DON'T make JS into a Java-like, OOP only,
monstrosity.

I seldom write real classes in JS. Its amazing what you can do with currying.
Supply first few data args - don't need a constructor/setter(s) to configure a
"one trick pony" class. Pass in and pre-bind a few function args - don't need
an abstract base class. Wrap a function around an existing function - emulates
OOP aspect orient programming.

I forgot to add, at least one IDE vendor, JetBrains IntelliJ (or Webstorm)
does an excellent job of inferring types in Javascript, as is, and much of the
autocomplete; find definition / usages; refactor stuff works just fine without
jacking up the language.

------
moron4hire
NOTE: I do a LOT of JS development. Just check my profile.

This is how the vast majority of web apps were built for the vast majority of
the life of the internet, and likely probably still are, considering the vast,
invisible depths of internal enterprise development. It's not surprising that
it can be made to work well. It's what HTTP is built for.

------
draw_down
Yes! Do use reddit and craigslist. Vote up some stories. Peruse some comments,
maybe collapse the threads you don't find interesting. Do a search and see
craigslist fill in potential matches for you. Hunt for places to live and
notice that it gives you a nice map you can zoom and pan with.

Oh, weird, that stuff uses JS. Huh.

------
CalmStorm
Pure server rendering will work for webapp. But if one day the client decides
to have iOS/Android apps, the backend will need to be updated to provide Rest
APIs. It is possible to do, just additional work. SPA with client side JS will
not have this problem.

~~~
spriggan3
> the backend will need to be updated to provide Rest APIs

In this day and age of micro-servicing everything, the backend should have a
front-end for webpages that uses the same Rest API as mobile devices.

------
amelius
The worst part of JavaScript is that the relevant committee is simply failing
to acknowledge that there are lots of bright computer language designers out
there who'd love to have a chance to bring their creations to the web.

~~~
cdmckay
Doesn't WebAssembly allow them to bring their creations to the web?

~~~
tyingq
Maybe, someday. The current course will only allow for statically typed
languages, and does not allow direct dom access.

------
m4nu
>the fact that it lives in the web stack right next to the presentation layer,
really sucks (I think)

I can't see by what logic the interviewee arrived to this conclusion. How is
the presentation logic out of place in the presentation layer? Modern
API/consumer based architecture make way more sense than having MVC structures
where business logic, storage logic and presentation logic intertwine.

------
BFatts
It's never about it being "better," it's only about it being "different." In a
world of cookie-cutter web devs, how does one stand out? By trying something
difficult, succeeding, and then saying it's the "better" way. Same reason we
have so many damn programming languages - they each claim to do something the
"better" way.

------
sickbeard
is "Amy G Dala" a fake name? I put it in google and got

"The amygdala is an almond-shaped structure in the brain".

Coincidence?

~~~
elbigbad
Of course it's not a coincidence. It's some pen name of some author trying to
be clever while chuckling to themselves about their high-brow inside joke.

------
Scarbutt
Regarding SPAs, is it worth it (besides learning purposes) if you are just
writing a web interface/front end in the same level of complexity as github?
github not being a SPA works pretty well and lots of it users like it (I know
it adds javascript to some parts to enhance the experience).

------
jasode
_> Then observe how much javascript it actually used. It’s used a ton because
we have been given the tool, and in having this tool, we use it._

I'm not convinced of this reasoning. I think computing history has shown
repeatedly that many ideals of declarative purity will give way to _something_
that becomes Turing Complete. (E.g. config files with IF-THEN/GOTO[1], SQL
that includes "stored procedures" with loops, TeX typesetting language adds
Turing-Complete programmability[2], etc)

Thought experiment... imagine a different starting point of browsers where
there was only HTML/CSS but no Javascript engine. Wouldn't the pent up desire
for some "programmability" in web pages eventually lead one of the browser
vendors to add new HTML "logic" tags that have if/else/goto/loop? Or a vendor
adds CSS "extensions" with eventual Turing Complete power? Once one browser
adds it, the others copy it and we have the same situation of "program code"
on the client browser. Maintaining 25 years of _no programming logic power_ on
browsers since the 1990s Mosaic browser does not seem realistic. In other
words, if it wasn't Brendan Eich's Javascript to dynamically mess with the
webpages, _it would have eventually been something else_ to provide similar
powers.

 _> The page loads, then, afterward, you tell some scripts in the footer to
observe the presentation in this pristine state, then to go around and mess
about with it. Is there any other place in the stack where we architect code
to work like this?_

I don't know what is meant by "other place in the stack" but in the wider
computing world, MS Windows Forms (WinForms) works like this. You have ".frm"
files with the "declarative" widget placements and then C#/VB code that can
hide/unhide, resize, add GUI elements, etc. Other GUI toolkits (C++ Qt) work
the same way.

 _> But the frontend? So I’d agree that it’s here to stay. But I don’t think
we have to embrace it for all web stuff as much as we have._

With mobile phones and many desktops experiencing 100ms to 500ms network
latency, what's the alternative? If a web surfer updates a shopping cart from
quantity of 2 to 3, is it really the best practice to have the server rebuild
the entire page and resend the result of "subtotal=price x quantity" to the
client just so we maintain ideological purity of no Javascript on the web
browser? Most users would find the constant page refreshes to be sluggish and
not user-friendly.

[1][http://stackoverflow.com/questions/648246/at-what-point-
does...](http://stackoverflow.com/questions/648246/at-what-point-does-a-
config-file-become-a-programming-language)

[2]Donald Knuth:
[http://maps.aanhet.net/maps/pdf/16_15.pdf](http://maps.aanhet.net/maps/pdf/16_15.pdf)

excerpt: In the 70s, I had a negative reaction to systems that tried to be all
things to all people. Every system I looked at had its own universal Turing
machine built into it somehow, and everybody’s was a little different from
everybody else’s. So I thought, _“Well, I’m not going to design a programming
language; I wanted to have just a typesetting language.”_ Little by little, I
needed more features and so the programming constructs grew. Guy Steele began
lobbying for more capabilities early on, and I put many such things into the
second version of TEX, TEX82, because of his urging. That made it possible to
calculate prime numbers as well as do complicated things with page layout and
figure placements.

------
luffy327
The entire argument against JS fell apart in the last paragraph. As long as
it's not me who is writing JS but some 3rd party library which I just pass
data along, then what I have is no JS.

------
JamesBaxter
Generally I feel if I have a lot of business logic in Javascript than my view
is wrong.

There are things like client side validation that I don't know how you'd do
another way?

~~~
petepete
Basic client-side validation is possible with HTML5 inputs and attributes, but
for anything more involved you need to use JavaScript.

------
bricss
What about writing web-apps with zero Java, Scala, C#, Ruby, Python, PHP ??

~~~
ArbitraryHobo
So, writing your web application in Node?

------
atomi
_I don’t even mind it living in the backend_

You lost me there.

~~~
sheeshkebab
same here, stopped reading after that

------
hutzlibu
So his solution is, to do everything on the server.

Great.

~~~
extropic-engine
Her name is Amy. It's right there on every paragraph.

~~~
balls187
I seriously doubt the interviewee's real name is Amy G Dala.

------
sanjeetsuhag
I hate the font on this page.

------
geggam
We can only hope more people lose javascript. Please ?

~~~
Roboprog
Javascript is a great language. Transpiling another language to run on the
browser (looking at _you_ , zombie GWT!) will NOT make CSS and event handling
any less complex.

~~~
wtbob
> Javascript is a great language.

I think you must be suffering a misunderstanding about the meaning of one of
those words. JavaScript is a hideous, misdesigned, sad and ultimately
embarrassing language. It's hideous: curly brackets and hieroglyphics galore.
It's misdesigned: insane type conversions & implicit declaration — and don't
even get me started about ===! It's sad: Eich originally wanted to build a
Scheme; while I'm no fan of Scheme (at all: frankly, I hate it), that would
have been a noble and good project; instead, we're left with a pathetic might-
have-been perversion of good intentions. It's an embarrassing indictment of
our entire industry that JavaScript is successful.

It has one virtue: it exists everywhere.

~~~
Roboprog
I don't know what your "language of choice" is, but here in the Sacramento
area, the selection of languages which there are jobs available to be worked
is somewhat limited.

Yes, ES/JS suffers from its "look like Javascript/C++/C" * heritage, courtesy
of the usual suspects from a marketing group. But get past the cosmetics, and
you can do some nice FP things with ES/JS.

* I'm in the camp that Modula / Delphi were MUCH better language(s) than C. But few groups were hiring for those skills back in the day - C and its spawn won out, sadly. At least C++ is pretty much dead outside of the video game industry. Good riddance.

