Comment by kasbah | Hacker News Reader

Comment by kasbah | Hacker News Reader

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-write everything in JS.

In retrospect Elm really wasn't the right choice for that project because it wasn't mature enough (and maybe I hadn't been using it for long enough either). The lack of any kind continuation monad for managing effects at that point (later added to the language as Tasks) and the cumbersome interop with JS (still an issue) were real sticking points. It's just frustrating when you have a problem that can be solved trivially with a state-mutating for loop and you have no easy mechanism to do it. The boilerplate required to use Chrome's messaging within the app was really painful.

I tried to use Elm again for a personal project, a kind of gallery website with a JS search function [2]. After starting an initial prototype in Elm I switched to using React (which I had never used before) and found I was much more productive (even though the code is messier). Having a much bigger repository of re-usable modules and being able to take short cuts is really valuable at this stage of development (and the server-side compilation ability is really cool).

These experiences have made me wonder about the real-world place for Elm and how long it would take for it to rival something like React. I definitely think there is a lot of value in learning Elm to help you think about state in your application in a more higher level way but I would really hesitate in advocating to use it for real-world project at this stage (it does depend on the project of course).

[0] https://github.com/switchface/helm

[1] https://github.com/kasbah/mooltipass.hid-app

[2] http://kitnic.it/ | https://github.com/monostable/kitnic (work in progress)

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 of any new language. If you can't easily interop with the lowest common denominator language in the platform you build for, your language is too restricted for meaningful use. This is why Rust integrates well with C, because it has to, or it is irrelevant in many cases. This is why Clojure interops seamlessly with Java. Elm needs to get this point, or it will remain a niche hobby language avoided by professionals.

I think that's a bit unfair as Elm is already seeing some professional use.

Though on the subject of inter-op, Purescript might be what you are looking for if you want a strongly-typed, Haskell-like language, compiled to JS with a less cumbersome foreign function interface.

Your point still stands though, I hope Elm comes up with some good ways to say "trust me I know what I am doing" and "here is some JS, run it".

EDIT: Though it might be that that goes against the whole premise of the language.

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/

Scala.js is simply amazing: powerful, performant, acceptable compiled code size, easy interoperation with JS, lots of well-tested libraries, a good community, and excellent IDE tools.

I am very tempted to start learning Elm and Purescript. They both seem very elegant languages, but I keep postponing it until there is an IDE with good code completion, to ease the learning curve.

There's some work towards that in PureScript: https://github.com/kRITZCREEK/psc-ide provides an interface for multiple editors, seems like Atom, Emacs, Vim and VS are available currently.

I use Elm in production and I feel like I have a sufficient interop toolkit between implementing tasks (writing native modules) and ports.

Unlike Clojurescript, Elm interacts with your explicitly defined Javascript boundary rather than tries to let you mix it all together in the same soup.

The person you're responding to points out that they were more productive once they refinanced their code to take on some technical debt, but that's always an available trade-off in programming.

Well the Elm architecture inspired ClojureScripts re-frame and JavaScripts Redux. Both of those handle state similar to Elm. You are right that Elm is not ripe for primetime but Elm's value stretches far beyond its handling of state.

Also make sure to checkout NoRedInk's take-home and its server-side usage of Elm including server-side rendering.

https://github.com/NoRedInk/take-home

100% agree and it makes me try and handle state in a similar way even in plain Javascript without any libraries.

Will check out take-home more when I get a chance, I did see some murmurs on the Elm mailing list of how it would be easy to do server side rendering. What impressed me about React's was that I could just call a function and get the HTML as a string. My project is statically generated so that was exactly what I needed.

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.

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

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.

Personally, even though I also do have quite some webdev experience, I am wishing that mobile native development wins.

But on HN that is a sure way to be downvoted.

I'm personally hoping the future holds some way to blend the openness/interoperability of the web with the performance of native apps. Maybe React Native, maybe web assembly, etc.

I hope that pure mobile development doesn't win, because the mobile app ecosystems are way more controlled than desktops/servers, and if everything went Android/iOS, it would be a major loss for freedom.

It does not fix itself. It gets fixed through a lot of hard work by many people who shouldn't be hidden behind the curtain.

But you are right that if a platform is popular enough, it will usually attract people that will do this work.

Is transpiling really that different than running google closure on "native" js?

Another thing that we don't use.

Either you're stuck with ES4 (and worse, you can kiss goodbye to a large number of NPM modules which are ES6+) or you still need a transpiler and a system to package your scripts, handle polyfills, etc.

It's just difficult to do non-trivial JS development without only "raw Javascript" in 2016.

RequireJS, jQuery, JSF, ASP.NET, Spring are what we use.

I have to say you're missing a few years of awesomeness should you take the plunge.

Given that I go native, when given the option, I doubt I ever will.

We used to be RequireJS/jQuery based on the frontend. While this obviously depends on what kind of application you have, attempting to develop complex UI in jQuery is not an experience I'd describe as "pleasant", nor does it naturally lead to creating reusable components.

On the other hand, switching to React + Redux + webpack (and NPM) has changed development from "we can't do that" or "let's copy paste from some other component" to "I'll have something by tomorrow" and "I'll reuse the generic React widget I made last time". It's really a game-changer.

Also, ES6 >> ES4. Destructuring doesn't bring you what real pattern-matching does, but it's still a lot nicer than what ES4 gives.

Now try that in the context of 30+ enterprise developer projects, composed with multiple outsourcing/offshoring partners.

Companies that still want to target IE 8 or even the old Safari for Windows.

Actually, we manage to mostly support IE 8 through a combination of Babel and polyfills. You don't necessarily need to forgo modern goodness in order to support prehistoric browsers.

Someone paid you to write something and you chose to use a language that is (only now) on version 0.16?

Yes, it was 0.14 at the time I believe, though that version number doesn't really mean that much. Would you have been more comfortable with 1.0.0? That's what the core library was at. Anyway, I should have realised there were some essential components missing and the JS interop would be a major road-block for this application.

To clarify further: I normally work as a firmware/electronics engineer so this was a bit of an experiment all around. I didn't charge my normal rates either.

I'll point out that React is itself on version 0.14. Version numbers don't mean much.

Reply on news.ycombinator.com