Java 9 and IntelliJ IDEA
blog.jetbrains.com
blog.jetbrains.com
I'm a full time Scala dev though, so I'm totally biased
Just finished porting a legacy 5K Coffeescript front end over to Scala.js. Having a typed front end with all the power of Scala completely transforms the browser development experience. Great stuff.
Only major drawback is generated js binaries incur a 160KB "tax", primarily due to size of Scala collections. Though, FWIW, the front end weighs in at 232KB non-gzip'd, and was able to scrap jQuery + DataTables + Modal window and Validation plugin dependencies -- shaved off about 200KB compared to previous front end.
Combine those with Babel or other ES6 transpilers, a linting and build system, and you've got yourself a pretty decent environment.
Personally I find working with JS far more fun (this phrase is used loosely) than working with Java.
Have you tried Kotlin's javascript backend?
ts2kt - https://github.com/kotlin/ts2kt
type definitions for many libraries - http://definitelytyped.org/
dynamic type - https://kotlinlang.org/docs/reference/dynamic-type.html
Generates large js binaries, poor js interop; it's well behind the curve compared to Scala.js and Clojurescript on the JVM.
Think they're putting all their developer eggs into the Native basket, which makes sense, iOS + Android would be huge for the language's adoption.
Bonus points because it will hot-reload code (figwheel) without destroying your current state. Speaking of state, you can see the entire state of your application with re-frisk, which also shows all the events going into the system. Really wonderful stuff.
Been doing imperative / oo for years so this is quite different but I’m persevering because I’ve bought into the reactive UI for web apps and JS just seemed like a total mismatch
Make sure you set your linter and typescript compile settings to be really strict. It will remind you a lot of Java/C#
So I just start my debugger, set a breakpoint, and can then poke around in the code directly, and inspect the state.
0 - http://java-performance.info/string-intern-in-java-6-7-8/
https://shipilev.net/jvm-anatomy-park/10-string-intern/
> In almost every project we were taking care of, removing String.intern() from the hotpaths, or optionally replacing it with a handrolled deduplicator, was the very profitable performance optimization. Do not use String.intern() without thinking very hard about it, okay?
So depending on your situation, you could want either, both, or neither. There is some overlap, however. If you have a lot of ascii strings but also a high level of duplication, either approach will save some memory, but if deduplication by itself saves x bytes, and compact strings saves y, using both will save a lot less than x + y bytes.
And, like the later poster says, don't use String.intern() for deduplication.
They're different fixes for the same problem: high memory usage. Depending on the situation you can use one or both, as you say.
(full disclosure: I'm author of Java 9 Modularity, O'Reilly, see https://javamodularity.com)
- OSGi: offers run-time modularization (based on classloaders), with a more dynamic model (bundles can start/stop/load/unload). Often derided for its complexity, which Jigsaw has tried to reduce (in part by offering a less dynamic model)
- Forced modularization: fortunately, Java 9 has many migration features to allow incremental modularization. Most notable are automatic modules, which allow you to treat non-modularized JARs as modules, and interoperation between automatic modules and the classpath
Hope this helps.