I’m curious about the transition from Oak to Lamdera. How did that evolve and was there a time where Lamdera did a broad analysis of options before picking a particular implementation platform for backend?
Also, what library does Lamdera use to talk to postgres?
Hey @kanishka
I think the origins of the Lamdera journey are in that I always felt like code ideas were clear in my head, but when I went to code, it always seemed so unnecessarily complicated. At some point I honed in on searching for isomorphic solutions (i.e. same language frontend + backend). I’ve tried this in many different forms over the years, in JS, Ruby, and then finally Haskell.
Initially passed over Elm back at 0.15 because it had no backend story, but returned again after failing to get frontend Haskell working acceptably (2.5MB runtime was a no go for me) but becoming irrevocably sold on pure, type-inferred FP.
After developing an Elm frontend + Haskell backend connected by websockets with Elm types generating Haskell types (a rudimentary version of all the current Lamdera primitives) – I did my first talk about that project at Elm Europe 2017.
This is where Oak the Haskell Library emerged from, as an exploration of TEA in Haskell. This then led to the idea of transpiling Elm to Haskell, which ended up a 1.5 year endeavour with @drathier before ultimately becoming unhappy with the complexity (in particular discovering all the ways in which Elm is not a subset of Haskell) and compilation times and parting ways.
It was at this point I dropped all that work and started from scratch targeting node.js for the backend. alpha2 was the first release of that, along with the implementation of Evergreen as an answer to the migration story for a TEA app (the concept having been spoken about at Elm Europe a year and a half earlier as Evergreen Elm.
Perhaps confusingly, in 2019 Filip and I were hired by a blockchain company to develop an Elm-based smart-contracts language, which they also called Oak. That project got dropped sadly (or fortunately?) but nothing of that work is present in Lamdera, and the team was forbidden from open sourcing it.
The Lamdera JS runtime uses the node pg package, but Postgres isn’t used in the TEA runtime, only in the Msg log store layer.
NB: these kinds of questions are probably better served in the Lamdera Discord 
Nice summary, Mario!
I’ve used the new nodejs-based Lamdera in anger for quite a long time now and it’s just a joy to use these days. Well worth a try if you haven’t already!
In the summer of 2020, I tried a small experiment, transplanting my miniLaTex compiler into a simple Lamdera app. Encountered obstacle #1: using KaTeX as a custom element to render TeX style equations. Mario helped me over that one within hours. Since then, Lamdera has been my go-to framework for making apps.
There was only one paint point: migrations that affect the backend model. These could be time-consuming + hair-pulling to write, though after a while I got the hang of it and it became a routine mostly boring task. That is, a target for automation, which Mario has now done. The newest version of Lamdera provides a draft migration which generally requires light-weight human intervention to complete. These almost always take less than a minute.
The new migration work flow plus the new source map feature make Lamdera, as Filip mentions, a joy to use in all respects.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.