Announcing `purescript-backend-optimizer`

If you are using halogen hooks, you will probably need to wait for an update. It is known to run afoul the “semantics” section in the readme due to how it uses unsafe effects. Without fixes it will result in all kinds of non local type errors.

I think this is expected. It’s inlining to pure data constructors, which is what you’d want for performance. One thing you could try is using —int-tags, or otherwise adding a directives file with never annotations for the things you don’t want inlined.

To be clear, this is an inliner, and so it’s job is to duplicate and evaluate code. Some things will get bigger, and some things will get smaller, which is why results highly depend on the use case.

Perhaps there’s a knob that can be added for people who don’t care about inlining and performance, and only want The ES code with smaller bundles.

1 Like

Oops! As @natefaubion said, Halogen Hooks has some code that is removed by the inliner because it has unsafe effects, which looks to the inliner like unused code.

I will release an update shortly that you can use.


Using purs-backend-es on Real World Halogen really trims the bundle, even above the significant changes brought with PureScript 0.15! Here’s how the repo has evolved since the 0.15 release earlier this year, with few internal code changes:

0.14 (purs + zephyr)          = 595.3kb 
0.15 (purs only)              = 502.9kb
0.15 (purs + purs-backend-es) = 400.3kb

If you were on the “state of the art” PureScript toolchain for 0.14 (purs + zephyr) and moved to the “state of the art” for 0.15 (purs + purs-backend-es) for this project you’d see about a 1/3 reduction in bundle size – not to mention the tremendous execution speed improvements!


I’m curious how we stack up to elm with this, both size and performance wise.

My opinion is that a language-level comparison does not exist (at least currently). It’s not obvious to me what baseline “Elm performance” is for the actual language, rather than elm-html. elm-html is fast, but elm-html is 100% JavaScript, no Elm code to be seen except bindings. Maybe you could test a UI library that is just bindings to JS? halogen-vdom is 95% PureScript, and definitely enjoys a solid speedup in script time with this backend. I think there exists a “web framework” comparison for a given set of choices (real world Halogen), but that’s a comparison of the dependency tree of halogen, halogen-hooks, routing, routing-duplex, etc. I think you will find that real world Elm is still significantly smaller on file size for those choices, but you could probably assemble a different dependency tree for PureScript that is more in line with Elm’s choices.

That’s not to say the comparison isn’t really useful for a certain audience, but just that any direct Elm vs PureScript comparison in there is only a small part of it.


Has anyone got a nix expression to build purs-backend-es for a nativeBuildInput?

There’s a purs-backend-es in easy-purescript-nix now. purs-backend-es v1.1.0 by jamesdbrock · Pull Request #214 · justinwoo/easy-purescript-nix · GitHub