
The JavaScript Problem - falava
http://www.haskell.org/haskellwiki/The_JavaScript_Problem
======
jurassic
The people who hate javascript the most are the ones who wish it was something
else. I used to be one of those people. Once I decided to accept it as it is
and read a few top books on the language to learn the "javascript way", my
life got a lot better. It's really not that bad. I actually like it a lot, but
there are still a lot of ignorant people who will look at you as if you're not
l33t enough to know that foo language is better if you tell them you have a
favorable view of js.

Of the things on his list, the only ones that really resonate with me at all
are verbose function syntax and silent coercion. Typing function () {} gets
old fast, but then I set up snippets and it ceased being a problem. That
really just leaves the type coercion problem, which you adapt to pretty
quickly if you're using the language in earnest.

What it boils down to is choosing to be a pragmatist who gets down to work
with what's available instead of a naval gazer who swears everything will be
awesome as soon as they have their preferred tool|language available. There
are tons of compiles-to-js alternatives, but I don't see a huge difference in
the productivity of people working in these not-JS alternatives. Where are the
killer apps that were developed through a niche JS transpiler? If you want to
build a web app in Haskell instead of the web's true lingua franca, all you're
accomplishing is making it harder to hire and harder to collaborate.

~~~
Swizec
Javascript's real problem is unfamiliar semantics hidden behind familiar
syntax. It throws people off and they hate the language because they think
it's weird. Really, they just haven't learned how to actually use it.

~~~
gutnor
Javascript is a tiny language, but it pack a serious amount of gotcha.

If you learn the javascript way, you just realise that the core language
provide little to no tooling around it. Like if you really want to fully
utilise the prototype based inheritance, or the functional aspect of the
language, you will basically have to write a whole set of utilities and
extension on your own.

Of course, javascript run in the browser, is small and super simple, so it
packs a lot of fun. To me it oddly reminds me toying with assembly in the old
DOS 16 bit days and I like it despite its flaws ( and well those flaws are
being addressed in latest iterations ) But the flaws are real, and if you need
to use it on a big project with a regular team, and not complete freedom of
choosing the browser you support, javascript will make you cry more often than
smile.

~~~
nilliams
> Like if you really want to fully utilise the prototype based inheritance, or
> the functional aspect of the language, you will basically have to write a
> whole set of utilities and extension on your own.

Hmm, this is definitely something of an exaggeration. With old-school cross-
browser JS you just need something like Backbone's `extend` implementation
(jashkenas posted a shorter example a while back [1]) for inheritance and
underscore.js [2] for your functional aspects (assuming that's the sort of
thing you mean).

If your criticism is that those things had to be written, then this was solved
with ES5 which gives you `Object.create` [3] for your inheritance needs and
`map()`, `filter()` et al for your functional stuff.

I certainly don't see why you'd ever need 'to write a whole set of utilities
and extensions of your own', that reads like pretty hand-wavey and unfair
criticism.

> if you need to use it on a big project with a regular team, and not complete
> freedom of choosing the browser you support, javascript will make you cry
> more often than smile.

I think you are depicting a pretty broadly-shit scenario that I don't think
you can say any other language ecosystem deals with well. Trying to support
many different clients is a nightmare across e.g. mobile and the desktop using
any other language/ecosystem too, with same 'regular team'. And I don't agree
there's anything particular about JS that will make you 'cry more often that
smile' in that scenario, but that's obviously subjective.

    
    
      [1] https://news.ycombinator.com/item?id=7244023
      [2] http://underscorejs.org/
      [3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create

------
pcwalton
> lack of module system

ES6 fixes this with, well, a module system.

> weak-typing,

Yup, this is a problem.

> verbose function syntax,

ES6 fixes this with arrow functions.

> late binding

Does this just mean dynamic typing? Well, yes, JavaScript is dynamically
typed, but I wouldn't call that a language flaw. Static vs. dynamic typing is
a tradeoff.

> which has led to the creation of various static analysis tools to alleviate
> this language flaw

The footnote talks about JSLint and friends, but none of those impose a type
system, which means that they do nothing about dynamic typing.

> but with limited success (there is even a static type checker)

Well, yeah. It's very hard (read: "research problem") to impose a good static
typechecker on a dynamically typed system, though.

> finicky equality/automatic conversion

Yeah, this is bad. I really wish tools like restrict mode [1] had caught on:
together with ES6 they eliminate a lot of what people dislike about
JavaScript.

> this behaviour,

Fixed in ES6 if you use arrow functions (finally!)

> and lack of static types.

Again, I wouldn't say it "sucks" for this reason, just that it's dynamically
typed. That's a tradeoff.

[1]: [http://restrictmode.org/](http://restrictmode.org/)

~~~
teacup50
> _Again, I wouldn 't say it "sucks" for this reason, just that it's
> dynamically typed. That's a tradeoff._

This is the _Haskell_ wiki. I would expect most participants to view having a
single global implicit union type to be a _flaw_ , not a _trade-off_.

~~~
djur
It's sad that we should expect Haskell users to be chauvinistic about static
typing. I have yet to read anyone who advocates for dynamic typing describe
static typing as a "flaw".

~~~
copergi
>It's sad that we should expect Haskell users to be chauvinistic about static
typing.

We don't expect that. We expect them to recognize that better type systems are
better than worse type systems. Which seems pretty obvious when stated that
way.

>I have yet to read anyone who advocates for dynamic typing describe static
typing as a "flaw".

Try looking on the internet. Every "static vs dynamic" argument has 99% of the
dynamic side arguing that static typing is bad because java's type system
limits them and doesn't prevent any bugs.

~~~
jkrems
> We expect them to recognize that better type systems are better than worse
> type systems. Which seems pretty obvious when stated that way.

Obvious - because you just said "with better defined as has more static
typing, static typing is better". That's an empty statement if I ever saw one.

~~~
teacup50
That it's better to accurately and reliably modeling complex systems and
invariants through provable assertions is objectively is no more an empty
statement than to say that it's better to apply informed materials and
structural engineering to the design of complex physical products than to
build ad-hoc designs of unknown parameters through guesswork.

~~~
jkrems
If you think that building software is like building bridges, then yes. If you
think that it's the exploration of a problem domain that may not be known to
you at the start of the process and is subject to various degrees of iteration
(e.g. a process more like writing a script/play), then you get vastly
different requirements. That's what I meant by "if you define better as more
static typing". "Better" is a normative statement and can never be absolute,
it's always relative to a choice.

~~~
teacup50
I don't see how it follows that iteration reduces the degree to which one must
understand a system. That's just a rephrasing of the attractive but ultimately
empty "dynamic typing is just more creative."

Bridges (or car engines, or any other engineered product) aren't invented
whole cloth sans iteration. However, it's understanding of the invariants of
the iterated system that allow for directed iterative design and ultimately
better products.

Rather than repeat this argument, I'll refer to
[https://news.ycombinator.com/item?id=7656184](https://news.ycombinator.com/item?id=7656184)

------
briantakita
I accept that I will be downvoted for this.

My impression of the Haskell community is its full of snobbery and
complaining.

This has got to be the 4th javascript ducks post on hn in the past week.

I like hearing the positive aspects of Haskell. However, the language x sucks
posts are tiresome.

Develop an imagination. Javascript can be wielded very effectively. It's just
different. I hope that I or someone else wires posts on what can be done to be
effective with javascript and weakly typed systems.

There are advantages to using weakly typed languages, mostly centered around
flexibility and rapid iteration. The disadvantages are alleviated by
comprehensive functional or black box testing. Skip the unit tests.

I feel liberated by not having a strong type system restricting my options.
Ymmv. People have different styles and preferences.

~~~
wyager
>My impression of the Haskell community is its full of snobbery and
complaining.

Probably because the Haskell community is used to having a programming
language that is, in and of itself, very good. They complain because they know
what they're missing when they have to use inferior tools.

>Develop an imagination. Javascript can be wielded very effectively. It's just
different.

The same can be said of x86 assembly. That doesn't mean we don't complain
about programming in it, and we don't try to find better alternatives. The
entire field of programming language development is about finding tools that
are better than the old ones, even if the old ones work OK.

>The disadvantages are alleviated by comprehensive functional or black box
testing.

If you think "more testing" alleviates all the problems of weakly typed
languages, you have _no idea_ what you're missing.

>I feel liberated by not having a strong type system restricting my options.

If you feel restricted by a type system, you're using it wrong. A type system
is a useful tool, not an impediment. It only prevents you from doing _wrong_
things.

"I like assembly because it lets me do any operation on anything."

~~~
gordaco
>>I feel liberated by not having a strong type system restricting my options.

>If you feel restricted by a type system, you're using it wrong. A type system
is a useful tool, not an impediment. It only prevents you from doing _wrong_
things.

I'm always baffled about how people say that using a dynamic language feels
"liberating". I feel completely the opposite; I have to be extremely more
careful with a dynamic language since either there is no compiler or it can't
detect many errors, so I have to do it myself (because, and this is a very
important lesson for absolutely everyone without exceptions: you _will_ commit
mistakes, no matter how good you are or how good you think you are). Getting
rid of static typing feels to me like, above all, getting rid of a lot of very
useful _guarantees_.

~~~
Solarsail
Aren't these two equivalent statements? Liberty to do any particular thing,
ever, increases the ability to do something wrong. And so requires more
caution. That doesn't stop restrictions that would alleviate said caution from
being overbearing themselves. (Maybe they aren't always overbearing, either
way...)

~~~
wyager
> Liberty to do any particular thing, ever, increases the ability to do
> something wrong.

The difference is that "liberty" tends to increase one's ability to do both
right and wrong. Dynamic typing tends to only increase one's ability to do
wrong.

~~~
pdonis
_> Dynamic typing tends to only increase one's ability to do wrong._

Apparently you place no value on programmer time. Why should I have to waste
time with type declarations that add no benefit to my program? Why should I
have to construct an artificial type hierarchy just so I can write common code
to deal with two different kinds of objects that are duck-type compatible but
don't happen to share a common base type that the type system recognizes?

I agree that there are certain kinds of applications where static typing can
be a benefit that is worth spending the extra programmer time; but the claim
you are making is _much_ stronger than that.

~~~
wyager
Static typing can save a lot of time otherwise debugging later, and really
isn't that much of a time investment.

~~~
pdonis
I agree, _for certain types of applications_. But as a general statement
applying to all types of applications, I disagree strongly.

------
jnbiche
I'm surprised that Elm is not mentioned:

[http://elm-lang.org/edit/examples/Reactive/ZipCodes.elm](http://elm-
lang.org/edit/examples/Reactive/ZipCodes.elm)

True, it's not Haskell, but it's clearly highly-influenced by Haskell.
Besides, they mention Fay, which isn't Haskell, either.

If the Haskell wiki didn't require a log-in and registration that requires
special, personal permission, I'd add it myself.

~~~
coolsunglasses
I don't recommend Elm because it's not Haskell and it's too boxed into its way
of doing things. Elm is really, really far from being an acceptable substitute
for Haskell. It's a gap comparable to that of what Java and Scala can do.

PureScript is a better choice for a Haskell'ish language that is generically
applicable to both browser and node-backed JS.

Importantly, you can decide how _you_ want to do FRP/callbacks/whatevers
according to the needs of the libraries/app/problem you're working with.

Also, PureScript has typeclasses, higher kinded polymorphism, the works. It
even has some cool stuff that Haskell does not built in!

See this post for example of why higher-kinded polymorphism is important:
[http://bitemyapp.com/posts/2014-04-11-aeson-and-user-
created...](http://bitemyapp.com/posts/2014-04-11-aeson-and-user-created-
types.html)

~~~
jnbiche
I would agree that there are probably more "Haskellish" compile-to-JS
languages, but the wiki mentioned CoffeeScript and TypeScript. Surely Elm
ranks above them in your book?

Besides, Fay doesn't have typeclasses, either, and it's mentioned.

I wasn't making the claim that Elm was somehow better than those options, just
that I was surprised it wasn't included. I've just played around with Elm,
nothing serious.

You're correct that Elm seems more like a DSL in some ways with its required
FRP, and I agree that typeclasses and HKTs are nice, but if I could choose
between doing my day job in Elm or staying with JavaScript, I know which I'd
pick (hint: it's not JS).

~~~
coolsunglasses
Do not underestimate how powerful and useful HKTs and typeclasses are until
you've used them in anger.

I have a guide to learning Haskell here:
[https://gist.github.com/bitemyapp/8739525](https://gist.github.com/bitemyapp/8739525)

You should give it a whirl.

Just use PureScript if you're fortunate enough to know alternatives to JS
exist :)

~~~
skrebbel
Why are you intentionally ignoring half of the parent's comment, twice? You're
not contributing to the discussion at all.

------
fiatmoney
Clojurescript is an excellent solution to most of the problems mentioned. In
particular, functional data structures & approaches are a great fit for
coordinating dependent updates to a UI based on events happening to a base
state - for a concrete example, the Om wrapper around React is very slick,
performant, and idiomatic.

~~~
camus2
clojurescript depends on the JVM.this is a no go for me.Once a cjs compiler is
implemented in javascript and can run on nodejs,then maybe i will consider it.

~~~
michaelsbradley
Would you articulate why it's a "no go" for you?

Leiningen[1] takes away 99.9% of the pain of having to work directly with
javac, maven, classpaths, etc. And lein-cljsbuild[2] offers a configuration-
driven approach to compiling and testing.

It's perfectly possible to create setups where node (plus grunt, gulp, shell
scripts, make, etc.) "drives" leiningen, and vice versa. About a year ago I
contributed such a setup[3] to David Nolen's mori library.

[1] [http://leiningen.org/](http://leiningen.org/)

[2] [https://github.com/emezeske/lein-
cljsbuild](https://github.com/emezeske/lein-cljsbuild)

[3]
[https://github.com/swannodette/mori/blob/master/package.json...](https://github.com/swannodette/mori/blob/master/package.json#L41)

~~~
jkrems
Because if other parts of your stack don't depend on Java, you have the
overhead of having to install a complete java environment (on dev machines,
CI, ...) just for compiling your front-end code. It also makes "language
independent" tooling for javascript harder. Then again: I guess most people
who use clojurescript are already using clojure so it wouldn't be a problem
for them.

~~~
michaelsbradley
Getting the JVM installed requires very little effort. On ubuntu linux, for
example, apt-get can be used to install openjdk or Oracle's distribution.
Travis CI provides java (with a choice of JDKs) in its testing environments.

So, I understand your point, but the installation "overhead" seems more like a
mole hill, hardly amounting to even a speed-bump sized obstacle.

~~~
jkrems
I recently had write up for a README how to install the JDK and set it up
correctly on OSX. You'd be surprised. Thanks to Oracle's policies it isn't
even close to where other runtimes/sdks are (e.g. installing ruby, node, gcc,
go, ocaml).

~~~
michaelsbradley
With homebrew and homebrew-cask installed on Mac OS 10.9, I was simply able to
do:

    
    
       brew cask install java
    

That might not cover the bases for every Java developer's needs, but leiningen
seems to work fine with the resulting installation.

~~~
jkrems
I'll have to look into versions (gotta be java7) but that looks pretty great -
thanks!

------
michaelsbradley
Seems a bit strange that there is no mention of ClojureScript in the "FP ->
JS" section.

------
vqc
I feel like "The Birth & Death of JavaScript" by Gary Bernhardt is appropriate
for this discussion.
[https://www.youtube.com/watch?v=Nr7ZEXLJHtE](https://www.youtube.com/watch?v=Nr7ZEXLJHtE)

In fact, the talk seems appropriate for every discussion regarding, but not
limited to, how terrible JS is or how it should die.

------
dpratt
I'm going to chime in to the chorus of "Why wasn't X mentioned" and throw out
Scala.js.

It would seem that Scala solves quite a few of the article's complaints about
Javascript, and in a manner that is accessible and usable for the masses. I
love Haskell as much as the next guy, but I'd rather use Scala if i need to
get stuff done.

------
girvo
I've been trying to convince my workmates to try something other than pure JS
(with Angular), but am not having much luck. TypeScript seems to have the most
buy-in, but most of the guys in the office aren't convinced of the benefits of
a proper type system, the just see it as more work for them for little upside.
Any ideas?

~~~
camus2
Typescript is hard.

It's module system is a mistake(it should be module system agnostic,not AMD or
CommonJS),and very confusing.

The biggest problem is javascript is so dynamic you cant create type
definitions for every library outthere and expect the typesystem to work.

Typescript is good if you are porting something from AS3/C#/Java to
javascript,or if You want to model a complex domain,without touching the DOM
api(or node api).

It sucks as soon as you try to use jQuery with it.You end up with any
everywhere which defeats the purpose of that language.

In my opinion,if you need to pick a js alternative,choose Traceur.

~~~
ehsanu1
Umm, no experience with typescript here, but can't you use the type
annotations from the DefinitelyTyped project [1] to avoid everything becoming
`any`? There are open source type annotations for all major (and many minor)
libraries, including jquery [2].

[1]
[https://github.com/borisyankov/DefinitelyTyped](https://github.com/borisyankov/DefinitelyTyped)

[2]
[https://github.com/borisyankov/DefinitelyTyped/tree/master/j...](https://github.com/borisyankov/DefinitelyTyped/tree/master/jquery)

~~~
camus2
definetly typed doesnt fix everything,just have a look at the ambient
declarations.

------
hrktb
The things that gave most of javascript quirks were auto comma insertion,
this, and global variable declaration. It's the same as how HTML has horrible
parts because from the start it bending backward to be as fault tolerant as
implementable.

That's why it succeeded and why a strong staticly typed language with very
strict error enforcement wouldn't have made it in the first place. Some things
are added bits by bits later (e.g modules, strict mode). The rest is a matter
of taste and use case: late binding allows different things, all numbers as
float is tasteless but it's not handicaping and there are ways around it,
syntax is a matter of tooling.

I think anyone wanting to write serious applications for a platform should try
to be the closer to the native environment, and adding an abstract layer on
top of javascript because 'it sucks' feels childish.

~~~
chrisdone
Using words like “sucks” is a bit of fun. Seeing obvious deficiencies in a
language and putting up with it for years instead of doing some work and using
a better one is childish.

------
chrisdone
I wrote (the start of) this page. Please bear in mind this _is_ the Haskell
community. We like our static types. This page is also kind of old news (2
years old) for us, the discussion is over, really. But I'll describe the
history of it for those interested.

So I wrote this paragraph
([http://www.haskell.org/haskellwiki/The_JavaScript_Problem#Ot...](http://www.haskell.org/haskellwiki/The_JavaScript_Problem#Others))
in 2012 in a reply to a reddit comment. Around that time the Haskell community
was growing in its web dev circles, and we as a community were cultivating a
sense that writing our web apps was not fun in 50% of the task, which was the
front-end.

There were actually a bunch of alternative attacks.

* Using so-called widgets which are compiled by Haskell and contain very minimal pieces of JavaScript that the user of the library never sees. This is okay. But if you're developing something more complex, you start to wish you were back in Haskell.

* Some were also thinking, perhaps it's just the framework that makes this work awful, we just need to pick the right reactive-MVC kind of framework.

* Use HJscript, an EDSL of JavaScript embeded in Haskell. This is not bad, I used this in hpaste and it's still running today: [https://github.com/chrisdone/lpaste/blob/master/src/Hpaste/V...](https://github.com/chrisdone/lpaste/blob/master/src/Hpaste/View/Script.hs) However, you're still left with the semantics of JavaScript, it doesn't really improve upon it. Although, if you're interested in this approach, definitely checkout Sunroof [https://github.com/ku-fpg/sunroof-compiler](https://github.com/ku-fpg/sunroof-compiler) which is like a new and improved version which has continuations out of the box.

* Some thought maybe CoffeeScript was enough, but it quickly becomes obvious that the problem is nowhere near syntax-deep.

In the end, I think everyone pretty much agreed just using Haskell would be
better. But there were no viable transpilers, so we were continuing with
JavaScript feeling that things could be better.

After that I decided to start trying out the bitrotted crop of compilers. I
tried GHCJS first, and reported my findings:
[http://chrisdone.com/posts/ghcjs](http://chrisdone.com/posts/ghcjs) The first
couple paragraphs are now on the wiki. I thought this community "feeling"
should be documented, and copying “The Expression Problem”, thought it would
be catchy to make a “The JavaScript Problem” post that is concise, opinionated
and comprehensive. Ask any random Haskeller and they will pretty much agree
with both paragraphs. It's easy to point someone to a wiki article to have a
common understanding of the problem.

I'm not one to simply whinge about things, however. I wrote down alternatives
and tried a few out myself. I experimented with GHCJS (above) and UHC (here
[http://chrisdone.com/posts/uhc-javascript](http://chrisdone.com/posts/uhc-
javascript)) and HJScript. Eventually, unsatisfied, I wrote the Fay compiler:
[https://github.com/faylang/fay/wiki](https://github.com/faylang/fay/wiki)
which was inspired by the simplicity and small output of Roy and the FFI in
UHC, and was a success (to some degree) because it was super easy to setup and
its output was understandable. We're using Fay at FP Complete for the IDE, we
have about 16k lines of code in Fay.

In parallel, the GHCJS codebase got a new set of very active maintainers, the
Haste compiler appeared [http://haste-lang.org/](http://haste-lang.org/) and
generally the community started to feel “hey, not only is compiling to
JavaScript practical, but we're starting to feel this should become standard
web dev in Haskell.” If you look at the crop of Haskell web frameworks (big
three are Yesod, Snap, Happstack) they all support compiling via Fay and I'd
expect haste, too.

I see some comments in this submission that the Haskell community is
"snobbish" and "complaining". We're apparently among the people who “wish
JavaScript was something else” and we shouldn't be one of those people, that
we just don't really “get” JavaScript and how to write it properly. We want a
car because we don't appreciate how to ride a horse properly. I'd say the
opposite. Here we saw the problem (as we saw it), and started working on
practical solutions and now people are getting paid to write Haskell that runs
in the browser. If that's not putting money where your mouth is, I don't know
what is.

Also look at the OCaml community with
[http://ocsigen.org/js_of_ocaml/](http://ocsigen.org/js_of_ocaml/) (also an
inspiration for my endeavors) and the Clojure community with
[https://github.com/clojure/clojurescript](https://github.com/clojure/clojurescript)
They identified the same problem and got to work. :-)

Since I added that wiki article, a bunch of new compilers and languages have
been added to the page (or invented). For the chorus of people asking "why
isn't X listed?", it's simply because users contribute to the article, it was
much smaller. So if you've heard of another approach, and, importantly, if
you've tried it and can report practicality, please go ahead and add it. I
think I'll add Opa to the list, it's like Ur in that you write front-end and
backend code in the same language.

------
WoodenChair
Pretty strange to mention TypeScript and not Dart... which solves a lot of his
criticisms and is arguably more popular. I respect the functional guys a great
deal but the use of Haskell for front-end dev is realistically going to only
be an interesting option for those already using it for the backend. It has
nothing to do with the merits of the solution and everything to do with
people's comfort zones.

~~~
dfkf
The page is about JS. TS is a superset of JS, and Dart is an entirely
different language.

~~~
mseepgood
All other languages listed on that page are entirely different languages as
well.

------
pan69
I'm surprised that Haxe isn't in the list of alternatives. It's been around
for quite a long time and it's very mature:

[http://haxe.org/doc/features](http://haxe.org/doc/features)

~~~
chrisdone
Oh, interesting. What's it like to use? Please add it to the article. I'm
adding Opa now.

------
Kiro
I'm surprised that lack of module system is the first thing brought up. Is
that really such a big deal? It's very much just a nice to have for me and has
plenty of third-party implementations if you want it.

~~~
zoomerang
It's just another annoying thing on the list of warts with Javascript that
make maintain a large codebase a pain in the arse.

Plenty of third party implementations is half the problem. Want to import a
module by somebody using a different module format? More pain in the arse!

~~~
chrisdone
It's similar in the Scheme community. It's easy to write your own module
system. So every compiler and every second Schemer has their own module system
with its own quirks and assumptions.

------
owenversteeg
I take issue with the paragraph about how Javascript sucks:

* Javascript is actually untyped, not weakly typed (untyped means no type declarations, not that it has no types) and I don't see that as a problem.

* Being an entirely interpreted language, JS cannot have static type checking. This has not been an issue in my experience.

* I think the syntax argument is laughably ridiculous. Programming languages that live in glass houses shouldn't throw stones. Just today, I've seen three links to guides "to learn basic Haskell syntax", two of which contradicted each other.

* I agree with their statement on `this` behavior. This (pardon my pun) is one of the places where JS's well-intentioned DOM-manipulation features cause problems with it as a language.

~~~
nilkn
> untyped means no type declarations, not that it has no types

I found this to be a very bizarre statement, given the existence of dynamic
typing. For anyone else confused, this is the best discussion I could find of
the issue:

[http://stackoverflow.com/questions/9154388/does-untyped-
also...](http://stackoverflow.com/questions/9154388/does-untyped-also-mean-
dynamically-typed-in-the-academic-cs-world)

~~~
seanmcdirmid
The programmer theorists view of what a "type" is will always differ from a
programmer's view. If I'm talking to a bunch of theorists, I know that types
are absolutely static entities, and everything else in the dynamic world are
actually tags. If I'm talking to programmers and am careful to make this
distinction, they will find me to be overall pedantic and verbose.

So unless one is having a discussion with someone like Bob Harper, dynamic
typing absolutely makes sense and is not a misnomer.

Untyped, however, is a bag of worms that you can't really get out of. To some
it means no type declarations, in which case Haskell is untyped to some extent
with its excellent support for type inference. To others, untyped means the
complete absence of types and type checking (static or dynamic)...like doing
something completely unchecked at run time with a void* in C. The views are
diverse among programmers, let alone theorists! So I just avoid this term in
any case.

------
z3t4
The problem you see is what I like about the language.

The javascript languages is great because I'm not forced into other peoples
way of thinking. With javascript I can choose my own paradigms.

module system: You can implement your own. Node JS has one built in.

verbose syntax: Use an editor that support macros. But compared to dot net and
Java, the JS syntax is not verbose at all.

getters and setters: I actually love not having to to write getters and
setters every time I want to add a property.

One important part in JS though is good naming. You can't get away with naming
everything x, y, z, a, b, c, etc.

Once you figure out that everything in JS is objects, it will be much easier.

------
benjaminjackman
Scala.JS is doing well for me.

~~~
chrisdone
Please add it to the article and report your findings! =)

------
stplsd
Oh, article with attitude.

