Oh how I miss those code inspections and refactorings available for Java. Unfortunately I am forced to used Javascript at the moment and this language just plain sucks compared to Java, although Webstorm is trying really hard to support me. I really hope something like Java, or even better Kotlin, will replace Javascript in future for programming browser applications.
I have been learning Clojurescript with re-frame (basically react + opinions about how to write apps). This has been the most fun and logical way to write SPA's I have ever experienced.
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.
I’m learning it as well. Was pretty blown away when I created a reagent SPA app skeleton with one lein command.
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
Scala.js scratches that itch for me. I rarely write frontend code, but when I do the extra IDE support given to me by IDEA for Scala.js is pretty great.
I'm a full time Scala dev though, so I'm totally biased
It is kind of surreal to look at a source file and not immediately know if it's Scala or Scala.js (like, oh wait, this is the front end).
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.
You can get far better IDE experience if you use TypeScript, instead of plain JS. Webstorm does a lot of things that are quite popular in IDEA, because it can rely on the type system. This includes refactoring and realtime compiler errors.
I used to love Webstorm. It works great for a simple layout and the code inspections and suggestions really speed things up. But a modern setup with ES6, Vue and Webpack almost completely render the IDE unusable for me -- everything slows down to an unbearable speed and most of the inspections either don't work at all or trip over themselves. With that, I've switched to Sublime Text almost exclusively. Any pointers on how to adjust Webstorm, apart from using TypeScript?
Webpack watch mode is how I use it. On top of that you can run webpack outside of the IDE, just like you do with sublime text. My setup is i7 with 16 GB, and only electron app ( webpack + react ) will make my setup really slow. Anything else usually is swallowed by webstorm
Those things are nice, but how would I work with third party libraries like Paper.js? I feel that the difficulties would outnumber the benefits in my case.
The teams are different - the native team has a distinctly different team than the one working on JS. I'm not sure what the overlap between the JVM and JS team is though. I'd say quite simply that the JS target is just still quite young.
There are projects of differing scope like TypeScript, ClojureScript, WebAssembly (not standardized but getting there) etc that are all helping to ease our pain. Javascript isn't going away but writing in pure JavaScript is.
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.
No, because I did not exprect my project to become as big as it is now. Also, I am using a lot of third party libraries, and I am not sure if they would work seamlessly with another language that compiles to Javascript.
It's a small thing, but I think JShell might be the feature of Java 9 I'm looking forward to most. When I was developing Python, being able fire up a REPL to poke at your code while you're writing it is a nice quality of life feature.
I'm excited to try Java9. I have an app that holds alot of strings in memory. I'm curious/hoping the 'compact strings' feature makes a noticeable difference on memory usage.
They're really different issues. Deduplication reduces the memory consumption of duplicate strings. Compact strings reduce the memory consumption of ascii strings, regardless of whether they're unique or mostly duplicates.
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.
> 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?
Not really: using modules is completely optional. Small applications likely won't benefit from the structure and guarantees modules offer. Large-scale applications, however, will certainly benefit from strong encapsulation and explicit dependencies all enforced from compile-time through run-time (and adding an optional linking step for modules with jlink).
How does it relate to OSGi? Also, if just one library uses modules, does it force modularization of everything else or can these two coexist in a reliable fashion?
- 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
I wonder how many will consider switching to Kotlin instead of upgrading to Java 9. Kotlin is really just what Java should/could have been. It wouldn't surprise me if Kotlin has mostly replaced Java in 10 years.
