Is it worth anything to start using GHCJS in 2021?

Learn
#1

By the time it was created, GHCJS was way ahead of anything in terms of front-end development.

But from an outsider point of view, it looks like the ecosystem kind of stagnated. Any Google search leads to 80% of results that are pre-2015. Very few resources, and I’m not even talking about the libraries (typeahead, UI framework, drag-n-drop managers…).

And during this same time, the situation of JavaScript frameworks improved dramatically, with Angular/React/Vue and gazillions of npm plugins that are ready-to-use and would take a monstrous amount of work to reproduce from scratch should they be absent when we need them (I’m looking at you, SortableJS).

Listening to a Haskell Podcast, I came across some guy who prided himself with having created ChatWisely’s entire front-end in GHCJS but honestly the site looks like a joke. No meaningful content, site takes ages to load and transitions between displays (pages or components) look like we’re running a PDP-8 terminal.

I went through the examples in https://github.com/reflex-frp/reflex-platform and they look appealing. But past these toy examples, is it a good strategy to build and maintain an actual real-world full-scale front-end application with GHCJS? Or has everyone kind of moved on to PureScript/ELM already?

There’s nothing I’d like more than to use Haskell for the front-end, and GHCJS’s 8.10 branch on GitHub looks up to date, but where are all the post-2014 libraries, tutorials, plugins, showcase examples, stackoverflow questions…

5 Likes
Beginner Question: Attempting to create copy of GHC
#2

To me it looks like miso and obelisk are still alive and kicking, but honestly this is not my forte.

Chris Done described his PoV on client-side web programming in Haskell in this article. It’s worth a read imo. I will also add one thing that wasn’t mentioned in Chris’ article which is purescript-specular - a port of reflex-dom to purescript.

4 Likes
#3

I can share a little about this, though my experience with GHCJS is as an operator running the product from the dev team (which used GHCJS on a frontend project). I did not write the code for GHCJS, I setup/ran CI and deployed the result.

  • The build and compile times were abysmal. Way worse than stock GHC. It took more than an hour to run a build for the UI.
  • I don’t remember the details, but I remember nearly everything about the setup and build were more difficult, less refined, and slower, than anything in GHC or something like Elm/Purescript/whatever. We either weren’t able to implement caching, or ran out of time due to the initial setup cost.
  • Implementing the project in GHCJS was a bit of an experiment for the dev team. We were mostly all backend folks and wanted to spend a little time with each of the options. The team didn’t use GHCJS on a second project.
  • There were good things about it that the devs liked, but they were also not happy about what had stalled on the project.
  • The ability to use Haskell for the front/backend is really nice. The interoperable data structures and not having to bridge that to javascript, also nice.
  • I would also guess including other/3rd party JS would be a problem at this point.
  • My opinion on it now: the project could be revived and live on, but not without significant effort and commitment. Without that, you’re either building a toy to learn, or playing with significant risk. I would not bet my project on it.
5 Likes
#4

I was under the impression that there was a recent effort to integrate GHCJS into GHC. Is that not true?

Edit: Source here: https://reddit.com/r/haskell/comments/msmv4l/is_ghcjs_stuck_on_ghc_865/gutn13h/

5 Likes
#5

GHCJS is definitely not dead. We actively work on it. However whether or not our use cases and priorities align with yours, I cannot say.

An eventual goal is to upstream ghcjs into ghc, making it just another codegen backend.

As probably one of the most prominent cross compiler, a lot of work that goes in general cross compilation improvements (hey, you can’t even use ghc plugins with cross compilers!), fixes that go into ghc to benefit all cross compilers (including ghcjs) won’t be visible as ghcjs improvements.

Recently a lot of work went into supporting unboxed tuples and unboxed sums for ghci. This means you less often need -fobject-code when using the interpreter. Quite a lot of work also went into adding a proper C toolchain (via emscripten) to ghcjs. Lots of Haskell code ends up somewhere depending on some C, thus having a better C toolchain integration means more code can be compiled.

The current focus is on fixing foreign exports to allow compilation of Haskell libraries to something that can be easily consumed/integrated into an existing JavaScript application.

15 Likes
#6

GHCJS is definitely not dead. We actively work on it

Well that’s a very encouraging thing to read. I can see that GHCJS, the compiler, is being worked on. But how about the other part, which matters just as much, and that is documentation, examples, learning resources, videos on YouTube, a StackOverflow community and so on?

I’m not saying it should all fall on the developers’ shoulders, that’s for sure. But I’d be curious to know if any efforts are being made in this direction.

Or is the work currently mainly focused on the compiler because the internals are just not mature enough to be widely used in production yet? That seems to be the consensus I’m hearing from external people who tried it (horrendously slow compile times, heavy runtime… that’s what I hear everywhere).

What is your answer to posts like this one, for instance? Because you know that every single person who’s initially interested in GHCJS will end up reading this post, and start doubting, simply because there’s no easy to find counter opinion.

Also what about libraries? Is Reflex still considered the de-facto best standard for writing single-page applications that run in the browser (let’s say an app like Discourse for instance)? Or is there something better now? Suddenly you understand the problem of almost every single searchable resource dating back from 2016. You can’t trust anything that’s out there, because it’s all so outdated.

Could some examples of moderately successful web applications being written with GHCJS be shared somewhere? Even closed-source, at least knowing they’re there and looking at how updated they look would be enough already.

Lots of questions and this may sound like a rant, but honestly it isn’t. Take it as the expression of my strong willingness to go and try GHCJS, otherwise I wouldn’t spend any time writing this. But we just simply don’t know where to start (e.g. should we try the 8.10 branch already or should we play safe and go with 8.6, which hasn’t been updated for more than a year)? So many unknowns.

– EDIT: it looks like Miso is very up-to-date and well-documented. Still on Miso, I found this YouTube video which dates from 2020, so fairly recent. Will have a watch.

1 Like
#7

Just learned about this new framework??? from the latest Haskell Weekly: Shpadoinkle

1 Like
#8

Thanks! I didn’t notice they talked about it in the latest weekly.

#9

We are using GHCJS, but I would say that the answer to this question (Is it worth anything to start using GHCJS in 2021?) is “we shall see”.

#10

We’ve implemented some rich frontend apps for our clients recently with GHCJS and had quite a lot of positive feedback. However, it’s very underdocumented, and having a solid background in Haskell and nix is a must. Earlier, we’ve open-sourced Octopod which uses GHCJS heavily. Also, you can find some tutorials in this series of blog posts: https://blog.typeable.io/posts/2021-03-15-reflex-1.html. So, the bottom line is: GHCJS is a working tool that can be used to do very useful things, leveraging Haskell on the frontend, but it’s more than a little bit rough, so I can’t just blindly recommend it to everyone. YMMV.

6 Likes
Beginner Question: Attempting to create copy of GHC
#11

What’s the status of GHCJS in 2024?

Was the OP a bit too harsh on this project in your opinions?

BTW I’m mostly interested in using GHCJS on its own without any frameworks like reflex or miso. I just want to end up with some basic JS (written in Haskell of course) to add functionality to an existing site, without any massive frameworks. Can you recommend GHCJS for this use case in 2024?

@ketzacoatl Can you please share the size of this GHCJS project in e.g. lines of code?

@ryantrinkle Can you please chime in? Presumably you have massive apps written ultimately in GHCJS (from Reflex). Any compile time issues like that?

#13

I never used GHCJS, but I recently started working with the new Javascript backend which is now a part of GHC.

I would not invest any substantial amount of work into building new frameworks or libraries on top of GHCJS, I think its days are numbered. That doesn’t mean that you shouldn’t use the existing frameworks which use GHCJS and are used in production, they have a proven track record of being used in industry, but nobody has an interest in developing GHCJS further. The reason for this is that GHCJS was a fork of GHC, but over time they couldn’t keep up with GHC’s development.

What people are focusing on right now is the Javascript backend which has been merged into the main repository of GHC. Being a part of GHC will ensure that the development of the Javascript ecosystem cannot fall behind the development of the rest of the Haskell ecosystem. The only caveat is that if you choose to work with this new Javascript backend you are still an early adopter, and a lot of things might go less smooth initially than with GHCJS. AFAIK the Javascript backend has not yet been stress-tested in production by anyone.

3 Likes
#14

Great idea. Since for now I’m just going to make small JS programs (max 1k lines of code), I hope I can skip GHCJS entirely.

Does anyone here have a sample flake.nix which makes available both the normal GHC (that’s my current setup) and (side by side) the customized GHC with the JS backend enabled (which I’d love to add to my flake.nix)?

#15

I am not a nix user myself, but I recently tried to figure out how to get javascript-enabled binaries of GHC without compiling them myself: How can I use GHC's Javascript backend in Github CI

GHCup provides experimental cross-binaries: User Guide - GHCup but currently only for GHC 9.6, hopefully they will provide a binary for the new 9.8.2 release shortly, since only 9.8 has the GHC.JS.Foreign.Callback module in base which is quite essential. (It only contains pure Haskell code, so you could also just copy-paste it into your own project, but that is the price you pay as an early adopter :wink: )

#16

Just to clarify, the JS backend in GHC is the continuation of GHCJS. IOG has been working hard on merging GHCJS into GHC with the original authors of GHCJS. We now have two options, with the WASM backend as well, which is sponsored by Tweag! For the JS backend, 9.8 and 9.10 should bring back most of the missing optimisations that got dropped during the initial integration of GHCJS into GHC.

10 Likes
#17

Last time, I built the bindists manually. Afaik, GHC HQ doesn’t produce cross bindists.

Since I don’t get paid, I don’t know when or if I will have time for this again, but it’s in scope for GHCup to build its own bindists.

1 Like
#18

When I wrote “they” I was thinking more about the response by @hsyl20 here: How can I use GHC's Javascript backend in Github CI - #10 by hsyl20
I didn’t want to to imply that I want to burden you with any more work :heart: