Those days I have a lot of questions from clients for mobile apps and I’m building apps for myself and startup projects. After trying alternatives like TypeScript, ClojureScript or Dart, I feel like I miss PureScript very much (especially when working with Dart). I already built an internal Dashboard with Firebase connection in PureScript with React Basic Hooks and both the FFI and the package were great.
But I’m wondering about the performance for a user-facing application. Do we observe a neat performance gap between vanilla JS and PureScript? For frontend or React Native? Do people here have applications running in production and feedbacks about that? I feel like backend code it’s not a huge problem because the user is not directly interacting with it.
On another topic, did someone tried to build a startup with fullstack PureScript? I’m afraid that recruiting will be hard if/when the startup will scale. Do someone have insights about that? Do you think it’s doable or I should switch to another tech, at least for backend?
Just to give a little bit of context, I’m more a frontend person, but also worked with Haskell, Lisp, ML languages as well as Ruby, Java, JS, etc. But I’m probably a little biased without frontend and JS code in general.
This is a small anecdote, but I’ve worked at two companies with their frontend applications written largely in PureScript (the JS in both cases was / is considered legacy). I’d guess both companies, CitizenNet and Awake Security, have PureScript somewhere in the 100k+ lines of code range.
In both cases we haven’t encountered performance issues specific to PureScript; anything performance related tends to come from doing a bunch of unnecessary rendering and DOM operations — where the problem was a bad implementation, not PureScript in particular.
In fact, from speaking with other folks with PureScript in production I don’t think I’ve heard anyone ever mention a performance issue. The sort of thing PureScript might be too slow for (crunching tons of data, manipulating huge numbers of nodes in visualizations, etc) are almost always done via the FFI anyway, and are thus pretty straightforward to get around.
I only have a small slice of experience so perhaps you’ll hear another story from someone else, but I really don’t think performance is something to worry about unless you know for sure you’re going to be doing a lot of intensive computation on the frontend.
I have definitely heard of performance issues - I remember one company wanting to do webgl stuff in PureScript a few years ago and struggling with performance a bit, and I think we also see the occasional query in Slack due to being accidentally quadratic with types like Array (you do sometimes have to be a little bit more careful when you’re working with types like Array which are immutable in PureScript but don’t have ideal asymptotics for working in an immutable setting). There’s also a couple of niceties from the JS world which aren’t always the easiest to make use of in PureScript, like lazy module loading. I agree with Thomas’ viewpoint though, we also have over 100k LOC of PureScript in production at Lumi and no real performance issues which are attributable to PureScript specifically.
Yea, thanks for adding your thoughts! To clarify — I also have heard of performance issues in PureScript code and encountered them myself, but not issues that would rule PureScript itself out as a viable technology choice for a normal application. Just things that you might sometimes need to work around.
I know there are some cases where you really need the utmost performance, and PureScript may not be a good fit, but I think that for a “normal” web application frontend this isn’t a common requirement.
I must admit that I wasn’t thinking much of bundle size or niceties like lazy loading, both of which are not strong suits of PureScript. For what it’s worth, a PureScript + Halogen application bundle will come in around the same size as a React or Angular app. But you won’t get the crazy tiny bundle sizes some JS frameworks can produce.
All in all, for a typical web application PureScript is almost certainly not going to have significant or deal-breaking performance issues.
We have about 40K lines of PureScript code, but our app is not an SPA, it’s a Rails/PureScript hybrid, where PureScript mini-apps live on Rails pages.
Performance issues we noticed are of a different sort though: the most inconvenient part is compilation, and it’s especially evident when contrasted against near-instant response of purely Rails HAML views. Many modules take under a second to rebuild (via IDE integration), but many take multiple seconds, and a couple - even tens of seconds, for reasons that I don’t understand. Yes, they’re big modules, but they’re not the only ones. One day I might even look into it…
Another concern that we have is bundle sizes. The most complex ones run over a megabyte (minified, but uncompressed), and the typical size is around 300-500K. The smallest one we have is just 30K, but that one has trivial functionality. And that’s not including React, which we load separately from a CDN (so it’s cached) and then reference from global context.
Anecdotally, it looks like derived Generic instances are expensive, but I haven’t looked into where the space goes exactly.
But once loaded in the browser - yes, I agree, performance is great, no complaints there.
Generic instances are terrible in terms of both size and performance when the datatype has a large number of variants. I suggested a small improvement in this issue - https://github.com/purescript/purescript/issues/3948
