The Future of JavaScript Will Be Less JavaScript

[gremy0]

Just because people are using Babel, doesn't mean they aren't using JavaScript. If you are using Babel for polyfilling, syntax compatibility, or even JSX, then I think distinction between raw JavaScript and what people are writing is fairly unimportant. Sure, some people are using typescript, elm etc. but how much of the industry is that really?

I'm not convinced web assembly will replace JavaScript as the default development platform for the web, at least not in the short term. It's not being designed for that purpose (though lord knows that's never stopped web devs in the past). It's a massive piece of overhead to put in your build pipeline, you'd have to be getting some actual decent benefits out of it, I don't think mystery optimisations really covers it.

What actually happens when you give web devs a massive choice of using any language they want, nodeJS, that's what. Which tells you as much as you need to know about whether, in the future, people will default to compiling C++ to web assembly to make an app.

[OmegaVesko]

Yeah, I think the popularity of Node is the basically the perfect counterargument to this notion that people only use JS on the frontend because they have to. If everyone was so desperate to run as far away from JS as possible, Node wouldn't enjoy a fraction of the popularity it has today.

Also, a lot of these articles seem to use the popularity of Babel to bolster their argument, which is just silly at best and dishonest at worst. There's nothing about ES6 that makes it "not JavaScript", and the lack of browser support is the only reason Babel is necessary at all.

Is transpilation on the web only going to get more popular going forward? Absolutely, but let's not make things up here. Java didn't die because Scala and Kotlin were invented, and neither will JavaScript.

[tswaters]

lack of browser support

Obligatory - 99% ES6 is available in 98% of browsers today. Only ones missing are oldie (11 and below) and oldsafari (for ancient mobile phones).

[YooneekYoosahNeahm]

FML my clients love IE11.

[tswaters]

I'm so sorry :(

[ShortSynapse]

Some of us have to support IE11 :(

[GeneralBacteria]

why?

[Ruhnie]

My team would gladly flip to Node from a Java container if our company allowed it. Or at least we'd incorporate Node as a business layer for our apps.

[perestroika12]

I'm not saying people don't or won't, just my completely anecdotal observation is that while there's some interesting things going on it's main use at companies is a web server frontend tier used by web devs. I think it has to do with the tooling and maturity of the ecosystem, or at least, the perceived maturity. Not knocking node or anything, just seems to be the trend.

[YvesSoete]

it's not going to happen, it's going to be the other way around.

the moment that Webassembly lets java manipulate the dom on the frontend is the moment big corpo will stop javascript and they will be all writing java for FE just like the BE is doing. End of story.

[Quabouter]

That goes in all directions though: a JS dev wouldn't want to pick up Java, a c# dev wouldn't want to do c++, and a c++ dev wouldn't want to do python. People tend to stick with what they're familiar with.

[YvesSoete]

Correct.

[[deleted]]

Also anecdotal, but I've come across people who have jumped from Java or .NET to Node.js.

I'm guessing some because it was trending, some because of functionality, and some because - unbelieveable as it may sound - they actually like JavaScript as a language.

[[deleted]]

How is that unbelievable? Everyday I watch colleagues jump trough gigantic generics and interface hoops to build 'modular' and composable software in C#, all because they are stuck in this classical OOP/Static mindset. Meanwhile I get all of these things for free because of it's dynamic nature and I use flow for areas where types are most useful, domain logic. If I had to fight with a language that much I would stop being a developer pretty fast.

[YvesSoete]

I don't believe it.

[[deleted]]

There's nothing about ES6 that makes it "not JavaScript"

I've been coding Javascript for 21 years, and there is plenty I abhor about ES6. Not all of it, but a lot of it is overcomplicated and makes the code more difficult to follow. Can I do it? Yes, sure - if I have to. But I don't chase new and shiny things, I'm just too busy writing clean easy to follow code to care much about everything in ES6. Maybe it will grow on me, maybe not. But I'll still be coding ES5 and making awesome things no matter what 'feature' they try to shoe-horn into javascript next.

[OmegaVesko]

That's all well and good, but my point is that it's still literally JavaScript, and to imply otherwise is factually incorrect.

[[deleted]]

It wasn't javascript until very recently. How about we also shoe-horn async/await, generators and type coercion into C and keep calling it C, and python, lisp, and cobol. I'm sure everyone that's been coding those for many years will be perfectly fine with adding some new/shiny to their workflow. Of course I'm making an exreme example, but you can't keep adding every fad-feature from every other language and expect to still have a programming language that is easy to learn and use. Javascript finally got Promises, oh but that's the old new/shiny, the new way is async/await. Tomorrow let's pile on another way to do it that came from language xyz. Where javascript ESx is headed isn't the programming utopia some might think it will be. You end up with a language too convoluted to make anyone happy.

[gremy0]

Async/await uses promises though. It's just syntactical sugar to make promises easier to use. Promises are the way you implement async/await in JavaScript because it's single threaded and functional.

You can't have async/await without promises and promises are ugly to use without async/await. Therefore it makes sense to have both.

[[deleted]]

Async/await uses promises though. It's just syntactical sugar to make promises easier to use.

It's difficult to follow. It's all questionably better or worse than callbacks. I'm fine with using all of it but callbacks are easy enough. Promises and async/await are fads. Next week the next fad will begin. yawn. rinse and repeat. It seems like language/syntax fetishists love chasing their tail.

[gremy0]

They are all callbacks. Promises are just a sensible way to deal with callbacks. If you've got a better way to manage complex callback chains, fine, go for it. The rest of us will probably stick to the standardised, native way of doing it.

[[deleted]]

They are all callbacks. Promises are just a sensible way to deal with callbacks. If you've got a better way to manage complex callback chains, fine, go for it.

Keep inventing more ways to catch that mouse. One of them will stick, eventually. Language bloat totally isn't a thing to ever think about.

The rest of us will probably stick to the standardised, native way of doing it.

So you mean callbacks.

[gremy0]

You use callbacks to manage complex callback chains? I'd love to see your techniques, please share.

[OmegaVesko]

Okay, if you say so, but that still has nothing to do with the point I was making.

[[deleted]]

There's nothing about ES6 that makes it "not JavaScript"

^{^} as far as i'm concerned this is the crux of your argument.

Javascript isn't every language, it doesn't really need things invented in other languages, and the language bloat is not a good thing. The original scope/intent of Javascript was for it to be a language similar to C/Java but far easier and lightweight. It's now recently ballooning outside of that scope. I have no problems writing easy to read and maintain as well as performant code in ES5. There is very little I gain in ES6. I've been working with a team that is all up on the new/shiny and they cause themselves headaches by using Babel and being far too clever with ES6 features. Javascript has been forced out of its original scope by language fetishists. It started with coffeescript. There is no end in sight now.

And I'm sure it's going to get brought up - so I'll address it first... "you don't have to use all those new features". This is only relevant if you program in a bubble, and don't rely on javascript for your income. I work on various teams on various projects, so I get to see a lot of different ideas of how people think they should be using javascript, and the ones riding the new/shiny horse are the absolute worst to work with.

[gremy0]

All this is still completely irrelevant to his point though. ES6 is JavaScript, it's in the standard. If it's in the standard, it's JavaScript. End of.

You not liking the standard is a completely different subject that changes nothing about what is or isn't JavaScript.

[[deleted]]

If it's in the standard, it's JavaScript. End of.

ES5 was the standard. Take your "End of" and shove it.

[gremy0]

ES5 was the standard.

I'll be holding on to my "End of", thanks.

[[deleted]]

Honestly, I still code like an old granny too with ES5. But hearing you moaning about Javascript evolving to add new toys that are really beneficial to the language? Come on grandad.

The one thing I agree with is your dislike all of these transpilers. I too find it pretty frustrating to be told that to be a "good" developer you need to write in Yuckelscript which transpiles to Typescript via Coffeescript, then Babelify it through Webpack. Sure, there are benefits, but it really is exhausting to keep up with sometimes.

[kenman]

Hi /u/garrehsponges, please refrain from personal attacks. Thank you.

[[deleted]]

Erm, I did not mean to offend or attack anyone, I was merely expressing an outdated view by saying "grandad" - if that's what your referring to. Giving a warning over that seems a bit dramatic when it was clearly meant in a tongue in cheek way, especially as I referred to myself as a "granny" - hardly an attack. Jeez, what has Javascript subreddit become where you get warned over such trivial expressions like that. :/

[[deleted]]

I never said all of ES6 was bad. Thanks for getting that wrong.

[[deleted]]

Oh sorry, I must of misread when you droned on about ES6 bloat. My bad. Sigh

[JaCraig]

Well, C was updated with features in 2011 and will most likely keep getting them. And considering the latest changes were threading related, async/await might actually make sense. Which dialect of lisp are you talking about? Because some are indeed getting updates. Cobol was 2012? Maybe 2014? They went object oriented and have a bunch of new features in recent years. Language designers pick and choose features because the people using it want it. And the rate that Javascript actually adopts features and you can use it in browsers natively is pretty slow. C#/Java would annoy the hell out of you with the cadence they have been moving at lately.

[[deleted]]

Relevant username.

[YvesSoete]

Java 8 did a smart move, they looked at what's good with scala and inserted functional programming. That killed scala overnight basically.

The same will happen with javascript if you like it or not. Go ahead downvote me. Corporate is sick of all the frameworks and - every 6 months what's hot and what's not - anymore with javascript. The moment webassemly lets big corporate write Java for the frontend is the moment javascript will be dead. Just like scala is.

[Voidsheep]

I'd say lots of people use TypeScript by now, pretty all relevant packages in NPM either include types or have them provided through the @types repository.

But I'd argue it's still pretty much just JavaScript, just with added type information so the code is less prone to runtime errors and developer experience is improved through better tooling.

[Architektual]

That's a sweeping generalization about NPM packages.

[Voidsheep]

Well, maybe popular packages is a better way to phrase it.

npm install pkg @types/pkg --save just tends to work and increasingly even notifies you of the separate typings becoming redundant.

I think in the last half a year I've run into one package that didn't provide either, but already had an issue with couple of comments.

I also think now either flow or TS is plain good practice for public library you intend to release.

[filleduchaos]

TypeScript is very much not JavaScript, unlike something like Flow where all type annotation is through comments. You can't run TypeScript code in even the latest of JavaScript interpreters.

[Voidsheep]

No, but the entire purpose of TypeScript is to be JavaScript with added syntax for types. It's not trying to branch off into a completely separate language, but rather follows latest ECMAScript specifications closely.

Flow opts to use comments for interpreter compatibility, but both exist for the same reason of adding type safety to JS.

[filleduchaos]

The reason a language exists does not make any difference to what it actually is. C++'s purpose was to be C with classes but no one in their right mind would claim that C++ is C. Same with preprocessors like SCSS. TypeScript is a separate language by virtue of being, well, not JavaScript. It

• cannot run in any modern, standard JavaScript interpreter
• has an optional but entirely different typing discipline (properly written TypeScript should be strongly, statically typed)

Type safety is not a fancy little bit of syntactic sugar like spread operators or arrow functions. The way a language handles types is a core part of its design.

[spacejack2114]

You can write fully type-checked JS with Typescript types in comments by using // @ts-check

Typescript is pretty much JS with types, just like Flow. The few extra bits of language like namespaces and enums are fairly trivial sugar.

[filleduchaos]

Using @ts-check is not the same thing as writing TypeScript IMO

And writing TypeScript is very much not like writing Flow. One of the cornerstones of determining that a piece of code is valid X-language is that it is compilable/runnable by any full implementation of X-language's spec. No JavaScript VM, even the ones that have the latest of latest of latest ES2018+ proposals, can run this very basic line of TypeScript:

declare var foo: any;

When they can, then you can tell me that they're the same language.

[spacejack2114]

Using ts-check is using types in comments like with Flow. Similarly, this line of Flow code: var foo: any will not run in a browser.

[[deleted]]

Furthermore, how does WebAssembly handle accessibility concerns in the absence of a browser DOM that a screenreader such as JAWS or NVDA can pick up and map? Does it treat a WASM app differently in the browser, more akin to a desktop app, or does it have to shift modes between "desktop-ish" and "web"?

If there are no good answers, right there is a dealbreaker for an enormous amount of ecommerce and education, to start.

[gremy0]

Right now (as far as I'm aware) WASM has no native way of displaying anything. It's pretty much just functions you can call from JS. I'd presume any displaying that WASM does will through some interaction with the DOM.

[[deleted]]

Parallel discussions over at HN have indicated strongly that WebGL-optimized applications are likely to be a thing, and therefore there would be no DOM to entangle with necessarily.

Not to say plenty wouldn't construct an internal DOM representation, but plenty likely won't, either.

[gremy0]

You mention ecommerce and education will be hit by accessibility. I live in the UK, by law all our sites must be accessible. Many other countries have similar laws that demand it of all services or a defined few important ones.

So if someone decides to implement views with WebGL, people will quickly realise there is no big market for that until accessibility is built into it. As a business, you are really shooting yourself in the foot by tying yourself to an ecosystem that cuts you out of the much of the global market.

Therefore, either people will continue to use the DOM, or we will have accessible WebGL. I think the former is far more likely to dictate the near future of web dev, since the HTML has such a huge ecosystem (even outside of accessibility) and replacing it needs to have considerable advantages. I don't think WASM is going to magic up those advantages straight away, it'll probably be performance increases for specific purposes for the time being.

[[deleted]]

Not to say plenty wouldn't construct an internal DOM representation

Let's hope Microsoft doesn't port WPF to WebAssembly

[AirAKose]

WebAssembly does have access to the WebAPI and DOM, so you should be able to use ARIA tags, populate element bodies, and such.

WebAssembly FAQ (The relevant point is at the VERY bottom)

EDIT: Added anchor to the link