JavaScript as default language and software stack

I disagree with some of your points. We tried writing a big web app in JavaScript, and we were extremely sad to see how hard it is to maintain JavaScript code. I like IDE support as well, and JavaScript provides terrible type inference, clear defined structures and other things needed to get it right. People argue that there is Definitely Typed and other things that provide type interfaces for libraries, but it kinda reminds me of header files in C&#x2F;C++, because it&#x27;s not defined <i>with</i> the code. We ended up using Dart because of it&#x27;s interesting take on Web Development (It doesn&#x27;t just give us the DOM APIs, it improves them and does the polyfilling and that stuff for us). We have been doing this for multiple years and have had a great success. Also, I have strong opinions about JavaScript, including that it looks like a monkey made it, and that someone literally took all the bad things from other languages and put them together. All in all, it&#x27;s a matter of preference. I&#x27;ve always gone against the crowd too (I think React is just meh, which is not popular), so there is that.

It&#x27;s a matter of opinion. If you get used to strongly typed languages, the idea of having your entire application in something barely typed like Javascript feels horrifying. I may be able to tolerate Javascript-with-a-typesystem (for instance, typescript), but raw JS? I don&#x27;t see why you&#x27;d ever want to do that.

&quot;This is not likely to change in the next couple of years while waters still settle. But generally the downsides of using JavaScript are fewer and fewer.&quot;<p>&quot;Give the community time, and they will come up with solutions to most things that are considered impossible today.&quot;<p>Okay, so JavaScript will be better&#x2F;awesome in the future. I still don&#x27;t see why my next project should be in JavaScript.<p>Every time I try to get into full Javascript, I come across so many things that feel half-baked that I decide to wait it out some more and go back to the tried-and-true tools.

&gt; Turns out, the amount of work that has gone into making JavaScript awesome surpasses every other language.<p>I still don&#x27;t see a Ruby on Rails, Symfony, Spring etc.-like framework for JavaScript in terms of maturity. Sure they are some frameworks, however most of them crash and burn when you want to upload a 1GB file or parse large JSON data arriving via HTTP... or try to extend it.<p>And I didn&#x27;t even mention NodeJS&#x27;s multiple loading and memory limit problem.

The hard part isn&#x27;t implementation or building; it&#x27;s requirements and design. If JavaScript as a default language and software stack gives me more time to design and gather requirements, then hell yes let&#x27;s do more of it. If it doesn&#x27;t, well it&#x27;s about as good as other languages and possibly more dangerous (yay for lack of types -_-)

C# dev here. Coming from statically typed language + dynamic support it just doesn&#x27;t make any sense to switch to full dynamic.

Not sure if trolling but... If not trolling, you should always learn how to evaluate what language will be the best tool for the job. If anyone&#x27;s choice of what language to use is based on a blog post that says &quot;You should use JS&quot; then language choice might be the least of your worries. I&#x27;m aware of core contributors of one of the hot new JS frameworks that are swapping out pieces of the back end JS tech for Golang because it makes sense! So this isn&#x27;t just me pulling nonsense out of a hat.<p>That said, should you learn JS? Hell. Yes!

It seems the author forgot to mention one area where server side (read NodeJS&#x2F;io.js) JavaScript really sucks: debugging.<p>It&#x27;s incredible slow to start a debugging session, making you feel miserable. See open issues like <a href="https:&#x2F;&#x2F;github.com&#x2F;nodejs&#x2F;node&#x2F;issues&#x2F;877" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nodejs&#x2F;node&#x2F;issues&#x2F;877</a><p>Instead of arguing in favor of JavaScript as the default language and software stack we should focus on a standard VM to use the language and libraries we prefer.

The IOT argument is specious and betrays a lack of understanding the challenges in connecting devices; specifically, the choice of controlling language begins at a lower level of the stack. New languages will arise, but they will be statically typed and speak protocols like LonWorks. Don&#x27;t confuse hobbyist kits that are well suited to JS for actual, useful-in-production programming stacks for IOT.

This starts with the blanket statement that you should always use javascript when starting a new web project and then follows up with two examples of using javascript in non-web environments.<p>While I agree that Javascript has matured a lot, and it has its place in the backend, I strongly disagree that it should always be used. We need to give thought about why we&#x27;re using it and make it a conscious choice. It can be that its a single language on the frontend and backend. It can be the abundance of developers. It can be it&#x27;s evented nature. But blindly making a choice without thought leads to a cargo cult mentality.<p>Additionally, there is no replacement to backend code. We may one day have good enough abstractions to allow us to mostly forget about the backend, but it will still be there. Bugs will arise where we need to understand how it works, and there will always be some sort of API (whether hidden or not) that we need to be mindful of. The web is a client-server system, and we can&#x27;t forget that.

Everybody&#x27;s fighting about why JS sucks... We know JS sucks. We&#x27;ve ALWAYS known JS sucks. It&#x27;s not a good language. It&#x27;s the new PHP. And it will <i>never</i> be good enough to make us all happy.<p>But you know what? It works... <i>well enough.</i> It&#x27;s fast... <i>enough.</i> It&#x27;s simple enough that mere mortals can use it. (Which is a strength, not a weakness!) And now, it works EVERYWHERE. You can get shit done with JS and having good JS experience means you can always find work. Maybe one day I&#x27;ll work on a magnum opus requiring a &quot;real&quot; language but for now, I&#x27;ll stick with what gets the work done. Because I&#x27;m not a rocket scientist, I&#x27;m more like a computer plumber. And I bet most of us fall into that category.<p>I don&#x27;t have to like it. But I do have to get stuff done. So I use JS.

I love when the satire just beats you over the head.

&gt; it will be the standard language for mobile apps.<p>For second-class mobile web apps, maybe. But for high-performance native mobile apps that don&#x27;t waste battery life on interpretation or JIT compilation, plus the overhead of bridging to the native APIs, a dynamically typed language like JavaScript is a bad fit. On iOS, Objective-C has always been compiled ahead-of-time to native code, and so is Swift. Android 5.0 introduced AOT compilation with the Android Runtime. And Windows Mobile has it too, with both C++&#x2F;CX and .NET Native. Conclusion: All three major mobile platforms prefer AOT compilation, which AFAIK isn&#x27;t feasible with JavaScript.

I do not agree.<p>1) Web Assembly will make the programming language you use on the front-end an open choice in web development (and, eventually, mobile). Javascript has very poor support for disciplined management of large codebases, and will eventually be abandoned for more sane languages.<p>2) Technologies like intercooler.js (<a href="http:&#x2F;&#x2F;intercoolerjs.org" rel="nofollow">http:&#x2F;&#x2F;intercoolerjs.org</a>) will minimize the amount of javascript necessary for the majority of web development (and, eventually, mobile) which will allow you to simply choose the best back end technology for your project without concern for matching a front-end language.

TypeScript is probably a better long-term programming tool and is aligned with future EMCA Script specifications.<p>Back-end I&#x27;m torn. I love Restify (Express without the web parts and just the api parts). But I also like ASP.NET Web API a lot too. They both have sizable benefits.<p>I think it&#x27;s less about language though than architecture. Microservices and user-driven UX is the future along with stakeholder-driven agile project management.

Ahah, nice joke :)

Hi, my name is __________ and I&#x27;m a mediocre programmer.<p>I&#x27;ve just kicked off the first 2 weeks of a significant project using only Javascript. This was entirely my own choice. I knew I&#x27;d have to write a lot of JS in the browser. So it made sense for me to bite the bullet and try to become as good as I could at JS. Equally I had to make a choice that I believed would work for my client in the medium-term, especially if I was not able to continue with the project at a future date.<p>This is my perspective (from the intellectual gutter): Javascript is hard to read and hard to reason about. It&#x27;s also hard to achieve a style that I am entirely comfortable with. It&#x27;s changing very fast. You learn things on the backend that are years from being universally useable on the frontend. Also: I seem to write <i>so many lines of code</i>.<p>That said I think I made the right choice. Ultimately the isomorphism argument is correct: at least I&#x27;m reasoning about the same kinds of things every day. I just came off 6 months of programming only Elixir and I could have used Phoenix for the backend, but I think I would have found the constant shifts in perspective very disruptive.<p>Which leads me to my main point: It isn&#x27;t about the language.<p>After all, multi-threaded programs in a more conventional language are also very hard to reason about. Shared data is hard to reason about. Immutable data is also hard to reason about (or rather its consequences are hard to reason about). Message passing can also become hard to reason about. Pointers are hard to reason about. Functional composition starts out simple and then...you guessed it: it gets hard to reason about. Once things get to a certain level of complexity, once you get using anything to its full potential you find the place in which it&#x27;s going to make your head hurt.<p>And for the plodders among us the answer is: libraries and patterns. Specifically, other people&#x27;s libraries and other people&#x27;s patterns.<p>So my recommendation to anyone that doesn&#x27;t like Javascript: if you don&#x27;t have to JS, don&#x27;t. If you do, at least enjoy the good things:<p>* Promises: One of those things you only appreciate by trying to do it <i>the other way</i>: <a href="http:&#x2F;&#x2F;callbackhell.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;callbackhell.com&#x2F;</a> * ES6: a lot of great features here. Makes an Elixirite feel almost at home: destructuring(pattern matching), arrow functions, generators and iterators * Libraries: Amazing number of libraries. I have barely had to code one really smart thing myself. * JSON: Think in JSON all day - now that&#x27;s nice. Serializing things to Lists, Maps, Tuples and what have you gets old.<p>And also read books:<p>* David Herman: Effective Javascript * Marijn Haverbeke: Eloquent Javascript * Daniel Parker: Javascript with Promises * Douglas Crockford: Javascript, The Good Parts (well actually I found this one hard to reason about :) )...

don&#x27;t waste your time doing thing big in javascript.