3 ms·

I looked at Fable and the resulting code just looked way more complicated than anything Javascript could write. I'm interested in F# still on the backend, but I

I looked at Fable and the resulting code just looked way more complicated than anything Javascript could write. I'm interested in F# still on the backend, but I don't think people "haven't discovered" Fable, it's just not a great alternative.

obeavs 3y ago
Yeah, I suppose it depends on what you're building. Three years of building with it (plus constant re-evaluation of that decision) has supports our conclusion that it is far more concise and easier to manage (esp for less technical folks who need to sign off on the business logic/domain) than anything we'd have done in JS. With that said, we're building a product that requires much more interactivity than most, and we're performing a lot of typical "back-end" logic in the client - that might color our evaluation. To be sure, it hasn't been without tradeoffs, but we haven't found those tradeoffs to be at the language level.
durable_queue 3y ago
The generated JS is only somewhat readable, but you're not supposed to be reading the F#.
- Capricorn2481 3y ago
  I'm not supposed to read the F#?? Someone should tell the Fable guys
catlover76 3y ago
Is it really appreciably different from "transpilation" with TypeScript? Like, I have seen a little of both (I've used a lot of TypeScript, but who actually looks at the output JS lol), and while I agree the JS output from Fable seemed surprisingly verbose, I'm not sure I see how it practically matters unless one is worried about bundle size or something.
- Capricorn2481 3y ago
  I'm not talking about that JS output, I mean the F# itself. While I'm not the most familiar with F#, I've enjoyed other languages that transpile to JS a lot more. For whatever reason, F# to me looks surprisingly verbose in Fable, which is odd because it's pretty terse on the backend.
  - catlover76 3y ago
    Oh, I see. You said "resulting code", that's why I thought otherwise.
    - Capricorn2481 3y ago
      My mistake!
phillipcarter 3y ago
FWIW the benefit tends to come in the long run. Same argument as TypeScript, really. You add some conceptual overhead to get code that fails less in the face of change, better refactoring, etc.

obeavs 3y ago

Yeah, I suppose it depends on what you're building. Three years of building with it (plus constant re-evaluation of that decision) has supports our conclusion that it is far more concise and easier to manage (esp for less technical folks who need to sign off on the business logic/domain) than anything we'd have done in JS. With that said, we're building a product that requires much more interactivity than most, and we're performing a lot of typical "back-end" logic in the client - that might color our evaluation. To be sure, it hasn't been without tradeoffs, but we haven't found those tradeoffs to be at the language level.

durable_queue 3y ago

The generated JS is only somewhat readable, but you're not supposed to be reading the F#.

Capricorn2481 3y ago
I'm not supposed to read the F#?? Someone should tell the Fable guys

catlover76 3y ago

Is it really appreciably different from "transpilation" with TypeScript? Like, I have seen a little of both (I've used a lot of TypeScript, but who actually looks at the output JS lol), and while I agree the JS output from Fable seemed surprisingly verbose, I'm not sure I see how it practically matters unless one is worried about bundle size or something.

Capricorn2481 3y ago
I'm not talking about that JS output, I mean the F# itself. While I'm not the most familiar with F#, I've enjoyed other languages that transpile to JS a lot more. For whatever reason, F# to me looks surprisingly verbose in Fable, which is odd because it's pretty terse on the backend.
- catlover76 3y ago
  Oh, I see. You said "resulting code", that's why I thought otherwise.
  - Capricorn2481 3y ago
    My mistake!

phillipcarter 3y ago

FWIW the benefit tends to come in the long run. Same argument as TypeScript, really. You add some conceptual overhead to get code that fails less in the face of change, better refactoring, etc.