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

Elm and Phoenix/Elixir in Production for France TV

vincent.jousse.org

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Elm and Phoenix/Elixir in Production for France TV

#71

Post by ergo14 »

Veen wrote: post #21
sotojuan wrote: post #3

Elixir 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 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…

You can solve this nicely with Polymer. When elements load they are just new HTML tags and they get "upgraded". Polymer gets way less love on HN than it deserves in my opinion.

Re: Elm and Phoenix/Elixir in Production for France TV

#72

Post by s_kilk »

sotojuan wrote: post #50
leshow wrote: post #29

I hope Elm doesn't get too closely tied with Elixir. It's a great language no matter what backend you choose.

I also don't get why they're coupled a lot... they're very different once you get past that they're both "functional" (and Elixir really just has HOFs and immutability by default, it's very practical). If it makes you feel better, I only see this coupling online. Most people just use server-rendered pages or regular JavaScript.

It's really just a weird overlap in the communities. There's nothing tying Elm and Elixir together aside from the anomaly where many people who started experimenting with one also started experimenting with the other.

Re: Elm and Phoenix/Elixir in Production for France TV

#73

Post by di4na »

ggregoire wrote: post #38

Even 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 (th…

Recruti someone that do not know it and teach. It takes at most a week. And probably productive in a day.

Re: Elm and Phoenix/Elixir in Production for France TV

#74

Post by not-much-io »

mattetti wrote: post #62

> Elm has a low entry barrier Sorry Vincent, you lost me there. Elm is interesting for sure, but it's far from having a low entry barrier. Something has basic has having a button play a sound takes forever to figure out. You almost have to learn everything all over again. It's a cool project and I'm glad it's working out well for you, but Elm has a serious learning curve.

Just my 2c:

Paradigm wise: Yes functional programming can seem strange and hard if you haven't done it before. But that really isn't the fault of Elm, elm makes FP as simple as it can.

Language wise: Yes, the Elm architecture takes a bit to grok, but for me it was just an afternoon. Once you grok it, there isn't really much else you need to learn - you can hit the ground running, look up what you need when you need it.

Tooling wise: Just some basic tooling you get will get you very far, no setup either, just install and use.

If you do js interop, yes that can be cumbersome, but it is intentional. Elm strives to keep js out and write libraries in Elm. This is so we can have more of the guarantees that Elm provides. (no runtime exceptions!)

I'd rather say: "Elm has a low entry barrier for a FP language". One of it's main goal is to bring FP to the masses after all. :)

Re: Elm and Phoenix/Elixir in Production for France TV

#75

Post by Skinney »

hellofunk wrote: post #59
bjz_ wrote: post #53

Earlier quoted context omitted.

I haven't had much luck the the advanced setting for Elm - seems to optimise too much away, and I get undefined field errors when I try to run the code.

That's because Elm does not output JavaScript in the standardized format for Closure.

Closure doesn't really have a standardized format. It does, however, not like that you mix string and dot access for object (obj['str'] vs obj.str), which Elm does a couple of places.

Re: Elm and Phoenix/Elixir in Production for France TV

#76

Post by pdamoc »

hellofunk wrote: post #14
sotojuan wrote: post #3

Elixir 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…

Elm compiler knows more about the code than Closure compiler. It can safely remove more and do a bunch of other optimizations facilitated by the types.

There was a DCE branch at one point but it never got finished.

Re: Elm and Phoenix/Elixir in Production for France TV

#77

Post by leshow »

mattetti wrote: post #62

> Elm has a low entry barrier Sorry Vincent, you lost me there. Elm is interesting for sure, but it's far from having a low entry barrier. Something has basic has having a button play a sound takes forever to figure out. You almost have to learn everything all over again. It's a cool project and I'm glad it's working out well for you, but Elm has a serious learning curve.

Elm is one of the simplest languages you will ever stumble across. I realise the simple is subjective, but you must be having some kind of mental roadblock, because it really does almost ALL the work for you.

Re: Elm and Phoenix/Elixir in Production for France TV

#78

Post by weitzj »

mavelikara wrote: post #68
weitzj wrote: post #4

Earlier quoted context omitted.

We are doing a fairly large Elm app right now. And especially the refactoring reasons and static type system are appealing to us when you work in a team. Also being a functional language it is easy to crank out features in an afterthought, e.g. we added an Undo/Redo feature for operations the user does in this single-page client app. And being side-effect free this "merely" boils down in wrapping function calls in an…

> We are doing a fairly large Elm app right now. And especially the refactoring reasons and static type system are appealing to us when you work in a team. Do you miss this in the backend with Elixir?

The backend is not done in Elixir, but Go.

I would love to do it in Elixir with Phoenix, but this would mean the team has to learn another tool. Go is really easy and fast to pick up. Here the Go Toolchain/Ecosystem matters, which is easy to grasp, and you get a type system, which is not as sophisticated as in Elm, but fits the job.

An older project was done with Grails/Groovy. This was fun and fast to iterate. But after a while, when you come back to the old project code, it is hard to get the dynamic types into your head. So actually I would prefer a static type system. I know there is some tool for Elixir to handle this. But I did not look into this.

Re: Elm and Phoenix/Elixir in Production for France TV

#79

Post by tessierashpool »

sotojuan wrote: post #3

Elixir 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…

A rare few people are using Elm server-side in production already with lukewestby's worker stuff. Check the Elm subreddit. Elm's JS interop is much more interesting than your understanding of it: it's a pub-sub system which allows you to embed small Elm components in otherwise "normal" web pages very easily. More info here:

http://tech.noredink.com/post/126978281075/walkthrough-intro...

I'm sorry to be so negative but I really hope your comment doesn't remain the top comment as it's not very well-informed at all.

Re: Elm and Phoenix/Elixir in Production for France TV

#80

Post by polotics »

ggregoire wrote: post #38

Even 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 (th…

Are your statement not a tad bit prejudiced? How is Elm a Javascript flavor? it's not surprising that it gets a bad rap from a stateofjs flavors survey. Elm is very much a competing language and ecosystem, it happens to be much better. I am certain I will still be interested in elm two years from now, the productivity gain is there to stay.
Post reply on HN