New Adventures for Elm | Hacker News Reader

New Adventures for Elm

elm-lang.org

283 pointsshoover86 comments

I've been looking at the options for pure-functional languages targeting JS, and it seems that PureScript is superior to Elm from a technical perspective for full-stack webdev. PureScript takes the approach of providing a full Haskell-like language that is "native" to the JS world. It has the features and type system of Haskell, but atop a cleaned up version of Javascript's semantics (e.g. strict evaluation, not lazy, by default). It's also well suited for both server and client code, and even has a C++11 backend in the works in addition to the native JS backend.

In contrast, Elm is focused on front-end work and is less expressive, but emphasizes simplicity. Elm's goal of figuring out how to simplify and distill the Haskell and ML world's abstractions is an admirable one, but as an experienced programmer interested in practical work I'd rather just go with PureScript and just learn the Haskell-like abstractions along the way. It also really helps that the PureScript compiler's javascript output is "natural" and easy to understand, without any mysterious transformations involved.

Have others looked at PureScript, Elm, Haste, GHCJS, etc and chosen differently?

I'm currently moving from Elm to PureScript. Here's why (from "strong" to "weak"):

- Currently Elm has a sad story addressing integration with "native" javascript libraries and Elm is too opinioated in some cases, e.g. you can only use either the built-in 'Elements' or virtual-dom Elements to render frontend. This makes it hard to build modular components (see https://groups.google.com/forum/#!topic/elm-discuss/65tiRM7S... for example)

- While the simple type system in Elm (e.g. no type classes, no monads, ...) makes beautiful error messages possible, it really limits the abstractions that I am used to coming from Haskell

- Elm/Elm-make does not generate modules that conform to a "standard" js module system - thus it will not integrate well with other js tools

- Elm syntax is lacking 'where' clauses, which results in constant reindentation of code

Don't get me wrong - I liked Elm a lot; but it just does not seem mature enough to use in production - but it looks like a great language to start learning FP.

Elm's extensible records are more powerful than even what Evan is willing to encourage. You can use them to implement type classes as well as first class modules, albeit with a bit of extra typing (ahem). They even permit you to have multiple "instances" for the same type if you require that.

The problem is that it will not work for higher kinded types as that's not supported in Elm. You can not define a functor, a monad, ...

Out of PureScript, Elm, Haste and GHCJS, I like PureScript the most. What sold me on this language was the JS output after compilation - PureScript doesn't translate a huge runtime to JS (like the other options), it will only include the code which is actually needed.

Another advantage of PureScript: The foreign function interface is ridiculously easy to use.

I moved from Elm to PureScript 1 month ago, and I don't regret it. Here's my earlier explanation why [0].

[0] https://news.ycombinator.com/item?id=10727009

I looked at Elm, PureScript and GHJS, and chose PureScript for pretty much the mentioned reasons (powerful types, clean output, easy JS interop). I have a lot of experience in Haskell, and I find it refreshing that PureScript libraries and solutions have a lot of freedom to implement whatever they want, compared to the Haskell world which has a large amount of conventions to adhere to (and standard libraries to be compatible with).

Well, "superior" is subjective in this case.

It's like an OO programmer claiming that Smalltalk is a superior language than Elm. Besides, Purescript is squarely targeted at experienced Haskell programmers, which is not the case of Elm. Elm is an ML language, not a Haskell dialect that compiles to JS.

I also evaluated Elm, Purescript, Roy, F#, JS_of_Ocaml and ended up choosing Elm precisely for the reasons you chose to stay away from it. I only use JS for front-end stuff, I value simplicity over expressivity and I don't want to spend many weeks learning Haskell-like abstractions to start being productive in a new language (in contrast, it only took me an afternoon to start being productive in Elm).

> "Elm is an ML language, not a Haskell dialect that compiles to JS."

To be clear, Haskell also comes from the ML lineage.

ML stands for machine learning, correct?

Not in this context. It's an old functional programming language that influences a whole family. https://en.wikipedia.org/wiki/ML_(programming_language)

In this context, it stands for MetaLanguage, which is a language family (and was at one point a language itself, I believe). The family includes Ocaml (see the ml there?) and Haskell, among many others.

Yup, and I have a sneaking suspicion "Elm" is "Evan's ML", except EML sounded bad.

As a point of possible interest to people who are interested in programming language history, I'm going to elaborate a bit on this topic:

The root of this particular family tree is essentially a fusion of the lambda calculus-inspired parts of Algol 60 and Lisp with some new ideas for syntax that were promoted by Peter Landin in his highly influential paper from 1966, "The Next 700 Programming Languages". He called this language ISWIM; it was studied extensively but never directly implemented. Landin was also associated with Dana Scott and Christopher Strachey in their foundational work on programming language semantics.

Robin Milner was interested in the relationship between the logic underlying the semantics of programming languages and the possibility of using computers to prove propositions in that logic (a logic developed by Dana Scott in support of his semantics work). At Stanford, he and a small team (including Whitfield Diffie, who later went into cryptography...) developed a system called Stanford LCF (for Logic of Computable Functions). This was an interactive system in which the user states a main goal in the logic, then splits it to subgoals and more subgoals until they can be solved directly. Proofs were represented directly by data structures and were built directly by the proof manipulation commands, which corresponded to the inference rules of the system.

Milner moved to Edinburgh in 1973, where he worked on a subsequent version of LCF, Edinburgh LCF. Stanford LCF was limited by the size of the proof data structures; for Edinburgh LCF Milner had the idea to forget the proofs, but store the results of them; i.e. the theorems. The proof steps would be performed, but not recorded. To ensure that theorems could only be constructed via valid proofs, a meta-language was developed with a static type system that would only allow data structures corresponding to valid theorems to be built. It also allowed more sophisticated proof development, since the meta-language was a full higher-order programming language modeled after Landin's ISWIM. Exceptions were included to deal with the possibility of failure of particular proof strategies. This version was implemented in Lisp.

LCF spread to other universities; it was early on split into two parallel tracks, ML and Caml. Both have continued to be strongly associated with implementation of theorem proving systems. ML and LCF have become Standard ML and HOL; Caml has become OCaml and Coq. A lot of programming language research has also gone into ML and OCaml as languages in themselves due to their close association with the logic underlying semantics of programming languages.

Meanwhile, a language called PAL was developed in 1968 at MIT in response to ISWIM and Strachey's ideas on programming languages. David Turner, while starting his Ph.D. research at Oxford, got access to the PAL sources and used a simplified form of the language as the basis for his lectures on functional programming at St. Andrews; he called this language SASL. It was initially just a blackboard language, but a colleague surprised him by implementing it in Lisp.

In 1976, Turner changed the semantics of SASL from eager to lazy, based on a lazy version Landin's SECD machine. Somewhat later in his career, he combined ideas from lazy SASL, a cut-down version of SASL called KRC, and the ML-originated Hindley-Milner type system to form a language called Miranda. And Miranda is one of the primary influences on Haskell.

So, this leaves out a lot of other languages such as HOPE and lazy-ML that also were developed in this space. But what's interesting to me is how all these languages, from ML to Haskell, are so strongly related to Algol and thus the Pascal, C, Java, etc. languages that are more familiar to industry.

That got a lot bigger than I intended; I hope someone takes some interest from the digression.

Indeed, thanks for taking the time to write that up.

Very interesting, thanks!

I thought that you might be one of my college profs, but then realized that he would never apologize for a long post.

excellent, thank you for the insight

However, the ML in OCaml stands for "Machine Language." OCaml stands for "Objective Caml." Caml, while in the ML lineage, stands for "Categorical Abstract Machine Language."

What were your reasons for picking Elm over js_of_ocaml?

If I remember correctly, js_of_ocaml was poorly documented and the community was miniscule at the time (we had a hard time finding code examples outside of Eliom on Github).

Also, I was the only one with actual OCaml experience, and the other devs found Elm much easier to learn.

We almost went with Funscript, I think, but unfortunately F# on *nix was a no-go.

Yes. Here's my LambdaConf 2015 talk on how I ended up at Elm from PureScript:

https://www.youtube.com/watch?v=B7Iwreo1ReU

I started writing a small-to-medium-sized web application in Elm, because I wanted to try out FRP. I mentioned my experiences here: https://news.ycombinator.com/item?id=10726648 In short, Elm has some nice error messages, and it's easy to use at first. But as my app got larger, other factors became major issues:

- Elm requires a painful amount of boilerplate code. A lot of this is related to the fact that it tries to do functional programming without many of the customary abstractions.

- Elm's FFI (via the ports system) is really painful to use. If you ever need to integrate to third party code, or get a value from the DOM, it's going to require creating a new port in your main module, a new listener in JS, and wiring everything up.

- A lot of Elm tools and APIs have bugs. For example, I discovered that if I built my app using the recommended Elm architecture, I couldn't use the debugger. But even some core APIs like Window.dimensions burned me more than once, with things like: https://github.com/evancz/start-app/pull/37

I've started porting the app to Purescript. I used the Purescript book, which is excellent: https://leanpub.com/purescript/read I'm especially happily with Purescript's FFI, and its generally pragmatic attitude.

However, Purescript doesn't come with a "blessed" UI library, so you have to pick. I briefly tried the ambitious Halogen library, but the sheer type-system complexity ground me down quickly. I eventually went with the Thermite library, which is a very thin library wrapper of React (< 300 lines of code). So far, Thermite has been very nice, and quite easy to use, though it could use some enhancements and tweaks.

Overall, I like Purescript a lot. My basic problem with Elm is that it tries to be very opinionated, with very few escape hatches, so when I got stuck, I tended to get stuck very hard. Whereas with Purescript, it's much easier to drop down to JavaScript, but also to "pop up" and pull a well-known abstraction out of the standard Haskell toolbox if I need one.

I've been thinking about this a lot lately and I think you might be right. I've been using ClojureScript professionally for years, shipped some stuff with TypeScript, used GHCJS for some side-projects, and not feeling satisfied with doing front end development with any of them I spent some time catching up with new front end tech and AltJS languages over the Christmas break. Here's my highly opinionated and shallow thoughts on this matter:

* ClojureScript: This is the only AltJS language I've done real work in and used in anger, so naturally it's the one I'd complain about the most. I don't like being negative so I'll keep it short: It doesn't provide the same increase in productivity relative to the host language as Clojure does to Java. The advantages it has over ES6 fail to make up for the loss of a huge ecosystem and this only seems to get worse because of the rate big JS community innovates (whether you'd classify this as 'churn' is another matter).

* GHCJS: One of the most impressive compilers out there that target JavaScript. If you are already spoiled by Haskell and comfortable with it's semantics and runtime system definitely go for it. But if you are approaching this from the perspective of a front end developer who's looking for a better language this will feel like learning C++ just so that you can compile it with Emscripten.

I've used GHCJS to build https://github.com/osener/markup.rocks which runs Pandoc in browsers and it's certainly the best, if not only, option if you are looking to compile some existing Haskell codebase to JavaScript. My decision to stop using it has more to do with my lack of experience with Haskell than any problems with GHCJS itself. I tried to adopt so much new stuff at once with my limited Haskell experience, Reflex, GHCJS, FRP etc., and I'm having a hard time pinpointing which ones netted the increase in program robustness I've experienced (app development in JS feels so brittle in comparison) and which ones caused my lack of productivity.

After visiting this codebase after spending more than half a year without doing any Haskell GHCJS DOM APIs were revamped and I was so unfamiliar with my codebase that I didn't know where to start converting it to the new API let alone add new features. I started exploring packages like https://hackage.haskell.org/package/react-flux to see if I can take a more conservative approach with GHCJS and get the benefit of leveraging the ready-made React components out there. Unfortunately I was also very unhappy with the 26MB uncompressed JS output and wanted to add JS based renderers for stuff like Markdown and split Pandoc to its own .js file to lazily load it when it's needed. Thinking about this I realized that my main use case for GHCJS was compiling Pandoc and once I split that up I don't need to choose between two Haskell front end libraries and write the app itself using a more pragmatic stack and get some performance benefits (GHCJS produced code is especially hard on mobile browsers).

At this point I was pretty spoiled by Haskell and wanted to keep most of it while taking a more pragmatic approach. This brought me to

* Elm: I didn't know a language could provide such a good UX until I discovered Elm. From simplicity of the syntax to compiler messages, wonderful piece of work! I won't get into it's shortcomings compared to Haskell; although I can see the usefulness of additions like Typeclasses there are lots of posts from experienced Haskellers suggesting language features, and posts from Elm's designers explaining their choices not to include these. I'm not educated enough in these matters to say anything that hasn't been said before in favor of either stance.

My real suprise wasn't lack of Typeclasses; it was how unpragmatic Elm is, especially since it's not an attempt to adapt an existing language for front end development but a language designed specifically for it. I certainly applaud their goal to create a better way to write browser apps and I understand that they are in it for the long haul but I need to be productive right now and even GHCJS has a better FFI solution than Elm. When people ask how to use a JavaScript library from Elm in mailgroups and stackoverflow, their communities stance seems to be "include CSS and rewrite the JS code in Elm". This might be fine if all you need is to rewrite Bootstrap's dropdown logic in Elm but for doing real work not being able to leverage existing open source projects will quickly invalidate any productivity benefits you get from using Elm.

I love everything about Elm and I'm sure it will keep getting better & gaining mindshare but for now I can only rationalize using it in a small well contained part of a big application that lives in an island (and it is hard to find a good fit for this). Elm programmers; please standardize a better way to use native libraries and lose that 'yuck, that's unsafe' attitude against existing solutions written in JS. After publishing a complete library by writing bindings you can always rewrite it internally in Elm one function at a time.

So Elm is not for me right now. If you are still with me, I'll finally cover...

* PureScript: For some reason, during my journey through AltJS languages I've never considered PureScript before exhausting most of my options. I think this has to do with the grumpy attitude I used to have about front end development years ago when I first started doing less and less back end work. I wanted to keep all my trusted tools and always sought solutions that would let me. I liked how ClojureScript would let me use Leiningen, GHCJS would let me use Cabal etc. to build my projects. After front end development started to be something I enjoy doing rather than something I have to do, I realized I should start seeking solutions that would let me embrace tools web community has to offer and piece well-made blocks together to create web applications rather than fighting against it and living in my own island grudgingly rewriting everything. I love how PureScript is just a part of the toolstack like CoffeeScript and each .purs file produces one .js file without any runtime. On a scale from line-to-line transpilers like CoffeeScripts to beasts like Emscripten this is the sweet spot for me.

I've been using React almost since it's first incarnation and after writing a lot of CLJS/Om code I've come to realize that HTML is the best DSL to write HTML in and plain React+JSX is the best way to create views for me. Plus, all the React components I can just grab and use give a huge advantage over any 'virtual-dom' based library like Elm-HTML, Halogen. JS leaves a lot to be desired regarding app structure, error handling, side effects, business logic etc. and fortunately you can mix-and-match PureScript with JavaScript however you like. It has a FFI system that's best-in-class and semantics that are easy to reason about and won't need a big context switch when interacting with the outside world. In fact, the approach I'm taking now doesn't require me to write the main application in PureScript with React bindings and treat the JS code to be as the 'outside world' because you can just https://github.com/ethul/purs-loader in your existing Webpack configuration and start doing require('./PurescriptModule') right away. If you are using Redux for example, you can write your Views in JS and let React+JSX do what they do best and write your Actions and Reducers in PureScript. This will give you the benefit of being able to use existing React components and concisely define browser rendering while defining your business logic & execute side effects in a safer and more expressive language.

I would seriously love a tutorial on how to write Redux actions/reducers/etc in Purescript.

One really nice thing about purescript is that it dumps out readable JS. It's a really handy aid to figuring out "So how can I use this with library X?"

> The advantages [ClojureScript] has over ES6 fail to make up for the loss of a huge ecosystem…

What kind of "loss of a huge ecosystem" did you have in mind?

> …and this only seems to get worse because of the rate big JS community innovates (whether you'd classify this as 'churn' is another matter).

Last time I looked at CLJS and JS, it was the JS community that was catching up with CLJS (figwheel vs hot reloading, re-frame vs redux). People like David Nolen, Bruce Hauman and Mike Fikes are doing a lot of stellar work!

ur/web is worth a look too: http://www.impredicative.com/ur/

Haste also generates reasonable output (it can be debugged, though it is nothing like as reasonable as purescript) and has a runtime that is only 500 lines of straightforward javascript. It had pretty haskellish runtime semantics (purescript doesn't) I was able to use my existing tools like hdevtools, and have what (with just a couple ifdefs) functions as a single code-base for client and server. But its community is just too small, its updates too sporadic. I couldn't see building a business on it. Purescript or Typescript would be the only compile-to-javascript languages I would consider for serious work.

Love purscript, big advantage to frontend devs

Here's the path I've been following :

(ruby)rjs -> prototype -> jquery -> backbone -> angular -> react -> flux -> redux -> elm...

But I'm just a backend guy happy with Ror, just waiting to go on the frontline... with the proper weapons!

My feeling about elm is that it's more than the new kid on the js block. It's closure without parens, it's Haskell without academy, it's Redux without facebook, it's duck-typing without quacks, it's MVC without objects and last but not least evan Czaplisky (the creaor) is the new Aaron Patterson (bright and fun!)

I'm all in (but yeah I've been bitten before)...

That's a lot of churn. You should stop and ask yourself if it's worth being on the cutting edge all of the time. Are you making better projects as a result of dropping "old" tech the moment something shinier comes around?

Everything has tradeoffs. Elm has no server side rendering, for example.

It may not be that he's trying to be cutting edge, so much as trying all of the options to see which one he wants to use.

Considering rjs and prototype are way past dead and buried, that path covers a good 6-8 years, and up until React mirrors what most client-side devs have gone through.

>Are you making better projects as a result of dropping "old" tech the moment something shinier comes around?

That's a lot of assumptions you are making there. Why "better projects" is the only metric considered here? Perhaps, OP utility in front end technologies is based on their learning. Or what's you reason to assume OP is dropping old tech "the moment something shinier comes around" and not after a reasonable period of exploration and trial?

Prototype.js was created in 2005, 10 years ago. Angular was released in 2009. React was released in 2013.

A lot of churn? Absolutely not. Someone staying current, perfecting their skills and knowledge? Good for them!

The HN trend of "hipster shaming" people trying new, sometimes esoteric technologies (even if it's only for the novelty factor!) is not conductive to constructive discussions and really has no place in the community named Hacker News.

Unless building a taste for long lived techs as opposed to favoring the newest reinvention of old ideas is part of the learning process?

You can skip all of that and just use https://github.com/gaearon/react-transform-boilerplate as your sole dev environment. You don't need all of that other stuff, especially for prototyping. This is an instant win if your familiar with React (its just JavaScript)

From my limited experience playing with Elm

Pros:

- All the Joys of functional programming .

- Once you satisfy the compiler you can be fairly sure that code will just work.

- FRP saves you from callback hell.

- Fairly easy Javascript Integration via Ports( also see con on this)

- Time traveling debugger ( see con about this)

- Active mailing list.

- Automatic package versioning which more or less works for the most part

- Pure render function ( popularized by ReactJS), makes writing/debugging UI's trivial and painless.

- "Concurrent" FRP

Cons:

- Javascript integration is very and tedious. You have to declare all your ports in main which breaks abstractions. There is "secret" way of integration via Native modules but this will break if compiler changes ( which does quite often ).

- Debugger/reactor won't work if you have ports, basically all non trivial apps.

- All the ui components have to be reimplemented since stuff like jqueryui/webcomponents don't work ( react suffers from this also)

- No support for isomorphic apps, its a client side only tech.

- Can't do code splitting. Compiler generates one big blob of js.

- Constantly changing terminology ( eg: mailbox)

- IDE's/code editors are on the same level as dynamic languages i.e no code completion, refactoring ect.

Maybe check out clojurescript. Lots of React/Flux/Redux/Elm like ideas in there, you'll get exposure to clojure proper.

That said, maybe stick with elm. The only way to make the thing you love blossom is by promoting and evangelizing it. :)

Most of these comments boil down to, "the food's awful and the portions are too small!". Someone wants better JS interop because Elm will be a small part of their stack; someone wants server-side and isomorphic apps because Elm will be a large part of their stack. Yes, the tooling and language features have a long way to go, and hopefully Evan will make progress while at NoRedInk. If you enjoy Haskell, you're not really Elm's target audience. If you hawkishly watch HN, you're probably not the target audience - the point is that it's sane programming for the rest of us.

For those just getting started in FRP or whom may have not seen the presentations at StangeLoop:

- https://www.youtube.com/watch?v=Agu6jipKfYw - Controlling Time and Space: understanding the many formulations of FRP by Evan Czaplicki (Elm language designer/Prezi)

- https://www.youtube.com/watch?v=1XNATGjqM6U - FRP In Practice: Taking a look at Reactive[UI/Cocoa] by Paul Betts (Slack/GitHub)

- https://www.youtube.com/watch?v=HPyKHxy7X0w&t=18 - ReactiveUI - It's pretty neat by Brendan Forster (GitHub)

What's the best programming environment for Elm? I know there's a Light Table plugin for Elm, which I think is promising (in some ways they seem like a natural fit, whilst they started separately the direction of both was inspired at least in part by Bret Victor's ideas), but I wonder what other tools are being used to code Elm.

https://github.com/rundis/elm-light

Sublime Text with Elm language support[1] does auto compilation and is plenty enough. It also comes with an extension to SublimeREPL[2]

[1] https://github.com/deadfoxygrandpa/Elm.tmLanguage [2] https://github.com/wuub/SublimeREPL

I'm using Emacs. Maybe it's not the best environment for Elm. But it's consistent across languages; almost every language that I've played with has a mode; and it runs damn near everywhere including a terminal. For me, I feel it was worth the investment in the learning curve I made a couple of years ago...and keep making today. YMMV.

The atom plugin is excellent

One of the things I found odd (or maybe just annoying) is how the Elm Architecture doc [1] keeps mentioning how you can cleanly model your code using modules. But the module system is about as primitive as you could imagine. The language would be much more expressive with ML's module system, and functors would relieve some of the pain of not having type classes.

[1] https://github.com/evancz/elm-architecture-tutorial/

Congrats! I hope one day to work for NoRedInk. Elm is a big reason why.

Please apply! We're hiring. :)

http://noredink.com/jobs

Remote US only or remote EU also?

We currently have remote developers from the UK, Germany, and São Paulo. (We do wantjunior hires to be in the office, though, to facilitate mentoring.)

We do a solid amount of pair programming, but remote pairing via ScreenHero is pretty sweet. :)

What would the requirements to apply for remote, "non-junior", position be?

There are more details for each position at our jobs page :)

https://www.noredink.com/jobs

Remote EU too for non-junior candidates!

I definitely will :-) Just need to wait until I am closer to graduating.

Not a single Elm job, though, which totally contradicts the article.

Both the Junior Engineer and the Senior Front-end Engineer are jobs with Elm.

I am a frontend developer and I wanted to learn Haskell for a long time. But I just can't wrap my head around it. Is Elm or Purescript a good way to ease into it? If so, which one is better?

One of the major goals of Elm is being easy to learn, both from a language and a library point of view. PureScript is, for better or worse, no simpler than Haskell as a language, with all of the power of Haskell but its complexity as well. Elm is going to be much more approachable, and has a major focus on readable documentation and simple, straightforward concepts. It takes trade offs in language features in exchange, but is probably a better bet for someone who wants to get up and running quickly.

> PureScript is, for better or worse, no simpler than Haskell as a language, with all of the power of Haskell but its complexity as well

Is it really no simpler? A few common complexity complaints i hear about Haskell that don't apply to purescript in order of frequency:

- Haskell is lazy by default

- has too many language extensions

- records pollute global namespace

- has fmap and map

- $ is confusing

Except that Purescript uses the liberty from Haskell legacy libraries to become even more hardcore on algebra and categoric language. The relatively small user base also consist of experienced Haskellers, and the libraries tend to be quite advanced. For example, the "basic component" in the beginning of the Halogen tutorial already mentions natural transformations (which made me instantly intrigued, personally, but I'm one of those experienced Haskellers).

> to become even more hardcore on algebra and categoric language

In some of the standard libraries, yes, that's true. However, it's possible to use PureScript without the standard libraries, and use alternatives such as Preface (a teaching library) or Neon (an alternative to Prelude)

https://github.com/paf31/purescript-preface

http://pursuit.purescript.org/packages/purescript-neon/0.1.1

- Lazy/strict does not make affect language simplicity. I'm talking about how much time it takes to learn how to write programs in the language.

- I'm not sure what you mean by too many language extensions. That's kind of like saying a language has too many libraries -- just use the ones you need. It doesn't make the language more complicated.

- The records problem is a problem, but that doesn't make Haskell more complicated.

- I never deal with the fmap/map problem because I use ClassyPrelude, and there are other even more trivial solutions out there (to the extent that that's a problem). Also, <$> is a thing.

- Doesn't purescript also have the $ operator? You could certainly define it if not. In any case, if you're not comfortable using $ and similar combinators, you're probably not going to find purescript easy...

As an experiment I tried rendering elm in the server. It's renders fine but I'm not sure that it doesn't re-render everything on page load.

http://blog.overstuffedgorilla.com/server-side-elm-with-phoe...

When is back-end elm?

These are some very exciting news for Elm and its community. Well done!

Nice.

"It's unprecedented for a company our size to hire a language creator," says R.Feldman of NoRedInk. http://tech.noredink.com/post/136615783598/welcome-evan This might be true, but it's also a very smart marketing investment. I would have never visited NoRedInk otherwise, and it's the kind of company that would benefit immensely from general word of mouth discussion

My comment is off-topic and likely to annoy people here, but I'll say it anyway: that entire page appears to have been generated in Javascript. If you view source, there is no HTML at all. What would a user with a screen reader hear if he or she were to visit that page?

If the page had been written in plain HTML and CSS, it might be about 10-15k in size. At the moment, written in Javascript, it's over 300K in page weight. So both inaccessible and bloated in page weight. This is really bad practice.

> What would a user with a screen reader hear if he or she were to visit that page?

Well, the page still renders paragraphs and titles to good ol' <p>s and <hX>s, so i'd presume a screen reader would just read those things as the page content. Wouldn't it?

the screen reader needs to execute the javascript before it can read the tags. I'm not sure if they do that

Most do, thankfully, and have done for a while now :)

Two years ago, 97.6% of screen-reader users surveyed had Javascript enabled.

http://a11yproject.com/posts/myth-screen-readers-dont-use-ja...

Depends on the screenreader. And unfortunately, also depends on the screenreader + browser.

If the proper HTML tags are used, and role attributes are applied, it should work fairly well.

The concern, however, is the weight of the page. But don't let React fool you - they try to do the same thing - rendering HTML with JSX. And the same problems can present themselves there.

Reply on news.ycombinator.com