4 ms·

It's not any less convenient than React appears to be. Disclaimer: I've only used it for small Todo project, I'm not a front end guy. Disdisclaimer: I've not

by qop 8y ago

It's not any less convenient than React appears to be. Disclaimer: I've only used it for small Todo project, I'm not a front end guy. Disdisclaimer: I've not used React at all. However, if you need really strong JS interop, consider something like F#'s Fable. F# is gaining a lot of momentum and now that SAFE stack is apparently Microsoft-blessed, I expect it to continue growing even more.

Rapzid 8y ago
1k upvotes. I check in on Fable and F# semi frequently but SAFE has somehow slipped under my radar. I wonder if the ionide project will get some extra support.. Suave though... Nothing against Suave, but it's not the Phoenix competitor the ecosystem is in dire need of. I was under the impression some newer frameworks like Giraffe were going to fill that void..
- grayrest 8y ago
  It's in an early stage but the Saturn [1] project is aiming to compete with Phoenix more directly. The owner is a fairly prolific F# open source contributor and presented it at NYC F# last month but that's about all I know about it. [1] https://github.com/SaturnFramework/Saturn https://github.com/SaturnFramework/Saturn
  - Rapzid 8y ago
    That's fantastic! I gave F# a look right after MS announced dotnet was being open source and have been excited for it's "arrival" ever since. The pieces seem to be coming together, albeit very slowly.. * "Official" Cross platform support -> dotnet core FTW! * Cross-IDE intellisense support -> Ionide, Check! * Dotnet core support -> Check, finally(and make sure to set Ionide to use core)! * F# to javascript cross compilation project with some traction -> Fable, check(Fable needs serious documentation help though)! * A great framework competing head on with Phoenix -> Hopefully soon :) The potential just seems sooo massive. Hopefully it blows up quicker than Haskell ;)
    - sasmithjr 8y ago
      I started looking at F# because of .NET Core, and I'm really liking it. I currently use Giraffe in a project, but I'll be switching it to Saturn soon (which uses Giraffe under the hood). And I've identified a potential use case for using Fable on some already written server-side code. Ionide is great, Neptune (F# debugger for VSCode) works well, and they both are maintained by the same person as Saturn. Rider also works pretty well with F#, which is nice if you prefer the JetBrains IDEs.
- qop 8y ago
  Are you aware of https://github.com/SaturnFramework/Saturn https://github.com/SaturnFramework/Saturn ? It's what the S in safe is actually meant to be, not suave. It's very similar, in heart anyways, to phoenix. The fsharp community is fighting what is essentially an uphill battle. We have ML but we've got to jump through dotnet hoops to get shit done. One man's cruft is another man's feature. I doubt ionide will support SAFE, but maybe they will have a sister plugin? Idk how all that works.
  - Rapzid 8y ago
    I had not! Looking into it now.. Ionide could just use some extra help I mean; it appears to be the work of just one guy. Hopefully with the increased interested in F# web development it will get some extra love more ala omnisharp.
  - Rapzid 8y ago
    So, I know this is a late reply to this but.. My reaction to the announcement post was "YES!", but I see a few choices in current "Moons" that are part of the same problem the project proposes to fix. Dapper is performant and good for what it is, but entity framework is an amazing ORM IMHO. Simple.Migrations does not have a CLI or support SQL generation?... These are too low level and don't really provide that flash OOTB experience IMHO; same critique(valid) made of Suave and Giraffe. To compete with rails and phoenix in velocity and user experience those technologies are going to have to be swapped out with more feature rich and ambitious libraries..
lf-non 8y ago
I like F# and believe the author has done an amazing job evolving a functional language on the dot net platform but there are simply too many design choices in F# geared around C# compatibility and limitations of CLR being an object oriented language that when you switch to a different compilation target, these language aspects begin to look like bizarre warts. Things like limitations on statically resolved type parameters being supported only for inline functions, etc. don't make sense for a language targeting javascript. It is interesting to note that F# took a lot of concepts from OCaml but stripped out functors, structural typing support etc. to adapt to dotnet. These adaptations are largely required because Microsoft does not treat F# as a first class citizen (at the same level as C#) and CLR is very explicitly geared towards object oriented languages. An occasional endorsement from Microsoft does not magically obliviate these deeply ingrained design decisions in F#. When targeting javascript these adaptions become really pointless. As demonstrated by Microsoft's own TypeScript language, Structural typing can be quite useful for interop. It would be really nice if F# was a first class citizen in dotnet world and javascript was a first class compilation target maintained by the F# core team adapting the language to javascript target in the same way it currently adapts to dotnet. However that is not the present day reality. However typescript, despite being a javascript superset (and inheriting all its warts) has a really flexible type system and lends itself well to functional programming (as demonstrated by Giulio Canti's fp-ts [1] project). Unlike ReasonML, however, typescript's type system is not sound. I have written a more detailed comparision [2] of TS and ReasonML. I do actively use TypeScript for my day job and mostly love it, but I am much more optimistic about ReasonML once the ecosystem matures. tl;dr: The 80% best practices parity between ReasonML and modern functional javascript which the "What & Why" page of official documentation [3] talks about, does not exactly hold true for F#. So, while it is not that F# is not a great language, or that you can't build great apps with F#, however, as it currently stands, I don't see any compelling advantages of preferring F# over ReasonML, unless your backend is also F# and you want to (and can) share code between frontend and backend. My familiarity with both F# and ReasonML is quite early stage (a few weeks each) and so would welcome any corrections. --- [1] https://github.com/gcanti/fp-ts https://github.com/gcanti/fp-ts [2] https://lorefnon.tech/2018/05/13/reasonml-vs-typescript-first-impressions/ https://lorefnon.tech/2018/05/13/reasonml-vs-typescript-firs... [3] https://reasonml.github.io/docs/en/what-and-why.html https://reasonml.github.io/docs/en/what-and-why.html

by qop 8y ago

Rapzid 8y ago

1k upvotes. I check in on Fable and F# semi frequently but SAFE has somehow slipped under my radar. I wonder if the ionide project will get some extra support.. Suave though... Nothing against Suave, but it's not the Phoenix competitor the ecosystem is in dire need of. I was under the impression some newer frameworks like Giraffe were going to fill that void..

grayrest 8y ago
It's in an early stage but the Saturn [1] project is aiming to compete with Phoenix more directly. The owner is a fairly prolific F# open source contributor and presented it at NYC F# last month but that's about all I know about it. [1] https://github.com/SaturnFramework/Saturn https://github.com/SaturnFramework/Saturn
- Rapzid 8y ago
  That's fantastic! I gave F# a look right after MS announced dotnet was being open source and have been excited for it's "arrival" ever since. The pieces seem to be coming together, albeit very slowly.. * "Official" Cross platform support -> dotnet core FTW! * Cross-IDE intellisense support -> Ionide, Check! * Dotnet core support -> Check, finally(and make sure to set Ionide to use core)! * F# to javascript cross compilation project with some traction -> Fable, check(Fable needs serious documentation help though)! * A great framework competing head on with Phoenix -> Hopefully soon :) The potential just seems sooo massive. Hopefully it blows up quicker than Haskell ;)
  - sasmithjr 8y ago
    I started looking at F# because of .NET Core, and I'm really liking it. I currently use Giraffe in a project, but I'll be switching it to Saturn soon (which uses Giraffe under the hood). And I've identified a potential use case for using Fable on some already written server-side code. Ionide is great, Neptune (F# debugger for VSCode) works well, and they both are maintained by the same person as Saturn. Rider also works pretty well with F#, which is nice if you prefer the JetBrains IDEs.
qop 8y ago
Are you aware of https://github.com/SaturnFramework/Saturn https://github.com/SaturnFramework/Saturn ? It's what the S in safe is actually meant to be, not suave. It's very similar, in heart anyways, to phoenix. The fsharp community is fighting what is essentially an uphill battle. We have ML but we've got to jump through dotnet hoops to get shit done. One man's cruft is another man's feature. I doubt ionide will support SAFE, but maybe they will have a sister plugin? Idk how all that works.
- Rapzid 8y ago
  I had not! Looking into it now.. Ionide could just use some extra help I mean; it appears to be the work of just one guy. Hopefully with the increased interested in F# web development it will get some extra love more ala omnisharp.
- Rapzid 8y ago
  So, I know this is a late reply to this but.. My reaction to the announcement post was "YES!", but I see a few choices in current "Moons" that are part of the same problem the project proposes to fix. Dapper is performant and good for what it is, but entity framework is an amazing ORM IMHO. Simple.Migrations does not have a CLI or support SQL generation?... These are too low level and don't really provide that flash OOTB experience IMHO; same critique(valid) made of Suave and Giraffe. To compete with rails and phoenix in velocity and user experience those technologies are going to have to be swapped out with more feature rich and ambitious libraries..

lf-non 8y ago

I like F# and believe the author has done an amazing job evolving a functional language on the dot net platform but there are simply too many design choices in F# geared around C# compatibility and limitations of CLR being an object oriented language that when you switch to a different compilation target, these language aspects begin to look like bizarre warts. Things like limitations on statically resolved type parameters being supported only for inline functions, etc. don't make sense for a language targeting javascript. It is interesting to note that F# took a lot of concepts from OCaml but stripped out functors, structural typing support etc. to adapt to dotnet. These adaptations are largely required because Microsoft does not treat F# as a first class citizen (at the same level as C#) and CLR is very explicitly geared towards object oriented languages. An occasional endorsement from Microsoft does not magically obliviate these deeply ingrained design decisions in F#. When targeting javascript these adaptions become really pointless. As demonstrated by Microsoft's own TypeScript language, Structural typing can be quite useful for interop. It would be really nice if F# was a first class citizen in dotnet world and javascript was a first class compilation target maintained by the F# core team adapting the language to javascript target in the same way it currently adapts to dotnet. However that is not the present day reality. However typescript, despite being a javascript superset (and inheriting all its warts) has a really flexible type system and lends itself well to functional programming (as demonstrated by Giulio Canti's fp-ts [1] project). Unlike ReasonML, however, typescript's type system is not sound. I have written a more detailed comparision [2] of TS and ReasonML. I do actively use TypeScript for my day job and mostly love it, but I am much more optimistic about ReasonML once the ecosystem matures. tl;dr: The 80% best practices parity between ReasonML and modern functional javascript which the "What & Why" page of official documentation [3] talks about, does not exactly hold true for F#. So, while it is not that F# is not a great language, or that you can't build great apps with F#, however, as it currently stands, I don't see any compelling advantages of preferring F# over ReasonML, unless your backend is also F# and you want to (and can) share code between frontend and backend. My familiarity with both F# and ReasonML is quite early stage (a few weeks each) and so would welcome any corrections. --- [1] https://github.com/gcanti/fp-ts https://github.com/gcanti/fp-ts [2] https://lorefnon.tech/2018/05/13/reasonml-vs-typescript-first-impressions/ https://lorefnon.tech/2018/05/13/reasonml-vs-typescript-firs... [3] https://reasonml.github.io/docs/en/what-and-why.html https://reasonml.github.io/docs/en/what-and-why.html