2

In these days there are many projects whose aim is to bring new languages to the browser by compiling them to JavaScript. Among the others one can mention ClojureScript, CoffeScript, Dart, haXe, Emscripten, Amber Smalltalk.

I'd like to try a few of these out, but I am not sure what I should be looking for when evaluating these languages to see if they are suitable for production.

How should I evaluate a new browser language, and what are the pitfalls I should be looking for?

Improve this question
12
  • 1
    Don't forget coffeescript.org, IMO one of the most interessting projects of that kind
    – user281377
    Commented Mar 21, 2012 at 9:51
  • @Tom It is not actually that open ended. There is a new technology out there and I want to find out whether it is mature enough to use it in production. In order to do so I ask people what there experience in the usage has been. There are much more open ended questions on this site.
    – Andrea
    Commented Mar 21, 2012 at 11:08
  • Please, understand that I do not want to argue over the definition of "open-ended", but I am genuinely interested in knowing which ones of these alternatives (if any) can be realistically used today in production.
    – Andrea
    Commented Mar 21, 2012 at 11:10
  • @Andrea If you think the close was wrong you can flag it for moderator attention or vote to reopen. Before you do though I really suggest you read the FAQ (programmers.stackexchange.com/faq)
    – Tom Squires
    Commented Mar 21, 2012 at 11:39
  • Hi Andrea, you would have better luck doing some research of your own into those frameworks, picking your favorite, and posting a question which asks if [insert framework here] is a good replacement for javascript. This will keep the question focused on a single topic which can be answered by a single answer, and not lead to many answers which discuss the merits of many different frameworks.
    – Rachel
    Commented Mar 21, 2012 at 13:35

4 Answers 4

Reset to default
5

This list could be used to evaluate a language, technology or process.

  • Does this language offer some benefit over what I currently use and trust?
  • Who else is using the technology in production and how does it seem from a user stand point?
  • What kind of community support does this project have? The more people using and working with something new the better your chances of getting things fixed and new features added.
  • What kind of learning curve does this language have for your team? The more difficult it is to pick up the greater the returns in functionality, speed, readability or maintainability must be.
  • Does this make sense for the project you are trying to complete? A great technology with only a few small advantages may not be worth the switch.
  • Lastly, give it an eye test. See how it works on a small sample to see how it really works for you and what problems you need to solve.

Specific things to look for with languages that compile to JavaScript:

  • Speed is a big issue with JavaScript, so testing the new language on a task vs the JavaScript you write yourself would be very helpful. You may find that the language writes faster running code than you do.
  • How easy is it to debug vs using strait JavaScript? It can be an issue if the generated JavaScript is to difficult to understand when things go wrong.
  • Check the overhead of using the included libraries, if everything is local it can be deceiving on how much code is being transferred to the client at every page load.
Improve this answer
3
  • Even though this answer isn't specific to browser languages, I still think it's a very good list of questions to ask when evaluating a new language or technology. Can you improve your answer to include some specific things to look for with browser languages that compile into Javascript?
    – Rachel
    Commented Mar 21, 2012 at 16:05
  • @Rachel What do you think? I am trying to write better answers, so any feedback is appreciated.
    – JustinDoesWork
    Commented Mar 21, 2012 at 16:19
  • 1
    Sourcemaps should solve a lot of the debugging issue. They are being demo'd right now on Chrome and firefox and will allow you to write code in whatever you want (GWT, CoffeScript etc) and debug in what you wrote. I expect that they will be out in a final version in 2-4 months in several browsers and packages (GWT, CoffeeScript, ClojureScirpt etc)
    – Zachary K
    Commented Mar 22, 2012 at 20:10
2

Checklist:

Potential Lose Concerns:

  • How does it handle a moderately complex webApp in all browsers you typically support.
  • How often do bugs get fixed?
  • How are the compiler debugging options?
  • What happens when you want to integrate with other dev's JS code?
  • What happens when you want to explain your code to JS developers who need to work with yours?
  • What happens if the community behind it walks away and JS eventually evolves beyond it leading to breakage when the JS down-compiler continues spitting out code that is no longer legal.
  • What benefit is it to your career as a developer if it never gains popularity and you pissed away years of professional experience on a fad language produced by people who just don't wanna like anything that doesn't work like the languages they know better?

Hopeful Win Concerns:

  • Does it help you produce faster?
  • Is it an absolute joy to work with?
  • Does it Make Working With the DOM easier than native JS (kind of a clunky API)
  • Is it easier for dirt cheap but otherwise completely useless sweatshop devs who can barely understand the Java they pretend they know to produce viable front-end code? (hint: no, it's not)

Obviously I've got a bit of a slant here but I have no problem with other languages getting popular on the front end. But not down-compiled to JS. That's just somehow offensive to me as a JS developer. If JS does what you need it to do, bend fold and mutilate it into something that works better for your thought process. It's flexible like that. The core syntax can't be altered but you can redefine the way you personally solve problems with it very easily once you know it fairly well.

Improve this answer
3
  • Why do you mind what other languages are compiled to? I like Javascript, but when I think of using another language, Javascript just becomes a target language. I do not feel offended that the compiler will emit unreadable code, just as I do not try to read the binary emitted by a dekstop compiler.
    – Andrea
    Commented Mar 23, 2012 at 16:14
  • By the way, about your last negative point, that is actually a positive side for me. Languages like ClojureScript or Amber are based on Clojure and Smalltalk, and these will not go away any time soon. Using their in-browser counterparts allows me to learn these languages while doing my work as a frontend developer. I would have less occasions to learn, say, Clojure on the JVM
    – Andrea
    Commented Mar 23, 2012 at 16:18
  • Finally, I really do not think that the people who have embraced, say, Clojurescript are people who are not willing to learn new tools. Most of them are people who were working in Java and decided to migrate to a Lisp...
    – Andrea
    Commented Mar 23, 2012 at 16:19
1

You should ignore these new languages unless they have a native VM/interpreter in at least two browsers. Only JavaScript currently complies with that criteria.

  • If a language doesn't have a native VM/interpreter it's inefficient. If your writing a non-toy application then you will care about being able to optimise performance heavy parts of your application. Having to use the abstracted language and hand optimised JS is a maintenance nightmare
  • If a language isn't natively supported in browsers then it's not future proof, it's a phase that will dissappear soon, (VBScript anyone?)
  • All of these abstractions are leaky. Your going to have to write or debug JavaScript in the end, and I wouldn't want to do both when I can only do JavaScript.

If your willing to maintain both JavaScript and the abstracted language in your application then you might want to consider using them

Improve this answer
19
  • So you're saying these new languages would not be appropriate for production at all until this gets implemented?
    – Rachel
    Commented Mar 21, 2012 at 15:25
  • 4
    You make an interesting claim, but offer no explanation.
    – Robert Harvey
    Commented Mar 21, 2012 at 15:48
  • 1
    @RobertHarvey CoffeeScript is always slower then JavaScript, if it's not, learn to write high quality JavaScript. If you think writing coffeescript and debugging/hand-tweaking JavaScript is maintainable then that's cool, I don't.
    – Raynos
    Commented Mar 21, 2012 at 16:03
  • 2
    I dont see why people would use anything else tbh.. I mean seriously just learn JS, even from a personal marketability standpoint it makes sense to just learn pure beautiful JS rather than some abstraction layer that may not be around in 2 years.
    – Loktar
    Commented Mar 21, 2012 at 16:31
  • 1
    The only possible advantage is that you happen to enjoy the style of coding better. I don't know what you expect these compilers to do for you. They boil it down to JavaScript. There is nothing the new language can do that the old one couldn't other than offer a different core syntax. For all this the negatives are legion: career experience wasted on a potential fad language, you lose or at least degrade your ability to debug from the console directly, and how are JS-only teams going to integrate stuff with your post-compiled code? JS is flexible and powerful. It doesn't need a do-over.
    – Erik Reppen
    Commented Mar 22, 2012 at 23:54
0

I find playing with a new technology is always going to be the best way to get to know it.

Once you have mastered the basics, you often start to try the more advanced features, or scenarios (ie. using the tool in some complex web app).

These are when you can start to find the limitations of a tool.

When this happens, I start searching SO, forums etc, to try and find ways round the issues. In these places you'll probably start to read other people's opinions and issues they have came across and it helps you get a better "feel" for the tool.

A more formal way might be trying to benchmark the tool against other solutions. Does it perform "well". (where "well" is to be defined by your system needs).

Improve this answer
4
  • 1
    The question is asking about specific things to look for when evaluating a browser language that gets translated into Javascript, not how to learn a new technology.
    – Rachel
    Commented Mar 21, 2012 at 15:00
  • @Rachel - not all tools are the same, like any new tech, the OP should play with and find it's pain points. I guess my answer is more generic than they were looking for though.
    – ozz
    Commented Mar 21, 2012 at 15:23
  • You got a downvote, because your answer is basically "try it out." The OP is asking how to evaluate the tool when he does try it out.
    – Robert Harvey
    Commented Mar 21, 2012 at 16:00
  • You just got an upvote, because your answer is basically "try it out" ;)
    – back2dos
    Commented Mar 22, 2012 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.