HN Explorer

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

124 points by js-fiend ↗ HN
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?

244 comments

[ 7.6 ms ] story [ 499 ms ] thread
coreyp_1
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.

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

api
Try C++ template metaprogramming or Java collections before generics.
mschuetz
> 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.

krzyk
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.
_ZeD_
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?
Sohcahtoa82
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?

tastyham
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.
scriptkiddy
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?
StavrosK
Class methods don't accept a "self" argument, though. In those cases, you call it cls.
scriptkiddy
I'm aware. The `self` vs `cls` thing is convention. You can call either argument whatever you want.
mschuetz
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

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

Sohcahtoa82
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.
[deleted]
(comment deleted)
cdelsolar
use ES6, Babel, and ===
sAbakumoff
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 ===.
BinaryIdiot
> 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).

giomasce
The problem with type coercion is when it happens without you noticing it. You cannot "avoid" it...
BinaryIdiot
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.

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

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

[deleted]
(comment deleted)
kbp
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.
mazelife
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

lispm
Most Lisp compilers will warn about wrong number of parameters at compile-time. Lisp typically warns at runtime, too.
z3t4
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.
sAbakumoff
>>this is only used with the new keyword

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

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

sAbakumoff
>>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.
z3t4
That is indeed ugly stuff. Thankfully you never have to use f.call(o)
sAbakumoff
I bet you never developed anything realistic with JS! The close neighbor of "call" called "apply" is a widely used tool.
z3t4
Show me some code and I will refactor it for you.
sAbakumoff
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]))
z3t4
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);
  }
sAbakumoff
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.
js-fiend
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...

graphememes
Why do you believe the language is dysfunctional?
smonff
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.
tobyhinloopen
[] + [] === ""

Elegant... hmmmmm

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

[].toString() === ""

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

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

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

sanjeetsuhag
Working with Qt was detrimental to my mental health. Why does everybody like it so much ?
simplehuman
Those are strong emotions. What do you hate about it so much?
inostia
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...

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

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

vinnymac
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

[deleted]
(comment deleted)
graphememes
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.
coldtea
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.

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

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

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

StClaire
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
mabynogy
Or maybe JS is like shell ("Web as the OS").
santaclaus
> 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.

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

steveklabnik
Rust already has preliminary wasm support.
vinnymac
That is awesome, thanks for letting me know!
WillPostForFood
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.
rayalez
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.

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

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

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

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

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

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

GavinMcG
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.
kelvin0
I've used JS enough to find that it's more like a nuclear powered .50 cal Gatling gun.
golergka
> 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.

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

bruce_one
There are many popular dynamically typed languages.

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

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

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

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

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

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

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

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

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

z3t4
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.
watson
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.
erikpukinskis
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.

Illniyar
We write tests.

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

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

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

    [][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+ [])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()
jaredsohn
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.

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

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

smonff
Why would you ever write such a thing?
krapp
It's an effective way of obfuscating malware, for one thing.
kwhitefoot
Surely not. It would be easy to spot.
chc
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.
kwhitefoot
If it's hard to understand like that then I would be automatically suspicious of it.
CognitiveLens
You wouldn't. The argument is so straw-man that it verges on trolling.
coldtea
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...

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

chrisfosterelli
These same obfuscations exist in many, many other languages.
steego
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?

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

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

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

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

ng12
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.
geuis
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.
ng12
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.
StavrosK
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.

z3t4
everything is stupid if you dont understand it. JS is pretty good at not getting in your way.
coldtea
>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.

StavrosK
There is no "stupid" and "clever". There's only "consistent" and "inconsistent". JS isn't very consistent.
frogstomp19
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.
erikpukinskis
> 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.

djmashko2
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.
erikpukinskis
Many (most?) libraries are not built that way. There are plenty of libraries that use async in their exports.
jfaucett
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.
yomly
that's really interesting - would love to know more about your JS stack and your project structure?
[deleted]
(comment deleted)
z3t4
i wish i could upvote you 100 times.
doctorcroc
> It's still pretty standard to compile es6 down to at least es2015

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

dntrkv
Yeah, they are. People get confused because ES6 === ES2015, "ES7" === ES2016. I sometimes make the same mistake.
dorfsmay
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.

[deleted]
(comment deleted)
woah
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.
tracker1
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.

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

blueprint
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.
z3t4
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.
jondubois
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.

spraak
I do like how the prototype way makes it more clear that it's just a function. What about you?
coldtea
I find that an implementation detail that most people don't care about in their use of prototypes.
spraak
I don't follow
woah
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.
ben_jones
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.

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

woah
You can put //@flow at the top of your files and install a plugin for your editor and have typing in about 30 seconds.
devwastaken
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.

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

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

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

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

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

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

sergiotapia
Go's kafkaesque error handling made me loathe writing code. No language has ever done that.
smdz
> 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. :)

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

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

What do you mean by that?

smonff
I would also like to know.
KirinDave
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."

graphememes
So typescript doesn't give you an escape hatch. To me Typescript feels like a poor mans Action Script.
[deleted]
(comment deleted)
mgalka
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.

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

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

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

hasenj
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.
troymc
"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
Bahamut
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?"

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

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

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

jedikv
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.
raquo
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.
holydude
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.
[deleted]
(comment deleted)
tastyham
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.

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

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

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