Have not had time to try Elm yet but Elixir is such a pleasure to use, it's painful going back to JS :)
Hopefully something grows out of https://github.com/bryanjos/elixirscript so far it seems very actively developed.
Elm and Phoenix/Elixir in Production for France TV
31–40 of 80 posts
Re: Elm and Phoenix/Elixir in Production for France TV
#32Have not had time to try Elm yet but Elixir is such a pleasure to use, it's painful going back to JS :)
Hopefully something grows out of https://github.com/bryanjos/elixirscript so far it seems very actively developed.
Yep hope it becomes production ready at some point, but you obviously will loose isolation and all soft real time properties when running transpiled JS.
Re: Elm and Phoenix/Elixir in Production for France TV
#33Earlier quoted context omitted.
Are you using ports much? The examples in the documentation aren't very clear, and I'd be interested to know how much plumbing is required to talk to external Javascript in real life.
It's not much. On the Javascript side, the Elm `app` is like an event emitter where you listen for updates and send it data. var app = Elm.Main.embed(...) app.ports.gameState.subscribe((data) => ...) app.ports.tileClick.send([x, y]) On the Elm side, you subscribe to incoming ports and map them into Msgs. And you emit to ports with Cmds from your update function. -- Ports.elm port gameState : Json.Encode.Value -> Cmd…
Yes, but just like the ones in the docs, that's a nearly trivial example, and so doesn't demonstrate the complexity.
What I'm concerned about is the case when I want to call a Javascript function from deep down inside, say, a computation function. Do I have to split my computation into two halves, one which sends the event which calls the Javascript function, and another which receives the result of the function? How do I pass the in-progress computation state from one to the other? Normally in a functional language I'd get around this by simply passing a function reference into the Javascript function which the handler would then call, so allowing me to have both parts of the computation in the same place and operating on the same data, but apparently in Elm function references don't survive being passed through Javascript.
Plus, each port only has a single incoming event, so if I'm calling the Javascript function from multiple places I can imagine it can very easily turn into a labyrinth of state passing code.
How do you avoid this?
Re: Elm and Phoenix/Elixir in Production for France TV
#34Earlier quoted context omitted.
> Elm apps are a single blob of JavaScript that either loads or doesn't This is what bothers me about Elm. In the next few months, I'll be starting on a site project, and I've been fiddling with Elm and I don't see how I can create progressive web apps with it. It doesn't seem to play well with service workers for an offline mode, and there's no fallback if Javascript is disabled. Either it loads or it doesn't. I wan…
Its true that you can't currently write a service worker in Elm. However, in practice for any decent size app you are going to end up with a mix of Elm and Javascript with communication happening through ports. Therefore you can write the service worker in JS and then talk to it from Elm. Of course it would be nicer to be able to write everything in Elm, but I find having the majority of your app in Elm with a bit of…
I'm a huge TypeScript fan.
Yet I worry about adding Elm to new projects, mostly because it raises the level of developer I need to hire to maintain it. I'm not in SV or in a tech hotspot at all, so maybe I have to think about this more than the average HN reader.
Re: Elm and Phoenix/Elixir in Production for France TV
#35Earlier quoted context omitted.
It's not much. On the Javascript side, the Elm `app` is like an event emitter where you listen for updates and send it data. var app = Elm.Main.embed(...) app.ports.gameState.subscribe((data) => ...) app.ports.tileClick.send([x, y]) On the Elm side, you subscribe to incoming ports and map them into Msgs. And you emit to ports with Cmds from your update function. -- Ports.elm port gameState : Json.Encode.Value -> Cmd…
Yes, but just like the ones in the docs, that's a nearly trivial example, and so doesn't demonstrate the complexity. What I'm concerned about is the case when I want to call a Javascript function from deep down inside, say, a computation function. Do I have to split my computation into two halves, one which sends the event which calls the Javascript function, and another which receives the result of the function? How…
Some interactions with 3rd party libraries (like rendering stuff, leaflet.js, pixi.js) fall along natural event-driven faults, like the game update tick finishing, something managed by Elm being clicked, that sort of thing. In these cases, ports (events) are the obvious fit.
Then there's synchronous 3rd party library stuff where you just want to execute a Javascript function, like a math function that you aren't going to reimplement in Elm. In that case, I wrap the function with a native module and call it like an Elm function. Since you talk of computation, is this what you're talking about?
The Elm community highly discourages native modules. For one thing, they aren't very well documented and the API seems to have recently changed. But I'm not sure what the alternative is.
Re: Elm and Phoenix/Elixir in Production for France TV
#36Elixir and Phoenix are stable and by now they're a solid choice (more than enough warranted praise on HN), but I'm still skeptical about Elm from a "platform" perspective. From what I can tell, Elm apps are a single blob of JavaScript that either loads or doesn't (e.g. you can't read the Elm site without JavaScript enabled), while the JavaScript ecosystem is moving towards server-rendering, dead code elimination, and…
At the very least, Elm code should be compatible with Google's Closure compiler (just like Clojurescript). There is no reason the Elm folks should try to re-invent the wheel on this, just harness the power of the Closure utilities by making your emitted JS standardized and compliant. Then you get all sorts of things for free, like dead code elimination, just for starters. The Clojure team realized this from the start…
I disagree. Google Closure is antiquated and complicated to configure and adds a lot of unpleasant baggage to cljs.
I love Clojurescript as a language, but using it alongside existing js libraries is awkward and error-prone, and getting the build process to work smoothly takes way more time than it should. Cljs gets a lot right too, but it shouldn't be held up as an example in this regard.
Re: Elm and Phoenix/Elixir in Production for France TV
#37Have not had time to try Elm yet but Elixir is such a pleasure to use, it's painful going back to JS :)
It really is. We're rebuilding our entire backend in Elixir and it's just been incredible every step of the way. I can't recommend it enough.
The language and ecosystem are an amalgamation of industry lessons from the past three decades on what it takes to build robust networked applications. It's the most painless programming experience I've had.
These days other languages feel like museum pieces when I have to jump back into them.
Not to mention being able to run dozens of services, background jobs, and API in a single box as one "umbrella application"!
Re: Elm and Phoenix/Elixir in Production for France TV
#38Even if you don't like JavaScript, it's really surprising to me that a CTO picks something like Elm that nobody uses and only a few know or are interested in [1].
I'm curious to know how the author will recruit developers, specially in France. My last company migrated all its backend in Node this year, ONLY because it was the easiest option to recruit full-stack developers. The market is completely saturated here (there are a lot more offers than developpers), you spend months to recruit a front-end developer or a full-stack developer with front-end knowledge, and I don't see how you can attract someone with Elm. Having 1 or 2 years of xp in Elm on a resume is not really usefull when all the companies use JavaScript. You don't even know if Elm will still be there in 2 years.
Re: Elm and Phoenix/Elixir in Production for France TV
#39Elixir and Phoenix are stable and by now they're a solid choice (more than enough warranted praise on HN), but I'm still skeptical about Elm from a "platform" perspective. From what I can tell, Elm apps are a single blob of JavaScript that either loads or doesn't (e.g. you can't read the Elm site without JavaScript enabled), while the JavaScript ecosystem is moving towards server-rendering, dead code elimination, and…
Elm is working on server side rendering and it will come once it's ready.
When it comes to dead code elimination, it is true that the compiler currently does not have that. Luckily, the compiled js is just a series of functions (namespaces is a part of the function name, like namespace$functionname) and so a tool like uglify has no problem removing dead code. A minified Elm app is smaller than a minified React app.
Re: Elm and Phoenix/Elixir in Production for France TV
#40Elixir and Phoenix are stable and by now they're a solid choice (more than enough warranted praise on HN), but I'm still skeptical about Elm from a "platform" perspective. From what I can tell, Elm apps are a single blob of JavaScript that either loads or doesn't (e.g. you can't read the Elm site without JavaScript enabled), while the JavaScript ecosystem is moving towards server-rendering, dead code elimination, and…
At the very least, Elm code should be compatible with Google's Closure compiler (just like Clojurescript). There is no reason the Elm folks should try to re-invent the wheel on this, just harness the power of the Closure utilities by making your emitted JS standardized and compliant. Then you get all sorts of things for free, like dead code elimination, just for starters. The Clojure team realized this from the start…
The way Elm outputs JS today, it doesn't really have much to gain from being Closure compliant. Even uglify manages to remove most dead code from an Elm "blob", because Elm outputs javascript with a single scope. An Elm app is smaller than both a Cljs+React(om, reagent) and a JS+React app.