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.

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.

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?

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.

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

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

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.

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

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.

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

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.

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.

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

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...

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.

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.

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

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'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.

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.

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

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?

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

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.

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?

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.

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.

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

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 )

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.

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

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

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.

And the world keeps spinning.

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

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.

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

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.

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?"

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

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

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".

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.

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...

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

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).

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.

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

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"?

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.

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

    # 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)

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

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.

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

    >>> 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'

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?

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

{} 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.

This is entirely incorrect information, consider a simple example:

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

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

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

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

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

Elegant... hmmmmm

[].toString() === ""

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

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

Would you write that in production?

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.

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.

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."

- 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.

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.

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

- 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.

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.

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!

People just have different preferences and that's okay.

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.

Why do you think this is not possible again?

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.

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.

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. :)

Go is not a good fit.

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?

What do you mean by that?

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."

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.

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

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

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

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

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.

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?

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

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.

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.

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.

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.

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").

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

No, it did not catch on.

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.

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.

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.

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 want to use an api, similar to Qt, to write webapp.

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

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.

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.

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.