Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

List of languages that compile to JS

github.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: List of languages that compile to JS

#41

Post by acjohnson55 »

babby wrote: post #17

I've had this discussion in other threads; but, how wise it is to use these instead of vanilla JS in a project you want contributed to? I personally find CoffeeScript very useful, and believe it's sufficiently widespread and mature as to be viable. All of these others though, I can only see it as increasing the learning curve on a project. I want to use IcedCoffeeScript (Oh, am I tired of Promises) and some of the JS…

The one limitation I see with using await-defer or generators for async code, instead of promises, is that you lose the ability to specify multiple continuations to your async call. With a promise, you can always continue your synchronous work after setting your `then` handler.

Re: List of languages that compile to JS

#42

Post by acjohnson55 »

lostcolony wrote: post #30
rubiquity wrote: post #25

Earlier quoted context omitted.

That would be a dream come true.

Provided it ran the same across browsers. My main gripe isn't Javascript (though I agree, argh), it's the DOM. So yeah, I could choose to write X instead of Javascript, but I still have the most painful of the pain points to deal with.

What's wrong with the DOM? I feel like jQuery abstracts away most of the pain. Do you mean the API itself, or in the abstract sense of laying out web apps like documents?

Re: List of languages that compile to JS

#43

Post by nickik »

nostrademons wrote: post #38
chc wrote: post #20

Earlier quoted context omitted.

CoffeeScript was never part of the pack. It's older than most of these and introduced most people to the idea of languages that compile to JavaScript.

CoffeeScript showed up in 2009. GWT has been around since 2006 and got widespread publicity when it launched. A number of the other options also came out well before CoffeeScript - Python's Pyjamas came out in 2007. What CoffeeScript did introduce people to was the idea of a language that compiled to only Javascript. And as such, it didn't have a pre-existing language community to point out the shortcomings of the JS…

> programmers used to the server-side implementation, which defeats the purpose of using the same language for both

I would actually disagree. In the Clojure world, we try to embrace the platform, meaning that we do not try to make all source compatible.

The goal is to have the basic comparable and then make all the more algorithmic library work everywhere. I think this has worked out pretty well so far.

Things like core.logic, core.match, core.typed and so on work on both sides with relatively small adjustments.

Re: List of languages that compile to JS

#44

Post by nickik »

gordonguthrie wrote: post #37
lucaspiller wrote: post #36

Earlier quoted context omitted.

Wow, I thought at first this was just making an Erlang-style syntax compile to JS, but this is much more than that. Very nice! Does it run on BeamJS? :D

No. The client and the server are such different environments. In the server you want 10s of 1,000s of processes, with long lifes (years, months) and hot code loading and supervision/restart. None of this is needed/available in the browser. So the key goal is low-impedance - the developer has a mental model where this is say a server-side process and the business rule is 'send the user a message' so they write code l…

On a browser you would also want 1000 process maybe. There can be tons of different inputs you need to monitor and then you might do a lot of transformation on them.

Supervision and restart are not only useful if a application is long running, if you implement a game, a user might to spend many hours on a page. They might leave it open in a different tab for a long time and expect it to work when they get back.

I know more about CSP and not Actors but there you use many of the same tricks (I think). And I really don't see why one would constrain the browser side.

See for example this project: http://www.infoq.com/presentations/pedestal-clojure

Re: List of languages that compile to JS

#46

Post by gordonguthrie »

nickik wrote: post #44
gordonguthrie wrote: post #37

Earlier quoted context omitted.

No. The client and the server are such different environments. In the server you want 10s of 1,000s of processes, with long lifes (years, months) and hot code loading and supervision/restart. None of this is needed/available in the browser. So the key goal is low-impedance - the developer has a mental model where this is say a server-side process and the business rule is 'send the user a message' so they write code l…

On a browser you would also want 1000 process maybe. There can be tons of different inputs you need to monitor and then you might do a lot of transformation on them. Supervision and restart are not only useful if a application is long running, if you implement a game, a user might to spend many hours on a page. They might leave it open in a different tab for a long time and expect it to work when they get back. I kno…

I don't agree.

The mission is to be a dom-scripting language http://luvv.ie/mission.html

I didn't just pluck 9 out of the air, it comes from thinking about how I would structure applications that I have written.

Take for instance our online spreadsheet - very complex GUI - 2,500 divs - but when you ask what are is the concurrency - what are the discrete functional data models that I need to manipulate - the number is low:

    * a menu bar
    * a toolbar
    * a tabs bar
    * a grid
    * the cell input overlay
    * 5 or 6 dialog boxes
The grid is endless scrolling set of spreadsheet cells and behind the scenes it is pre-built panels of 20x20 which are 'next-but-one' assembled on the fly for smooth scrolling.

Even if you break the grid out for max concurrency - you only add another 8 or 9 concurrent data models.

9 - 29 Web Worker processes for a page sounds liveable with.

With regard to restart and supervision I really do mean the Operational Supervision that Erlang/OTP supervision does in terms of handling errors. I don't see how the sophisticated restart and fail-over strategies that you might have in a 50-node server cluster will ever work. The user is the consumer, and they are in front of their device, failing over to another browser is not an option. Page refresh covers most of what you might ever need.

I don't know what CSP is, so I can't really comment. I also don't really have any knowledge or desire to support gaming.

Re: List of languages that compile to JS

#49

Post by chc »

nickik wrote: post #43
nostrademons wrote: post #38

Earlier quoted context omitted.

CoffeeScript showed up in 2009. GWT has been around since 2006 and got widespread publicity when it launched. A number of the other options also came out well before CoffeeScript - Python's Pyjamas came out in 2007. What CoffeeScript did introduce people to was the idea of a language that compiled to only Javascript. And as such, it didn't have a pre-existing language community to point out the shortcomings of the JS…

> programmers used to the server-side implementation, which defeats the purpose of using the same language for both I would actually disagree. In the Clojure world, we try to embrace the platform, meaning that we do not try to make all source compatible. The goal is to have the basic comparable and then make all the more algorithmic library work everywhere. I think this has worked out pretty well so far. Things like…

Clojure is odd in this way. Java was created as a cohesive, self-sufficient platform. Clojure was always envisioned as sort of a passenger — something to be grafted on to an existing platform. From the very early days, it already lived in two different environments simultaneously (the JVM and CLR), so the culture and the practices were already there, and it wasn't too jarring when they added JavaScript.

Re: List of languages that compile to JS

#50

Post by nickik »

gordonguthrie wrote: post #46
nickik wrote: post #44

Earlier quoted context omitted.

On a browser you would also want 1000 process maybe. There can be tons of different inputs you need to monitor and then you might do a lot of transformation on them. Supervision and restart are not only useful if a application is long running, if you implement a game, a user might to spend many hours on a page. They might leave it open in a different tab for a long time and expect it to work when they get back. I kno…

I don't agree. The mission is to be a dom-scripting language http://luvv.ie/mission.html I didn't just pluck 9 out of the air, it comes from thinking about how I would structure applications that I have written. Take for instance our online spreadsheet - very complex GUI - 2,500 divs - but when you ask what are is the concurrency - what are the discrete functional data models that I need to manipulate - the number is…

> The mission is to be a dom-scripting language http://luvv.ie/mission.html

If that is your goal then I dont want to clame that you have not achived it. This looks quite good for many things, my point is however that I mayself would not want to restrict myself this way.

In the future we be able to directly go from one browser to another, we might query or get messages from tons of diffrent servers, the OS might send us events and so on. More and more, the browser becomes a application deployment target.

> 9 - 29 Web Worker processes for a page sounds liveable with.

The question is not really if I can live with, the question is if I want to.

It just seamst to me that, when light weight concurrency is good on the server we should also use it in the browser. Seams to me this would help with the idea of using simular programming models on both ends.

> I don't see how the sophisticated restart and fail-over strategies that you might have in a 50-node server cluster will ever work. The user is the consumer, and they are in front of their device, failing over to another browser is not an option.

I can imagen many things. Lets say a you inplment some game or simulation where you have threads of executuion doing some calculation and maybe rendering themselfs on the screen. Now it would be nice to have some sort of fail-over system that might monitor all these and can potentially restart them, maybe get some information from the server or internal data store, maybe it is required to shut down all the other threads and restart them as well.

Maybe you stop getting messages from the server, and you have to restart the server or go and search for another server. Maybe you have to get a message from the server, informing you that it is shuting down and internal storage should be used.

I can image lots of things, and I dont know why I should restrict myself by design.

> I don't know what CSP is, so I can't really comment. I also don't really have any knowledge or desire to support gaming.

CSP is what Go implments (or core.async library in clojure).

Post reply on HN