Ask HN: Have you worked on F# web apps in production?
9 comments
I have multiple Fable apps in production - one of which for 2+ years. They are among the most stable apps I have published, and they are a real joy to maintain.
I too had initial concerns about adding Fable as a dependency, but it has been rock solid and has proven to be a great decision. The safety and clarity it provides by allowing you to use F# type system is a vast improvement over JS.
Many of the React libraries that I use already have bindings, and of the ones that didn't, I can usually create my own minimal bindings within a few hours. The community is also very helpful in this regard and are generally eager to assist.
With that said, if you want to go hog wild with incorporating every new React library out there, then this could start to feel like a hinderance if a library doesn't already have bindings. But for me, the advantages of being able to use F# on the front and back end outweigh the inconvenience of occasionally having to create my own bindings. Plus it's fun (IMO) to contribute bindings back for the rest of the community to use.
It may also be worth noting that I look forward to waking up in the morning when working on an F# project!
I too had initial concerns about adding Fable as a dependency, but it has been rock solid and has proven to be a great decision. The safety and clarity it provides by allowing you to use F# type system is a vast improvement over JS.
Many of the React libraries that I use already have bindings, and of the ones that didn't, I can usually create my own minimal bindings within a few hours. The community is also very helpful in this regard and are generally eager to assist.
With that said, if you want to go hog wild with incorporating every new React library out there, then this could start to feel like a hinderance if a library doesn't already have bindings. But for me, the advantages of being able to use F# on the front and back end outweigh the inconvenience of occasionally having to create my own bindings. Plus it's fun (IMO) to contribute bindings back for the rest of the community to use.
It may also be worth noting that I look forward to waking up in the morning when working on an F# project!
I've been using F#, Giraffe, Fable.React/Feliz, and Fable.Remoting in production for the past four years. Fable enabled us to grow and maintain a stable team of people that work both server- and client-side. You can join our team without any prior javascript experience and we'll have you productive in days.
It does not and cannot take away the complexity of writing an SPA in React. If you want to write a high quality SPA in React using Fable, you'll still need React, webpack, ... expertise in the team.
I know that in theory we all write perfect apps and have test suites with 100% coverage that do not hinder us as we change the codebase. Reality is much different though. You are behind on a deadline, your spouse and kids are home with COVID, and the junior has made 20 changes that should've been in prod last week but aren't because you haven't had the chance to review them. This is where F# shines. Merge the shit code to prod (after maybe some manual testing :P). You will be able to refactor it later with relatively high confidence.
The interest on technical debt in F# is so much lower compared to any other language I've used in prod (C#, Typescript, Javascript, and PHP).
It does not and cannot take away the complexity of writing an SPA in React. If you want to write a high quality SPA in React using Fable, you'll still need React, webpack, ... expertise in the team.
I know that in theory we all write perfect apps and have test suites with 100% coverage that do not hinder us as we change the codebase. Reality is much different though. You are behind on a deadline, your spouse and kids are home with COVID, and the junior has made 20 changes that should've been in prod last week but aren't because you haven't had the chance to review them. This is where F# shines. Merge the shit code to prod (after maybe some manual testing :P). You will be able to refactor it later with relatively high confidence.
The interest on technical debt in F# is so much lower compared to any other language I've used in prod (C#, Typescript, Javascript, and PHP).
Why depend on Fable? If something goes wrong, you need to hunt some bug in horrible javascript code. I would still use F# but not Fable.
For the same reason that people depend on TypeScript.
The JS output created by Fable is fine to read, and I very rarely, if ever, need to look at it.
Note I advocated to use F# but not Fable. You're assuming in your answer that you need to interoperate with JS, why?
Because JS is pervasive.
What are you thinking of when you say "something goes wrong"?
When you use better tooling like vite/snowpack the code produced by fable is served as is, and it's really close to the F# sources, the webpack bundle used in development is what looks horrible in reality
My point was not comparing Fable vs plain JavaScript, but F# vs Fable.
F# seems great and well supported given that it's a fully supported .Net language. But on the Fable side you have to rely on the Fable project and on React. I think both of these projects are solid but there is always a cost to bringing in dependencies.
Is this something you have worked with? Are there any recommendations you'd make to someone investigating these technologies?