The Future of JavaScript Will Be Less JavaScript
1–8 of 8 posts
Re: The Future of JavaScript Will Be Less JavaScript
#2For me the main point is WebAssembly. Javascript was the only option for the web (As the article notices you can compile/transpile to Javascript but this was adding more complexity for less gain).
With more options developers will use languages that better adapt their taste and needs. C++ can be highly optimized when creating WebAssembly code, C# and Java offer flexibility, Python and Groovy are easier to star to use, etc.
Javascript was used beyond it's own merits as a language. It was the only feasible door to pluguinless development in the web. WebAssembly will allow people to choose. And even that a lot of developer will still have Javascript as a first option, others will not, and the web development environment is going to deeply change.
Re: The Future of JavaScript Will Be Less JavaScript
#3For me the main point is WebAssembly. Javascript was the only option for the web (As the article notices you can compile/transpile to Javascript but this was adding more complexity for less gain). With more options developers will use languages that better adapt their taste and needs. C++ can be highly optimized when creating WebAssembly code, C# and Java offer flexibility, Python and Groovy are easier to star to use…
If javascript goes the ecosystem goes too.
In real applications we need to use social login, share, google maps, shopify buy SDK, S3, Azure speech API and so on. The javascript tools to access all of that are plain old ES5 at best. How will we use them from another language?
Libraries, too. Are we going to find ourselves writing our own custom dropdowns and datepickers in C++? Not to mention our own view update and state management libraries.
This is the reason there are next to none real world examples of web apps made in Elm. No communication with planet Earth.
Re: The Future of JavaScript Will Be Less JavaScript
#4I will be hanging around the next 60 years creating more JavaScript 1.5/ECMAScript 3 code, oh the horror.
Re: The Future of JavaScript Will Be Less JavaScript
#5I don't understand why the author sounds so excited about the premise of his article. Nor do I understand the fervor, in general, surrounding transpliers and the constantly-expanding JS toolchain. It seems people are too busy fawning over the latest JavaScript-adjacent tool to remember that the sole benefit of using said tools is basically to support browsers that don't yet support ES6. Yes, in doing so you are able to implement bleeding edge features that you couldn't otherwise, but this will not be the case once ES6 is fully adopted. Until then they are merely a necessity.
ES6 is JavaScript in its actualized form, and once fully adopted it should suffice for most developers unless you really want to implement bleeding edge ES7 tech. WASM is pretty cool, though I personally believe you have to be some kind of masochist to put yourself through the torture of building your web app in C++, unless said application would really benefit from the optimization factor.
Re: The Future of JavaScript Will Be Less JavaScript
#6For me the main point is WebAssembly. Javascript was the only option for the web (As the article notices you can compile/transpile to Javascript but this was adding more complexity for less gain). With more options developers will use languages that better adapt their taste and needs. C++ can be highly optimized when creating WebAssembly code, C# and Java offer flexibility, Python and Groovy are easier to star to use…
If javascript goes the ecosystem goes too. In real applications we need to use social login, share, google maps, shopify buy SDK, S3, Azure speech API and so on. The javascript tools to access all of that are plain old ES5 at best. How will we use them from another language? Libraries, too. Are we going to find ourselves writing our own custom dropdowns and datepickers in C++? Not to mention our own view update and s…
I second this. I will be hedging on JavaScript reigning supreme for the next 5-10 years
Re: The Future of JavaScript Will Be Less JavaScript
#7For me the main point is WebAssembly. Javascript was the only option for the web (As the article notices you can compile/transpile to Javascript but this was adding more complexity for less gain). With more options developers will use languages that better adapt their taste and needs. C++ can be highly optimized when creating WebAssembly code, C# and Java offer flexibility, Python and Groovy are easier to star to use…
If javascript goes the ecosystem goes too. In real applications we need to use social login, share, google maps, shopify buy SDK, S3, Azure speech API and so on. The javascript tools to access all of that are plain old ES5 at best. How will we use them from another language? Libraries, too. Are we going to find ourselves writing our own custom dropdowns and datepickers in C++? Not to mention our own view update and s…
Dunno, I am one of the suckers who learned AngularJS 1. May the whole JS ecosystem burn in hell? Don't mind switching wasm GUI frameworks if I can choose the language.
Re: The Future of JavaScript Will Be Less JavaScript
#8For me the main point is WebAssembly. Javascript was the only option for the web (As the article notices you can compile/transpile to Javascript but this was adding more complexity for less gain). With more options developers will use languages that better adapt their taste and needs. C++ can be highly optimized when creating WebAssembly code, C# and Java offer flexibility, Python and Groovy are easier to star to use…
If javascript goes the ecosystem goes too. In real applications we need to use social login, share, google maps, shopify buy SDK, S3, Azure speech API and so on. The javascript tools to access all of that are plain old ES5 at best. How will we use them from another language? Libraries, too. Are we going to find ourselves writing our own custom dropdowns and datepickers in C++? Not to mention our own view update and s…
> Libraries, too. Are we going to find ourselves writing our own custom dropdowns and datepickers in C++?
You are talking about C++. If a library exists, already exists an implementation for it in C++. Comparing Elm with C++ doesn't makes so much sense.
https://en.wikipedia.org/wiki/List_of_platform-independent_G...