31–40 of 46 posts
Earlier quoted context omitted.
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.
Is transpiling really that different than running google closure on "native" js?
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…
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
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.
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…
Someone paid you to write something and you chose to use a language that is (only now) on version 0.16?
That said, every time I see a post about it I can't help the immediate response of "didn't pine replace that?"
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
Is transpiling really that different than running google closure on "native" js?
Another thing that we don't use.
It's just difficult to do non-trivial JS development without only "raw Javascript" in 2016.
For a moment I thought the article would be about the email client: http://www.instinct.org/elm/
Earlier quoted context omitted.
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.
But you are right that if a platform is popular enough, it will usually attract people that will do this work.
Earlier quoted context omitted.
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 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.
Earlier quoted context omitted.
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.