

Show HN: EmberScript - Ember.js Infused JavaScript - ghempton
http://emberscript.com

======
ebiester
The idea is intriguing. What if we think about tying a language to a library
rather than the other way around? Lisp and Forth both had the idea that you
should be able to build your language around the needs of your application,
rather than the other way around, and this kind of source compilation feels
like the extension of the idea.

(Yes, we could always do the same thing, and often have, but not in web-
world.)

~~~
gte910h
The web is a really weird platform for this though: There are SO many places
the lower level language (the one you're translating to) has to properly
handle, that DSLs feel like a big risk to many people

I'm personally looking forward to stuff like "CoffeScript, a 5 year
retrospective" etc, to show how safe all that stuff ended up being long term

~~~
ghempton
Can you elaborate on some places where "low-level" javascript is needed?

~~~
gte910h
Unfortunately, no I can't. I don't know where the frameworks break in 2013.
Been off the web for too long.

------
bengillies
This is interesting, but tying a language to a particular (version of) a
specific framework strikes me as a bad idea.

If the aim is to bake in syntactic sugar for different constructs within Ember
that are awkward in plain CoffeeScript (and there are a few), wouldn't
creating a CoffeeScript version of sweet.js[1] not be a better idea (I have no
idea if such a thing exists already)?

[1] <http://sweetjs.org/>

~~~
shaunxcode
I have been contributing to the strange cousin of the macro which is the
notion of inline DSL fragment. <https://github.com/ngn/coffee-subscript> In
essence you get latex looking (\dsl) syntax to enter what ever DSL (which is
just a standard node module). So this could be something as simple as an
annotation style approach in which you consume the next chunk of coffee-script
and simply wrap it - or something more involved like an entirely different
language (this originally stemmed from the desire to have inline APL ala
<https://github.com/ngn/apl> \- which provides \apl and \apl.fn respectively).

<http://github.com/shaunxcode/jsedn> and <http://github.com/shaunxcode/swedn>
also work currently. Right now they are naive e.g they just emit a call to
parse at runtime, when I get the time they will actually be more clever and,
well, actually compile at compile time hah.

Recently I have been toying with adding type annotations so I can easily port
a code base to typescript but have them be entirely ignored by coffee.

One side note is that we have discussed adding support for sweetjs as right
now these are definitely DSL hooks and not hygenic macros. In fact I would go
so far as to call these toothless macros e.g. it is up to you to chew the food
(parse) and swallow it (emit valid js).

------
machty
I love the CoffeeScriptRedux project and this is a perfect little application
of it. It's very easy to pick up once you know CoffeeScript and I love the
idea of stylizing your developer tools to fit a framework as rightfully
opinionated as Ember.

