Damn, look at this European protectionism /s.
(I'm a functional programmer, so yay for them!)
Elm and Phoenix/Elixir in Production for France TV
11–20 of 80 posts
Re: Elm and Phoenix/Elixir in Production for France TV
#12Elixir 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…
You can do progressive web apps quite easily. Your Elm code is included as always with and you pass the id of any container to initialize it. The container can be , but you can just as well attach to some in the footer and the rest is rendered independent of Elm. Regarding dead code elimination: yeah, elm doesn't do it yet. But the code generated by elm-make is very predictable and therefore easy to process. I just t…
Right, I get the last part. Just saying I wish I could have it now with little to no configuration :-) Not blaming Elm, it's still quite young and evolving.
Re: Elm and Phoenix/Elixir in Production for France TV
#13Nice writeup. Elixir definitely seems like a solid language for web dev. For the frontend, I prefer Scala.js since I'm kind of a Scala fanboy, but I've heard great things about Elm. One little comment. At the beginning of the post, you make it seem like the app needs to scale with the number of viewers, when in fact it doesn't. I think you should clarify this to avoid confusion.
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…
From what I can tell, basically all of the reasons you state for using Elm are also present in Scala.js.
Re: Elm and Phoenix/Elixir in Production for France TV
#14Elixir 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 and it has done a lot for the cljs ecosystem.
Re: Elm and Phoenix/Elixir in Production for France TV
#15This was great to read and it inspired me to give both a try soon. Question: Did the app receive millions of visitors or was it basically 1 visitor with millions of viewers via the television showing a recorded screen? At first I thought Phoenix was used because of scaling reasons but now I'm not so sure. Either way, nice work and thanks for the write up!
In my experience, Phoenix is used because a) it's easy to get started with b) isn't a monolith like Rails (e.g. Phoenix could be one part of your complete application) but it has good conventions and c) it leverages the Erlang VM's performance and concurrency through Elixir. I know HN gets a lot of hype for X new tech every month, but I'm really liking Phoenix. Ignore the "Phoenix is the future/saved our lives/best t…
I'm enjoying working with phoenix, but when comparing it with Rails, it would be fair to say "it's basically rails" and add a few footnotes about the differences.
People who started after Rails was released don't see it because they haven't seen how it was done before. But it's incredible how many conventions DHH created with rails that have since entered the basic repertoire of all web frameworks: migrations, its take on MVC, :belongs_to, the router DSL, the asset pipeline, generators – while you can probably find prior art for all of them somewhere, it's the implementation in Rails that, 10 years later, is still the blueprint for new frameworks.
Rails was also the best teaching tool ever invented in the space. Code quality was atrocious, people were reinventing "clever" solutions for every project, testing was probably rare (I never saw it, but it must have been around, right?) I distinctly remember a templating system that turn .xls into a perl script that would write php. If you changed projects, you'd usually be greeted by a directory tree 8 levels deep with the main config.php in /[..]/tmp-2008_b, along with config.inc, main.html.php.old and construction.gif~2.
(Not that Phoenix doesn't add lots of refinements that make it a pleasure to use)
Re: Elm and Phoenix/Elixir in Production for France TV
#16Nice writeup. Elixir definitely seems like a solid language for web dev. For the frontend, I prefer Scala.js since I'm kind of a Scala fanboy, but I've heard great things about Elm. One little comment. At the beginning of the post, you make it seem like the app needs to scale with the number of viewers, when in fact it doesn't. I think you should clarify this to avoid confusion.
Elixir is a fantastic platform for apps, and using Phoenix for the web interface makes things super easy.
I love it.
Re: Elm and Phoenix/Elixir in Production for France TV
#17Earlier 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…
From what I can tell, basically all of the reasons you state for using Elm are also present in Scala.js.
Elm has a sound type system, no compromise and is purely expression based. Scala, not quite. You can still have runtime exceptions in "normal" situations, you can still have statements that aren't expressions, etc.
Scala gives you the options to do it right, but Elm enforces it. Heck, because of how the application type works, its pretty much impossible to make an Elm app that doesn't follow proper architecture. It just won't compile.
Re: Elm and Phoenix/Elixir in Production for France TV
#18Earlier quoted context omitted.
From what I can tell, basically all of the reasons you state for using Elm are also present in Scala.js.
Elm has a sound type system, no compromise and is purely expression based. Scala, not quite. You can still have runtime exceptions in "normal" situations, you can still have statements that aren't expressions, etc. Scala gives you the options to do it right, but Elm enforces it. Heck, because of how the application type works, its pretty much impossible to make an Elm app that doesn't follow proper architecture. It j…
Definitely, but I see that flexibility as a good thing. I can either depend completely on the type system at compile time, or I can move some things to runtime, depending on what I'm writing and how much time I have to complete it. The boiler plate introduced by immutability and pureness can become unwieldy in large projects from what I've read.
Another cool thing is the option to use either a pure expression-based functional approach or a OOP approach, or even a mix between the two.
Re: Elm and Phoenix/Elixir in Production for France TV
#19Earlier quoted context omitted.
Elm has a sound type system, no compromise and is purely expression based. Scala, not quite. You can still have runtime exceptions in "normal" situations, you can still have statements that aren't expressions, etc. Scala gives you the options to do it right, but Elm enforces it. Heck, because of how the application type works, its pretty much impossible to make an Elm app that doesn't follow proper architecture. It j…
Definitely, but I see that flexibility as a good thing. I can either depend completely on the type system at compile time, or I can move some things to runtime, depending on what I'm writing and how much time I have to complete it. The boiler plate introduced by immutability and pureness can become unwieldy in large projects from what I've read. Another cool thing is the option to use either a pure expression-based f…
Yup, I know :) it's a matter of opinion. I was just saying that that's a significant difference that will make a segment of engineers pick something like Elm. Elm is also more minimalist and easier to pick up if you're not into FP. Even knowing Haskell, some Scala types make me go cross eyed.
On my side, if i have the choice between boilerplate or having to debug runtime errors, I'll pick the boilerplate any day. If my product manager thinks its worth it to push a feature earlier (and risking having it blow up), well, I'll go work for someone else ;)
Re: Elm and Phoenix/Elixir in Production for France TV
#20Have not had time to try Elm yet but Elixir is such a pleasure to use, it's painful going back to JS :)