Ask HN: Will front end development ever move away from JavaScript? | Hacker News Reader

Ask HN: Will front end development ever move away from JavaScript?

124 pointsjs-fiend237 comments

Developers have done some amazing things with JS, but I think everyone can agree its not the most elegant language.

I understand we are where we are because the its the only language supported by browsers. But will we ever move away from it?

Could Google or Mozilla build support for another language into their browsers while developers gradually move away from JS?

Will developers be open to alternatives? Will we finally standardize on a simpler set of tools and frameworks?

Does WebAssembly solve this? Is TypeScript good enough?

View on HN

I think it's a common misconception that JavaScript isn't an elegant language. The real issue is that it's the only language with a monopoly. So people who want to work on the web have to use it. This results in people being forced to use it against their will. So obviously a lot of people don't like it - probably because it doesn't have that feature they really like from their primary language - whatever that is. If we invented a replacement language, the issue would not go away, but simply shift.

I think instead the real issue is that we're too bad at educating people in how to properly use the language. Sure there's corners of the language that are bad, but as a seasoned JavaScript developer you simply know to ignore those corners. So they don't bother you. You instead focus on the cool things about the language. Any programming language have good and bad things. And we as developers learn to focus and leverage the good parts to our advantage. The ideal of a perfect language is a pipe dream unfortunately - instead my advice is to really learn the language and embrace it instead of fighting it.

I think ES6+ has done wonders for JavaScript and has made it a highly expressive language. It's true there are quirks and poorly designed aspects which can be confusing at first glance. But like with any language, once you understand how it works, you learn to work with it. Moreover, as the language continues to improve, many of those quirks become irrelevant.

It's important to understand that, by virtue of having been bestowed with a monopoly over the web, JavaScript holds a great deal of leverage as a language. If you want to develop for the web, you pretty much have to adopt JavaScript into your stack. It's no surprise, then, that Node became so popular. Being able to use that language you're forced to use for the client on the server and to run the same code has major benefits. The Node and npm developers got many things right to be sure. But Node and its ecosystem, by virtue of offering JavaScript, benefitted immensely from developers' desire to unify a previously disjoint part of their stack.

I find myself asking instead, how far will JavaScript's reach continue to stretch? Electron and React Native have become extremely popular. It's not just speculation, there is undeniable momentum.

I think ES6 is the worst thing that ever happened to JavaScript because it killed it's best feature: being a small language that runs everywhere.

Now when I want to use a JS library, I have to think: what is this author's philosophy about language extension? Are they going to start using some new feature that some other library I depend on is incompatible with?

You used to be able to run JavaScript anywhere on any device. Think about how powerful that is. We sacrificed that for supposed gains in "ergonomics".

People hate callbacks. People hate "this". But if you ask people who really learned how to use those things, they're not problems at all. They're only problems if you're coming from Ruby.

It's like someone took an Apple and said "this is gross, it's not juicy and tangy like an orange!" And then they soaked it in vinegar and wrapped in orange skins. Now it scores well on orange-ness but is that a virtue?

I really don't agree, as a developer writing predominantly js. It's still pretty standard to compile es6 down to at least es2015 using babel or typescript, meaning js still runs everywhere. I've also literally never met anyone who thinks that callback-structured code is "not a problem". And you can work around issues of "this" and lexical scoping to the point where it isn't as irritating, but it's completely unintuitive to a new js developer, and IMO at least never stops feeling "wrong". There are also a ton of features aside from arrow functions and promises that completely change the way code is written for the better- off the top of my head I use ` string formatting, classes, let/const declarations, and module loading every day.

> It's still pretty standard to compile es6 down to at least es2015

Yea, but that means if I want to use your library, I need a build chain. It used to be I could just do require("you") or <script src="you"> and be done with it. That's what we lost.

Actually I need n buildchains, one for each npm module I use. And they better all be compatible and target at least one common runtime. And that better be a runtime I am comfortable deploying for my app.

> I've also literally never met anyone who thinks that callback-structured code is "not a problem"

Well here I am. Pleased to meet you. Might I also point you at: http://callbackhell.com There are many of us.

I think what this really shows is how much professional ES6 programmers live in a filter bubble.

This also explains why you think "just transpile" is a reasonable substitute for a simple, run-anywhere language. Professional ES6 programmers think everyone has 40 hours a week of paid time to spend maintaining a build chain.

Javascript+Node used to be one of few languages that you could use without a build system. That's no longer the case. Maybe the loss was worth it to you. Fine. Makes sense. I wish more people would just acknowledge something has been lost, and that amateurs are struggling now at the expense of pros.

I agree with a lot of your sentiment. But there's still nothing stopping you from writing ES5 or even ES3 and just ignoring ES6. Thats what we do and it works great for us. And we build extremely high end interactive apps using virtual dom, webgl, etc.

that's really interesting - would love to know more about your JS stack and your project structure?

I think you missed that the parent meant that libraries are compiled _before_ publishing. So even if the library is written with ES6 you can simply require it with no build setup.

Many (most?) libraries are not built that way. There are plenty of libraries that use async in their exports.

i wish i could upvote you 100 times.

> It's still pretty standard to compile es6 down to at least es2015

...aren't ES6 and ES2015 the same thing?

Yeah, they are. People get confused because ES6 === ES2015, "ES7" === ES2016. I sometimes make the same mistake.

If you transpile down to an old version of js, does it matter what language you're transpiling from?

The minute you decide to transpile, you no longer really using javascript, and this discussion isn't really relevant any more.

Well, jQuery is the single most popular JavaScript library ever, with over a decade under its' belt, and going to be around for likely another. Its' style was not predefined by the JS language... It has a monadic style in nature... Likewise, JS didn't prevent coffee-script or transpilers...

That said, I still feel that not sending the event registration context (not just the target) in with the event is a mistake... escalated by the use of fat-arrow functions today. You never know where things will go.

As to callbacks, I think it provides a great base... allows for easy extension and progression. I do now prefer Promises where async/await is available or via babel.

Java 8 isn't the same as Java 3... it's changed... languages evolve, and JS has done so rather rapidly the past 6+ years... It looks to be settling in a bit now. Next will be the module support, and that shift will be more painful than everything that came before.

I don't mind the context class sugar... there are places where it makes sense, and far cleaner than the prototype syntax. I tend to only use it for UI components, and even then sparingly. Just the same, other parts of ES6+ have been incredibly great.

What are you talking about? ES6 transpiles down to ES5, and this is what people publish libraries as. The language version compatibility story is way better than it is for most languages.

Who's writing native ES6 code? Support for IE8 is just now starting to slip in the community (due too old, mundane things like Object.defineProperty). Almost every package on NPM targets ES3. Also, IE never ran everywhere. Targeting IE8 is hard, targeting IE6 was a nightmare.

I can't speak for you, but I've worked at a few companies and done some contracts overs the last 5 years and supporting ie8 easily stopped around 2012.

Microsoft ended support for IE8 early 2016. Until then most open-source libraries supported it. I wrote an IE8-compatible application this year and only had to downgrade a few random libraries.

I see this misconception a lot in this thread. "Yes, people say the language has problems, but there are people can work around the problems, so they aren't really problems!"

The very fact that you need to learn to work with X means that it's a problem. Otherwise, all languages are just fine.

everything is stupid if you dont understand it. JS is pretty good at not getting in your way.

There is no "stupid" and "clever". There's only "consistent" and "inconsistent". JS isn't very consistent.

>everything is stupid if you dont understand it.

Some things are stupid even after you understand them, and JS has plenty of those, as its creator and its greater evangelizer both admitted.

I don't think it's about missing features. JavaScript has a lot of footguns. You admit that, but dismiss the complaints. Sure, with experience you know what to ignore, but a well-designed language has fewer of those areas in the first place.

I've used JS enough to find that it's more like a nuclear powered .50 cal Gatling gun.

We hate JavaScript, because writing the code below is a perfect valid way of calling alert(1).

    [][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+ [])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()

That's a feature if most of the keys on your keyboard are broken. :)

Seriously, it is not a good reason. Just don't write code like this nor allow other people in your team to write code like this. Fortunately, this kind of code is unlikely to be written by mistake so it is easily avoidable.

That was just one example, there are lots of other WATs.

As for team, in enterprise consulting, the concept of team is very shallow.

I initially believed it was a sarcasm!

Are you familiar with Gary Bernhardt's talk "Wat"? (https://www.destroyallsoftware.com/talks/wat)

I don't think it's that productive to judge a language on the worst features and edge cases that most teams will be able to easily reach consensus on avoiding, as every language will have its bullshit.

>I don't think it's that productive to judge a language on the worst features and edge cases that most teams will be able to easily reach consensus on avoiding

Only those edge cases merely expose functionality that can burn programmers on an everyday basis, like coercion rules.

It's not something that you have to get out of your way to get.

These same obfuscations exist in many, many other languages.

I imagine they hate those other languages too.

You do know there are many, many languages where that sort of obfuscation lay between difficult to impossible, right?

Why would you ever write such a thing?

You wouldn't. The argument is so straw-man that it verges on trolling.

Actually you don't have to write such a thing to get the same BS behavior, and it's not a strawman at all.

It's just a side-product of JS god-broken coercion rules and types, and those affect every statement one writes, down to the suggestion to use === instead of == for the most fundamental thing any language does: equality comparison.

The example is just meant to showcase how far the brokeness can be taken...

Actually I like the ability to == all known ducks. There are a lot of cases that we run into like a DB that we have no control over where they use null, '' or 0 as some form of indicator of no value, it's nice to be able to ignore all of those cases when one does not have control over the quality of data coming in the pipe.

I tend to favor the mantra of be a liberal when consuming data and a conservative when exporting data and I find the == vs === does that very well. Sure it's a gotcha but no big surprise to most people that have been doing JS for any amount of time. I personally think it is a brilliant feature that save a lot of boilerplate when one understands the difference.

It's an effective way of obfuscating malware, for one thing.

Surely not. It would be easy to spot.

Obfuscation doesn't necessarily need to be hard to spot, just hard to understand. Like, could you spot this in a chunk of minified code? Probably. Would you be able to figure out what was going on? Probably not without some difficulty.

If it's hard to understand like that then I would be automatically suspicious of it.

>I think instead the real issue is that we're too bad at educating people in how to properly use the language.

I don't think this is true at all. I think over time it becomes very easy to apologize for the environment we're forced to use, because there is no comparison, we only have JS for the web.

In any decent project, you're going to have hundreds of 3rd party dependencies installed from tons of sources, some of which could freely introduce exploits into popular programs at any time. If any of these break, you're going on a long hunt to track it down, ultimately to be met with authors that aren't responsive or some bug caused by god knows what incompatability.

We're stuck between the ever flowing battle of new language constructs and languages ontop of JS that try to make it 'easier'. JS lacks very important things that devs have found to be necessary, like typings, and even trying to add typings is a huge battle in itself, that again, is ever changing. Just try and google for where you should put your .d.ts files, and you'l get 4 different answers, all from different stages of versions and recommendations.

You can't teach JS. You can only say that things never stay the same, so build things fast and break them quicker. What you consider 'properly' today, is tomorrows bad practice.

You can put //@flow at the top of your files and install a plugin for your editor and have typing in about 30 seconds.

See, thats the thing though. There's so many ways to do something, with multiple competing standards on how to do it, along with plenty of quirks and ways of working with it you only understand by experience. This is good, when you already know exactly what you need and what that provides, but its impossible to keep up unless you're spending a lot of time testing and researching, and even still, at the end of the day you've gotta make the application.

One of those 'it takes a village' to make a good JS app.

a village?! Come on healthcare.gov ...

I agree, JS is quite an elegant language, especially since ES6.

I'm kind of disappointed with the introduction of the 'class' keyword though (and the way it was implemented). The old prototype function declaration approach is really good once you understand it.

I do like how the prototype way makes it more clear that it's just a function. What about you?

I find that an implementation detail that most people don't care about in their use of prototypes.

I don't follow

Prototypes in js are almost always used in a way that approximates classical classes, but with confusing syntax. The 'class' keyword just makes things more readable.

> seasoned JavaScript developer you simply know to ignore those corners

I'm sorry, but how does a seasoned Javascript developer ignores the absence of compile-time type checks? Aside from switching to a language that compiles to Javascript.

You can't have a language that satisfies both camps. Some like statically typed languages, some don't. Stating that it's an inferior language because it's not statically typed is just plain wrong. I accept that you belong to the statically typed camp, and that's awesome. But don't be fooled into thinking that it's somehow better - it's just a different approach to programming. If you like it, then that's cool.

I guess I'm a seasoned JS developer.

If I needed compile time type checks for a snippet of code, I would use a language with compile time type checking that compiles to JavaScript.

If I needed compile time type checks for many snippets of code, I would take a few days off and rethink my architecture. Ask myself why my call sites are so brittle or confusing that I am making frequent type errors.

Well said, came to say this.

There are many popular dynamically typed languages.

Why is it suddenly a foregone conclusion that seasoned Javascript developers all want compiled statically typed languages?

I know that it's a very old argument that I'm not going to win. But I would like to provoke you to it because I'm really trying to change my mindset, coming from a static language to Javascript - and I still just don't see, where are the wins.

Please argue with me, because I _want_ to be convinced. I'm trying.

It may be because of the habits I developed, writing compiled code. I always would first concentrate on my concepts, things that I want the code to do, data and flow structure - while keeping all errors (even syntax) silent. And only when I got everything I wanted implemented and consistent, I would turn to a compiler to quickly fix all mismatches in API, all wrong method names and other trivial blunders.

Now I stumble, feeling that I'm a blind man going through a minefield. Every line I write, I have to think about the things that I want to express and the mechanics of language and API simultaneously - because nothing's got my back. (Yes, I know that I should write unit tests, but not all of us have the luxury of working on perfect projects, starting perfect projects from scratch, or having the resources of putting good practices into legacy code).

Every time I discover that I mistyped the name of the function or variable, forgot to use "this" when referring to an object property (C# habit), forgot that external API function returns a custom type and not a string - I do it too late. Instead of quickly fixing the thing that I've only typed right now, I have to go back, and spend time reading and understanding relevant code again.

All I'm trying to understand is, where are the trade-offs? Where are all the awesome dynamic things that make all that worth it?

The trade-offs are that the language implementer has an easier time of it (once), then every programmer has to expend extra effort writing the code (a lot of the time), the computer has to work harder running it (every time), and code browsing/refactoring/etc. tools are literally never, not even in theory, going to work 100% perfectly.

Now, if you're writing a programming language, this probably seems pretty awesome...

I wrote on my blog about some of the annoyances that come with type checking:

Type Checking vs. Metaprogramming: http://www.oilshell.org/blog/2016/12/05.html

http://www.oilshell.org/blog/2017/01/21.html (at the end, pretty printing requires metaprogramming, or escaping into another language)

Whenever you have a code generator like an ORM, or protobuf-like schema languages, you can use metaprogramming instead. Generally I think this helps the program so you don't have these impenetrable walls between layers, where one person understands one side and the other person understands the other.

I find that a lot of programmers coming from statically typed languages are writing Java in Python, or Java in JavaScript. In Java you don't really think in terms of metaprogramming.

If that's the case, then it is going to feel annoying. You're getting all the downsides without any of the upsides.

I would look at Go for other examples of the downsides -- namely the lack of generics. Go is attracting a lot of Python and Ruby programmers.

In Go, you can't write basic generic functions like max(), map(), filter(), and sort() -- in JavaScript and other dynamic languages this is not something you would think twice about.

I guess between metaprogramming and generics, dynamic languages let you write more abstract and concise programs. Programming in statically typed languages feels repetitive to me, and the architecture is quite clunky unless you are doing textual code generation.

Steve Yegge also has a bunch of good posts about dynamic languages.

Thanks for the honest question. I think it's important to remember that there are tradeoffs. I fully admit that type checking is useful in many circumstances. I would like the best of both worlds. I'm a little disappointed that recent hybrid languages like Dart and to some extent Racket have had problems with optional typing and gradual typing. It is something I'm interested in but it seems like an unsolved problem.

I can see benefits of metaprogramming in quite a few very specific tasks - but most of developers who are using Javascript day in and out aren't writing compilers. We're writing business logic. And because this logic comes from human, fuzzy rules, to accurately represent all the corner cases and not drive the code into a globe of insane parameters and checks, one have to get into a mindset of _not_ trying to generalize things.

Thanks for "When Polymorphism Fails" link, it was a wonderful read. I've actually run into such situations a couple of times - but in my experience, you want most of your methods to be statically checked, and only a minority of them to be added and checked dynamically in runtime. May be the solution is to have two different method tables, that look and behave in a different way?

Yes I totally believe that part of the static vs. dynamic debate is different use cases.

However I will point out that probably 80% of the world's top websites are written in dynamic languages -- Wikipedia, Facebook, Yahoo, YouTube, Reddit, etc. (that's not even counting the JavaScript.)

So there is something about that use case and dynamic languages... That's not to say a language is great because it's used widely. But it means that it must be getting something right, and not doing other things too badly.

So yeah all I'm saying is that there's a tradeoff. If there's was no tradeoff, then it would have never have swung toward dynamic languages in the 90's/2000's. It's not like we didn't have statically typed languages before the web. But things swung that way, and it sounds like they're swinging back, with PHP, Python, and JavaScript all getting optional types in one way or another.

I don't really think so. F# and Haskell are WAY more expressive and compact than JavaScript. And they have probably among the best statically typed systems out there. I guess you didn't use many languages in your career if you are in awe of JavaScript expressiveness..

There are linting tools that you can and should add to your text editor of choice. Whenever I reference a variable in JS, if that variable is not assigned it highlights it as a possible error. If I define a variable or function and don't use it, that gets highlighted too. If my syntax is wrong, that gets highlighted. If my team had decided that we only want to use single quotes around strings, that gets highlighted. Even our build will complain and our tests will fail because we have incorporated linting into them. With ES6 there is no reason to have global variables anymore, so it is possible to confidently identify all these errors before the code is even run.

The language is constantly being improved while maintaining backwards compatibility. Finally it's ability to handle whatever kind of data you throw at it until you choose to check the data is a strength in an environment (web pages) where nothing is certain. You aren't sure about the data you will get from an API, from the user, you don't even know what kind of environment your code will be run in! The same code might run on the latest version of Chrome, a headless test environment, or some old version of Internet Explorer. And that is totally possible. It's all up to how you code it. And you have to get used to coding in this type of language. You can and should test your code as you go along, no need to wait to compile, you can see the results right away. Build your code to handle errors, because even if the code is perfect, the data you are working with will not be. And have lots of tests. Not only do they identify current errors in the code, but they allow you to make large changes with confidence that everything else is still working like it should.

You're bolting on an optional, incomplete compiler to make up for the shortcomings in the environment.

I jist can't deal with the sloppy wild west way Javascript world works.

It's alright, I have no interest in an argument :-)

I like Javascript, and that's enough for me - and I (in _most_ situations) find dynamic typing more of a benefit than hindrance; but I don't mean to purport that my perspective is everyone's perspective :-) IMO it's very plausible that dynamic typing will never be better for you; because we're all different and we don't all like the same thing. If you've come to learn that dynamic typing doesn't suit you, act accordingly, don't just try to change yourself because something else works for others.

If you're interested in static typing, maybe try moving to Typescript? AFAIU it also integrates fairly well with normal Javascript, and hence maybe it's more to your taste? And if there are other people feeling the same way you are on your projects, it mightn't be too difficult to move new (or maybe a subset of new) development to something more your taste instead? (I've heard good things about Flow as well, and maybe it's simpler to "sneak in" to your projects, and offers big enough benefits for you?)

In my experience, legacy projects (or projects where there's pressure to cut corners (eg unit tests)) are often the bigger issue than the language. (eg I've been "in pain" working with code in languages I otherwise like that was obviously done in a big hurry, or evolved obviously from clumsy requirements and hence has big inconsistencies.

(As an actual example of a reason _that applies to me_, the last Javascript project I worked on ran the integration tests faster than the last compiled statically typed project compiled (and reloaded) - hence I ran the tests in a watching process, and felt more productive and less frustrated. And yeah, I haven't written `this` for a very long time :-p )

i rarely think of types when writing JS. where something is not obvious, like i forgot if it returned a string or object i write an error that will throw if my expectations are wrong. i call them sanity checks. also where something is not obvious you want to rename it so it becomes obvious. so you kinda replace type annotations with better easier to understand names.

Dude.

I've always thought that Javascript makes up for its lack of compile-time guarantees with compensating tooling.

For example, it's common to use Flow with Javascript to enable static type checking before actually running it.

The language itself doesn't guarantee type safety, but when used with peripheral tooling, the developer isn't missing too much.

We write tests.

Really, I find compile time checks to be moot when you have fast running and good unit tests.

Yeah, that whole suite of tests that you don't have to write yourself (or, more likely, you were never going to write, if you had to do it yourself...) that runs automatically every time called a compiler.

That's misleading. You don't write tests to check types. You write the same tests you would with a typed language. There is no extra work.

A by product of testing your logic is that it will fail if there is a type cast problem.

Having a monopoly could potentially be a great thing, no more tech-change anxiety, consolidation of effort etc

But there is so little structure, and so many roll-your-own efforts, the JS world is heavily fragmented...

> we're too bad at educating people in how to properly use the language

Does such a thing exist? How does a seasoned JS dev avoid DOM manipulation/interference nightmares, lack of typing, event hierarchy complexity? How do you really make a modular site without heavily committing to one framework?

> ideal of a perfect language is a pipe dream

Nothing's perfect, but still keep fighting for better.

I think we know how to teach it but we can't agree on how to use it. How many shops are more then happy to cut corners, pull in gigantic misunderstood 3rd party libs, green light advertisers code, allow unsupervised and under-trained juniors to contribute if it "looks right", etc. etc. Bottom line is the business and administrative aspects of language usage are loosely defined with javascript and it makes our lives as engineers slightly less pleasant (or potentially extremely unpleasant depending on what you have to work on).

And the world keeps spinning.

> I think it's a common misconception that JavaScript isn't an elegant language.

1 + 'a' = "1a", I've seen more ellegant solutions, I'd love JS to be strongly typed at least (without typescript).

I'm not nearly so concerned with elegance as I am with being able to manage memory simply. the GC and "needed" detection lend themselves, how shall I say, to complexity.

GC is often better at the job then humans. you can manage memory in JS yourself though by not crating new objects and using pre alloc buffers instead.

By using the word "ever," you cast this question into historical or even religious proportions.

1000 years ago, the primary frontend toolchains were singleton and handmade: every instance of a piece of data needed to be individually crafted.

500 years ago, the printing press had made significant changes, but frontends were still largely coupled to the available presses and their character sets (let alone niceties like layout and graphics).

100 years ago, frontends still remained tied to their physical layers (ie, it wasn't possible to scrape data and create a new frontend without recreating the entire medium) - ie, books and magazines and newspapers.

20 years ago, javascript was barely known even in programming circles, much less a lingua franca for publishing worldwide.

Today, javascript is the control structure by which the vast majority of data is accessed by human eyes and ears.

In 20 years, something that has already been invented but is today not largely known might well be responsible for most knowledge exchange. It's completely plausible that technologies like AR, crypto-blockchains, and newly legalized psychedelic drugs will be as important as HTTPS is today for transmission purposes, let alone the particularities of the application layer.

100 years from now, it's highly unlikely that the screen-and-keyboard model of data ingestion will be regarded as anything but a historically important link in data evolution, cast away in favor of more tactile, neurochemical, and cybernetic interfaces.

500 years from now, most of the world's governments, media traditions, and spoken dialects of language will have folded and made way for a completely new condition of humanity. Who knows what the frontend will look like.

In a 1000 years, our species might plausibly have no biological footprint (ie, no sensory organs to use for the purposes of distinguishing "frontend" from "backend") whatsoever, and live on as information and knowledge, present in the physical universe only in ways that we can't possible yet imagine.

So yes, the species will someday move away from javascript.

Unless as we shed these corporeal bodies and transition into more informational forms of being.. what if the language that creates our informational selves is JavaScript?

In other words... What if we BECOME Javascript?

I try to think and get undefined is not an object. Perfect.

Or your thoughts are mixed with other peoples because you were defined globally.

When we look back, we recognize that things took a lot of time, but when looking forward we expect everything to go fast ...

> 100 years from now, it's highly unlikely that the screen-and-keyboard model of data ingestion will be regarded as anything but a historically important link in data evolution, cast away in favor of more tactile, neurochemical, and cybernetic interfaces.

Very imaginative and sci-fi, but not likely. Just because we've advanced this fast in the past 50 years doesn't mean we'll be able to keep this rate up. There are physical limits to the things we can do, even if we keep gaining knowledge at the same speed. We'd have to break a lot of very big scientific barriers before any such technology would be both practical and affordable.

Really? It seems to me that the touchscreen has already supplanted the screen-and-keyboard for most people for most of their day.

If that's really true, I feel sorry for them! My experience with touchscreens has been that they are mostly sort of okay in small doses, if that's all you've got - but if I need to write anything longer than a sentence or two, or read anything that takes longer than a minute or two, I'll wait til I can use a computer instead.

Yep. 99% of programmers use an actual computer to type their code into, rather than typing on an iPad or other touch screen. And 95% of programming still requires manipulating text.

And 99.9% of humans are not programmers.

Well worded. I think we either bomb ourselves back to the times of basic survival or transition into digital entities.

This is a beautiful answer.

I'm surprised at how many of the answers here are rationalizing JavaScript's monopoly, saying that it's a fine language / it's optimized / stop complaining / etc. That seems like the programming-language equivalent of Stockholm syndrome, i.e. "We're stuck with X, so we should justify and defend X as a coping mechanism."

The question you should consider isn't, "Is JavaScript a good language?"

The question you should consider is, "Is JavaScript's monopoly good for the web platform?"

I'm not sure even that question is a good one to consider - I think the market already has shown what happens when attempts to move off JavaScript happens with Google and Dart. The various other browser vendors didn't bite, and the industry as a whole remained with JS.

IMO the best question we have given the realities is "what can we do to make JS workable?"

The same could be said for HTML.

And CSS

And FORTRAN.

And my axe!

Reddit is leaking

Adjusting to reality is a good thing. Expecting reality too adjust to your personal whims and desires is kind of messed up.

I don't see anyone defending JavaScript as if it had no flaws. So I'm not sure what your getting at exactly.

"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." - George Bernard Shaw

>Expecting reality too adjust to your personal whims and desires is kind of messed up.

Man made things, like programming environment and the web, are not some immovable physical reality.

And when it comes to man-made "realities", Rosa Parks probably has one of two things to say about wanting to adjust them being "messed up".

If you want to dedicate your life in advocacy for JavaScript replacement, go ahead, but I think that would not be a wise decision for one to make.

Saying "it's not the most elegant language" is quite (mis)leading. While I would not claim that it is the most elegant language, I would most definitely claim that it is elegant.

Two things that many people get wrong about JavaScript: (1.) Most of the ugly parts involve interacting with the DOM, and the DOM is NOT JavaScript, and (2.) Just because some people write ugly code with it does not mean that the language itself is ugly.

ES6 and ES7 have done wonders for the language syntax, and the flexibility of the language allows you to write in any combination of procedural, functional, prototypical, object-oriented programming styles. I mix them together as needed to make programs more intuitive and easier to follow. Programming is an art, and JavaScript is a powerful and versatile tool.

You are also wrong in that it being the only language supported by browsers. That may be the case now, but in the past many, many, many websites used flash and java applets. Quite frankly, the reason that JavaScript is what we have now is because it really is that good that it replaced all the other options.

All of the other questions are all over the board... It sounds like you are trying to get us to write a homework assignment for you.

I haven't looked at ES6/7, and its true that any language in the wrong hands can be ugly. But there's a lot wrong with JS besides how it interfaces with the DOM[1]. Which is funny because it was originally conceived as a browser scripting language[2].

And JS beating flash and java applets may be more a result of market forces (Apple) and the lack of better alternatives.

Brendan Eich designed JS in 10 days for the early era of the web, which is very different today. Its both a testament to the language and the hacks on top of it that its stayed in use this long. But maybe its time to move on?

[1] https://medium.com/javascript-non-grata/javascript-is-a-dysf...

[2] https://en.wikipedia.org/wiki/JavaScript#Beginnings_at_Netsc...

Why do you believe the language is dysfunctional?

>>Most of the ugly parts involve interacting with the DOM, and the DOM is NOT JavaScript, and

Yeah, like dealing with "this" keyword or type coercion in JS is not the ugliest thing ever in the history of Programming languages

> Yeah, like dealing with "this" keyword

This can get a little confusing until you understand how context works. Then it makes sense but you know what? You don't always need to use this. In fact you can build entire applications in different ways without ever using this. And no writing without using this doesn't make your code ugly or unmanageable. There are just many ways to get the same or similar things done in JavaScript.

> type coercion in JS

Type coercion is ugly in any programming language. It's best to avoid it, even in JavaScript (which you can do, btw).

The problem with type coercion is when it happens without you noticing it. You cannot "avoid" it...

Sure but this problem is inherent to any dynamic language. I find other issues far worse than simple type coercion. What about calling a function? Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice.

You can avoid type coercion if you understand how the language works (aka strict equality in JavaScript) but this isn't something only in JavaScript land either.

There are two separate issues in play here. You're conflating the static/dynamic dimension of language classification with the strongly-/loosely-typed dimension of languages which is what the poster you are responding to was talking about [1]. These two dimensions are orthogonal: languages may be static, but weakly typed (like C), or dynamic but strongly typed (like Python).

I'll allow that there's inevitably some degree of opinion involved here, but I tend to agree with the parent poster that implicit conversion in languages like Javascript, PHP, and Perl is just another vector for bugs, and outweighs any of the advantages you get from having your language coerce everything for you. But then again, i'm one of those people that likes my language to force me to be very explicit about what I mean, so YMMV.

Regardless, the strict equality operator is not at all sufficient to avoid the dangers of JavaScript's implicit conversions. Pretty much _all_ the operators are going to coerce types for you, whether you meant for them to or not. For example, this function:

function increment(i) { return i + 1; }

Adds one to number right? But let’s say you’ve neglected to convert some user input in a form to a number as you should have done elsewhere in your code, and you end up calling increment("1"). This will return "11". So now you potentially have introduced a serious math error into your code you may not notice right away. Conversely, if you did this in Python, the function would have raised a TypeError immediately, because you can’t apply the arithmetic operator to two different types. You can’t just “avoid” type coercion in these loosely-typed languages by understanding the specifics of how it works, because you may not even know it’s happening until you start seeing unexpected results somewhere.

[1] https://en.m.wikipedia.org/wiki/Strong_and_weak_typing

> Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice.

Python will throw an error. Ruby will throw an error. Tcl will throw an error. Erlang will throw an error. I believe most of the Lisps will throw an error.

What was it about "most dynamic languages"?

> What was it about "most dynamic languages"?

I should have changed my text to not say "regardless of definition" because you can do that in Python, Ruby, PHP, JavaScript, etc.

Python and Ruby support it through (star)args or default parameters

JavaScript supports it regardless

PHP supports it regardless

We can argue semantics or the fact that some of those types of errors can be caught with some subset of dynamic languages but I don't think that's useful.

My only point was when comparing a dynamic language with a static language I find variable function parameters to be one of the bigger issues over type coercion. But that's just, like, my opinion.

Those aren't particular to dynamic languages, though. You can add C, C++, Java, and C# to your list of languages that support it. Being able to explicitly make a parameter optional, or to have a 0-or-more rest argument is different from how function application works in Javascript or Perl because you have explicitly made that part of your function's signature, and the language still checks calls against that signature.

Most Lisp compilers will warn about wrong number of parameters at compile-time. Lisp typically warns at runtime, too.

> Yeah, like dealing with "this" keyword or type coercion in JS is not the ugliest thing ever in the history of Programming languages

Try python. Python's handling of this/self makes javasacript look like the most amazing thing ever.

Could you please explain? It's always very clear in Python what `self` refers to. Self is always an instance of the parent object of a method. Some classes can also have static class methods that can be called from the class itself instead of one of it's instances. Maybe that is where your confusion is arising?

It's not that it's confusing, rather it's unnecesarrely cumbersome because it's explicit and because you have to put it as an argument. Looking at the "most used words" [1] list of python, self is the #1 used word by far, occuring three times as often as the second most common word, "if". At this point, it's just a filler that bloats code and makes it less readable in many cases

    # so much text for such a little task
    def length(self):
        return math.sqrt(self.x*self.x + self.y*self.y + self.z*self.z)
        
    # better, but not quite there yet
    def length(self):
        return math.sqrt(self.x**2 + self.y**2 + self.z**2)
        
    # this would be perfect, but it's not allowed by python
    def length():
        return math.sqrt(x*x + y*y + z*z)

To be fair, javascript also forces you to explicitly specify "this" so there is no difference in that regard. What I find worse than that is that you have to specify self in the parameter list. Calling a function with 2 parameters but having to declare 3 doesn't make sense. The usuall reasoning is that "explit is always better than implicit" but I do not agree. We could take this philosophy all the way to explicitly defining all the global variables that may be used by the function in the parameter list, maybe even all the packages that this function is going to use. We don't do that for a good reason.

[1] https://anvaka.github.io/common-words/#?lang=py

Saying it's unnecessary is incorrect, and I don't agree about it being cumbersome either. On the first point, how would you disambiguate between reading from an attribute and reading from a global (or non-local) variable? How would you disambiguate between assigning to a variable and assigning to an attribute? You'd have to explicitly declare all your variables (making other things cumbersome instead) or accept that the semantics of your program could change during run time, depending on the contents of outer scopes (which I doubt you'd find an acceptable option). This is the main reason the 'with' statement is deprecated in JS. C++ can get away with implicit 'this' because it has static dispatch and all variables are explicitly declared anyway. But truth be told, I'd remove it from C++ too if I could. I like the clarity of knowing at call site whether something is a function or a method call without having to look it up. Paying for it the price of having type a few more characters has never bothered me.

And I somewhat like that I can name my 'self' argument whatever I like instead of having to resort to obtuse workarounds like 'var that = this;'. Not that I've ever had the need to take advantage of that possibility in Python, but it's comforting to know it's there.

In a short function that makes a lot of references to self, yeah I agree in can be a bit cumbersome. But as the functions get longer, I much prefer the explicit use of self. It makes the code far more readable as you can tell at a glance where a variable comes from.

> It's not that it's confusing, rather it's unnecesarrely cumbersome because it's explicit and because you have to put it as an argument.

I don't feel the same way. To each their own I guess.

Regarding your example, I don't see anything wrong with the second version. Anyone who reads the code will easily be able to tell what it does and where the variables come from. In your third example, how is anyone supposed to know whether or not `x`, `y`, and `z` are class variables or global variables? Kind of defeats the purpose of namespacing, I think.

> What I find worse than that is that you have to specify self in the parameter list.

This is really one of Python's implementation details. Methods can be bound or unbound. Without going into to much detail, just know that a bound method can be used as a regular function. Here is some code to illustrate what I mean:

    >>> class A():
    ...     def a(self):
    ...         print('hello')
    ... 
    >>> A
    <class '__main__.A'>
    >>> A.a
    <function A.a at 0x7fc4009381e0>
    >>> A.a()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: a() missing 1 required positional argument: 'self'
    >>> A().a()
    hello
    >>> b = A()
    >>> A.a(b)
    hello
    >>> class B():  
    ...     pass
    ... 
    >>> b = B()
    >>> A.a(b)
    hello
    >>> class B():
    ...     def a(self):
    ...       print('goodbye')       
    ... 
    >>> b = B()
    >>> A.a(b)
    hello
    >>> c = A()
    >>> B.a(c)
    goodbye

Self does not have to be the same class it's called on. It can be any class. However, if you try to access a class attribute that doesn't exist, you get an attribute error.

    >>> class C():
    ...     x = 10
    ...     def a(self):
    ...         print(self.x)
    ...
    >>> C.a()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: a() missing 1 required positional argument: 'self'
    >>> C().a()
    10
    >>> a = A()
    >>> a.a()
    hello
    >>> C.a(a)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 4, in a
    AttributeError: 'A' object has no attribute 'x'

Since bound methods need to behave like regular functions, it is improper to not pass the object instance to the function.

Class methods don't accept a "self" argument, though. In those cases, you call it cls.

I'm aware. The `self` vs `cls` thing is convention. You can call either argument whatever you want.

What do you mean? Could you give an example? I always regarded python self to be one of the cleanest ways to show that we have another parameter in a method.

are you joking, right? in javascript you cannot ever KNOW what this refers to (is the instance of a new Thing()? is null? is "window"? is something set with .bind()? is just "the left thing before the dot before the function"? is something else?

Does "this" work differently in JS as it does from Python or even C++?

Is it not always the object that owns the function currently being executed?

If the "this" is implicit, then how can you possibly know where the variable comes from?

Eh. Python and JavaScript are very similar at the language level. They each have warts and are more expressive in certain areas, but at a high level they have the same semantics and the exact same advantages and disadvantages.

this is only used with the new keyword. You can however program JS avoiding both new, prototype and this, by using "factory functions". Or avoid OOP structures altogether using a more functional paradigm.

>>this is only used with the new keyword

This so not true. "this" is much wider paradigm in JS.

If the new keyword is not used, "this" will point to the global scope. You do not however have to use the new keyword when creating the built in JS objects.

{} is new Object();

If you find "this" confusing you can and should avoid using it. JavaScript has many bad parts that some programmers love to use because it makes their code "elegant". It is however possible to write simple and easy to understand code by only using the good parts.

>>If the new keyword is not used, "this" will point to the global scope

This is entirely incorrect information, consider a simple example:

    function f(){console.log(this.a);}
    var o={a:"c"}
    f.call(o)

there is no "new" keyword involved, and "this" is not pointing to the global scope and there is a huge amount of other samples which I can show, but I won't. I don't have any problems with understanding "this" in JS. I just firmly believe that this is superb ugly stuff.

That is indeed ugly stuff. Thankfully you never have to use f.call(o)

I bet you never developed anything realistic with JS! The close neighbor of "call" called "apply" is a widely used tool.

Show me some code and I will refactor it for you.

Just for fun, why not..Let's take a look at the classic one:

    Math.hypot.apply(null, [1,1,3,3,4])

Try to refactor without using ES6's "spread" feature(Math.hypot(...[1,1,3,3,4]))

You've got an array, and want to "hypotenuse" it. Your code is fine, as it's pretty clear what it does. But for the sake of refactoring:

  const hypot = arrNum => Math.sqrt(arrNum.reduce((sum,n) => sum + n*n))

  hypot([1,1,3,3,4])

Although I would prefer:

  function hypot(arrNum) {
    for(var i=0, sum=0; i<arrNum.length; i++) sum += arrNum[i] * arrNum[i];
    return Math.sqrt(sum);
  }

I don't think it's a good solution because it performs the operation manually instead of calling the built-in Math.hypot method. This is the point - "apply" is a widely used technique, at least it used to be on pre-ES6 times.

Try C++ template metaprogramming or Java collections before generics.

use ES6, Babel, and ===

ES6's arrow function might help to avoid "this" problem in some scenarios, but it does make it any better. Type coercion is a lot more than == vs ===.

[] + [] === ""

Elegant... hmmmmm

[1,2,3].toString() === "1,2,3"

[].toString() === ""

It's only confusing to people who really don't know anything about the language.

this might be a better example

https://twitter.com/codinghorror/status/476826733576847360

Are you arguing that this is confusing to you and therefore not elegant, or are you arguing that this code compiles and that means it is not elegant?

Would you write that in production?

JavaScript is as elegant as a cat scratching his nails on a blackboard. it's a mongrel language without any whatsoever elegance. Taking your art metaphor further is like comparing the ceiling of the "cappella sistina" to a cut in a canvas.

3) Maybe a language don't need to be that "elegant", it's not required in all situations. I think I would prefer a "practical" language over "elegance" but like the appearance.

I think there's another way to look at this. Right now the DOM is exposed to the browser in a way that makes Javascript the most natural way to manipulate browser elements.

There is a movement towards a more elegant way of expressing UI, where functional languages and imperative languages with functional features can both be used, but these currently require often large and complicated frameworks or even comete language runtimes.

Ultimately these also require some kind of Javascript bridge which leads us back to it being central to web programming. You either use Javascript or you go to great lengths to hide it.

The solution, which is slowly emerging in a de-facto manner, is to expose to any chosen language whether implemented in Javascript, wasm, or some new JIT compiled bytecode with dynamic features, a transactional, IPC-based API for rendering, diffing, and merging web content.

JQuery inspired the selector APIs (querySelector*) which in turn improved the efficiency of, then mostly obviated, JQuery itself.

I imagine the same thing could happen with React-like frameworks and things like Elm.

There are sites written entirely in Flash and ActionScript, a platform that is now obsolete. Another attempt was Silverlight and XAML (and JavaScript), dead also. I am not sure the desire to abandon JS is shared by all.

Yes, and to be clear I am not calling on developers or browser makers to abandon JS.

I'm talking about an additional API that is more suitable to polyglot support in the browser and more in tune with how modern browser frameworks work.

JS would remain a first-class language, and users of libraries or frameworks such a React would have to make very few changes to their application if they had to make any at all. The difference is the new API used by React itself to render HTML elements would be faster with native support for diffing and batching updates. Less work would be performed in blocking script contexts or on UI threads with changes to content being essentially atomic.

A developer could decide to implement an ES6 module and use a new tag, <import module />, instead of <script>.

This tag would support JS, WASM, and a new Dynamic WASM with support for interpreted and dynamic languages like Python or Ruby or Clojure or Elm using a similar bytecode and syntax to WASM.

The <script> tag would not change and the window, navigator, and document objects and DOM APIs will be available as always.

The same would be true for Angular, Ember and even JQuery.

I'm pretty happy developing in TypeScript these days, it at the stage where its more than good enough for most tasks.

Just like the JVM is more than Java, JavaScript is the bytecode of the browser. There is plenty of languages which compile to JavaScript if you want a different style or expressiveness in your code. https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

How good the tooling is (maturity, source maps etc) for other transpiled languages may vary a lot but there is still a lot of choice. I'll be sticking to TypeScript for now.

    "There is plenty of languages which compile to JavaScript if you want a different style."

I hear this a lot, but when you actually look at the list, there is not much to choose from.

- Dart - not used outside of Google.

- CoffeeScript - people are leaving this for ES6+, does not provide anything other than nicer syntax.

- TypeScript/Flow - is just javascript + types. This is bad because it doesn't solve any of JavaScript problems and good at the same time because it is easy to introduce incrementally and there are 0 problems with interaction with plain JavaScript code). This seems to be good enough for most people, as you mention.

- Elm - Second most promising ATM but not mature enough, you still need to fall back to JS for lots of the browser API. You need to buy into the Elm world 100%, simple stuff like creating an element and using JS library which will modify that element still requires hacks (my info might be out of date, last time I worked on Elm project was ~4 months ago).

- Reason - Probably the most promising because Facebook backs it, but nowhere near production ready. At least it seemed to me last time I checked - no tutorials, even installation was not straightforward and required some consultation with GitHub issues.

- the rest is in the toy/abandoned/not mature enough territory.

There was another thing that CoffeeScript provides that I still missed a couple of years ago when moving to ES6/7 only projects. While ES6 provided a lot of conveniences from CS, like destructured params and a terser function syntax, it couldn't remove anything.

I've never intentionally used JS == comparisons in any code I've written for work, but I've still had to deal with code written by others that did. CoffeeScript eliminates the possibility entirely by only having a == operator, and it works like a JS ===. Similarly, CS won't let you leak a var to global scope by forgetting to declare. Every variable is local by default and if you don't want that, you've got to explicitly set window.someVar.

In short, compile to JS languages have the advantage of being able to eliminate foot guns rather than just tack on new features. ES2018 probably isn't going to get rid of any. Even extremely dangerous and mostly unused keywords like with will remain because of backwards compatibility concerns.

'use strict' solves the forgotten 'var' and dangerous 'with' by prohibiting these parts of language. Also if you are using ES2016+ you are most likely compiling your code with Babel (to have more backwards compatibility) it will turn on the strict mode on by default.

"use strict" will save you from some of the foot guns but not all of them. E.g. it still allows the double equal comparisons I mentioned above, which have been the source of some frustrating debugging sessions ever.

If you want a safe language on the front end, use Elm.

Are Scala and ClojureScript toys, abandoned or not mature enough?

- ClojureScript I forget and it is good alternative, but it doesn't seem to be on the rise either

- I have not seen anyone using ScalaJS

- These two are probably fine alternatives to do frontend for Clojure/Scala shops, but outside of these circles, they do not seem to have much traction.

You're wrong about Clojurescript. It's the most pragmatic and efficient language today that compile into JS. And it's definitely steadily growing.

There are also versions of ruby, python, even haskell, ocaml. Basically google any language you like and add compiled to javascript to your search terms.

Typescript is good, I also like the closure compiler. Both help enormously when a project gets beyond a handful of files. But there's still an onus on developers to actually structure their code and do some 'engineering'; a ball of string in any language is still a ball of string. Not js's fault.

I would say it has certainly become elegant in recent years.

I imagine instead of alternatives we will see a lot of things being compiled from X down to WebAssembly. I see Rust/Go/Haskell targeting WASM in the near future.

WebAssembly has a lot of potential, but I think JS will have its place for a long time to come as it always has on the web. It makes me laugh whenever I think I might be writing Java for the frontend again, but it could actually happen!

Asking if TypeScript is good enough is kind of an odd question, good enough for what exactly? If you meant web development it certainly has its use case, but I think the discussion around TS and Flow is still open.

Perhaps more elegant, but at the price of increasingly complicated tooling and complex ecosystem. The startup cost for a new user arriving into today's JS world is pretty high.

Rust already has preliminary wasm support.

That is awesome, thanks for letting me know!

Yes, front end development will move away from JS to statically typed languages in 5 years. The fact that JS doesn't have integers and had to invent monstrosities like Uint32Array objects just shows why you do need a sanely typed foundation.

Calling JS elegant is like calling a gnarled, slime monster dressed in pink clothes elegant. Ooooooh I have shiny lambdas! Makes me soooo pretty - I can cover my warts and dazzle programmers!

I don't think this will happen, we went from statically typed, to non-statically typed, to statically typed, to non-statically typed.

People just have different preferences and that's okay.

If we "move away" from Javascript, we also "move away" from being able to properly support and display much of the web in the future.

We can either discard the current web as obsolete and start over with a new, stricter or more elegant framework, or else support something alongside Javascript, which only compounds the problem when every new browser then has to support every web language, and older browsers can no longer run code written in the 'new' languages.

To say nothing of the likelihood that each language will have browser-specific implementations, so each language also gets its own unique ecosystem of frameworks and shims for cross-compatibility.

All this towards the same end of doing stuff with the DOM, AJAX and Canvas. Doing what you can already do in Javascript, despite its issues. Why? How does it help the end user?

Javascript may be bad, but the alternatives seem to be worse for everyone other than programmers who don't like Javascript.

WASM will become available on every major browser and there will be ways to backport the code to older browsers (i.e ASM.js or polyfilling). There are also multiple implementations but the community is not split into different ecosystems.

Why do you think this is not possible again?

I don't think it's impossible, I just think it's not worth the effort. Other languages won't add any functionality that javascript doesn't already provide, or that isn't already served by languages compiling to javascript. It only adds unnecessary complexity to an already messy ecosystem.

> Is TypeScript good enough?

Yes. Once you move to TS, it's inconvenient to move back to JS

> Will developers be open to alternatives?

I would like to see GoLang supported in the browser (natively, not transpiled). Go has some awesome potential that's probably being wasted by limiting it to systems programming. Before Go I might have said C#. However, sometimes I want my stuff to be strongly typed, and sometimes I want to keep it flexible to change types.

Do you really think Go is that good? I look at it as a very awkward language in many ways.

1. Go's got just... broken error handling. Please write a dozen if (err != nil) gates in a row and try not to mess up.

2. Go's principle concurrency primitive, channels, is actually very slow as per its implementation and is often avoided because of it.

3. #2 may be a blessing in disguise because working with large single-delivery channel pipelinesis actually quite awkward. Our normal go-to techniques of exception handling and trace debugging don't handle it well outside of very small contexts. 40 years of debuggers all focus on the call stack and Go smashes that.

4. Go's quite convenient for a small team banging out software but for a large team over a long period of time, we still don't have access to the versioning and build systems Google had that make a lack of good version control feasible.

5. Despite being a language all about I/O, Go brings no real new innovations in I/O to the table.

6. Go's developer mantra is at least as patronizing as Python's. Probably more so.

Go's kafkaesque error handling made me loathe writing code. No language has ever done that.

> Do you really think Go is that good?

Its not that good yet. It doesn't even have the capacity to replace my Python usage yet. What I miss is the community driven libraries/packages - including sci-computing libs. If Golang is supported in browser, things could change for it quickly.

Its not the stuff like error handling that irks me - atleast not in comparison to JS callbacks and promises. I think the error handling is necessary. In Go, you could always ignore errors with underscores. But then ignoring errors works great until it doesn't. :)

However, we want to bring something better to the web not something that is detrimental in hopes that thing itself becomes better.

Go is not a good fit.

> Go's principle concurrency primitive, channels, is actually very slow as per its implementation and is often avoided because of it.

I've only heard the opposite about it (only used Go on hobby project, so no first-hand knowledge). Can you please elaborate or give some links that discuss it?

> Go's developer mantra is at least as patronizing as Python's. Probably more so.

Are you referring to limiting developer's freedom?

Well channels use mutexes underneath and they are "slow". So slow in this case is very relative.

Go channels are slower than go mutexes for the same task set. See: http://www.jtolds.com/writing/2016/03/go-channels-are-bad-an...

They don't need to be. But using channels for message passing instead of actors makes performance difficult.

> 6. Go's developer mantra is at least as patronizing as Python's. Probably more so.

What do you mean by that?

One of Go's design principles is that "we're full of untalented junior programmers who wouldn't know what to do with fancy techniques anyways."

Sort of like Python's multi-decade insistence that Lambdas confuse people despite the fact that it's standard after massive popular demand even in Java.

It's quite insulting, if you ask me. Sort of like an elder telling a teen the power tools are off limits because they are "only 16 and not coordinated enough yet to use the table saw without losing a finger."

I would also like to know.

So typescript doesn't give you an escape hatch. To me Typescript feels like a poor mans Action Script.

Wondering how old you are.

Javascript has only been "a thing" in front-end development for about 10 years. Before that, it was sort of a joke.

IE used to (maybe still does?) support VBscript. It could support other languages also via ActiveX. I remember articles about how to use Python in the browser.

Javascript will fade from the web scene, just as Perl has, when a new generation comes along who will once again reinvent everything with new languages.

Google Maps was released in 2006, and it was not the first "single-page app". XmlHTTPRequest was invented at Microsoft for Outlook's browser-based client in 1999, and Mozilla had a compatible copy by 2000. The original iPhone was released in 2007 without 3rd party native apps or an App Store, pushing devs to build HTML5 apps instead. Even small consulting firms like the ones I worked at at the time we very interested in JS to "prevent screen flicker" (aka page reload in MBA speak).

I think it's a major stretch to say JS wasn't taken seriously 10 years ago.

I really suggest watching these talks for anyone who hasn't. The first especially gets at what kinds of issues javascript has, and what might happen to it.

https://www.destroyallsoftware.com/talks/the-birth-and-death...

https://www.destroyallsoftware.com/talks/wat

I think the better question is, "Will front end development ever move away from CSS?"

In all honesty though, with ES6/7 writing programs in Javascript is a joy. CSS still sucks...

Devs are certainly trying to make CSS not suck. It seems the number of CSS inline style, document.createElement('style'), etc libs are growing each month. Some library will hopefully hit the nail on the head for this problem in the coming years.

The first project I worked on where I was able to isolate all my styles by component was eye opening. It becomes less like CSS and more like Androids XML styling.

> "the number of CSS inline style, document.createElement('style')"

Can you expand? Which libraries, I know BEM hopes to isolate CSS styles to "components" by using strict CSS rules, but are you speaking of inline styles as they relate to JavaScript libraries like React?

I was referring to CSS-in-JS and what is coming out of it. https://speakerdeck.com/vjeux/react-css-in-js

Not all of them use inline styles and a lot are library agnostic. Here are just some of the ones I have played with, plenty more exist.

https://github.com/rofrischmann/fela

https://github.com/FormidableLabs/radium

https://github.com/Khan/aphrodite

https://github.com/threepointone/glamor

https://github.com/MicheleBertoli/css-in-js

https://github.com/styled-components/styled-components

https://github.com/css-modules/css-modules

https://github.com/cssinjs/jss

https://github.com/smyte/jsxstyle

https://github.com/rtsao/styletron

Dynamic styling with JavaScript seems to be the best approach, allowing the browser to interpret that opens the doors to multiple security vectors. Not that JavaScript / Cookies already don't. But there would be a lot more.

It's not just CSS that sucks, it's the whole, totally arbitrary, web UI stack.

Unlike with desktop apps, everybody pretty much builds everything in the UI for themselves, with the exception of a handful of primitive items (button, radio-button, text-field, etc) that people still re-implement anyway.

If there was a set of rich widgets to just take, configure and use in your JS app, like you can in Cocoa, Windows Forms, etc, it would be great. And no, React is not that.

Have you ever sat down and read the reasoning for why things are the way they are? Why the accessors can't / don't go traversing through it's parents and only goes down?

It feels like many people who argue against these things are only the ones using them not the ones developing them or actively interacting with the repercussions of those developments.

It's a completely different world when you're creating something and using something.

One person might use that thing vastly different than how you would and the repercussions of their implementation can do a lot of damage to others.

Something to keep in mind.

You say it as it is some huge mystery, but we've had good UI platforms for ages, that have been way better to work with than the web ui stack.

The web implementations doesn't follow some inherent constraints of UIs, they are designed this (bad) way because they need to work with the pile-up of hacks upon hacks, and design by committee that is the web stack.

JS, for example, is not bad because there were some great domain constraints -- it's bad because as it's creator says, he had a tight deadline to go create it, alone, in a couple of weeks -- and had a design spec to make it look like Java as much as possible too.

CSS is not bad because layout is inherently difficult. It's bad because it started like a pure styling solution, and all kinds of hacks were piled to make it useful for layout (abusing the floating functionality, which was not meant as a layout solution). It took 20+ years to get to CSS Flex and Grid layout -- features that have been in desktop UI libs since forever...

And if forms have seen any love from the beginning, we'd have things like inter-changable re-usable components 20+ years ago, without the BS that is Web Components and the extra hacks like Shadow Dom etc. But they didn't even bother to add a few standard widgets like calendar in all those decades.

> You say it as it is some huge mystery, but we've had good UI platforms for ages, that have been way better to work with than the web ui stack.

Not as broad reaching as JS/CSS/HTML.

> The web implementations doesn't follow some inherent constraints of UIs, they are designed this (bad) way because they need to work with the pile-up of hacks upon hacks, and design by committee that is the web stack.

They were made to fit the growing needs and have done remarkably so.

> JS, for example, is not bad because there were some great domain constraints -- it's bad because as it's creator says, he had a tight deadline to go create it, alone, in a couple of weeks -- and had a design spec to make it look like Java as much as possible too.

Doesn't make it bad. Made it lean, portable, ultimately an easy to use language. There have been many languages in the browser.

> CSS is not bad because layout is inherently difficult. It's bad because it started like a pure styling solution, and all kinds of hacks were piled to make it useful for layout (abusing the floating functionality, which was not meant as a layout solution). It took 20+ years to get to CSS Flex and Grid layout -- features that have been in desktop UI libs since forever...

Progressive enhancement is a large part of software engineering and doesn't make something bad. Users of software abusing the software doesn't make the software or implementation bad either, they simply are adopting to the situation they are in.

Yep, and the result of those libraries and implementations gave us what we have now across not just a single platform but multiple platforms and distribution models. Modern achievements.

> And if forms have seen any love from the beginning, we'd have things like inter-changable re-usable components 20+ years ago, without the BS that is Web Components and the extra hacks like Shadow Dom etc. But they didn't even bother to add a few standard widgets like calendar in all those decades.

Except, you can do those things, and that does exist. Just check out bootstrap v4 it has html5 calendar support, just off the top of my head.

Shadow dom was an experimental phase to improve performance, it worked out, taught a lot of engineers a lot about not just Javascript & DOM but the browser, it brought about a lot of beneficial tooling and lead to Native applications.

We had interchangeable components for a very long time, riding on bleeding edge doesn't change that fact.

Everytime I hear developers trash a language for this or that feature or more generally on its "elegance", it reminds me of the old debate people had over Mac being too controlling of what the user could do and PC with linux being the ultimate tool of freedom.

In the end what won?

The simplest, and the practical. With Linux inside it.

Thinking a new language will or should come and replace JS for frontend after it has been developed and continuously improved with the web for 20 years is just tiring. JavaScript has been polished, it is practical, it has a plethora of tools and ressources. Improve javascript if you want to improve things, stop creating new paradigm all the time. I am quite happy that ES6 proved that JavaScript could become a very modern language although it is not strongly typed, tools like flow are filling the gap for now.

I personally think Swift ans JavaScript are the most elegant language. And although I can see the beauty of functional programming - I dont see it being used widely or being very pratictal for frontend.

As for typescript, it is a very good formalisms but it is made better by the tools built around it. I think JavaScript could go there on its own, no use having two languages in the long run. Some key improvements it does need would be to formalize flow types, more integrated linear algebra tools (or C++ extensions like numpy/scipy), a way to transpile/compile to native apps that is more efficient than electron (although electron is the bomb), and that's it. The rest has to be the job of browser making companies to comply to new standards.

Developers always want to reinvent the wheel instead of submitting PRs and participating to the debate about the future of open projects as "participants". It's ok to "only" participate.

>it reminds me of the old debate people had over Mac being too controlling of what the user could do and PC with linux being the ultimate tool of freedom. In the end what won? The simplest, and the practical. With Linux inside it.

Not sure what you mean. But Linux hasn't made any inroads to the desktop, and the fact that Android runs Linux is irrelevant as it's just an implementation detail (nothing Unicy is exposed to the users).

What won is Windows (still) and OS X (4-5 times more popular than in 1999 when everybody predicted "Linux on the Desktop").

Maybe it's just because I'm used to it, but I would say it is an elegant language. Either way, it's always under development. And any problems with the syntax can be changed in a future version, easier solution than establishing a new front standard.

It also has NPM, React and other frameworks, V8. Any challenger has a lot to overcome before people will consider switching.

I doubt it. I think the opposite will happen: JS will become the defacto UI language for web, mobile, and desktop.

The ongoing effort to improve the language has hit some stumbling blocks and made some outright mistakes, but overall has improved the language significantly.

Competitors like Elm and Dart are certainly compelling, but I don't think they have enough weight to entice UI platforms to converge.

The major players seem to agree that incremental improvements are easier than getting a huge amount of diverse vendors to converge on an entirely new/different platform.

Honestly JavaScript is not so bad but I could see multiple things evolving web development pretty significantly.

1. WebAssembly is cool but can't currently replace JavaScript. Now if the standard could get in gear and go a bit faster and work towards being the Java Bytecode / MSIL of the web? Then there would be zero reason to NOT develop in whatever language you want that compiled down to that. Yeah there is transpiling to JavaScript but that is more of a hack than anything; if you have to debug in an environment without source maps then it sucks hard core the further away you are from JavaScript.

2. The separation of HTML, CSS and JavaScript kinda sucks. CSS can do a lot but not everything, your HTML structure needs to be a certain way for some CSS to work correctly so the two are tied far more together than in the past. I'd like to see something eventually combine the two because let's face it, beyond basic things I almost never see the "swap a stylesheet to make everything different". Seems more of a novelty than a practical thing in my opinion.

3. I think the upcoming web component standards are going to make module web development a ton easier but the standards have been moving at a SNAILS pace. Poylmer's polyfills are great but don't cover everything and is extra overhead. When browsers support these natively it's going to make things so much easier to create 1 component that can end up being used in any web application regardless of framework.

I think the upcoming web component standards are going to make module web development a ton easier but the standards have been moving at a SNAILS pace.

Yeah tho, I'd rather have them go slowly and do a good job, because we're going to be stuck with it for a long time.

I'd just like to see the footprint (storage, memory & performance) of JS/Electron et all apps to be reduced to the levels of applications written with traditionally compiled code.

I don't see anything on the horizon that would be a good JS replacement.

At the moment, frontend libraries like React, and the new ES6 features is the best we have.

WebAssembly will allow other languages to run in the browsers, but how it will work is still unclear.

The only other option I've heard of is Elm. I haven't used it, but many people claim that it might be a good JS replacement. Though I don't know if it offers enough of an advantage to cause everyone to switch. If anyone has more information or opinions - please share.

> Could Google or Mozilla build support for another language into their browsers while developers gradually move away from JS?

I recall a time when Mozilla was shipping Python until HTML5 kill it. HTML5 gave features front-end developers desperately needed whereas Python honestly did not.

> Will developers be open to alternatives?

If the alternatives are significantly better at solving their problems, sure. People are switching to React despite React seemingly going against the 20 year paradigm of programing web UIs. Why? Because the pattern works for many people (not all people).

> Will we finally standardize on a simpler set of tools and frameworks?

Do other languages have a simpler set of tools and frameworks, or they simply better at hiding the complexity from you? In my first programming class, we were shocked to see how a 2kb C source code file was turned into a 200kb executable file by the compiler.

I've worked at companies using Java and Scala where I spend my first two days just getting the code to run. Is that tooling really that much easier?

> Is TypeScript good enough?

TypeScript is just a superset of JavaScript that adds in types. If your only complaint about JavaScript is the lack of types, then sure.

I think the JavaScript world is going to get better and worse at the same time over the next five years. I'm certain that we have even more tooling (which many people complain about) around code quality. We aren't going to be just doing static analysis, we will have new machine learning libraries, written in JavaScript, to review code.

> I recall a time when Mozilla was shipping Python until HTML5 kill it. HTML5 gave features front-end developers desperately needed whereas Python honestly did not.

Mozilla never shipped python in its browser. There was an extension called PyXPCOM that allowed python access to XPCOM, which also had an associated variant of PyDOM. PyDOM was apparently never allowed for content (I'm going by https://developer.mozilla.org/en-US/docs/PyDOM), only for chrome. In any case, PyXPCOM was mostly used only by the Komodo IDE.

It seems unlikely. Modern JS tooling has gotten very powerful, and it's still improving.

Heck, even with WASM coming around, you need many external tools for building and deploying applications. If you're targeting the web you'll still need to be fully aware of its limitations as well as having a strategy for handling em. These problems won't get magical solutions all of sudden.

I'd be interested in hearing of some ways in which you believe tools and frameworks could be simplified, as well as your current complaints with the ecosystem.

It's important to understand that the JS world has many players, and different groups of people have vastly different requirements. For example, even if picking up Webpack takes a bit of tinkering first, once you have it in place it requires very little maintenance. If you're working on a larger web app, paying that price up front is well worth it, as you can tweak the config to easily handle most future problems and requirements.

Yes. We moved away from Fortran, Cobol, and Basic when something better came along. Eventually we'll move away from Javascript too. Maybe it will be a language that spits Javascript, maybe it will be a language that runs on Chrome and Firefox. Right now I don't know what that language will be, but I'm sure it'll arrive one day

> moved away from Fortran

Once in a blue moon I still have to hit up some damn Fortran because the latest badass optimization routine is cooked up by a crusty German. JavaScript is gonna be around for a minute, I'd wager.

We have, it's called TypeScript.

Or Dart... What ever happened with that?

Or ECMAScript 7 or 8 or 9...

Or maybe JS is like shell ("Web as the OS").

It'll happen, especially now that WebAssembly is getting rolled out, but not sure what is going to replace it. Things like C++ or Rust are still too cumbersome for a lot of front end development. Not sure what the replacement for JS will be, but something new is going to eventually take over.

It will, and wasm is part of that (though plain old compile-to-JS is too), but it won't be a fast transition, and it won't be all to one other option, and JS will be the main choice for many years to come; it's got lots of inertia.

There are plenty good languages today that compile to JS: Scala, OCaml, Clojure, just to name a few. And if you really like JS but want types, check out Facebook Flow, it's better than Typescript even though it's not as popular.

I fear a WebAssembly rise of Swift as the new Javascript running in iOS, WebAssembly and server environments. I tend to agree that ES6/7 is a more elegant option and more in the spirit of OSS these days, but the backing of Apple on Swift could lead our stacks that way (though not with anywhere near the permanence that JS has had). Pure conjecture, of course. Either way, I couldn't see webAssembly as a replacement for just page logic though. It would be replacing the whole front-end stack...

So far browsers hasn't found nothing better than Javascript. Beside it is grownig not only in browsers now. It seems that Javascript is required in 30% of the job offers now: https://jobsquery.it/jobs;tags=Javascript https://jobsquery.it/stats/language/group

Oh gosh, this thread is all purests...I hate es6, but it is kind of fun to watch people misuse the arrow syntax and then ask, so what does that do? Their response is almost 1000000% "oh this is how you write functions in JavaScript bro". That's when I laugh and write a named function and continue working smart instead of trendy winky face. Full disclosure I love JavaScript and will become a farmer rather than switch to another language!

Too many man hours into optimizing Javascript. I doubt it.

I think a realistic alternative will be transpilers. Say coding Clojure, Scala, etc.. and then it convert down to javascript.

Also from what I've seen so far Mozilla really love javascript. It continues to push forward with no real alternative. Also the creator of Javascript is working with them.

I love Mozilla but I wish they tackle on an alternative javascript, they're too busy with the wonderful looking Rust though. I can't blame them.

The creator of JavaScript stopped working there a few years ago. Now started a new browser company called Brave. The Brave browser is written entirely in JavaScript by the way

I seem to vaguely recall there was a few years were Mozilla was shipping Python as an alternative to JavaScript. I want to say that HTML5 was what killed Python in Mozilla. HTML5 gained huge traction that Python never got.

If someone remembers more clearly, please correct my cloudy memory.

That's why I like Clojure(script). It does not fight the language and the ecosystem. It's "hosted" - meaning that like a symbiotic organism it "latches" onto the host language and can fully reuse its features. It does not try to "reinvent" and fix what's not broken, yet at the same time liberates you from glaring awfulness. It enforces certain discipline to protect you from shooting yourself in the foot.

There is work on WebAssembly to add DOM support [1] but for now it is speculative. This is the main limiting factor since other languages have to use JS as a compile target instead of WASM if they want to interact with a web page.

[1] https://github.com/WebAssembly/design/blob/master/GC.md

If you focus on business apps/sites, you might only need "low-code" tools like outbrain and mendix, which combine domain level focus, mostly visual tools, and maybe some code. Those tools are starting to become pretty successful, and it seems some of the big cloud guys also go in that direction.

And who knows, maybe some of those companies will adapt their platform to fit consumers.

I don't believe we will ever move away from JavaScript. Remember GWT? It's Google's pseudo WebAssembly built at the height of Java's popularity. It compiles your Java code into JavaScript and optimize accordingly to each browser. A few companies bet heavily on this technology, Workday is one.

No, it did not catch on.

Consider how long php has been used on the backend, and it's only getting more popular, there's your answer.

Quick answer: no.

Unless there's a unified effort between major browsers to bring support for a new language we'll have to use js. And that seems highly unlikely (see dart for instance). However, you now have languages that compile to js, that start to satisfy most developer needs, as well as the sketchy evolution of js.

With ES6, the only thing I'm missing in Javascript is static typing. Other than that, it has become a very nice language. There are some ugly sides, as in every language, but for the most part you can simply opt out of using these parts.

You can't opt out of implicit type conversion.

I think this is one of the biggest issue Javascript have.

I think the Wat lighting talk really hone this fact in far more than I can.

https://www.destroyallsoftware.com/talks/wat

ES6 did some nice things but at the core the language was never meant to be code more than 100 lines or so of code.

You can tell when it didn't have module or package system in place from the get go. Also strict typing whether dynamic or static really goes along way in term of code maintainability especially more so when you're doing tons of lines of code.

So I guess this reply is to say you can't really opt out of Javascript's hideous wart of all imo.

> implicit type conversion

Yes, defenitely one of the biggest problems. However, after switching to === and never using == again, I've found that it's easy to avoid implicit conversions and I haven't had a problem with it in years. I totaly agree they should remove implicit conversions from javascript by yesterday, though.

> but at the core the language was never meant to be code more than 100 lines or so of code.

Lot's of things aren't meant to be used the way they are but things evolve.

I'm sure it will be different. Technology don't usually move upwards gradually. They jump and improve for years and jump again. So I can sense the jump is coming. But it won't be just a additional language on browsers.

Do you think java is elegant or do you think ocaml is elegant?

Google built Dart once as a alternative and it did not make it into the Browser.

Are JS frameworks not simple? I really want to know how you feel about Spring or Magento.

I really hope webassembly could introduce some desktop/mobile app development experience to the web.

I want to use an api, similar to Qt, to write webapp.

Working with Qt was detrimental to my mental health. Why does everybody like it so much ?

Those are strong emotions. What do you hate about it so much?

Cough cough https://www.webtoolkit.eu/wt

TypeScript and Dart are viable options for scripting. (Try it!)

Wasm modules will be viable options for processing-intensive tasks.

probably.

But it moved 'to' JS not long ago, so it will probably stay there for a while.

I mean, remember the Swing and Qt days, when you needed to wrangle the C++ or Java?

JS is a breeze compared to this.

I don't think JavaScript is the problem. It's not the best language, but by far it's also not the worst, and there are lots of alternative tools that keep you from having to touch it. Use Opal, or Coffees riot, or ClosureScript, or Elm, or whatever else is out there; there are dozens.

What is much more concerning is the dogmatic, hyper reliance on all-encompassing frameworks, with a commensurate scrabbling for these frameworks to only be made by large corporations. It used to be that you could start a side project on your own, working at a small company, with a decent work-life balance, and grow it into a jQuery or Underscore or Prototype.js and people would even thank you for it. Now, you get people questioning whether or not you should even be allowed to exist if you aren't an official project from Mozilla, Google, or Facebook.

Just because a large corporatiom makes a thing doesn't mean it's particularly good. We've all been complaining about how Google's brain-teaser style job interviews are only effective at keeping good programmers who aren't also autodidacts out of the company. Yet out of the other corner of our mouths, we assume anything they make is great just by virtue of them "only hiring the best". I'm sorry, Angular is a pile of garbage. And I mean the rewrite that was supposed to fix all the problems of the first version. Their official documentation's setup instructions are to clone an example repo and delete the parts you don't want. This isn't just unprofessional, it's infantilising. Or the alternative is to install yet another CLI tool for what should just be a front-end library. Every single place they use decorators--which are an experimental feature in TypeScript, so Google is building a core feature on unfinalized syntax--they could have been done with superclasses instead and just kept the whole project to one paradigm. But OOP isn't sexy anymore, and you can't get overqualified PhDs to work on business issues unless there is something to overcomplicate in there. They claim you can't get the live-reloading development server to work on Windows because of something Microsoft supposedly did to block it in January. That's funny. I have no problems with my build and dev tools, and I'm running on top of the same, exact Node ecosystem. But they don't actually explain anything or link to any issue, so there is no telling what they mean.

Don't be afraid to "reinvent the wheel", and stop complaining when others do. This search for "the one, true wheel" is what is killing us. Quit trying to take jobs with companies that expect you to know React and Ember. You don't have to learn everything that is out there, and you can stay on one thing for a while. Or you can even make your own things. Your worth as a developer is not in the tools you know today, it's in your ability to learn and solve problems.

Preach on preacher. This, this so this. Well said.

The thing with Javascript is that, although the language may suck, it is a great ecosystem and platform to build on. It's what Java always dreamed of: build once, run everywhere. Literally! (Well, except for Node, but mostly)

Don't think of Javascript as "the browser" since you've got browsers, Node, React Native, Electron, SmartTV, STB, Tizen, Xbox, PS, Wii, Switch (probably) etc.

If it was easy, Java was the closest thing we ever got to this sort of portability across platforms, except for web frontend and this is what killed it. Java also has a great ecosystem and platform, it's open source (well, kind of), backed by several big software companies and lacks most of the things those who hate Javascript has (i.e. static typing). If Sun/IBM released their own browser engine with Java, instead of those stupid Applets or letting Javascript be built, the world would be different today.

> But will we ever move away from it?

The sheer amount of money for this to be possible is unimaginable and I don't think anyone's budget would allow for this. Hell, Facebook decided to invest on React Native when they could have done other crazy stuff like launching their own browser with ObjectiveC support.

> Could Google or Mozilla build support for another language into their browsers while developers gradually move away from JS?

Their engines are open source, and if this was easy I'm sure as hell someone would already have <script src="text/brainfuck"> working. You're also forgetting about Opera here. Opera is big and although its browser is not on all PC's it's on almost lots of media devices out there. Except for LG, Samsung, Roku and Android, all SmartTVs ship with an Opera browser which is what's used to run YouTube, Hulu, Netflix, HBO, etc.

> Will developers be open to alternatives?

Sure, Dart had its time, and TypeScript is getting lots of traction right now. You also see people writing frontend code on .Net and Java.

> Will we finally standardize on a simpler set of tools and frameworks?

Although I understand the frustration Javascript may raise with its tools (grunt, gulp, bower, webpack, babel, react, angular, etc), I don't see other platforms any better. I'm sure most C#, Java, C++, C, iO developers can give you great examples of how those systems are also complex, with shared libraries, low quality tools, integration, system and API problems, etc. I've used many IDEs and build tools, but the level of fear I have of XCode of breaking is huge.

> Does WebAssembly solve this?

No. Although some crazy people may decide to port a UI toolkit (Qt? GTK? WxWidgets?) or write a new one, the complexities this introduces are not worth it, business wise. Also, I'm sure it will also bring its own subset of problems. I particularly see WebAssembly used for two things:

- Games. - Stuff you don't want people to mingle with: DRM, banking, cryptography, etc.

Building a CRUD SPA in WebAssembly would be, IMO, a very stupid decision.

> Is TypeScript good enough?

Well, I work with quite a lot of people doing Javascript doing lots of FE projects and there isn't a big interest on it right now. Actually, Angular2 has been removed from any future projects roadmaps and we're moving to a React focused one. Thing with TS (or any other transpiling tool) is that, now you have to fight with TS problems and Javascript problems.

What is elegant?

I hate transpilers and the added complexity and abstraction layer. I love ruby but i cant imagine to write ruby in smh like coffeescript or opal for frontend. JS is the necessary evil but i would never join a company that does everything in js (frontend,backend, desktop / mobileapps ) you either love jd or you hate it.

No.

yes

Reply on news.ycombinator.com