Do you mean something more like "I personally just want another option besides JavaScript"?
I personally am a huge proponent of pushing browsers towards the same specifications. JS is the de facto browser scripting language. It isn't broken (though lots of devs don't like it...) and it's only getting better. I personally love JS for basic web stuff, front-end libraries, AND Node as well. Javascript is only growing and becoming more robust. So why does it "need" competition?
If you see Google keynote part about WASM they show how to create a C++ program and compile it to web assembly. Basically all Dom manipulation is done in a pseudo-Javascript macro inside the C++ code
TLDR: The web does not need a new language, but instead a new runtime to address the weaknesses of the DOM. Crucially targeting this runtime should build upon and not abandon the best parts of web technologies (simplicity, ease of access).
I don't think JavaScript is really a bottleneck to the performance of most web applications and these modern VMs perform miracles in optimisation. Additionally the language is getting a lot of attention now and with ESLint and Prettier I find it expressive, flexible and pleasure to use.
If all JavaScript was magically rewritten to C++ overnight I am sceptical it would even make that much difference because the real problem or bottleneck in performance is the DOM (not a new or original observation).
The DOM was never designed with performance as a consideration and certainly not with rich web applications in mind. Avoiding excessive repaints and reflows, minimising the number of DOM nodes etc. are all still concerns no matter which library or language you use.
It is also harder for browser vendors to optimise because they must still be forgiving to all of the ambiguous/bad markup and CSS in the world. Compare this to modern JavaScript where the browser does not tolerate errors.
I don't think it will ever happen and would take years, but it would get the biggest win in performance if a replacement for the DOM (a new web runtime) were to be standardised. It is a hazy idea - and I imagine other people have had better thoughts - but it seems like the way to go is compilation...
Development would use familiar web technologies with a markup language and a stylesheet language (based on and familiar to HTML/CSS with optimisations).
There would then be a compilation step to convert markup and styling documents into standard binary package intended for execution by the (also standardised) web runtime. These could possibly also be transpiled to HTML/CSS for backwards compatibility.
HTTP 2 is a binary protocol already... so this would build on top of that as the browser would be executing the binary directly rather than parsing the HTML and building the DOM/CSS.
The main benefit of this approach is it bring the web up to the same level of responsiveness and performance as a native application by removing the bottlenecks associated with parsing and managing the DOM/CSSOM. A secondary benefit is it would remove the need to perform manual performance optimisations like inlining critical CSS and hacks like the PRPL (push, render, pre-cache, lazy load) pattern.
In some ways it would be taking us back to the plugin model - but unlike the plugins it would be an open standard governed by the w3c with an implementation test suite which could be run by all vendors.
To quote Sean Denny from earlier:
gone are the days of being able to view-source on a Web page and see how it works
This is a big concern and to address this the source documents must be accessible from the same location as the binary. There are a couple of possible ways this might be strongly encouraged:
Firstly have the servers (Ngnix, Apache Http, S3) perform the compilation as an implementation detail of hosting - thus requiring them to have access to the source files.
Secondly make crawlers (Google, Bing) require the source files or mark down sites which don't provide sources.
This idea does sound interesting. I do have a question though: when you do "view source" on the page, I assume it shows the updated HTML source, correct? So would the markup source have to be updated anyway in the browser, would markup viewing not include any updates that have been dynamically done to the page, or would there be no viewing of the markup (in your opinion)?
Also, this does make me want to look into DOM performance. For some reason, JS seems to always be blamed (and I'm also guilty of that). But it does also make sense that markup, which needs to be re-rendered with each update, could actually cause the performance issues.
I do have a question though: when you do "view source" on the page, I assume it shows the updated HTML source, correct? So would the markup source have to be updated anyway in the browser, would markup viewing not include any updates that have been dynamically done to the page, or would there be no viewing of the markup (in your opinion)?
The idea would be that upon opening developer tools the browser would fetch the source documents. I would envision this experience to be akin to how source maps function for LESS/SCSS/transpiled JavaScript - but for markup instead.
The browser would be running native (compiled) code - it wouldn't be parsing the markup, building the DOM etc. As such there would not be the concept of "generated source" as it exists today, but it would still be possible to map the rendered views back to the original (declarative) source documents.
Also, this does make me want to look into DOM performance. For some reason, JS seems to always be blamed (and I'm also guilty of that). But it does also make sense that markup, which needs to be re-rendered with each update, could actually cause the performance issues.
Definitely try profiling the layout and painting performance.
The perception of performance is far more likely in most cases to be layout related than any scripting.
Well this is happening already with WebAssembly, I'm not on top of the news when it comes to WA, but as long as you can produce ways to interop WA libraries between languages, it will be fine. For example let's say someone wrote a WA Lib on rust and I want to consume it in my C# App or Elm App (all of them are targeting the browser with WA) in my opinion there should be no hassle on doing so.
Why? well simply because the sole reason javascript has the vast amount of libraries and tools and such a great ecosystem is because everything is interoperable between it (yeah it's a sole language I get it).
But if we start doing WA and we can't have interoperation I think it will bring some harm into the web landscape and cause fragmentation, and niche positions along the industry, and the mainstream development may not be javascript but I believe it will settle down on a main language (resembling how today there is a lot Compile to javascript stuff)
Javascript is a really broken lang by design, it is used just because is the only option, just like VBA in Microsoft Office macros. I think a lot of people would choose another lang if they could.
Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
I generally hear things like 'javascript is a broken language by design' from the same devs who don't code in Javascript and still call it a 'toy' language as if this were still 2002. In 2018 Javascript is a rich ecosystem that can be used in many different ways and styles. It has frameworks that make static-typed proponents happy, you can write in an object-oriented, functional or procedural style, and you can set very clear standards for your team based on your team's preferences. It's really one of the most diverse, flexible, expressive languages in the market today. When I hear 'I don't like Javascript' I translate that to 'My experience has been with teams who use Javascript in a way that I don't like'
Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
And I just don't know that you can prove anything that you're saying. Would lots of C++ and Java devs choose something else for backend programming? Probably. Would lots of front-end programmers choose something else for the front-end? Probably not. Would people with extensive MEAN Stack experience choose something else for the full stack? I know I would if there were a good technical reason to do so, but in general, I would enjoy the benefits of a unified stack. Given that the question is 'does Javascript need competition on the front-end' my personal answer would be no, because fracturing the ecosystem is a bad thing (I lived and coded through the browser wars JScript/JavaScript/ECMAScript drama. I don't want to go back to writing the same code 3 times for different browsers)
So you like javascript for the full stack, lots of people does not but have no choice for the front end. Having options is always good so yes it needs competition.
Sorry i will not spend time talking about the specific poor design choices of js, there is a lot of information out there.
Honestly? No, I don't think it does. It's evolving so quickly and absorbing features from other languages, so I don't think there any technical advantage to writing in another language. Strong typing is basically a static analysis issue that doesn't require browser involvement and already has two good solutions (flow and TypeScript).
IMO, that's an argument in favour of the OP's point. In your mind, JS evolving is a good thing, so we don't need a language to compete with it. But there is another perspective that its evolution is a bad thing and we need an alternative that is small and stable. So, depending on what you prioritize, the JS changes are positive, or they are negative. Hence, it makes sense to decouple the browser from the language and treat it like a platform (ie if it was a VM, then you could tell it where to find the bytecode for your interpreter, and then you could ship code to it in any version of any interpreted language that you wanted -- or compile your language to its bytecode). Then old websites don't break, b/c they can link to the version of JS they were implemented against (exempting changes in the platform itself), and you don't have to wait for browser adoption to ship features, b/c nearly all features are built on the platform, not provided by the platform natively, so you can implement new features and ship them to the browser without depending on the browsers to implement them, and to implement them consistently.
Going against JS in the front-end is counter-productive... All options that worked out are JS derivatives transpiled into JS. And it produces code bloated with polyfills.
Unless we find a way to pre-load polyfills in some way, it's always going to be difficult to bring the whole runtime of a language into the browser at a fraction of second's notice...
Latest comments (40)
Interesting that both use the Google Closure compiler.
DART...
I think dart actually fits the bill very nicely...
My thought is...
Why?
Do you mean something more like "I personally just want another option besides JavaScript"?
I personally am a huge proponent of pushing browsers towards the same specifications. JS is the de facto browser scripting language. It isn't broken (though lots of devs don't like it...) and it's only getting better. I personally love JS for basic web stuff, front-end libraries, AND Node as well. Javascript is only growing and becoming more robust. So why does it "need" competition?
I think it'll be very interesting to see how existing and new languages that work with WebAssembly end up handling the DOM
If you see Google keynote part about WASM they show how to create a C++ program and compile it to web assembly. Basically all Dom manipulation is done in a pseudo-Javascript macro inside the C++ code
TLDR: The web does not need a new language, but instead a new runtime to address the weaknesses of the DOM. Crucially targeting this runtime should build upon and not abandon the best parts of web technologies (simplicity, ease of access).
I don't think JavaScript is really a bottleneck to the performance of most web applications and these modern VMs perform miracles in optimisation. Additionally the language is getting a lot of attention now and with ESLint and Prettier I find it expressive, flexible and pleasure to use.
If all JavaScript was magically rewritten to C++ overnight I am sceptical it would even make that much difference because the real problem or bottleneck in performance is the DOM (not a new or original observation).
The DOM was never designed with performance as a consideration and certainly not with rich web applications in mind. Avoiding excessive repaints and reflows, minimising the number of DOM nodes etc. are all still concerns no matter which library or language you use.
It is also harder for browser vendors to optimise because they must still be forgiving to all of the ambiguous/bad markup and CSS in the world. Compare this to modern JavaScript where the browser does not tolerate errors.
I don't think it will ever happen and would take years, but it would get the biggest win in performance if a replacement for the DOM (a new web runtime) were to be standardised. It is a hazy idea - and I imagine other people have had better thoughts - but it seems like the way to go is compilation...
The main benefit of this approach is it bring the web up to the same level of responsiveness and performance as a native application by removing the bottlenecks associated with parsing and managing the DOM/CSSOM. A secondary benefit is it would remove the need to perform manual performance optimisations like inlining critical CSS and hacks like the PRPL (push, render, pre-cache, lazy load) pattern.
In some ways it would be taking us back to the plugin model - but unlike the plugins it would be an open standard governed by the w3c with an implementation test suite which could be run by all vendors.
To quote Sean Denny from earlier:
This is a big concern and to address this the source documents must be accessible from the same location as the binary. There are a couple of possible ways this might be strongly encouraged:
I've been thinking what if browsers adapt Elm completely as a new JS specification. I think there is a chance but it's like 0.01% or higher?
This idea does sound interesting. I do have a question though: when you do "view source" on the page, I assume it shows the updated HTML source, correct? So would the markup source have to be updated anyway in the browser, would markup viewing not include any updates that have been dynamically done to the page, or would there be no viewing of the markup (in your opinion)?
Also, this does make me want to look into DOM performance. For some reason, JS seems to always be blamed (and I'm also guilty of that). But it does also make sense that markup, which needs to be re-rendered with each update, could actually cause the performance issues.
The idea would be that upon opening developer tools the browser would fetch the source documents. I would envision this experience to be akin to how source maps function for LESS/SCSS/transpiled JavaScript - but for markup instead.
The browser would be running native (compiled) code - it wouldn't be parsing the markup, building the DOM etc. As such there would not be the concept of "generated source" as it exists today, but it would still be possible to map the rendered views back to the original (declarative) source documents.
Definitely try profiling the layout and painting performance.
The perception of performance is far more likely in most cases to be layout related than any scripting.
Well this is happening already with WebAssembly, I'm not on top of the news when it comes to WA, but as long as you can produce ways to interop WA libraries between languages, it will be fine. For example let's say someone wrote a WA Lib on rust and I want to consume it in my C# App or Elm App (all of them are targeting the browser with WA) in my opinion there should be no hassle on doing so.
Why? well simply because the sole reason javascript has the vast amount of libraries and tools and such a great ecosystem is because everything is interoperable between it (yeah it's a sole language I get it).
But if we start doing WA and we can't have interoperation I think it will bring some harm into the web landscape and cause fragmentation, and niche positions along the industry, and the mainstream development may not be javascript but I believe it will settle down on a main language (resembling how today there is a lot Compile to javascript stuff)
Javascript is a really broken lang by design, it is used just because is the only option, just like VBA in Microsoft Office macros. I think a lot of people would choose another lang if they could.
I generally hear things like 'javascript is a broken language by design' from the same devs who don't code in Javascript and still call it a 'toy' language as if this were still 2002. In 2018 Javascript is a rich ecosystem that can be used in many different ways and styles. It has frameworks that make static-typed proponents happy, you can write in an object-oriented, functional or procedural style, and you can set very clear standards for your team based on your team's preferences. It's really one of the most diverse, flexible, expressive languages in the market today. When I hear 'I don't like Javascript' I translate that to 'My experience has been with teams who use Javascript in a way that I don't like'
As i said, given another option, lots of people would not choose javascript.
And I just don't know that you can prove anything that you're saying. Would lots of C++ and Java devs choose something else for backend programming? Probably. Would lots of front-end programmers choose something else for the front-end? Probably not. Would people with extensive MEAN Stack experience choose something else for the full stack? I know I would if there were a good technical reason to do so, but in general, I would enjoy the benefits of a unified stack. Given that the question is 'does Javascript need competition on the front-end' my personal answer would be no, because fracturing the ecosystem is a bad thing (I lived and coded through the browser wars JScript/JavaScript/ECMAScript drama. I don't want to go back to writing the same code 3 times for different browsers)
So you like javascript for the full stack, lots of people does not but have no choice for the front end. Having options is always good so yes it needs competition.
Sorry i will not spend time talking about the specific poor design choices of js, there is a lot of information out there.
um... no its not. that is the only response I can think of. Javascript is not "a really broken language"
I don't think so. Like CSS and HTML don't need a competitor.
All we need is more features and a more homogeneous support from all browsers
Honestly? No, I don't think it does. It's evolving so quickly and absorbing features from other languages, so I don't think there any technical advantage to writing in another language. Strong typing is basically a static analysis issue that doesn't require browser involvement and already has two good solutions (flow and TypeScript).
IMO, that's an argument in favour of the OP's point. In your mind, JS evolving is a good thing, so we don't need a language to compete with it. But there is another perspective that its evolution is a bad thing and we need an alternative that is small and stable. So, depending on what you prioritize, the JS changes are positive, or they are negative. Hence, it makes sense to decouple the browser from the language and treat it like a platform (ie if it was a VM, then you could tell it where to find the bytecode for your interpreter, and then you could ship code to it in any version of any interpreted language that you wanted -- or compile your language to its bytecode). Then old websites don't break, b/c they can link to the version of JS they were implemented against (exempting changes in the platform itself), and you don't have to wait for browser adoption to ship features, b/c nearly all features are built on the platform, not provided by the platform natively, so you can implement new features and ship them to the browser without depending on the browsers to implement them, and to implement them consistently.
Going against JS in the front-end is counter-productive... All options that worked out are JS derivatives transpiled into JS. And it produces code bloated with polyfills.
Unless we find a way to pre-load polyfills in some way, it's always going to be difficult to bring the whole runtime of a language into the browser at a fraction of second's notice...