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

Elm in the Real World

futurice.com

Post reply on HN
Print view View original

11–20 of 46 posts

Re: Elm in the Real World

#11

Post by pjmlp »

kasbah wrote: post #6

I really like Elm and have become an intermediate user of it (as well as Haskell). I felt like I really understood what Elm signals are about and made some optimisations to Helm [0] based on that. I pushed to use it for a contract for an open source application [1]. Ultimately that wasn't a success due to various factors but it's interesting to note that the client dropped Elm after I left and hired people to re-writ…

Personally I don't buy into any "Compiles to JS" language for production code, other than for dabbling.

The JavaScript compatibility problems across browsers are already enough, for me to sell to customers yet another layer to debug that might not even be properly supported by the respective browser debugging tools.

Re: Elm in the Real World

#12

Post by drapper »

seivan wrote: post #5

I guess this is like a better version of using TypeScript, React, *Flux and RxJS. Mostly because Elm seems to have everything builtin while you might have issues with TS typedefinitions. Also their success/fail tasks for HTTP calls reminds me of flux actions being dispatched. Dispatch action for an http class and then dispatch another action for success or failure. Or did I miss understand?

Someone should make an opinionated, batteries-included JS/TS framework like Elm, based on TS, React, Flux.

Re: Elm in the Real World

#13

Post by kasbah »

pjmlp wrote: post #11
kasbah wrote: post #6

I really like Elm and have become an intermediate user of it (as well as Haskell). I felt like I really understood what Elm signals are about and made some optimisations to Helm [0] based on that. I pushed to use it for a contract for an open source application [1]. Ultimately that wasn't a success due to various factors but it's interesting to note that the client dropped Elm after I left and hired people to re-writ…

Personally I don't buy into any "Compiles to JS" language for production code, other than for dabbling. The JavaScript compatibility problems across browsers are already enough, for me to sell to customers yet another layer to debug that might not even be properly supported by the respective browser debugging tools.

Yes, the source-map support in browsers really needs to improve. NodeJS is another matter though as, in my experience, it maps seamlessly.

I think Coffeescript, TypeScript and Babel (ES6 and JSX) are completely different beasts to Elm though. I can look at the compiled output of these languages and debug that, I don't really need source maps (though they would be nice).

I guess the idea for Elm is, you won't need to debug as you won't get runtime errors.

Re: Elm in the Real World

#14

Post by seivan »

drapper wrote: post #12
seivan wrote: post #5

I guess this is like a better version of using TypeScript, React, *Flux and RxJS. Mostly because Elm seems to have everything builtin while you might have issues with TS typedefinitions. Also their success/fail tasks for HTTP calls reminds me of flux actions being dispatched. Dispatch action for an http class and then dispatch another action for success or failure. Or did I miss understand?

Someone should make an opinionated, batteries-included JS/TS framework like Elm, based on TS, React, Flux.

The JavaScript world doesn't like that. That's why no one has made a carbon copy of Rails.

Even React, Flux, Router and etc comes in several parts.

I know railties are modular but at least they come from the same project and repo and update together.

Re: Elm in the Real World

#15

Post by cies »

pjmlp wrote: post #11
kasbah wrote: post #6

I really like Elm and have become an intermediate user of it (as well as Haskell). I felt like I really understood what Elm signals are about and made some optimisations to Helm [0] based on that. I pushed to use it for a contract for an open source application [1]. Ultimately that wasn't a success due to various factors but it's interesting to note that the client dropped Elm after I left and hired people to re-writ…

Personally I don't buy into any "Compiles to JS" language for production code, other than for dabbling. The JavaScript compatibility problems across browsers are already enough, for me to sell to customers yet another layer to debug that might not even be properly supported by the respective browser debugging tools.

I look at compile-to-JS as a temporary solution until WebAssembly is the norm. No way that in 2016+ the best we have for web development (most common case of GUI development) is JS :)

Re: Elm in the Real World

#16

Post by drapper »

seivan wrote: post #14
drapper wrote: post #12

Earlier quoted context omitted.

Someone should make an opinionated, batteries-included JS/TS framework like Elm, based on TS, React, Flux.

The JavaScript world doesn't like that. That's why no one has made a carbon copy of Rails. Even React, Flux, Router and etc comes in several parts. I know railties are modular but at least they come from the same project and repo and update together.

Yeah, the JS world currently is very pro-modularization, but I already saw some discussions on Twitter from the React/Flux people how that creates too big barrier of entry for the newcomers. One of the things that draw people to Angular is that it has almost everything that you need included - it's easier to say to someone "just use Angular", than "try React, with Redux, and Router, and Webpack - it will take some time to configure it, but it's worth it".

Re: Elm in the Real World

#17

Post by cies »

seivan wrote: post #5

I guess this is like a better version of using TypeScript, React, *Flux and RxJS. Mostly because Elm seems to have everything builtin while you might have issues with TS typedefinitions. Also their success/fail tasks for HTTP calls reminds me of flux actions being dispatched. Dispatch action for an http class and then dispatch another action for success or failure. Or did I miss understand?

> I guess this is like a better version of ...

Make sure to look at PureScript as well. It is a much less "opinionated" cousin of Elm. By opinionated I mean that Elm pulls HTML and CSS into the code, and has functional reactive programming built in; in PureScript these are libraries.

Re: Elm in the Real World

#18

Post by sjrd »

hellofunk wrote: post #8
kasbah wrote: post #6

I really like Elm and have become an intermediate user of it (as well as Haskell). I felt like I really understood what Elm signals are about and made some optimisations to Helm [0] based on that. I pushed to use it for a contract for an open source application [1]. Ultimately that wasn't a success due to various factors but it's interesting to note that the client dropped Elm after I left and hired people to re-writ…

I strongly believe that for any language that compiles to JS to be successful, seamless integration with existing JS is absolutely required. This is the main selling point of Clojurescript which, while I enjoy Clojure a lot, is a dynamically typed language like JS itself, and I wish I could interact with JS in a stricter way. If Elm can improve on its interop, it has potential to be a strong force. But this is true o…

And this is why Scala.js interops seamlessly with JavaScript. [1] Most of the time, you don't even know whether you're calling other Scala.js code or JavaScript libraries, and it's all typed. If you want to interact with JS in a stricter way, you should check it out.

[1] http://www.scala-js.org/doc/interoperability/

Re: Elm in the Real World

#19

Post by lumpypua »

pjmlp wrote: post #11
kasbah wrote: post #6

I really like Elm and have become an intermediate user of it (as well as Haskell). I felt like I really understood what Elm signals are about and made some optimisations to Helm [0] based on that. I pushed to use it for a contract for an open source application [1]. Ultimately that wasn't a success due to various factors but it's interesting to note that the client dropped Elm after I left and hired people to re-writ…

Personally I don't buy into any "Compiles to JS" language for production code, other than for dabbling. The JavaScript compatibility problems across browsers are already enough, for me to sell to customers yet another layer to debug that might not even be properly supported by the respective browser debugging tools.

Any commentary on "The Birth and Death of Javascript"?

https://www.destroyallsoftware.com/talks/the-birth-and-death...

As far as I can tell, Javascript the runtime is a juggernaut that there's no stopping. If a platform gets popular tooling fixes itself.

Re: Elm in the Real World

#20

Post by seivan »

drapper wrote: post #16
seivan wrote: post #14

Earlier quoted context omitted.

The JavaScript world doesn't like that. That's why no one has made a carbon copy of Rails. Even React, Flux, Router and etc comes in several parts. I know railties are modular but at least they come from the same project and repo and update together.

Yeah, the JS world currently is very pro-modularization, but I already saw some discussions on Twitter from the React/Flux people how that creates too big barrier of entry for the newcomers. One of the things that draw people to Angular is that it has almost everything that you need included - it's easier to say to someone "just use Angular", than "try React, with Redux, and Router, and Webpack - it will take some ti…

Well, it has it's benefits. I don't like Redux and I like Reflux so it allows me to do that.

Then again Rails does let you switch out compatible parts. By compatible I mean if it adheres to "Railties", e.g. using ActiveModel for replacing Pgsql with MongoDB.

Post reply on HN