There are lots of tools that promise to let you write your client-side code without touching an ounce of JavaScript.
Which ones does the Dev.to community use? Why should we drop everything and run towards your tool of choice? What are we gaining over just using ECMAscript?
My personal number 1 choice is Re-Frame. The minimal (750 SLOC!) structure it imposes makes perfect sense, and it lets you avoid rolling your own architecture. Defining UI with Clojure vectors via Reagent couldn't feel more natural, and interop is so seamless you barely notice you're doing it. Once you learn where everything goes, you've got everything you need to build performant, scalable real-world applications.
Next on my list to try is Halogen, but I haven't managed to get my head around it quite yet beyond a "hello world" application. PureScript is fascinating tech, though, and I'd love to dedicate more time to learning how to use it.
The easiest one I've used so far is ReasonReact. If you've used React, you can already use this tool and reap the benefits of the underlying OCaml compiler to check your code.
There's dozens I haven't mentioned - that's your job! Sell me on something nifty.
I'd also love to hear opinions about why this is all hogwash and we should just stick with what's already right in front of us. ES6/7/next/infinite is an expressive, robust tool in its own right, drawing inspiration in many cases directly from these tools - make your case below.
Top comments (17)
Highly recommend Elm (it has everything, its own package system as well, no runtime exception - and that is true and has been tested in production).
+1 Elm!
While I actually don't favor anything over vanilla JS, if you absolutely want to compile to JS from something else, Elm seems to offer some cool stuff. I've dabbled with it and it is a lot of fun. Wish it were more popular.
It is somewhat Haskell like, but doesn't have typeclasses.
This is my trepidation - typeclasses are one of the things I love most about Haskell. Is it limiting to not have an analogous system?
I hear both sides of the story. The general picture is:
I personally don't mind that at all. The language is very productive after all.
P.S. I was, maybe, a little bit misleading. It doesn't have typeclasses. But it has types and type inference as well. You can define your own types with custom types (previously known as union types).
Fair enough! Thank you.
If I can recommend the best presentation on the language, this one would be it.
No, I do not find lack of typeclasses or HKTs limiting (in Elm or F#). F# has sorta-kinda-halfway emulations of typeclasses and HKTs using statically resolved type parameters (SRTP) and inline functions. F# itself uses those as convenient solutions to problems like equality and math operators. But I never use those in my own code. Immutable types already have built-in value equality in F#, and for other types of operations, I'd rather use it as
MyTypeModule.opNamefor clarity of what it's doing and where the code lives. There are a few places where I would find HKTs useful, but it is not a big deal. I typically find I focus on types as data structures in F# and not so much on the type theory. And that makes coding pretty straightforward to read later albeit not quite as abstracted as it could be.Great answer, thank you! It's true I mostly leverage Haskell's typeclasses in the form of libraries that provide powerful abstractions. My love for them came from studying them, but that love hasn't necessarily translated into real creative use much. Ease of reading is a huge point too. I have a lot of appreciation for what Clojure can do with only the most basic building blocks, and Elm seems to embrace a similar simplicity but with types.
Thanks for the links, too. Hadn't heard of SRTPs, that's pretty cool. I assumed the solution was always modules, OCaml style, like your example - not that that's a bad thing by a long shot.
Fable-Elmish. It’s basically MVU (hence “elmish”) in F#. Plus the ability to write your own effects in F# (and synchronous if you want). Also auto gen JSON parsers if you know the JSON structure up front. The F# code is translated to JS thru Babel (hence Fable). It uses React to render the UI.
I still hate front end build stuff. But these tools at least make the coding part of the UIs nice.
Huh, this sounds really nice. I've never touched anything .NET, but if I did I always assumed F# would be my jumping off point. I'll have to look more into this, thank you!
I'm starting to explore using Kotlin/JS. I'm really intrigued by the idea of being able use one language to create libraries shared by frontend web, Android, iOS, and the server, but haven't really done enough in it to know how well it actually works for frontend web dev.
Awesome! In a similar vein, I've heard that people who try out ScalaJS never really want to use anything else.
Kotlin is seeming more and more like an excellent choice for my "new language of the year" in 2019.
Thanks for the recommendation!
By the way, the JS itself compiles to JS(Babel).
True enough! It's rare not to use some sort of compilation pipeline these days. Not to mention JITing engines in most major browsers
Take a look at Mint. It certainly has some potential.
Interesting! Never heard of this, thank you