WASM is a compilation target. Think of it as a little machine in the browser you're writing code for. While you technically could write direct WASM code, the idea here is to have other languages compile to it, which you could then debug as normal.
Outside of needing some extreme performance optimization, most web developers should never need to read or write WASM code.
> WASM is a compilation target.
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.
> manually reviewing WASM
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.
But... Java developers should have a clue how bytecode works in the JVM. Otherwise I agree.
Honest question, why? Surely some would benefit, but the average java dev hacking on a spring app? Not so sure. Would love to hear your thoughts tho
I agree totally that most will do fine without, but the parent comment cited the fact that few devs know about bytecode/jvm to support not knowing wasm. But descriptive statements don't imply prescriptive statements. So just because most have no clue, doesn't make it "right", or able to be used as justification.
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.
WASM is just an intermediate representation / compilation target. It's not meant to be human readable or human writeable.
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.
Even after 10 years or so, when the tooling is good enough to match the debugging experience we have now, it won't be a moot issue. There will be a much more common problem where you want to examine/modify the source code for a site, and you can't, because that site only published the non-debug WASM. One of the things that keeps the web platform healthy is the way that client-side sources are pretty visible.
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.
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.
100%. In addition, I know I can hire tons of mid-level people with JS skills and they'll be effective quickly. As much as I'd love to throw a bunch of Haskell into the codebase, the vast majority of engineers will take a while to be productive in it.
Be aware that this might be short term thinking. What you gain in getting features done fast by mid level developers will probably cost you later in the form of technical debt. I'm not saying you can't write good and maintainable software in JS, but the features and practices other languages offer (strong and static typing, interfaces or traits, ownership reinforcements, monadic entities like list comprehensions) aren't there just to make things harder. They are usually worth the perceived extra complexity for bigger projects
Good point, especially that last sentence.
Ok, what about something more mainstream than Haskell, like Java?
Clojure plug: You can cover server, frontend & mobiles with Clojure as well - mobiles with the Re-Natal, leveraging React Native.
(This is also part of the "JS wins" story since two out of those three are ClojureScript, using JS as a compile target)
> the overarching benefit of being proficient in modern JS and sorrounding tooling is that I can use the same language for my whole stack...and spend more time thinking about the product and business
As someone who's proficient in multiple languages, I've never had issues switching between 2 languages. Am I missing something?
If you have a couple small teams, it's nice when any one of your developers is able to work on any part of the app.
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."
It's not just a matter of switching your brain, it's also about reusing code across projects, and being able to use the same toolset for everything.
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.
Nice straw man argument. You don't need to be a special genius to be proficient with 2 languages.
You need to be a genius to use two languages well in a single software while at the same time working on figuring out how to solve the constant barrage of new business problems that an enterprise software product needs to solve in the early stages.
If you say so. :|
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.
1. Can you give me an exam of something that is trivial in another lang, but requires "sailing to Africa and back" in JS?
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.
"Can you give me an exam of something that is trivial in another lang, but requires "sailing to Africa and back" in JS?"
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!)
Agree with you on this one. Module systems are kind of a mess in JS land, and from the looks of it, will remain so for a few years.
However, from a purely pragmatic point of view, not a deal breaker for early stage companies.
1. You already responded to that post, so did I
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
On 2. If you have that requirement, I don't think you can use any scripting language. If you have to use one, JS is probably the best option out there.
Only demoralizing if your staff haven't updated their knowledge of JS since 2005. :P
english is similarly a terrible language in many ways. Its only benefit is it is fairly easy to learn and start speaking with in a “broken” way but still gets its point across.
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”
Emulating classes hierarchy using prototypes while always keeping on mind what "this" means right here right now at this very call stack/context, without async/await basically any resource loading (unless you use some lib that is hiding nasty pieces from you), no enforced object structure/properties and passing them arbitrarily and then in the next version needing to add/remove some property everywhere, and many more.
From this comment, I'll make an inference that you aren't comfortable in writing complex JS apps. Am I right?
My bad. By the way, I didn't think of you as a noob, I just wanted to see if you have explored JS to the point of being able to use it predictable while managing a few developers.
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.
For me, as a founder of a young startup, the overarching benefit of being proficient in modern JS and sorrounding tooling is that I can use the same language for my whole stack(servers, web, Android, iOS), and spend more time thinking about the product and business. In the possible future where the company grows enough where it needs a distributed server software, the only part of the product that'd be changing would be the backend, and I'd probably look at Java for that. For the rest, React(& react-native) + graphql + a typesystem is a pretty good stack for UI software.
You did attack them personally.
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.
> There is a package for every possible problem you have just waiting to be used.
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.
"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.
Even if it does come down to just import statements they'll still be plenty of jobs.
Since the deploy tools are rewritten or replaced every couple months somebody has to maintain the build process.
Yeah, the reality is some of us got replaced by Adobe and Salesforce.
So you are saying you couldn't apply your skills as a java developer anymore because of salesforce?
> highly generic, often looking to implement something completely off the shelf as far as problems go.
That’s been 5-10 years out since the 50’s, right?
Yeah, but this time we actually seem to have some half-functioning ML in form of Deep (Reinforcement) Learning, which we didn't have before. You can't expect all issues will be automated away, but more like a gradual process when more and more tasks will be, and companies competing with each other on who finds a new way to automate something, like we saw with any explosive R&D in the past.
why is it that in all advancement of machine learning and AI prophecies, the developer becomes obsolete.
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.
I am working in that area myself, maybe I am just better informed and convinced by what I experimented with. Even Adobe is now doing LEGO-esque photo editing and looking for testers. When we get those things to production, there will be serious shift in basic-level developer demand; those will be likely out of luck soon. Most people would be able to assemble a simple app covering many of their needs just by dictating to their phones what would they expect to see and pre-baked LEGO blocks will be applied. Imagine fun with Minecraft but this time with blocks of properly encapsulated code, real-time using voice, touch and eye tracking.
>Most people would be able to assemble a simple app covering many of their needs just by dictating to their phones what would they expect to see and pre-baked LEGO blocks will be applied
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 used to hate JS because the language is objectively badly designed, but then I realized that the merits of the language provide a glimpse of the future of programming.
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.
> it becomes usable [...] for interfacing with the web browser
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.
This is a common sentiment but it certainly doesn't cover "all the things" people hate. I hate dynamic types, I hate imperatively constructing "types" through prototypal inheritance, I hate "this", and none of that has anything to do with the DOM.
> I hate imperatively constructing "types" through prototypal inheritance
You hate objects... basically?
While objects are overrated, that's not what I'm talking about here. I didn't say "imperatively constructing objects of a type", I said "imperatively constructing types".
Likely you'd like the modern class syntax then.
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.
Even then I don't think they would tie it to the WASM definition that tightly as they intend it to be used on other platforms than just web browsers. It seems to me that you could just have the DOM be expressed as a kind of interface which the browser implements, and then each language just has a DOM library which exposes that interface to the programmer.
Right, I agree but every time someone talks about tighter integration with the browser it really, under the hood, requires DOM access.
Because it does basically everything else (or is spec'd to).
the border between non-type and type check languages is getting diffuse these days with typescript going one way and C++ the other way http://en.cppreference.com/w/cpp/language/auto
Type deduction is very different from dynamic typing. It's still perfectly safe static typing. A better example would be C#'s "dynamic" type. I can agree with typescript though.
xkcd for everything: https://xkcd.com/297/
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.
Yeah, I definitely thought of Gary when I was writing the piece. The first time as tragedy, the second time as farce!
And somewhere, Gary Bernhardt is shaking his head in disbelief.
https://www.destroyallsoftware.com/talks/the-birth-and-death... was supposed to be satire... but "asm everything" might actually kind of happen.
I'm not sure if this is a good or a bad thing. On one side we might get stuck on a local maximum as all languages stick to the universally established features to be marketable, on the other side it seems that some arguably objectively useful abstractions crystallize, which makes things easier for everyone.
I think (hope) that Academia, or individuals, would still be able to churn out "original" languages if there were no immediate need in industry.
The problem is that these features get watered down as they make the jump. There’s a very clear scala > java > php feature pipeline, but features get worse with every leap. The way lambdas work in scala is better than java which is better than php. I wish languages would solve these problems in a way that nicely fits the language, instead of copying the subset of the feature which they can make compatible.
Maybe the programming world has become too networked and there’s a lack of original thought when implementing
The missing point is that other languages have bigger/more specialized ecosystems.
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.
Why? Just because a non-typed language is dominant, doesn't mean that typed languages disappear.
If a non-typed language wins, then god help us and I fear for the youth :)
I am amused by a lot of the hyperbole used against JS, as if it somehow is hard to use or drastically restricts the problems you can solve.
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.
> first-ever truly dominant programming language?
... after Visual Basic.
> Finally, there are the networked information sources for news and discussion, primary among them being Hacker News. Though it’s notoriously the most hostile of these large, networked coder communities [...]
I mean... he's not wrong.
But it's also got nice folks! :D
Absolutely! But there’s a reason a lot of professionals avoid here and call it The Orange Website in a derogatory fashion...
... and it’s not because it’s overfloeing with kindness & tact.
The type of organizations I work on, node.js is only used as requirement for Web frontends.
Which I anyway avoid thanks the bundlers in Java and .NET frameworks.
Unless you're disputing Node.js' popularity I'm not sure how your anecdote is relevant...
Blazor and similar technologies built on WASM are the future of web dev.