Mark my words, Web ASM will be just as opaque as traditional assembly languages. Which is to say that we'll shift the problem from "JavaScript is bad" to "I cannot debug this," "I cannot see what this script does," "I lost the original source code, and now I have to reverse engineer WASM! Help!"
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.
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.
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.
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.
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.
Use JavaScript or its wrappers (TypeScript, Dart etc.) just to glue modules written in C++ or other sane language, compiled into WASM. That's the future. JavaScript's role will be diminishing, paradoxically when it is now becoming an actually usable language, e.g. finally removing callback hell by async/await, adding some "borrowed" stuff from Scala etc.
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.
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
> 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.
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.
You literally restrict yourself to one of the worst languages ever designed. What could be solved with elegance and without demoralizing your staff in 5 minutes in some other language, in JavaScript it might require "sailing to Africa and back" to achieve the same (though I must say it has improved a bit recently from the insanity it used to be). On paper it might look good to you, but the reality is very different and you are making yourself seriously restricted in competing with other companies using more sane languages.
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?"
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!)
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.
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.
Dunno, wrote games in JavaScript that left people gasping for air it was possible in a browser, wrote most algorithms in some image/vector processing tool you might be using in your business right now where I had to interleave JVM, JavaScript, WebGL and GLSL in areas nobody tried before; wrote facial/emotion tracking system with advanced computer vision in a browser etc. Maybe I am not a noob you think you are talking to?
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.
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.
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.
No problem. I usually learn a new language by picking a very challenging idea and then implementing it; that way I can see how the language performs "under stress", though I might have skewed view for normal use cases. Still, companies seem to be more interested in the weird cases I am forced to explore (much to detriment of my happiness), and JavaScript was making me quite grumpy at times.
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.
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.
Not to attack you personally, but it seems like you have never written software professionally. All the available packages you mention quickly become useless as soon as you have a use case that is not in the package's, often very short, README. More often than not, you need functionality which is at the intersection of what is provided by 2 or more packages with no easy means to make them work with one another nicely, so you basically have to write one for yourself. And when you remove all these useless packages, you get a set of useful packages which are not unique to javascript but can be found in any mature language.
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.
> highly generic, often looking to implement something completely off the shelf as far as problems go.
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.
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 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.
I think within a few years WASM will finally be in a place where it becomes usable without relying on JavaScript for interfacing with the web browser and people will be able to develop high-performance, isomorphic web applications in other programming languages. This will definitely start to eat into it as it makes gains elsewhere. As such, I don't really see JavaScript reaching the level of dominance implied in this article - and to be honest, I wouldn't want it to when Oracle has gone after developers for naming it as something they support on trademark grounds.
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.
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.
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".
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.
I think that's fine because WASM isn't meant to write code in. It's just a source language for other compiled languages. I'm assuming the javascript complaints you're talking about are because people actually have to write javascript code?
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.
To put things in perspective, every decade there is an uber popular so called simple but highly inadequate non-type checked language that is taking over the world of novice developers. It's a social phenomenon. Started with Basic, JavaScript is the latest incarnation.
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.
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.
All the C derivatives are getting closer to one-another. How different are Typescript, C-sharp, and Java? When JavaScript adds gradual typing, interface, etc. won't all these languages be nearly the same? The runtimes will differ but the language features and syntax will be almost the same.
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.
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
language features.
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.
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.
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.
You are completely missing the point here. It is not the question if JavaScripts wins - humans are not great at writing software to begin with regardless of the language. Soon, machine-learning assisted programming will be a thing and JavaScript will be a non-issue - applicable to any other language for that matter.
> 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 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.
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.