10 ms·

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" p

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 "progressive web apps" so to speak. PureScript for example has dead code elimination—you can make a <1kb PureScript "Hello World" app. I know the Elm team is capable of all of these—I just haven't heard of anything yet. While they're "nice to have" now, these features might become crucial and important. Another interesting thing about Elm is its progressive removal of features (I think the infix operator was or is going to be removed soon) in order to make the language more approachable. I actually support this because if you need "true" ML/Haskell features, there's PureScript. Anyway, glad to see Elixir and Elm being used productively!

gotofritz 10y ago
Server side rendering doesn't remove the need for loading js on the client.
- sotojuan 10y ago
  The idea is to render as much of the app (usually the "shell" or the static content) through the server and then the client-side JavaScript takes over. As of right now support ranges from excellent (Ember FastBoot, out of the box), okay (React with some configuration), and nonexistent (Elm).
matt4077 10y ago
You can do progressive web apps quite easily. Your Elm code is included as always with <link..> and you pass the id of any container to initialize it. The container can be <body>, but you can just as well attach to some <div> 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 tried uglifyjs: raw elm-make output; 196kb uglifyjs -m -c: 68kb tar czf: 20k The inventor of elm is very deliberate in the project's development. I believe his argument is that including dead code elimination now is premature, because it adds a lot of maintenance work, especially at a time where the language is still evolving. Once the raw js is no longer a moving target it shouldn't be too difficult, and until then uglify and similar do a good job.
- sotojuan 10y ago
  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.
hellofunk 10y ago
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.
- danenania 10y ago
  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.
  - hellofunk 10y ago
    Closure's advanced compilation mode really optimizes the final JS, no?
  - smnplk 10y ago
    Do you know about cljs-js ? https://github.com/cljsjs/packages https://github.com/cljsjs/packages
    - danenania 10y ago
      Nope, I hadn't seen that. Definitely helps!
- Skinney 10y ago
  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.
Veen 10y ago
> 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 want to use Elm, I don't want to use JavaScript, but I also want a progressive web app that will offer some functionality offline. I guess there's a way to do some server-side stuff with Phoenix, but then the front-end / back-end division isn't so clear and I'd end up using JavaScript for the service workers anyway. I've not looked super deep into this, so I'd be happy to be corrected if I've got the wrong end of the stick here.
- ccapndave 10y ago
  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 JS is significantly nicer than having the whole app in JS. You can make it nicer still by using Typescript instead of Javascript, and defining interfaces for the data going through the ports, giving you type safety across the whole stack. I'm using this approach right now in a mobile Elm/Typescript app with great success.
  - softawre 10y ago
    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.
    - ccapndave 10y ago
      If you don't mind using remote developers, then your location doesn't have to matter. It's true that it might be a bit harder to find a developer (although Elm is getting more popular day by day), but the other side of the coin is that your application is likely to have less bugs and need less maintenance. My experience is that Elm takes a bit longer to write than JS/TS, but once written it tends to work correctly the first time.
Skinney 10y ago
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.
coldtea 10y ago
>while the JavaScript ecosystem is moving towards server-rendering, [...] and "progressive web apps" so to speak. Hardly. Server rendering remains at best a novelty, and "progressive web apps" are not coming back anytime soon.
tessierashpool 10y ago
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-introducing-elm-to-a-js-web-app 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.

gotofritz 10y ago

Server side rendering doesn't remove the need for loading js on the client.

sotojuan 10y ago
The idea is to render as much of the app (usually the "shell" or the static content) through the server and then the client-side JavaScript takes over. As of right now support ranges from excellent (Ember FastBoot, out of the box), okay (React with some configuration), and nonexistent (Elm).

matt4077 10y ago

You can do progressive web apps quite easily. Your Elm code is included as always with <link..> and you pass the id of any container to initialize it. The container can be <body>, but you can just as well attach to some <div> 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 tried uglifyjs: raw elm-make output; 196kb uglifyjs -m -c: 68kb tar czf: 20k The inventor of elm is very deliberate in the project's development. I believe his argument is that including dead code elimination now is premature, because it adds a lot of maintenance work, especially at a time where the language is still evolving. Once the raw js is no longer a moving target it shouldn't be too difficult, and until then uglify and similar do a good job.

sotojuan 10y ago
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.

hellofunk 10y ago

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.

danenania 10y ago
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.
- hellofunk 10y ago
  Closure's advanced compilation mode really optimizes the final JS, no?
- smnplk 10y ago
  Do you know about cljs-js ? https://github.com/cljsjs/packages https://github.com/cljsjs/packages
  - danenania 10y ago
    Nope, I hadn't seen that. Definitely helps!
Skinney 10y ago
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.

Veen 10y ago

> 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 want to use Elm, I don't want to use JavaScript, but I also want a progressive web app that will offer some functionality offline. I guess there's a way to do some server-side stuff with Phoenix, but then the front-end / back-end division isn't so clear and I'd end up using JavaScript for the service workers anyway. I've not looked super deep into this, so I'd be happy to be corrected if I've got the wrong end of the stick here.

ccapndave 10y ago
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 JS is significantly nicer than having the whole app in JS. You can make it nicer still by using Typescript instead of Javascript, and defining interfaces for the data going through the ports, giving you type safety across the whole stack. I'm using this approach right now in a mobile Elm/Typescript app with great success.
- softawre 10y ago
  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.
  - ccapndave 10y ago
    If you don't mind using remote developers, then your location doesn't have to matter. It's true that it might be a bit harder to find a developer (although Elm is getting more popular day by day), but the other side of the coin is that your application is likely to have less bugs and need less maintenance. My experience is that Elm takes a bit longer to write than JS/TS, but once written it tends to work correctly the first time.

Skinney 10y ago

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.

coldtea 10y ago

>while the JavaScript ecosystem is moving towards server-rendering, [...] and "progressive web apps" so to speak. Hardly. Server rendering remains at best a novelty, and "progressive web apps" are not coming back anytime soon.

tessierashpool 10y ago

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-introducing-elm-to-a-js-web-app 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.