Show HN: EmberScript - Ember.js Infused JavaScript

by ghempton • 13 years ago

37 12 13 years ago

ebiester• 13 years ago

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.)

gte910h2• 13 years ago

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

ghempton2• 13 years ago

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

mhd• 13 years ago

This is basically what Vala is doing for glib/gtk (and it transpiles, too).

Languages with a more flexible syntax probably don't need it as much, of course (lisp, forth, SmallTalk, tcl etc.).

pavlov• 13 years ago

Now that Objective-C finally has shorthand creation syntax for NSDictionary and NSArray, the language is officially tied to a particular library (Foundation -- although there are of course other implementations in addition to Apple's).

bengillies• 13 years ago

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• 13 years ago

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).

tlack• 13 years ago

It would be fantastic if this kind of stuff was embraced by the CoffeeScript people and something like Erlang's parse transforms was implemented:

    # mycode.coffee:
    "use parse_transform('observers.coffee')"
    
    class Gradebook
        +observe scores
        gpa: ->
            sum(@scores)/@nGrades

Imagine the interesting (or perhaps chaotic) ecosystem that would develop if this kind of thing was encouraged?

ghempton2• 13 years ago

In EmberScript's case, sweet.js isn't sufficient for things like dependency inference (which require walking the AST).

In general, however, from the end user's perspective, why is using something like sweet.js better?

ratbeard• 13 years ago

I used batmanjs on a project a bit ago and enjoyed it a lot due to the API being designed specifically for CoffeScript.

It used the `class` construct instead of building its own Object.extend class system like most libraries do. Not only is that simpler, its much more powerful than the standard 'prototype = object literal' approach as CofeeScript classes have executable class bodies, so you can build macro-like class-level methods similar to ruby:

    class Alfred.Todo extends Batman.Model
      @persist Batman.LocalStorage
      @encode 'body', 'isDone'
      @validate 'body', present: true

From my brief glance at Ember it seems like the pattern to add macro behavior is to wrap property values in calls to things like `Ember.computed` which looks pretty clunky.

machty• 13 years ago

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.

Show HN: EmberScript - Ember.js Infused JavaScript

Related Stories