Is it worth anything to start using GHCJS in 2021?

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…

4 Likes

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.

3 Likes

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.
4 Likes

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/

4 Likes

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.

12 Likes

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

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

1 Like

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

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”.