4 ms·

I wonder about the ecosystem of any advanced language running on a JS engine. Basically, two things may happen in the future: - all the libs existing in JS ar

by lolive 10y ago

I wonder about the ecosystem of any advanced language running on a JS engine. Basically, two things may happen in the future: - all the libs existing in JS are recoded by dedicated fanatics in the advanced language. Then you have a versatile all-purpose development ecosystem with this language. or - you rely upon the existing JS ecosystem and libs, and eventually spend your time struggling with the impedance mismatch between JS and your advanced langage. Did you feel something like that with Purescript, Elm, etc?

somedudethere 10y ago
I think one of the primary benefits to ELM, etc is the typechecking, which you lose if you use FFI to call outside JS. Once you dont need jquery and you actually have a standard library, 2 of the largest requirements to the existing ecosystem (JQuery and Underscore.js) are no longer needed. Elm looks to handle much of he DOM and events so I doubt you would need React.js or Angular, which just leaves your datastore. (to better put it, much of the packages in Javascript are there because the language itself is insufficient to describe DOM interactions. Elm was created explicitly for the web thus removes the need for many packages)
- lolive 10y ago
  The other issue is the untyped nature of JSON. Interacting with JSON from Elm does require a lot of Encoder/Decoder. May be JSON/LD could be a nice improvement for that, but it will require a significant effort to be broadly adopted.
mbrock 10y ago
I haven't used Elm, but generally I think it shouldn't be that scary to use an "advanced language" if it has an even remotely decent FFI. It might seem like horror to have to interface to external dependencies, but if the libraries you want to access aren't extremely complex then interfacing with them probably isn't going to be such a huge problem. In some cases you might want to use the advanced language for some things but keep the outer layer of the app in JavaScript. At a previous workplace we had a particularly tricky parsing module written in Fay (Haskell subset compiling to JS).
- bbaumgar 10y ago
  The latter case has worked out great for us at helme.io. Our computational forecast library is written in Clojurescipt, while the rest of the application is in JS + Angular. A word of warning: with Clojurescript, at least, there is a big cost to converting between JS and CLJS types. This has been a big painpoint as our need for frequent calculations increases. Still, we wouldn't have it any other way.
clarus 10y ago
There could be also a third thing: - continuous evolution of the JS ecosystem towards a cleaner language, with solutions like Flow or TypeScript.

by lolive 10y ago

somedudethere 10y ago

I think one of the primary benefits to ELM, etc is the typechecking, which you lose if you use FFI to call outside JS. Once you dont need jquery and you actually have a standard library, 2 of the largest requirements to the existing ecosystem (JQuery and Underscore.js) are no longer needed. Elm looks to handle much of he DOM and events so I doubt you would need React.js or Angular, which just leaves your datastore. (to better put it, much of the packages in Javascript are there because the language itself is insufficient to describe DOM interactions. Elm was created explicitly for the web thus removes the need for many packages)

lolive 10y ago
The other issue is the untyped nature of JSON. Interacting with JSON from Elm does require a lot of Encoder/Decoder. May be JSON/LD could be a nice improvement for that, but it will require a significant effort to be broadly adopted.

mbrock 10y ago

I haven't used Elm, but generally I think it shouldn't be that scary to use an "advanced language" if it has an even remotely decent FFI. It might seem like horror to have to interface to external dependencies, but if the libraries you want to access aren't extremely complex then interfacing with them probably isn't going to be such a huge problem. In some cases you might want to use the advanced language for some things but keep the outer layer of the app in JavaScript. At a previous workplace we had a particularly tricky parsing module written in Fay (Haskell subset compiling to JS).

bbaumgar 10y ago
The latter case has worked out great for us at helme.io. Our computational forecast library is written in Clojurescipt, while the rest of the application is in JS + Angular. A word of warning: with Clojurescript, at least, there is a big cost to converting between JS and CLJS types. This has been a big painpoint as our need for frequent calculations increases. Still, we wouldn't have it any other way.

clarus 10y ago

There could be also a third thing: - continuous evolution of the JS ecosystem towards a cleaner language, with solutions like Flow or TypeScript.