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.
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 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.
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.
(This is also part of the "JS wins" story since two out of those three are ClojureScript, using JS as a compile target)
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.
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.
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.
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”
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.
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.
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.
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.
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.
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.
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?
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.
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.
Which I anyway avoid thanks the bundlers in Java and .NET frameworks.