JS also uses several times more memory, is slower, and has a terrible (non existing) threading model. Yes you can run multiple instance of node or whatever, but sharing objects between them requires message passing which is orders of magnitude slower.
Until JS has a good threading model I'm never using it for backend. It's too expensive to use a bunch of single core machines to make up for it.
All of our devs use Typescript and Java daily for front and backend, the only overhead is making sure objects were passing around match on both ends. The only advantage to using the same language for everything is hiring inexperienced devs that don't know both IMO
> the only overhead is making sure objects were passing around match on both ends
Seem like is it a big deal based on the first sentence.
I've never been convinced of the single language argument. Sharing code between frontend and backend sounds good but as in practice there's little overlap... models have subtle differences, there's extra logic server side... All in all it's not very practical.
To me the most awesome part of a fully TS project is that you can use the same interfaces everywhere. If you take the time to define them for any input / output, everything is pretty much guaranteed to be sound.
> the type erasure problem is far worse than Java
Check out RunTypes [1], amazing to guard any incoming data.
There is big difference between "this API can blow" and "it can blow everywhere".
Don’t Node.js worker threads solve exactly this?
Which means you are second guessing the compiler, which provided you with such great guarantees.
You should do your best to minimize this kind of code.
It completely succeeded in that!
Java (well JVM) developers today can
- Write code on any of Windows/Linux/macOS
- Deploy that code on any of Windows/Linux/macOS
Not a lot of language/platforms can claim to this amount of success, let alone with such an amazing set of tools and ecosystem.
In practice, how many developers write C# on a non Windows platform? I'd say a very, very tiny minority.
On the other hand, Java is being written on all platforms and being deployed on many as well.
Plenty do - think of deploying c# web services on Linux servers / containers.
I write C# on Linux and I am basically the only person I know who does that.
Whether that effort pays off, only time will tell.
You can also compile JavaFX apps AOT for iOS! It's called Gluon Substrate, check it out.
Java really does run on a lot of stuff, even if OpenJDK itself may not.
That's what people say, but I don't see that.
The same Java code is extremely portable, from Windows, MacOS, Linux, etc, on both the server, cli, and GUI app side.
It's just that its UI libs have historically been over-engineered shit like Swing.
But much of the original late 90s hype about Java was its cross platform nature, especially in the browser, but Java applets and other in-browser Java technologies were never popular (consider GMail and other GWT apps were written in Java but compiled down to Javascript).
Java owes 90%+ of its ubiquity and longevity to its success on the server.
Applets were very much a victim of various power struggles within the browser industry, combined with Sun's general lack of competence on the desktop - for instance, their online upgrade engines have always sucked. Though in fairness, nobody got that right until Chrome.
i wonder if it was because at the time, the different DOM api in each browser was so immature, that to unify it into a single api is too big a task. The applet+blackbox region for rendering is the easiest MVP. Of course, with hindsight, that turned out to be a piece of crap.
That crown properly belongs to the UCSD P-System, which was the Java of the 1980's. It was the same idea as Java - compilation to a bytecode which an interpreter ran. It failed because the interpreter performance penalty was too high.
Java also started out as an interpreter, which made it too slow. Steve Russell of Symantec invented a JIT for it, and like the lumbering Allison-engined P-51 getting a supercharged Merlin, it brought Java to life.
You could run p-system on a lot of machines - Apple II, IBM PC, TI-99/4A, PDP11... but how would you (and why would you) distribute your code across machines with such different storage media?
I transferred files from my PDP-11 (8" floppies) to my PC (5.25" floppies) using Kermit.
I coded in UCSD-P quite a bit (and played a few games written in it, Wizardry on the Apple 2 anyone?).
But UCSD-Pascal never reached a tiny fraction of the audience that Turbo Pascal did.
Are you talking about the host OS and the fact that Turbo Pascal was Windows only, as opposed to Pascal UCSD which was a VM?
I write a lot of JavaScript (typescript included) and I have found it to be a very nice combination of things I like from both Java/JavaScript.
Admittedly I have been primarily writing Java for the last 15 years and consider JavaScript a second language for me, you may find Kotlin gives you a good reason to come back to the JVM (where it makes sense to of course).
I do it daily during most of those 25 years, developing on Windows, deploying across multiple flavours of UNIX.
In my experience, the engineers that can do that and still produce solid code are very, very rare.
I was pretty much exclusively a Java programmer for the first decade and a half of my career, before moving to Node and TypeScript. I don't think I could ever go back at the point. Most importantly, this is my first time where the entire code base (front end and back end) is in the same language and toolchain, and I think it is the single most important thing I've seen in years for improved team productivity. The ease with which engineers can go between front end and backend is an incredible boon that shouldn't be underestimated.