6 ms·
Hm. Have you taken the time to learn all the new features and develop something with them? Most people who work with JavaScript these days seem to like it quite
by cjmoran 8y ago
Hm. Have you taken the time to learn all the new features and develop something with them? Most people who work with JavaScript these days seem to like it quite a lot, myself included. Since ES6 released it's become a solid language with a few strange quirks, whereas it used to be a crappy language with a few useful features.
- linkmotif 8y agoES6 is really nice but it’s still JavaScript so it’s untyped and therefore much less pleasant to work with at any kind of scale than, say, Java+IntelliJ which is like butter. Not sure which static typed languages will be WebAssembly-able, though? Go? Rust?
- noelwelsh 8y agoRust already compiles to WebAssembly: https://github.com/rust-lang-nursery/rust-wasm https://github.com/rust-lang-nursery/rust-wasm WebAssembly doesn't yet have garbage collection so Rust is currently the best choice targeting it, IMO.
- joepie91_ 8y agoJS isn't "untyped", it's dynamically typed. And this is absolutely not a problem at scale if your development practices are up to scratch - or at least, not a bigger problem than the myriad of other design tradeoffs that every major language has to deal with. Static typing is massively overvalued. It has non-zero value, but it's a tradeoff with other things, and the amount of importance that people tend to place on it is absolutely out of proportion with the actual value it provides. EDIT: This extends beyond just 'static typing', as well. The design of programming languages is an exercise in tradeoffs, and people rarely take the time to understand the tradeoffs introduced by their pet language feature, instead presenting it as some inherently ideal thing where any language that doesn't have it must therefore be bad.
- ape4 8y agoIts ugly but for global js variables I use Hungarian notation - eg `var gstrHomeUrl`.
- joepie91_ 8y agoYou really shouldn't have global variables in the first place, and this misses the point entirely; the type of something isn't what's important, the semantic meaning of it is. The type can be mentally inferred from that. Hungarian notation 'solves' a problem here that doesn't exist in the first place.
- Clubber 8y agoIt's not scaling issue, it's a refactoring / maintenance issue. Weakly typed languages cost much more to maintain because you can't have good refactoring tools. In a strongly typed language, if I want to rename a parameter that is used in 20 places, I can hit "Rename," rename it, and it will rename all 20 instances with perfect precision, and that's it. With weakly typed languages, you have to search and replace, which is much more prone to error. This is much more of an issue for JS applications that are much larger than just doing some stuff on a page. I agree, it's a tradeoff. Many languages these days can do both. The best is strongly typed until you are dealing with JSON or something of that nature.
- joepie91_ 8y agoThere is absolutely no reason why this wouldn't be possible in a dynamically typed language. I'm in the process of building such a tool for JS, in fact. You don't need static typing to do codebase-wide renaming, it just makes it a little easier to build the refactoring tools, but since that is a one-time cost it's not really a particularly important factor in the language design. Other language design decisions have much more influence on this development cost, too, such as reassignability and scoping rules. "Strong typing" is also something totally different from "static typing" - I'm not sure why you're bringing it up here. The two are not interchangeable terms. EDIT: Actually, doesn't Webstorm already do such mass-renaming for JS? EDIT 2: I also object to the use of the word 'refactoring' to refer exclusively to renaming variables. Proper refactoring involves much more work, most of which isn't automatable regardless of the language you're using.
- gaius 8y agoTry Groovy. All the verbosity of Java and all the type safety of JavaScript.
- vorg 8y agoApache Groovy's original use case was for scripting classes already written in Java, for stuff like testing and glue code. It added closures to Beanshell, which was the de facto language for scripting Java at the time. New leadership, er, took over in late 2005 and re-oriented it as a DSL for Grails, and later Gradle. Grails has since died, with virtually no-one upgrading to version 3, or starting new projects in it. The Grails 2 plugin scene is dead. Many sites are converting their Gradle build scripts to Basel, so it's also starting a slow decline. Around 2012, Groovy was repurposed again with static typing to compete with Java and Scala on Android. But it never succeeded, and the leadership was retrenched 3 yrs ago from VMWare and couldn't find anyone else to financially support them. Groovy remains OK for scripting Java classes, but it's fast becoming irrelevant now that Java itself has lambdas and type inference.
- gaius 8y agoAs Scala and Clojure both have REPLs and now Java too[1] Groovy is totally irrelevant, but it still clings on in a few places. [1] https://blogs.oracle.com/java/jshell-and-repl-in-java-9 https://blogs.oracle.com/java/jshell-and-repl-in-java-9
- linkmotif 8y agoYeah with lambdas and local type inference in Java it’s less and less relevant but it’s still dynamic and that can be great for tests and little scripts with Grape. I really enjoy Grape despite using it so rarely that I always need to look up how to do things.
- linkmotif 8y agoI find Spock to be highly enjoyable. It warms my heart.
- 8y ago