5 ms·

I really want to use PureScript, but I wonder why I should use PureScript if I already have TypeScript? Besides, as far as I know, the PureScript part is only

I really want to use PureScript, but I wonder why I should use PureScript if I already have TypeScript? Besides, as far as I know, the PureScript part is only for the business logic, not for the rendering, etc like if you want to use React or Angular or pure DOM manipulation. The backend story goes the same (i.e, PureScript only for business logic). With the extra tooling required (i.e, spago, bower) it seems pretty pointless to use PureScript these days, what am I missing? Someone please convince me to use PureScript.

mlboss 6y ago
If you considering Purescript then also look at Elm. Few plusses - It handles dom manipulation. - Simpler syntax - Elm-UI framework - No extra dependencies
- christiansakai 6y ago
  I tried Elm but it is too DSL for me. Its approach also doesn't scale. Too much writing, like Redux.
  - cies 6y ago
    > I tried Elm but it is too DSL for me. Fair. And that's what it wants/advertises to be. "Not a general prog lang". > Its approach also doesn't scale. Too much writing, like Redux. Not sure what you mean by this. Software that needs to scale do not run in browsers. Elm is just for the FE bit, the UI, the interactive browser stuff. Hence the DSL thing makes sense (to me); though I totally understand one does not like that. And when it comes to writing: it has very terse syntax. Look at all TodoMVC examples and you find that Elm will use about the least number of characters of any implementation that gives strong typing guarantees.
- mannerheim 6y ago
  As far as I've heard, it's crippleware as of v0.19
nikitaga 6y ago
You want Typescript because you want to write JS with type ascribtions that will catch some errors (but give you a false sense of security in more complex code). You also prefer to use JS idioms and using hundreds of npm packages, so you want the most frictionless integration for that. You want PureScript because you want the safety of Haskell style functional programming on the frontend, with strict types, effects tracking, category theory, and all. You want Scala.js because neither of these extremes are appealing to you. You've been burned by Typescript, you're interested in functional programming but don't want to completely give up the good parts of OOP just yet (or ever). I'm here to sell Scala.js (of course). You can use it with React or with one of Scala.js UI libraries. It's very nice.
- logicchains 6y ago
  Random interesting factoid: the guy behind Scala.js (and lots of other awesome Scala libraries) is actually the son of the prime minister of Singapore. I discovered this when talking to some Singaporeans who were quite surprised to hear the name in the context of programming language libraries. This means that if like his father and grandfather he eventually becomes prime minister, it'll be the first to-Javascript compiler maintained by a head of state.
  - nikitaga 6y ago
    I do find it interesting. I can't speak for Singapore's rules of succession, but I will nitpick however that Li Haoyi does not maintain the Scala.js compiler, that would be Sebastien and Tobias. He is nevertheless an exceptional, foundation-building creator in the Scala.js ecosystem, and has been at it from the start. https://github.com/com-lihaoyi https://github.com/com-lihaoyi https://github.com/lihaoyi?tab=repositories https://github.com/lihaoyi?tab=repositories https://www.lihaoyi.com/ https://www.lihaoyi.com/
    - logicchains 6y ago
      Thanks for clarifying! I assumed he was the maintainer because he's put a lot of effort into publicising it.
gb 6y ago
PureScript isn't just for business logic at all - it has its own UI libraries, React bindings, DOM API bindings, and so on. It is more often used for front-ends than anything else that I've seen. You only need to use one of spago or bower (spago being the recommended choice now), and that's because npm style dependencies are not suitable for PS. As for why you'd choose it over TypeScript... well, you'd do so if you want to use a functional language that doesn't allow arbitrary effects and has a sound type system.
- christiansakai 6y ago
  I haven't actually checked more on PureScript and about the UI libraries and so, I'll try to dig more.
  - nikitaga 6y ago
    Halogen is a popular one https://purescript-halogen.github.io/purescript-halogen/ https://purescript-halogen.github.io/purescript-halogen/
kqr 6y ago
Huh, I would go the other way around: If you're adding all the complexity that comes with using a language that must first be compiled to ECMAScript anyway, then why would you pick a language that's essentially ECMAScript with fancier clothes? The build chain complexity tax is already paid. Now you can go for the best language the ecosystem offers. Half-measures seem wasteful. (This was at least how I reasoned when I went for F#-to-ES.)
- dwohnitmok 6y ago
  > Half-measures seem wasteful. I would be very very cautious about this line of reasoning. It can work for certain situations, but there are enough tradeoffs and exceptions that I am hesitant to recommend this as a general rule of thumb. The ability to incrementalize risk (JS code snippets on the web just work, the compilation target is trivial to deduce, runtime characteristics do not change, no need to write wrapper code to consume npm packages, etc) instead of taking a lump sum hit to your novelty budget is valuable. Not always overwhelmingly so, but enough to give me pause.
  - kqr 6y ago
    This is a good counter-argument to my simplistic view. Thanks for bringing it up!

mlboss 6y ago

If you considering Purescript then also look at Elm. Few plusses - It handles dom manipulation. - Simpler syntax - Elm-UI framework - No extra dependencies

christiansakai 6y ago
I tried Elm but it is too DSL for me. Its approach also doesn't scale. Too much writing, like Redux.
- cies 6y ago
  > I tried Elm but it is too DSL for me. Fair. And that's what it wants/advertises to be. "Not a general prog lang". > Its approach also doesn't scale. Too much writing, like Redux. Not sure what you mean by this. Software that needs to scale do not run in browsers. Elm is just for the FE bit, the UI, the interactive browser stuff. Hence the DSL thing makes sense (to me); though I totally understand one does not like that. And when it comes to writing: it has very terse syntax. Look at all TodoMVC examples and you find that Elm will use about the least number of characters of any implementation that gives strong typing guarantees.
mannerheim 6y ago
As far as I've heard, it's crippleware as of v0.19

nikitaga 6y ago

You want Typescript because you want to write JS with type ascribtions that will catch some errors (but give you a false sense of security in more complex code). You also prefer to use JS idioms and using hundreds of npm packages, so you want the most frictionless integration for that. You want PureScript because you want the safety of Haskell style functional programming on the frontend, with strict types, effects tracking, category theory, and all. You want Scala.js because neither of these extremes are appealing to you. You've been burned by Typescript, you're interested in functional programming but don't want to completely give up the good parts of OOP just yet (or ever). I'm here to sell Scala.js (of course). You can use it with React or with one of Scala.js UI libraries. It's very nice.

logicchains 6y ago
Random interesting factoid: the guy behind Scala.js (and lots of other awesome Scala libraries) is actually the son of the prime minister of Singapore. I discovered this when talking to some Singaporeans who were quite surprised to hear the name in the context of programming language libraries. This means that if like his father and grandfather he eventually becomes prime minister, it'll be the first to-Javascript compiler maintained by a head of state.
- nikitaga 6y ago
  I do find it interesting. I can't speak for Singapore's rules of succession, but I will nitpick however that Li Haoyi does not maintain the Scala.js compiler, that would be Sebastien and Tobias. He is nevertheless an exceptional, foundation-building creator in the Scala.js ecosystem, and has been at it from the start. https://github.com/com-lihaoyi https://github.com/com-lihaoyi https://github.com/lihaoyi?tab=repositories https://github.com/lihaoyi?tab=repositories https://www.lihaoyi.com/ https://www.lihaoyi.com/
  - logicchains 6y ago
    Thanks for clarifying! I assumed he was the maintainer because he's put a lot of effort into publicising it.

gb 6y ago

PureScript isn't just for business logic at all - it has its own UI libraries, React bindings, DOM API bindings, and so on. It is more often used for front-ends than anything else that I've seen. You only need to use one of spago or bower (spago being the recommended choice now), and that's because npm style dependencies are not suitable for PS. As for why you'd choose it over TypeScript... well, you'd do so if you want to use a functional language that doesn't allow arbitrary effects and has a sound type system.

christiansakai 6y ago
I haven't actually checked more on PureScript and about the UI libraries and so, I'll try to dig more.
- nikitaga 6y ago
  Halogen is a popular one https://purescript-halogen.github.io/purescript-halogen/ https://purescript-halogen.github.io/purescript-halogen/

kqr 6y ago

Huh, I would go the other way around: If you're adding all the complexity that comes with using a language that must first be compiled to ECMAScript anyway, then why would you pick a language that's essentially ECMAScript with fancier clothes? The build chain complexity tax is already paid. Now you can go for the best language the ecosystem offers. Half-measures seem wasteful. (This was at least how I reasoned when I went for F#-to-ES.)

dwohnitmok 6y ago
> Half-measures seem wasteful. I would be very very cautious about this line of reasoning. It can work for certain situations, but there are enough tradeoffs and exceptions that I am hesitant to recommend this as a general rule of thumb. The ability to incrementalize risk (JS code snippets on the web just work, the compilation target is trivial to deduce, runtime characteristics do not change, no need to write wrapper code to consume npm packages, etc) instead of taking a lump sum hit to your novelty budget is valuable. Not always overwhelmingly so, but enough to give me pause.
- kqr 6y ago
  This is a good counter-argument to my simplistic view. Thanks for bringing it up!