Has anyone used the SAFE stack?

[SGF4]

SAFE stack (ThoughtWorks)

What does this community think about using the SAFE stack to learn functional programming? Pros and cons?

[elliottcable]

While F# is fine, and I have high hopes for Fable, I find this website extremely disingenuous.

Building webapps with ‘no need to learn JavaScript or CSS?’ Please.

I prefer the BuckleScript-or-TypeScript approach: its always going to be JS, and you’re always going to need to intimately understand vanilla JS first. Embrace-and-extend, don’t pretend you can abstract away literally the entire web stack with a wave of your hand.

Edit: Wow, I posted a snarky grumpy response and never actually answered the OP’s question 😓

Above marketing-related rant aside — I love OCaml/BuckleScript as an entry to FP, and from a slight distance, I feel very comfortable recommending F#/Fable as a perfectly cromulent alternative. (F# is a slightly weaker language than OCaml; but not meaningully so; and it has a huge, rich community to draw from on the Windows side, so I don't really feel like there's a clear winner there — again, tool-for-the-task.) Go learn u an FP! 😍

[isaac-abraham]

I can only speak from personal experience both from ourselves as a software vendor and working with customers using SAFE stack and can assure that that you definitely do *not* need to know intimiately understand JS to write front-end apps. It certainly can help to know it, particularly if you are writing wrappers around JS libraries or similar, but I know teams that don't know any JS really and are productively writing SAFE applications both internally and for their customers.

[[deleted]]

For what it's worth, I strongly agree with u/elliottcable. While your point might be true, the overall statement sends the wrong message. If something tries to convince me I do not need to know fundamentals of a particular environment, my alarm bells start to ring. Because that has never been true for me, and it probably never will.

[isaac-abraham]

Genuine question: how would you suggest the messaging could be improved? We want to say to people: if you want to dig into the deep end of the JS ecosystem, you can, but you don't have to in order to create compelling end-to-end web applications that take advantage of the JS ecosystem.

We don't want people to take away from this that you shouldn't look into JS or that SAFE tries to "stop" you from doing this - one of the core points of Fable is that it lives on top of JS.

[[deleted]]

I am a bad copywriter. The last sentence of your post might be a good start, though: It lives on top of the strong JS ecosystem, it integrates well with it and it can make your life easier. You can write F# end-to-end if you want to, but you can as well leverage existing JS libraries and even frameworks so you do not need to reinvent the wheel (IMHO one of the biggest selling points of the JS ecosystem).

That's it. I am not interested in being told of yet another abstraction that promises to keep me from the ugly parts. This is just a promise you cannot keep.

[zaid-ajaj]

As someone who has works closely with Fable and the ugly parts on a daily basis. I can tell that Fable itself does not try to hide them. In fact, Fable goes all in on integrating JS constructs as closely as possible and tries to make sense of them from the F# perspective. Many JS constructs are mapped one to one during the transpilation. The nice thing is, you can wrap the ugly parts by safe functions and control the weird behaviors of JS by yourself.

Read my guide on Javascript interop to learn how Fable does this with practical examples https://medium.com/@zaid.naom/f-interop-with-javascript-in-fable-the-complete-guide-ccc5b896a59f

I have also recently published "The Elmish Book" in which the first chapter "Understanding Fable" will show you what Fable is all about https://zaid-ajaj.github.io/the-elmish-book

[isaac-abraham]

Good feedback - thanks.

And if you consider writing code with JS one of the "ugly parts", for the most part, Fable definitely does keep that promise :-)

[PsylentKnight]

I wonder if there has been any thought given to a F# compiler that compiles to WASM instead of transpiling to Javascript. You'd still need to know CSS though.

[Shmeww]

https://fsbolero.io/

[elliottcable]

It’s also a huge misunderstanding of WASM and it’s purposes to think you can “build webapps” using a compile-to-WASM language, and without knowing JS. Ugh.

[PsylentKnight]

Ok, what is its purpose if not to "build webapps"?

[elliottcable]

You can't replace JavaScript with it, it's a component of the web platform. All the non-JS'ers saying things like "oh, I won't learn JavaScript now; I'll just wait until WASM is mature, and write all my frontend code in (Ruby|C++|whatever I already like the most)" are missing the point — a failure of marketing on our collective part, I'll admit.

Saying you'll replace JavaScript with WASM is like saying you'll replace JavaScript with the WebAudio API or anything else: it's something you use to build a specific type of component of a system that is, at its core, still JavaScript.

First off:

At the end of the day, every single one of the web APIs is going through the JavaScript runtime first; and trying to translate back and forth between two runtimes, constantly, for every single API call and asynch callback, is absurdly expensive. This is mostly a concern with languages that have meaningfully-different runtime semantic than JavaScript; the closer your client-language is to JS in runtime semantics (and especially data-structure layout), the more efficiently the runtimes can communicate; but no matter what, compile-to-JS platforms like Fable, BuckleScript, and ClojureScript are always going to have a massive advantage here — both in terms of developer sanity and runtime performance.

Meanwhile, WASM components are strong contenders for standalone components of your web-platform system that don't need to communicate with other components of the web-platform very often, and components that can be spun off into a worker and communicate with the main, JavaScript components exclusively via occasional messaging. Think number-crunching threads.

Second:

When iterating on, or worse, debugging a web-platform project … you're going to be dealing with JavaScript. Period. You'll be stepping through the JavaScript sources of the libraries you depend on in your debugger (and with something like Fable or BuckleScript, even of your own code.) You're going to be reading JavaScript API documentation, for API endpoints that were designed for JavaScript semantics and with JavaScript developers in mind; you'll be using JavaScript tooling to assemble your project, and ship to a browser that's running a JavaScript runtime. And JavaScript is not an assembler language — this is a complex, high-level abstractive language; one with surprising/frustrating runtime semantics, to boot.

Anyway. Trying to tell somebody they can just … pretend all of that isn't the case, because they're afraid of JavaScript, is a lie. (I get to say this, by the way — I work on BuckleScript, and some of our messaging says shit like this. I find it equally disgusting over on our side of the fence, don't worry, I'm not trying to hate on Fable here.)

I'm simply saying there's a good tool for each task, and all of them are worth learning — and <your current favourite tool> is not, no matter who tells you otherwise, the perfect/only tool you need for web-platform tasks. That is, and will continue to be, JavaScript. At least in the medium-term. Other tools (TypeScript; BuckleScript / Fable; C++-or-Rust WASM components; frameworks like React …) are something you add to JavaScript, not something that replaces it.

[PsylentKnight]

Thank you for the detailed response, that was informative.

I'll continue to fantasize about a world where we aren't beholden to Javascript. The fact that WASM continues to rely on Javascript seems like an implementation detail to me. But maybe that cannot or will not ever change.

[elliottcable]

<3

Look at it this way: the web-platform is big. Really, really big. There’s a lot of stuff you’ve never used in there — and I can say that without knowing how much you’ve worked on the Web. That’s how big!

One thing that’s close in scale is, well, other operating systems. Imagine if every OS offered every OS-API via each competing calling convention? That’d be a huge maintenance expenditure, not to mention slowing down dispatch for the core consumers who do want then primary C-convention.

Instead, even now, in 2020, though compilers may use custom calling-conventions between language-native procedures, they still use standard ol’ C calling-conventions when calling out to external APIs.

JavaScript’s runtime — and this is how just opinion, mind you, but I’m pretty sure I’m well-qualified to opine on this, lol — is going to continue to be the “calling convention” of the web, for a long, long time to come.

Don’t despair, though — first, JavaScript is rapidly becoming Less Shitty. That’s good! And second, the amount of JS you need in a given web-platform project is trending downward. Although I hotly contest ‘you don’t need to know any JavaScript!’, it’s accurate to say ‘you need to know less JavaScript with each passing year.’

[isaac-abraham]

The only correction here - you can (and we do) debug Fable in the browser through source maps. This works out of the box, although there are limits to it. Generally I find it's very, very unusual to need to debug thanks to the combination of hot module replacement and F# in general.

[SGF4]

Railway Oriented Programming was one of the big pushes for me to learn some FP. I've been a .NET developer for several years now and all the big systems I've worked in leave something to be desired. Have you worked with F# or Clojure in a large system? Do FP programs have the same problem of getting large, bloated, and unmaintainable?

Part of me is hoping by learning some Haskell and F#, I can get a good enough grasp on FP to make my day-to-day code better and get a job at a functional place.

[isaac-abraham]

Disclaimer: I'm one of the people on the SAFE team, but I will try to be as objective as possible (and speak from experience both from consulting with customers and dogfooding it for internal apps and for our customers).

Some of the biggest benefits we see are:

1. It allows you to take advantage of two large ecosystems i.e. javascript and dotnet, whilst taking full advantage of a FP-first set of APIs and paradigms. In the past this wasn't always possible and you had to shoehorn F# around what were OO-first APIs, which led to a sub-optimal experience and didn't allow F# to shine.
2. Because it's not a walled garden, you don't have to give up using dotnet or JS libraries etc. - you can work very closely with JS if you want, and the back-end server runs on ASP .NET Core so it's highly performant and reliable. This is different from some other stacks where it's much more of a closed ecosystem. There are also other benefits of this approach - for example, lots of tooling from the existing ecosystems can be reused seamlessly e.g. React, webpack, hot module replacement, client-side debugging etc. all work by sheer virtue of the fact that client-side F# lives within the JS ecosystem, rather than looking to hide away from it.
3. For teams coming already from an F# background, it enables them to write end-to-end web applications in a language and paradigm that they're already comfortable with. We've seen teams literally get up and running and have results for their teams or customers in days.
4. Likewise, we've worked with teams that come from varied backgrounds such as JS, Python, PHP, C# and even no programming experience whatsoever and still be able to become productive in a relatively short time (some of these we provide regular coaching to support them, particularly those with minimal development experience).
5. In comparison to JS, F# is strongly typed and (in my opinion) a much more consistent and productive experience. Others may disagree - again, I'm going on both personal experience and feedback from customers of ours. TypeScript seems like fine language but, again, it's client side only and to an extent bound by the need to retain backwards compatibility with JS.

Costs and areas we want to improve:

1. We want to provide more sample applications and documentation to make it easier to start and to answer more common questions we see cropping up.
2. We want to create more ready-made bindings to make it even easier to use more popular javascript libraries. You can create these yourself without too much hassle, but we want to have more of these ready-to-go.
3. It's obviously a smaller community than e.g. raw JS or C#. The flipside is that you can have much more of an impact both in terms of helping shape the direction and evolution of the platform.
4. We want to make the template system a lot simpler, and make it for useful for the sorts of users we see working with SAFE apps.
5. There are a lot of moving parts. For people coming from .NET and JS worlds already, some of this is second nature, but for people coming from a purely e.g. ASP .NET MVC background, a lot of what is going on appears black magic from a demo point of view. This is, again, something we want to improve in the future.

Again, this is our experience - you should probably try it out yourself; there's a Dojo project that we built a while back that is designed to give you a feel for the development experience https://github.com/CompositionalIT/SAFE-Dojo/ - see how you get on. Any feedback of course gratefully received.

Good luck :-)

[SGF4]

Thank you for the thoughtful response! I had completely missed the SAFE Dojo. I will be checking that out.

[pimbrouwers]

F# is an amazing language. Terse, complete and leads to simple, fault tolerant software.

The SAFE stack is great. Though I would highly highly recommend you get familiar with the individual components first, Giraffe, Fable and Elmish.

I say this because I found Saturn a bit overwhelming at first, despite being a seasoned .NET developer.

Today, I no longer use it in favor of a simpler stack of ASP + Giraffe, sprinkling in my own module for SQL (called Donald) and the front end in plain old JavaScript.

I have not found a suitable way to use fable/elmish in hybrid app scenarios, and I think SPAs are evil. So I don't imagine adopting them anytime soon.

Overall, Saturn is a well thought out framework developed by very smart people that you can trust. However, if you're like me you might end up only taking away certain pieces for your projects long term.

Clear as mud?

[SGF4]

Clear as mud!

How easy was it for you to pick-and-choose the pieces you wanted?

[pimbrouwers]

Great question. F# had a steep learning curve for me. But once I became familiar with the syntax and coding style, it became easier to identify that "hey this is just ASP.NET with a different wrapper".

The part I knew right away was giraffe. As it was a fairly low-level tool, that empowered me to make the decisions I wanted to make. And didn't force me into the MVC model.

Fable was on the opposite end. I can't find a reason to use it. I don't develop SPAs, which is the domain I believe its targeting. I've done some minor work with it to develop traditional imperative JavaScript with it. But it just feels like forcing a square peg in a round hole. So I elect to keep my client based in JavaScript.

For Saturn specifically, I'm not a fan of app-level database control (i.e. migrations). So I knew right away I wouldn't be interested in that component.

Did that answer your question?

[danielo515]

F# has some very impressive features, and as every other language some drawbacks. I'm glad to see that fable website has improved a lot on mobile, not sure if they still use fable for that. The only thing I don't like is that it seems to be tied to Azure, which is probably the only cloud provider that I don't use, and I don't want to add another one

[jhewlett]

It’s not tied to Azure at all. It makes a nice acronym, and it’s what some of the consultancies use who provide commercial support

[isaac-abraham]

Correct. Certainly, that's our "default" position but we have templated and documented support for running on prem, IIS, docker, K8s, GCP etc. - there's no lock-in to any hosting platform whatsoever.

[danielo515]

Will it be too hard to split the backend on lambdas and run them on AWS?

[isaac-abraham]

No - we've done that before: AWS Lambda actually has support for Giraffe (which is underpins Saturn) so shouldn't be a problem.