5 ms·

From ES6 to Scala: Basics

71 points by manx 5y ago

danmur 5y ago
I tried scalajs for a few tiny personal projects and I really like it. For me it would have to be a very application-y product to use this over typescript but I really liked the experience.
valenterry 5y ago
ScalaJS is awesome. Really solid and mature project, can totally recommend. It's especially worth if you want to write complicated business logic and prefer to use Scala and the whole ecosystem of JVM libraries to do that. The only thing that can be annoying is when you want to have a typesafe interface and have to write a lot of adapters for javascript libraries. Fortunately there is even a project that can make use of typescript interfaces for those libraries, so that you can use them from ScalaJS more or less automatically: https://scalablytyped.org/ https://scalablytyped.org/
wiradikusuma 5y ago
How's the compilation speed for compiling Scala to JS? Eons ago I used Scala for Android development. Let say it was a traumatic experience, so now I use Scala exclusively at the server side.
- manx 5y ago
  From saving the file until the browser refreshes it usually only takes a few seconds. Especially if the compiler JVM is warm.
  - cerved 5y ago
    how does it compare with typescript?
    - nikitaga 5y ago
      Typescript's main advantage is convenience and familiarity to JS devs. With typescript you just put type hints on your good old javascript and you get to keep using all your javascript coding patterns. This comes at a cost of unsafety / unsoundness which is a tradeoff by design. Scala's type system is infinitely more robust. I use Typescript occasionally with all the strictest flags, and yet it allows invalid code that shouldn't compile, all the damn time. Such unreliable type checking is all but worthless to me personally. Scala is hands down better than Typescript for functional programming. It was actually designed for that from the start. But it's not religious about it either, its OOP features are rich and integrate with FP features very nicely. Scala.js community and ecosystem is small compared to Typescript, but very diverse and passionate. The mechanism of interfacing with JS is in principle similar to Typescript, but in practice takes a bit more setup. Also with Scala/Scala.js, you get to a whole other level of productivity when you use the same language on both the client and the server.
      - cerved 5y ago
        I meant in regards to compile times I'm intimately familiar with both languages but thanks for the run down
        nikitaga 5y ago
        Incremental compilation is pretty fast on Scala.js – it usually takes just a few seconds for me, about half of which is usually webpack bundling. Although if you make a code change that affects many modules of your app, it will take a bit more, but still very reasonable. I haven't had a chance to compare speeds apples-to-apples, but I expect Typescript incremental compilation to be faster than Scala.js. Though, to me this metric has stopped being relevant because using a type safe language I stopped looking at my changes in the browser every minute, like I used to do when I was writing frontends in Javascript. LESS/CSS compilation is the only part where I really care about speed since pixel pushing always needs trial and error, so I set it up to be separate from Scala.js compilation, and it's as fast as it would be in JS world.
throwaway4good 5y ago
Looking at the examples; I am the only one who prefers the ES6 version?
- Deukhoofd 5y ago
  Half half for me. I personally prefer the typed parameters, the if expression, and the explicit Option type of Scala, but for the class contructor and variable parameter syntax I prefer the ES6 version.
- Joeri 5y ago
  That's because you're seeing ES in Scala notation. If you see what is possible with idiomatic scala, ES has no equivalents. The match statement alone is incredibly powerful, but you wouldn't think it going by these examples.
- valenterry 5y ago
  There are a lot of them. Which one(s) are you talking about and why?
LAC-Tech 5y ago
Variables ES6 wins, 'val' and 'var' are annoying close to each other. Primitive Types Scala hands down. Not even close. Functions Scala is more expressive (well if you ignore the types). I wish more languages would do the Haskell thing and let you write the type sig at the top. Typescript functions get so long. Anonymous Functions Very similar, so calling it a tie. Default, named and rest parameters I'll give this one to ES6 because the spread syntax feels more intuitive than * at the end of a type. if, while, for, match control structures Scala, because if is an expression and the for loop syntax is so concise. Also forget how nice nested looping was. Classes Scala. It's just more concise, I always liked not having to write boilerplate constructors. Case classes I mean I guess Scala but I still prefer polymorphism to pattern matching (please don't hurt me 2022 programmers) Objects Scala is shorter and more expressive here. Traits Scala because I never liked mutating objects, though I guess that's the prototype way. Option, the type safe undefined I mean Scala because I guess it actually has it, but worth pointing out it's like 30 LOC to define one for JS, depending on how many convenience methods you want. ---- Pointless post but this has made me kind of nostalgic for Scala. Maybe I own a computer fast enough to compile it now..
- valenterry 5y ago
  > Variables > ES6 wins, 'val' and 'var' are annoying close to each other. Disagree. I don't like either Scala nor ES - but "const" is really confusing. It implies that whatever we store is constant, but it's not. I can store a mutable object and it changes whenever I want - only the reference is constant. > Default, named and rest parameters > I'll give this one to ES6 because the spread syntax feels more intuitive than * at the end of a type. Not sure. If I imagine I come from a language without such a feature, then having "..." infront of the parameter seems confusing. "...args..." would be clearer. Having "Double*" is also a bit confusing, but I find that * is often used for such a situation (e.g. in regex) > Case classes > I mean I guess Scala but I still prefer polymorphism to pattern matching (please don't hurt me 2022 programmers) Scala is really lacking a way to easily support structural typing like typescript does. ES clearly wins here, since in Scala you have to define the case class in advance. And while you can just use maps, you give up typesafety.
  - 5y ago
udbhavs 5y ago
Are there any frameworks or bindings for ScalaJS that can utilize the full expressiveness of the language and encourage idiomatic code? Because I would love to use Scala, Kotlin or even Dart compiled to JS but while it might easy to interface with JS libraries, major frameworks like React, Vue or Svelte are written with JavaScript idioms in mind and it's much harder to wrangle with those since they usually dictate the entire architecture of your project. I haven't looked into the options but I would love to see something that feels like it was meant for the language from the ground up. Eg. Blazor probably qualifies because it was written specifically for C#
- sp33der89 5y ago
  Check out: https://laminar.dev/ https://laminar.dev/ or https://github.com/PurpleKingdomGames/tyrian https://github.com/PurpleKingdomGames/tyrian Event ho it's a React wrapper it's still a really good one: https://github.com/japgolly/scalajs-react https://github.com/japgolly/scalajs-react The downside of this approach is the ecosystem isn't that big compared to JS.
- manx 5y ago
  Have a look at Outwatch (https://outwatch.github.io/docs/readme.html https://outwatch.github.io/docs/readme.html), it was designed from the ground up to be used with idiomatic scala code.
- leodriesch 5y ago
  You didn’t mention it specifically, but for ReasonML (which now appears to be called ReScript) there are official React bindings. https://rescript-lang.org/docs/react/latest/introduction https://rescript-lang.org/docs/react/latest/introduction
- AzzieElbab 5y ago
  Here is the one I have used. It is more scala centric then the rest of them https://laminar.dev/ https://laminar.dev/
- halfmatthalfcat 5y ago
  Japgolly has put a ton of time and care into https://github.com/japgolly/scalajs-react https://github.com/japgolly/scalajs-react which is a complete React binding in scalajs. This paired with something like Diode (https://github.com/suzaku-io/diode https://github.com/suzaku-io/diode) and you get a full frontend solution in scalajs.
cerved 5y ago
or C# before you may have noticed that type definitions are all over the place nitpicking but CSharp rarely requires type definition, AFAIR it's about the same as Scala
usrusr 5y ago
With posts like these pointing out syntactic similarities between 21st century languages I always get this funny idea that there might be one "true language" they all converge to. It's a silly idea, but we do see a general trend towards less imperative, more expression, across the whole board. The biggest limiter that keeps people from replacing more local scope imperativity with expression style seems to me that very practical, almost depressingly mundane topic of debuger ergonomics. Stepping through and looking at intermediates just works, and it's so easy that the mind can remain focused on the domain problem. If there was some miracle UI paradigm that provided similar ease of understanding to deeply nested expressions we'd hardly see any local vals at all. But I doubt this miracle UI will ever happen, we do know that it hasn't happened in decades of trying to make excel expressions more approachable, with presumably millions of dollar thrown at the problem.
- agumonkey 5y ago
  It's hard not to see it. 10 years ago closures were a schemer fanatic term, now it's in every tutorial. Same for destructuring .. I mean python adopted it way faster than I thought. PHP, js, python, they're all revolving around a very similar core nowadays. Same for react like frontend.. it's all "pure expression" "gui as formulas".
  - usrusr 5y ago
    "It all converges on becoming like a glorified excel sheet" I think I'm done for today with provocative statements.
    - agumonkey 5y ago
      don't forget to patent that quote, cause you'll be entirely validated for eternity
- valenterry 5y ago
  There will be the one true programm language once there is a one true natural language. :)
- 5y ago
jmaker 5y ago
Decided to join this conversation and share my very recent experience. We recently switched from Haskell to Scala for a new project due to the scope of the JVM ecosystem, in spite of having inline-java available in Haskell and GHC‘s excellent FFI. We’re a team of mathematicians and physicists working in finance (not a fintech company though). Originally we chose Haskell because it felt as the most natural fit to us to expressing our domain models and producing great EDSLs. But now it looks like we‘re going to transfer all prospective projects to Scala. It took some time to get used to it. At first the syntax felt unergonomic with Scala 2.13. Scala 3 / Dotty seems to have improved over it significantly. And the functional programming libraries come to the rescue. Scala’s standard build system, the sbt, is a boon, we got to really like it. Then the differences in the semantics occupied me for a while, but I managed to quickly get used to them. Except perhaps for the local type inference. However, with certain GHC extensions, the program becomes undecidable anyway, and we have to specify the types here and there despite the global HM style inference. Overall it still feels like I can more easily express type-level programs in Haskell rather than in Scala. GHC Haskell feels just more expressive and powerful. But this is likely to mostly be due to me having written Haskell for several years now. However, me and my folks all have become significantly more productive in Scala 2.13, and even more so with Scala 3, than we were used to with Haskell. You can do the easy things the easy way. it’s awesome that in Scala you get the benefits of both worlds, and can commit to explicitly managing effects when you’re ready, laying ground for quick prototyping and cost-efficient MVPs. You simply get the opportunity to run more experiments in your business area rather than in the programming language theory. With ScalaCheck there’s a QuickCheck for Scala, there’s also a couple more for the JVM. ScalaTest is more than good enough. MUnit is also nice. Due to the different type system, we had to extend our testing. There are also great integration and end-to-end testing frameworks for Scala and the JVM. So we’ve mostly covered our implementation risks. I’m unaware of anything for which GHC would provide stronger guarantees for our services. We run and maintain several services written and executed on another managed and unmanaged platforms. We benchmarked some of their aspects with almost identical implementations in Scala, trying to translate certain idioms to a more natural Scala style. Well, we were surprised to see how extraordinarily well our Scala services performed, we even outpaced a highly optimized Go service, but we couldn’t match a modern and optimized C++ service whose implementations only few folks in my team understand, more or less. In other words, we’re extremely satisfied with Scala 2.13 and 3.0 through 3.1. Binary compatibility is attained through cross-compilation with a couple caveats pertaining to certain old-style macros. So we’re mostly certain that we’re sticking now with Scala. For front-end development, there‘s also GHCJS which transpiles Haskell to JS and PureScript along with Elm transpilers that are great for the front end, with Elm being extremely performant but sometimes quite painful. We went with some PureScript + React and were mostly satisfied. We haven’t dealt with front ends in Scala.js yet though.

71 points by manx 5y ago

I tried scalajs for a few tiny personal projects and I really like it. For me it would have to be a very application-y product to use this over typescript but I really liked the experience.

valenterry 5y ago

ScalaJS is awesome. Really solid and mature project, can totally recommend. It's especially worth if you want to write complicated business logic and prefer to use Scala and the whole ecosystem of JVM libraries to do that. The only thing that can be annoying is when you want to have a typesafe interface and have to write a lot of adapters for javascript libraries. Fortunately there is even a project that can make use of typescript interfaces for those libraries, so that you can use them from ScalaJS more or less automatically: https://scalablytyped.org/ https://scalablytyped.org/

wiradikusuma 5y ago

How's the compilation speed for compiling Scala to JS? Eons ago I used Scala for Android development. Let say it was a traumatic experience, so now I use Scala exclusively at the server side.

manx 5y ago
From saving the file until the browser refreshes it usually only takes a few seconds. Especially if the compiler JVM is warm.
- cerved 5y ago
  how does it compare with typescript?
  - nikitaga 5y ago
    Typescript's main advantage is convenience and familiarity to JS devs. With typescript you just put type hints on your good old javascript and you get to keep using all your javascript coding patterns. This comes at a cost of unsafety / unsoundness which is a tradeoff by design. Scala's type system is infinitely more robust. I use Typescript occasionally with all the strictest flags, and yet it allows invalid code that shouldn't compile, all the damn time. Such unreliable type checking is all but worthless to me personally. Scala is hands down better than Typescript for functional programming. It was actually designed for that from the start. But it's not religious about it either, its OOP features are rich and integrate with FP features very nicely. Scala.js community and ecosystem is small compared to Typescript, but very diverse and passionate. The mechanism of interfacing with JS is in principle similar to Typescript, but in practice takes a bit more setup. Also with Scala/Scala.js, you get to a whole other level of productivity when you use the same language on both the client and the server.
    - cerved 5y ago
      I meant in regards to compile times I'm intimately familiar with both languages but thanks for the run down
      - nikitaga 5y ago
        Incremental compilation is pretty fast on Scala.js – it usually takes just a few seconds for me, about half of which is usually webpack bundling. Although if you make a code change that affects many modules of your app, it will take a bit more, but still very reasonable. I haven't had a chance to compare speeds apples-to-apples, but I expect Typescript incremental compilation to be faster than Scala.js. Though, to me this metric has stopped being relevant because using a type safe language I stopped looking at my changes in the browser every minute, like I used to do when I was writing frontends in Javascript. LESS/CSS compilation is the only part where I really care about speed since pixel pushing always needs trial and error, so I set it up to be separate from Scala.js compilation, and it's as fast as it would be in JS world.

throwaway4good 5y ago

Looking at the examples; I am the only one who prefers the ES6 version?

Deukhoofd 5y ago
Half half for me. I personally prefer the typed parameters, the if expression, and the explicit Option type of Scala, but for the class contructor and variable parameter syntax I prefer the ES6 version.
Joeri 5y ago
That's because you're seeing ES in Scala notation. If you see what is possible with idiomatic scala, ES has no equivalents. The match statement alone is incredibly powerful, but you wouldn't think it going by these examples.
valenterry 5y ago
There are a lot of them. Which one(s) are you talking about and why?

LAC-Tech 5y ago

Variables ES6 wins, 'val' and 'var' are annoying close to each other. Primitive Types Scala hands down. Not even close. Functions Scala is more expressive (well if you ignore the types). I wish more languages would do the Haskell thing and let you write the type sig at the top. Typescript functions get so long. Anonymous Functions Very similar, so calling it a tie. Default, named and rest parameters I'll give this one to ES6 because the spread syntax feels more intuitive than * at the end of a type. if, while, for, match control structures Scala, because if is an expression and the for loop syntax is so concise. Also forget how nice nested looping was. Classes Scala. It's just more concise, I always liked not having to write boilerplate constructors. Case classes I mean I guess Scala but I still prefer polymorphism to pattern matching (please don't hurt me 2022 programmers) Objects Scala is shorter and more expressive here. Traits Scala because I never liked mutating objects, though I guess that's the prototype way. Option, the type safe undefined I mean Scala because I guess it actually has it, but worth pointing out it's like 30 LOC to define one for JS, depending on how many convenience methods you want. ---- Pointless post but this has made me kind of nostalgic for Scala. Maybe I own a computer fast enough to compile it now..

valenterry 5y ago
> Variables > ES6 wins, 'val' and 'var' are annoying close to each other. Disagree. I don't like either Scala nor ES - but "const" is really confusing. It implies that whatever we store is constant, but it's not. I can store a mutable object and it changes whenever I want - only the reference is constant. > Default, named and rest parameters > I'll give this one to ES6 because the spread syntax feels more intuitive than * at the end of a type. Not sure. If I imagine I come from a language without such a feature, then having "..." infront of the parameter seems confusing. "...args..." would be clearer. Having "Double*" is also a bit confusing, but I find that * is often used for such a situation (e.g. in regex) > Case classes > I mean I guess Scala but I still prefer polymorphism to pattern matching (please don't hurt me 2022 programmers) Scala is really lacking a way to easily support structural typing like typescript does. ES clearly wins here, since in Scala you have to define the case class in advance. And while you can just use maps, you give up typesafety.
- 5y ago

udbhavs 5y ago

Are there any frameworks or bindings for ScalaJS that can utilize the full expressiveness of the language and encourage idiomatic code? Because I would love to use Scala, Kotlin or even Dart compiled to JS but while it might easy to interface with JS libraries, major frameworks like React, Vue or Svelte are written with JavaScript idioms in mind and it's much harder to wrangle with those since they usually dictate the entire architecture of your project. I haven't looked into the options but I would love to see something that feels like it was meant for the language from the ground up. Eg. Blazor probably qualifies because it was written specifically for C#

sp33der89 5y ago
Check out: https://laminar.dev/ https://laminar.dev/ or https://github.com/PurpleKingdomGames/tyrian https://github.com/PurpleKingdomGames/tyrian Event ho it's a React wrapper it's still a really good one: https://github.com/japgolly/scalajs-react https://github.com/japgolly/scalajs-react The downside of this approach is the ecosystem isn't that big compared to JS.
manx 5y ago
Have a look at Outwatch (https://outwatch.github.io/docs/readme.html https://outwatch.github.io/docs/readme.html), it was designed from the ground up to be used with idiomatic scala code.
leodriesch 5y ago
You didn’t mention it specifically, but for ReasonML (which now appears to be called ReScript) there are official React bindings. https://rescript-lang.org/docs/react/latest/introduction https://rescript-lang.org/docs/react/latest/introduction
AzzieElbab 5y ago
Here is the one I have used. It is more scala centric then the rest of them https://laminar.dev/ https://laminar.dev/
halfmatthalfcat 5y ago
Japgolly has put a ton of time and care into https://github.com/japgolly/scalajs-react https://github.com/japgolly/scalajs-react which is a complete React binding in scalajs. This paired with something like Diode (https://github.com/suzaku-io/diode https://github.com/suzaku-io/diode) and you get a full frontend solution in scalajs.

cerved 5y ago

or C# before you may have noticed that type definitions are all over the place nitpicking but CSharp rarely requires type definition, AFAIR it's about the same as Scala

usrusr 5y ago

With posts like these pointing out syntactic similarities between 21st century languages I always get this funny idea that there might be one "true language" they all converge to. It's a silly idea, but we do see a general trend towards less imperative, more expression, across the whole board. The biggest limiter that keeps people from replacing more local scope imperativity with expression style seems to me that very practical, almost depressingly mundane topic of debuger ergonomics. Stepping through and looking at intermediates just works, and it's so easy that the mind can remain focused on the domain problem. If there was some miracle UI paradigm that provided similar ease of understanding to deeply nested expressions we'd hardly see any local vals at all. But I doubt this miracle UI will ever happen, we do know that it hasn't happened in decades of trying to make excel expressions more approachable, with presumably millions of dollar thrown at the problem.

agumonkey 5y ago
It's hard not to see it. 10 years ago closures were a schemer fanatic term, now it's in every tutorial. Same for destructuring .. I mean python adopted it way faster than I thought. PHP, js, python, they're all revolving around a very similar core nowadays. Same for react like frontend.. it's all "pure expression" "gui as formulas".
- usrusr 5y ago
  "It all converges on becoming like a glorified excel sheet" I think I'm done for today with provocative statements.
  - agumonkey 5y ago
    don't forget to patent that quote, cause you'll be entirely validated for eternity
valenterry 5y ago
There will be the one true programm language once there is a one true natural language. :)
5y ago

jmaker 5y ago

Decided to join this conversation and share my very recent experience. We recently switched from Haskell to Scala for a new project due to the scope of the JVM ecosystem, in spite of having inline-java available in Haskell and GHC‘s excellent FFI. We’re a team of mathematicians and physicists working in finance (not a fintech company though). Originally we chose Haskell because it felt as the most natural fit to us to expressing our domain models and producing great EDSLs. But now it looks like we‘re going to transfer all prospective projects to Scala. It took some time to get used to it. At first the syntax felt unergonomic with Scala 2.13. Scala 3 / Dotty seems to have improved over it significantly. And the functional programming libraries come to the rescue. Scala’s standard build system, the sbt, is a boon, we got to really like it. Then the differences in the semantics occupied me for a while, but I managed to quickly get used to them. Except perhaps for the local type inference. However, with certain GHC extensions, the program becomes undecidable anyway, and we have to specify the types here and there despite the global HM style inference. Overall it still feels like I can more easily express type-level programs in Haskell rather than in Scala. GHC Haskell feels just more expressive and powerful. But this is likely to mostly be due to me having written Haskell for several years now. However, me and my folks all have become significantly more productive in Scala 2.13, and even more so with Scala 3, than we were used to with Haskell. You can do the easy things the easy way. it’s awesome that in Scala you get the benefits of both worlds, and can commit to explicitly managing effects when you’re ready, laying ground for quick prototyping and cost-efficient MVPs. You simply get the opportunity to run more experiments in your business area rather than in the programming language theory. With ScalaCheck there’s a QuickCheck for Scala, there’s also a couple more for the JVM. ScalaTest is more than good enough. MUnit is also nice. Due to the different type system, we had to extend our testing. There are also great integration and end-to-end testing frameworks for Scala and the JVM. So we’ve mostly covered our implementation risks. I’m unaware of anything for which GHC would provide stronger guarantees for our services. We run and maintain several services written and executed on another managed and unmanaged platforms. We benchmarked some of their aspects with almost identical implementations in Scala, trying to translate certain idioms to a more natural Scala style. Well, we were surprised to see how extraordinarily well our Scala services performed, we even outpaced a highly optimized Go service, but we couldn’t match a modern and optimized C++ service whose implementations only few folks in my team understand, more or less. In other words, we’re extremely satisfied with Scala 2.13 and 3.0 through 3.1. Binary compatibility is attained through cross-compilation with a couple caveats pertaining to certain old-style macros. So we’re mostly certain that we’re sticking now with Scala. For front-end development, there‘s also GHCJS which transpiles Haskell to JS and PureScript along with Elm transpilers that are great for the front end, with Elm being extremely performant but sometimes quite painful. We went with some PureScript + React and were mostly satisfied. We haven’t dealt with front ends in Scala.js yet though.