What if JavaScript wins?
medium.com
medium.com
WASM isn't a panacea. Much like Flash, Java Applets, and ActiveX it is just the newest in a long line of Magic Blobs™ that supposedly solve all of our problems. Sooner or later it will become so complex that even the prospect of manually reviewing WASM will be seen as more unrealistic than a simple re-write based on input/output conditions.
You should not write code in WASM.
You should not review WASM.
In the same way that most Java developers don't have a clue how bytecode works in the JVM.
I wouldn't call myself a Java dev - I mean I know Java like 99% percent of the world does - so I may have a terrible perspective on this anyways. Although knowing the basics of how Java source code -> running process would certainly help any Java dev.
Outside of needing some extreme performance optimization, most web developers should never need to read or write WASM code.
Like the VM in the Flash runtime that runs ActionScript bytecode. Part of the GP's point still stands regarding MagicBlob™s. That said, it does differ (massively) in that it doesn't cast the spell of being a closed proprietary format: primarily driven by motivations of it's owner rather than the benefit of it's community.
You're right that today it could be difficult to debug things that are compiled down to WASM as initially it was difficult to debug C code compiled to traditional assembly. The next step, though, was debuggers. These will come, and the issue will become moot.
tl;dr: The tooling will follow.
In response to "But JS can be obfuscated/minified" - Minified JS is still much easier to examine/modify than WASM, and it's really rare for a site to deliberately obfuscate their JS beyond minification.
Not to mention the web stack changes every single year completely, node has scalability and versioning issues, and you end up relying on quickly changing pieces of code you have zero control about.
I wrote code in way better and more productive languages than JavaScript. I can somehow tolerate JavaScript when I write code alone, but once I have to deal with the fart-mess that most JavaScript developers write, I have to eject. There are very few JavaScript projects that are well designed and I always need to debug and fix them as I put most of them into their knees when they aren't working anymore. You have no idea how far "the best JavaScript" libraries are quality-wise from what you'd expect from a well-designed C++, Java or Scala library.
In my defence:
I haven't worked on webGL or facial/emotion tracking system with CV in a browser yet. My experience has been more towards apps that tend to be very heavy in functionality, and are written with a specific personas of users in mind.
I have been using JS in a functional manner for quite a few years. And I have found that JS works best when you don't have to deal in classes when writing domain-specific code. Using "functions-as-first-class-citizens" is what I have found works in scalable way. And I generally get any new junior dev up to speed on basics of functional programming before working with them.
(By the way, have you seen https://js.tensorflow.org/)
EDIT: By the way, I mentioned tensofrlow.js because with it, if you have a dataset, you can prototype the emotional recognition thing in a week or two. Just don't have the need/time to spend that effort at the moment. Needed to share that information in order to see if i'm correctly gauging the complexity of the type of work you mentioned.
Right, with TensorFlow.js (or even better Keras.js) you can write a simple CNN in a few hours that given a good dataset of facial keypoints can allow you to build a fairly accurate (80-90%) emotion detection framework, and it's pretty fast. I am past this stage though; right now I have e.g. a working state-of-art model for detecting offensive visual content on the web based on very deep DenseNet, which might be difficult to fit into a browser implementation and the more Titan Vs you throw at it, the better; Python only then.
I agree, with functional approach, especially with the recent additions to ES, it seems like JS is becoming a quite OK language, though the issue of having somebody using ugly old hacks is not going away, unfortunately.
Usually in teams I worked before for anything more complex we used transpilers from one language to JavaScript and relied heavily on our IDEs to allow us debugging. Kotlin seems to be pretty popular in that space right now; if I haven't had some personal gripe with its authors I'd have probably used it as well ;-)
Good luck with your company, keep your eyes open for things to come! :)
And by the way, using python for training is a must right now(though JS is going to become an alternate for this in a few months, as tensorflow.js is being ported to node with bindings to actual tensorflow's C++ layer). Using tensorflow.js, I'd have been able to use saved models in the browser.
2. What sort of scalability issues related to Node.js are you talking about? Isn't node.js (thanks to V8, and async IO) much more performance friendly than other scripting langs?
3. Regarding web-stack changing quickly, this hasn't effected me on server side yet. It has effected me on the mobile apps and web app side of things where I am using react 15.x, but it'll make sense to tackle that after raising meeting the next few business milestones.
Packages and imports. First-class entities, built in to every other modern language. A mishmash of different "standards" and proprietary implementations in Javascript. Even K&R-era C had a better solution than Javascript (until ES6, anyway).
And do not tell me that ECMAScript 6 fixes this -- as long as there are multiple implementations in use in legacy code (there are) JS will have to live with a rat's nest of horrors at this incredibly fundamental level (not to mention the fact that ES6 imports aren't yet universally supported!)
However, from a purely pragmatic point of view, not a deal breaker for early stage companies.
2. Compare some well-designed async framework on JVM like Netty (used by most game studios for their high-throughput servers) with node.js. See the benchmarks. Still wanna use node.js? Do you think you can cost-compete with any company that needs 4x less servers than you do for the same functionality? Show me something close to zeromq capable of reaching over 1M messages/s on a single computer?
3. No comment. Plenty of posts about it over here every year
Which has led to a meta advantage which is it being used everywhere.
So while Esperanto speakers bemoan this, the rest of the world doesnt care too much.
The rest is disagremeent or agreement on the quote “If it’s stupid and works, it’s not stupid”
As someone who's proficient in multiple languages, I've never had issues switching between 2 languages. Am I missing something?
Is that worth anything? I dunno. But I can see a certain appeal to that line of thought. Similar to why a startup might do their mobile app in react native. "We have react devs, this way any of them could work on it."
But on the topic of switching your brain, you have to know that not all developers can switch between languages as easily, they aren't all special geniuses like you.
(This is also part of the "JS wins" story since two out of those three are ClojureScript, using JS as a compile target)
Most programming problems people have are highly generic, often looking to implement something completely off the shelf as far as problems go. Wheels can only be reinvented so many times in so many ways.
To me the JS ecosystem offers a level of high level programming that you just don't get in other languages. Nothing comes close. There is a package for every possible problem you have just waiting to be used. You wan't some complicated auth feature? Consider it done with one require statement and calling a function to set a configuration. You want some reusable components for your frontend to solve some complicated issue? Somebody has a crazy React package doing exactly what you need. Obviously there are security concerns with this but that is a totally separate topic.
In the future programmers won't be replaced by robots, they will be replaced by import statements.
I disagree. How is this different from someone 20 years ago saying programmers will be replaced by jar files.
Since the deploy tools are rewritten or replaced every couple months somebody has to maintain the build process.
There is serious work being undergone in automating this using advanced ML. In 5-10 years most of these problems will be LEGO-ized and humans won't be needed on that level. So your generic JavaScript developer used to glue these pieces will be gone.
Remember, we are automating systems and technology to advance our species when facing tougher problems. The rise of AI and machine learning came out of the necessity of faster computers and a bigger connected community of humans and devices. Turnaround time for features and business value also is driving this innovation.
As systems get more complicated, the roles of developers will change, not be obsolete. For a developer to cease to exist, humanity itself would have to change. When you imply technology being created and managed its own, the implications to society are huge. I might even argue that the species survival would even be at risk here.
I think in the foreseeable future, developers would interface with ever more smart and complete features.
Most people don't need an app. Generally, businesses with intent on making profit need an app. Even then, the app is usually just an interface to the real beast driving business value hidden behind a DMZ in the cloud. Even if an application becomes autogenerated, a developer will have more time to focus on the rest of the flow that delivers value.
My point is that as engineers, we build systems using ever improving tools. I don't think we should fear AI and Machine learning, but embrace it and work at higher abstractions to solve even better problems.
I would say a javascript developer might become obsolete, just as a flash developer did. But an engineer focusing on end to end systems who uses javascript won't.
The JS module ecosystem is far ahead of most other languages for web stuff. Most of the time the modules are perfectly sufficient, and if not, patching them is also easy.
Sure there's a lot of glue code required, but that is a reality in every language.
Only if you work on the same kinds of things everyone else works on. There are certainly tons of jobs that qualify in that regard.
For other kinds of work there aren't packages that cover needed functionality, because either there wouldn't be many consumers of a package or the functionality is actually new. This is where I've found myself over the last couple of decades and I like it better, personally.
https://www.theregister.co.uk/2018/04/18/oracle_ios_app_take...
Honestly, I think JavaScript at some point - not in the near future - will see its 'Flash' moment where a large organisation stops supporting it entirely if Oracle keeps up stuff like this.
As soon as you add DOM integration... all the things people hate about JS in terms of architecture and compromises will show up in WASM.
You hate objects... basically?
This has likely changed since I last used javascript, but in the bad old days, if you wanted to specify a "type" (in the structural sense- a common set of fields that you might construct instances of), you build that type with statements rather than declarations. That feels icky. Also, that means that any potential IDE has to interpret your code (rather than simply parsing declarations) to provide any real support for you, which meant it took forever for IDEs to provide things like autocomplete (let alone foolproof renaming).
You declaratively specific the "class" (it's just an Object under the hood, it's mostly sugar for prototypes) and then you could just to instanceOf to test if it's your "type".
I mean in JS basically everything is an object so if you're constructing a "type" you're constructing an object no matter what.
Because it does basically everything else (or is spec'd to).
By the same token, there is also one overcomplicated yet unavoidable professional language. In that sense, Scala these days has a proud lineage of C++ and PL/I.
And one Lisp leader per decade for humans who not only perceive human-oriented syntax as an apostasy and a personal affront but expect that Borg of parentheses will win any moment now. Hi, Closure.
https://www.destroyallsoftware.com/talks/the-birth-and-death... was supposed to be satire... but "asm everything" might actually kind of happen.
Maybe the programming world has become too networked and there’s a lack of original thought when implementing language features.
For the networking effect to exist, your network doesn't needs to be just big. But it needs to be bigger than the rest. That's why people don't leave Facebook.
Java, C#, C++, Python have big ecosystems with specialized libraries for enterprise applications, performance, data analytics, etc.
If any, Javascript is already decreasing its influence in the web. Unity3D works with C# and it is removing support for its own version of Javascript. Or your choice may be Unreal Engine and C++. Or you can use Emscripten with C++ to build your own solution.
JavaScript is a language with a lot of problems. The final blow is going to be WebAssembly, as it will open direct web development to all other languages.
JavaScript will stay with us for long. But I don't think that is reaching its peak right now.
At this point, I'm not even sure if a single comment in this thread that poses itself as obviously anti-JS has a valid knock on the language, just high-level, hand-wavy reasoning about why it is so poor.
... after Visual Basic.
... and it’s not because it’s overfloeing with kindness & tact.
http://blog.stevensanderson.com/2018/02/06/blazor-intro/
I no longer read articles on JavaScript or related libraries, it's all obsolete. I know enough JS and TypeScript to get by until WASM-based tech takes over, hopefully within 2 years.
Which I anyway avoid thanks the bundlers in Java and .NET frameworks.