
Ask HN: Will front end development ever move away from JavaScript? - js-fiend
Developers have done some amazing things with JS, but I think everyone can agree its not the most elegant language.<p>I understand we are where we are because the its the only language supported by browsers. But will we ever move away from it?<p>Could Google or Mozilla build support for another language into their browsers while developers gradually move away from JS?<p>Will developers be open to alternatives? Will we finally standardize on a simpler set of tools and frameworks?<p>Does WebAssembly solve this? Is TypeScript good enough?
======
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.

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

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

~~~
graphememes
Well said, came to say this.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
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](https://anvaka.github.io/common-words/#?lang=py)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

~~~
Hurtak

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

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

\- Dart - not used outside of Google.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

People just have different preferences and that's okay.

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

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

------
ams6110
Wondering how old you are.

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

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

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

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

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

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

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

What do you mean by that?

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

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

[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

[https://www.destroyallsoftware.com/talks/wat](https://www.destroyallsoftware.com/talks/wat)

------
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](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/rofrischmann/fela)

[https://github.com/FormidableLabs/radium](https://github.com/FormidableLabs/radium)

[https://github.com/Khan/aphrodite](https://github.com/Khan/aphrodite)

[https://github.com/threepointone/glamor](https://github.com/threepointone/glamor)

[https://github.com/MicheleBertoli/css-in-
js](https://github.com/MicheleBertoli/css-in-js)

[https://github.com/styled-components/styled-
components](https://github.com/styled-components/styled-components)

[https://github.com/css-modules/css-modules](https://github.com/css-
modules/css-modules)

[https://github.com/cssinjs/jss](https://github.com/cssinjs/jss)

[https://github.com/smyte/jsxstyle](https://github.com/smyte/jsxstyle)

[https://github.com/rtsao/styletron](https://github.com/rtsao/styletron)

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

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

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

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

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

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

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

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

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

> Will developers be open to alternatives?

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

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

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

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

> Is TypeScript good enough?

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

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

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

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

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

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

~~~
cube00
We have, it's called TypeScript.

~~~
ubersoldat2k7
Or Dart... What ever happened with that?

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

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

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

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

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

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

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

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

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

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

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

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

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

No, it did not catch on.

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

------
ruipgil
Quick answer: no.

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

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

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

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

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

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

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

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

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

------
k__
probably.

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

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

JS is a breeze compared to this.

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

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

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

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

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

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

------
andreapaiola
What is elegant?

------
tommynicholas
No.

------
cammio
yes

