4 ms·

I actually proposed this route where I work. We have a decade old large and complex front end JS app, and my suggestion at improving it was to replace and rewri

by dxbydt 11y ago

I actually proposed this route where I work. We have a decade old large and complex front end JS app, and my suggestion at improving it was to replace and rewrite most of it in scalajs in a phased manner. We already have a ton of Scala engineers working on hbase, presto and Spark on the back end, so why not hire a few who can do Scala on the front end as well ? The response from the front-end guys was mostly not pretty. Over time I've come to realise the cultures are miles apart. Scala devs really value type systems and FP and all its benefits - the JS guys value very different things. The hotchpotchness of tools and frameworks in that world is actually seen as a plus point, as diverse devs collaborating, as some community thing. I will never understand it.

weego 11y ago
My feeling from a business point of view is: with Scala devs being a) relatively scarce in the market and b) the salary attached to a Scala dev, why would I spend their time getting them to write that's going to end up being JS when a highly skilled JS dev can be found easier and costs less (if you have both already then the relative opportunity cost difference). Add time for compiling, edge cases, bugs and no matter how awesome it is, I can't see how it ever makes sense outside of a 1 person project.
- djtriptych 11y ago
  Because scala code done well eliminates huge swathes of bug classes that are common in javascript. It may be worth it for "mission-critical" UI, or to rewrite lower-level UI code in stronger semantics.
- lomnakkus 11y ago
  When the compiler eliminates huge classes[1] of bugs you can afford to hire fewer devs and not suffer any loss in quality. Salaries are a huge part of why software development costs as much as it does. [1] Yes, classes. As in: You can never misspell an object property and have that mistake make it into production (&c for lots of other types of bugs). Plus, you get automatic refactoring you can actually rely on. Now, your JS devs may not appreciate that, but I suspect that's just because they're inexperienced and/or haven't actually worked in a good[2] statically typed language. There's also the fact that we (as humans) unconsciously try to minimize our own mistakes; "oh well, it was just a typo and we fixed it quickly!" and for most of us mistakes tend to fade quickly from memory... thus leading to a very biased view of one's own development practices which doesn't take into account how many mistakes you really make. [2] I'm going to do a D. F. Wallace here[3]. [3] ... and say that Scala isn't great as languages go[5], but I'll bet you it's a hell of a lot better than any statically typed language your typical JS devs have any experience with[4]. One particular gripe of mine is that they still permit "null", but that's because of Java compatibility. (Oh, how much better Scala could have been without Java compatibility.) [4] ... which would obviously colour their perception of the trade-offs between static type checking and "verbosity", "bondage & discipline", etc. [5] It is good, though. I think that's enough footnotes for now. EDIT: Sorry, I lied. Added another footnote. Really doing the DFW thing, but in Reel Time(TM).
  - nawitus 11y ago
    If static typing is the selling point of Scala.js you might as well use TypeScript, which would be familiar to JavaScript developers.
    - lomnakkus 11y ago
      No. Static typing in TS is very very far from what Scala can do[1]. Just as an example: Scala can do type inference (albeit local) which TS cannot do in any meaningful sense. There's a huge difference and you owe it to yourself to try it out for a real project! [1] My company started out with TS, but after converting about 10% of our app from TS to Scala.JS + scala.js-react we just decided to convert the rest in a mad sprint over a few weeks. It has paid off in spades. We still struggle with the abomination that is CSS and separating styles from components, but it is what it is.
      - nawitus 11y ago
        You're incorrect. TypeScript can do a lot of type inference. I've used TypeScript full-time for about two years, I don't have experience with Scala.js though.
        airless_bar 11y ago
        I think most types for which you would care about type inference in Scala can't even be expressed in Typescript ...
        lomnakkus 11y ago
        Yeah. HKTs are one particular instance, though even Scala doesn't necessarily do particularly well on those compared to e.g. Haskell (well, GHC, really). (It seems subtyping and higher-order reasoning just don't mix well. Undecidability abounds, unfortunately. I tend to prefer higher-order reasoning over subtyping.)
- jtwebman 11y ago
  This is only true because after a few years the front-end guys want and probably get to re-write their code for some new design or the latest fizz-bang framework. So they don't have to refactor / maintain 5+ year old code. I would look at Elm as if it compiles you will not get a runtime error but Elm devs probably are even more scarce then Scala devs.
spriggan3 11y ago
The problem is how easy (or not) it is to interface scala.js with third party libraries not written in scala. js. I doubt scala has the same semantics as Javascript. If the semantics are too different it's not going to work unless you expect your engineers to write everything from scratch. Also there is a the speed factor. Is compiling to JS fast ? what kind of code does it produces ? how big ? is it easy to take a library written in Scala.js then interface it with plain old Javascript ? ect ... It's definitly not a culture problem, I believe using Scala.js or Gopher.js or Opal(Ruby) or any language which semantics are too different from Javascript is just not pragmatic.
- sjrd 11y ago
  I wonder how much of your comment follows from past experiences with other compile-to-JS languages. Scala.js solved all the problems you mention. * Performance is on par with hand-written JavaScript. * The compiler and optimizer are incremental so they compile your code in 1-2 seconds for significant codebases. * Interoperability is as easy as in TypeScript: just use type definitions for external JS libraries and then transparently call them. It's all explained from the big boxes on the page of https://www.scala-js.org/ https://www.scala-js.org/ Don't let your past experiences give you wrong impression of Scala.js.

by dxbydt 11y ago

weego 11y ago

My feeling from a business point of view is: with Scala devs being a) relatively scarce in the market and b) the salary attached to a Scala dev, why would I spend their time getting them to write that's going to end up being JS when a highly skilled JS dev can be found easier and costs less (if you have both already then the relative opportunity cost difference). Add time for compiling, edge cases, bugs and no matter how awesome it is, I can't see how it ever makes sense outside of a 1 person project.

djtriptych 11y ago
Because scala code done well eliminates huge swathes of bug classes that are common in javascript. It may be worth it for "mission-critical" UI, or to rewrite lower-level UI code in stronger semantics.
lomnakkus 11y ago
When the compiler eliminates huge classes[1] of bugs you can afford to hire fewer devs and not suffer any loss in quality. Salaries are a huge part of why software development costs as much as it does. [1] Yes, classes. As in: You can never misspell an object property and have that mistake make it into production (&c for lots of other types of bugs). Plus, you get automatic refactoring you can actually rely on. Now, your JS devs may not appreciate that, but I suspect that's just because they're inexperienced and/or haven't actually worked in a good[2] statically typed language. There's also the fact that we (as humans) unconsciously try to minimize our own mistakes; "oh well, it was just a typo and we fixed it quickly!" and for most of us mistakes tend to fade quickly from memory... thus leading to a very biased view of one's own development practices which doesn't take into account how many mistakes you really make. [2] I'm going to do a D. F. Wallace here[3]. [3] ... and say that Scala isn't great as languages go[5], but I'll bet you it's a hell of a lot better than any statically typed language your typical JS devs have any experience with[4]. One particular gripe of mine is that they still permit "null", but that's because of Java compatibility. (Oh, how much better Scala could have been without Java compatibility.) [4] ... which would obviously colour their perception of the trade-offs between static type checking and "verbosity", "bondage & discipline", etc. [5] It is good, though. I think that's enough footnotes for now. EDIT: Sorry, I lied. Added another footnote. Really doing the DFW thing, but in Reel Time(TM).
- nawitus 11y ago
  If static typing is the selling point of Scala.js you might as well use TypeScript, which would be familiar to JavaScript developers.
  - lomnakkus 11y ago
    No. Static typing in TS is very very far from what Scala can do[1]. Just as an example: Scala can do type inference (albeit local) which TS cannot do in any meaningful sense. There's a huge difference and you owe it to yourself to try it out for a real project! [1] My company started out with TS, but after converting about 10% of our app from TS to Scala.JS + scala.js-react we just decided to convert the rest in a mad sprint over a few weeks. It has paid off in spades. We still struggle with the abomination that is CSS and separating styles from components, but it is what it is.
    - nawitus 11y ago
      You're incorrect. TypeScript can do a lot of type inference. I've used TypeScript full-time for about two years, I don't have experience with Scala.js though.
      - airless_bar 11y ago
        I think most types for which you would care about type inference in Scala can't even be expressed in Typescript ...
        lomnakkus 11y ago
        Yeah. HKTs are one particular instance, though even Scala doesn't necessarily do particularly well on those compared to e.g. Haskell (well, GHC, really). (It seems subtyping and higher-order reasoning just don't mix well. Undecidability abounds, unfortunately. I tend to prefer higher-order reasoning over subtyping.)
jtwebman 11y ago
This is only true because after a few years the front-end guys want and probably get to re-write their code for some new design or the latest fizz-bang framework. So they don't have to refactor / maintain 5+ year old code. I would look at Elm as if it compiles you will not get a runtime error but Elm devs probably are even more scarce then Scala devs.

spriggan3 11y ago

The problem is how easy (or not) it is to interface scala.js with third party libraries not written in scala. js. I doubt scala has the same semantics as Javascript. If the semantics are too different it's not going to work unless you expect your engineers to write everything from scratch. Also there is a the speed factor. Is compiling to JS fast ? what kind of code does it produces ? how big ? is it easy to take a library written in Scala.js then interface it with plain old Javascript ? ect ... It's definitly not a culture problem, I believe using Scala.js or Gopher.js or Opal(Ruby) or any language which semantics are too different from Javascript is just not pragmatic.

sjrd 11y ago
I wonder how much of your comment follows from past experiences with other compile-to-JS languages. Scala.js solved all the problems you mention. * Performance is on par with hand-written JavaScript. * The compiler and optimizer are incremental so they compile your code in 1-2 seconds for significant codebases. * Interoperability is as easy as in TypeScript: just use type definitions for external JS libraries and then transparently call them. It's all explained from the big boxes on the page of https://www.scala-js.org/ https://www.scala-js.org/ Don't let your past experiences give you wrong impression of Scala.js.