10 very good reasons to stop using JavaScript

JavaScript MVC frameworks are booming, but this post may change your mind about them. Before I explain to you the ten very good reasons to stop using JavaScript, I will first list a few popular JavaScript MVC frameworks:


  • We start with one of the most well known frameworks, Backbone.js. With Backbone, your data is represented in Models.
  • Second is Ember.js. Whilst Backbone is fairly low level, with a lot of code that you need to write yourself, such as code to update the view when model data changes, Ember does a lot of that work for you.
  • Next up is Google’s offering, the relatively new Angular.js. Angular takes a slightly different approach by doing data binding directly in your HTML.
  • Knockout.js is an MVVM (Model-View-View Model) framework written in pure JavaScript. MVVM frameworks are split into three parts.
  • Finally, I wanted to pick something different to all of the above and went with Batman.js, and not only because of the name.

Source: JavaScript MVC framework top 5

Now brace for the 10 very good reasons to stop using JavaScript:

1. JavaScript hurts your mobile visitors

Yes, you heard me right! Do you think that 600 Mhz CPU of the mobile device used to visit your site will execute the 10.000 lines of JavaScript you added (or linked) in your page? It does, but your visitors won’t wait for it. And how much memory do you think your cleverly AJAX loaded DOM objects take in the browser memory? Try using the Google Chrome Heap Profiler and double-check your findings. You need to because they are that high.

You may want to read Who Is Murdering PhoneGap? It’s jQuery Mobile as a reference.

2. JavaScript hurts your robustness

A single bug in your JavaScript can break the functionality of your entire website. Especially when you are relying on one of the above MVC frameworks. And you cannot test against future browser implementations of JavaScript, can you now? I feel JavaScript should only be used to enhance a website. If it is not available or it fails, it should degrade gracefully. This means that your website should still work, albeit less conveniently or pretty. Even better is the related concept of  progressive enhancement.

Oops. Firefox 18 broke my JavaScript-heavy website when no other version of FF did. This proves the point, right?

3. JavaScript hurts your security (and your privacy)

XSS and XSRF are the acronyms most web developers do not understand. Let’s keep it that way, because hackers and security consultants are making good money on them. No kidding, I think that knowledge about these subjects is much more important than your client-side script-fu. So if you are using JavaScript, but have no idea how to avoid these attacks, then please, for the sake of the web, stop using JavaScript (and start reading some security books). AJAX based content loading and form submission are often vulnerable to these kind of attacks. Also automated security tools often fail at detecting these issues, since they rely on HTML parsing, which is not possible when using AJAX.

Sure, you knew all about that, since you are very security aware. This video explaining XXXSS attacks is so awesome, that after seeing it you may be tempted to start using NoScript: a Firefox plugin that blocks all scripts on non-trusted sites.

4. JavaScript hurts your SEO

Yes, that is right, we are talking about Google’s almighty spiders that are not (good at) executing your JavaScript. This means that the JavaScript loaded parts of your website will not be indexed. This should not be a shock to you, since this is a well known fact. But it makes investing money in AdWords (for example, e-commerce) and using JavaScript a problematic combination. On the other hand you may be creating a website that is behind a pay-wall or a web application that requires authentication. In those cases the Google spider bots have no access anyway, so you don’t have to worry.

AJAX can make a site difficult for search engines to index if the technology is not implemented carefully. There are two main search engine issues around AJAX: making sure that search engine bots can see your content, and making sure they can see and follow your navigation.

This is not my opinion. I’m quoting Google’s advice on applying AJAX:

… view it in a text-only browser such as Lynx. Viewing a site as text-only can also help you identify other content which may be hard for Googlebot to see …

Try a text-only browser like “lynx” or “elinks” and you will be shocked by what Google will see!

5. JavaScript hurts your development time

Debugging JavaScripts can be a very tedious task. Especially when your JavaScript codebase is large and it is connected to many events on your DOM. It may be very hard to exactly find out how often and in what order events are happening. Also you have to rely on the debug tools provided by the browser. This is fine for a modern Firefox or Google Chrome, but how about old Internet Explorers? How many hours did you waste on that, honestly?

Testing cross-browser and cross-platform is expensive because of the numerous combinations possible. This form of testing is needed, because implementations differ, since there is no JavaScript standard.

6. JavaScript hurts your testing costs

Test driven development often relies on functional tests executed by test robots (much like Google’s spider bots). This form of automated testing relies on parsing the generated HTML. But JavaScript applications cannot be tested without the actual use of a browser, causing the testing to become very complicated and expensive. I have seen whole server farms being setup to automate the testing of a web application in different browsers on different operating systems. And the costs are not only in building such a setup, you should be mainly concerned about its maintenance costs.

The “Selenium Grid” approach is good but costly. It is well described in “Headless Functional Testing with Selenium and PhantomJS”.

7. JavaScript hurts your website performance

Lots of people are using AJAX to load multiple parts of their website in separate requests. Where you normally have one request for the HTML, the web server now handles multiple requests for HTML from the browser. That way the web browser is tricked into thinking that the website is loaded after the first request of HTML. This allows the visitor to look at something (which according to some UX guru’s is important), but it will slow down the actual loading of the website. It is even worse if you consider that this behavior will put a higher strain on your web server, resulting in slower serving of the page during peak hours (when it matters most).

Also interesting to read is that JavaScript may slow down your website due to poor JavaScript performance.

8. JavaScript hurts your software investment

Client-side technology is doomed to fail. We have seen Java applets fail. Then we’ve seen Flash fail (under suspicious circumstances). If history repeats itself (and it mostly does), JavaScript will fail as well, since it is the third in it’s kind. When exactly is still unsure, but investing a lot of money in a codebase built on such an uncertain platform seems like a huge risk to me.

9. JavaScript hurts your software architecture

The reason the above MVC frameworks are on the rise is easy, there is no good way to write substantial software in JavaScript. The lack of any traditional OOP structures drives programmers mad. MooTools tries to fill that gap by providing just that. A good try, but it is still a hack that is lacking a lot of core OOP principles. These things frustrate professional and experienced programmers, since they are simply not used to write in functional languages. How many programmers that have a professional education actually know how to do functional programming? And how many are good at it?

JavaScript is sexy describes very thoroughly, how to apply the OOP paradigm in a classless (prototype-based) scripting language.

10. JavaScript is not needed

Yes, you can create websites and applications without JavaScript. Everything that is possible in JavaScript can be done on the server side. But this is not how we roll, right? We need “new” and “cool” technology don’t we? Otherwise we (web developers) would be bored. But I ask you, can you look your boss straight in the eyes arguing that you “need JavaScript”? Is there a valid business case? Does this technology really pay off?

A lot of web development is done on applications that consist of lists, forms and buttons (administrative applications). Those applications definitely do not need JavaScript. People creating games or other real-time experiences, may consider themselves lucky, they are excepted.


Great! Not convinced? And you think I am a JavaScript hater? Well, I am not. I am the author of the extensive MinJS.org JavaScript MVC web framework.

NB: Thanks to Niko Schmuck I found an excellent post that explains in a much more subtle ways why progressive enhancement is important, read it! Please also read this excellent article from Chris Taylor on AngularJS and why not to use it.

104 thoughts on “10 very good reasons to stop using JavaScript”

  1. sorry to say, the worst leaseweb lab blog i’ve seen to date.

    starting with point 10. you can’t do everything serverside what javascript does. case in point something as simple as mouseover events.
    but also somethings like getting the user ip adres.

    futher more, this artikel is mostly based on frameworks. i personaly stay far away from frameworks. as this artikal mentions they have a huge overhead and hurt performance. just create you’re own javascript code as needed and don’t rely on a library of books where you only need 1 from.

  2. @Arnold: This may be the worst post in your opinion, but it certainly is the first one you replied to. Thank you for that. On your mouseover argument: reasonable actions, like changing color on mouse-over can be achieved using CSS. On the user IP address: Getting the IP address is only possible on the server side (not using JavaScript). But then again, why should we want such a thing? I am referring to the security argument.

  3. Thank you for this post. How about this statement: The amount of jQuery used in business websites is often directly proportial to the programmers lack of CSS knowledge (transitions, browser support, graceful degredation, media queries, etc.).

  4. “Client-side technology is doomed to fail”. Really?

    Applets and Flash have failed largely because both technologies require (buggy) plug-ins, and most functionality provided by each technology can now be implemented using standards-compliant JS/CSS. Notice the ‘JS’. Take that away, and you’ll actually go *back* to the situation where Flash/Java could provide stuff that the browser couldn’t, natively.

    So your argumentation on that point, IMO, is faulty.

    Regarding #2: “And you cannot test against future browser implementations of JavaScript, can you now?”. You also can’t test against future browser implementations of CSS and HTML, so should we stop using those two as well?

    Regarding #3: any non-well-implemented server side technology (PHP, anyone?) can hurt your security, too.

    Regarding #5: this is mostly an issue for non-experienced developers. I can’t for the likes of me remember spending much time getting JS code working properly cross-browser.

    Regarding #7: you’re describing a faulty client side setup as argument for why JS as a whole would make your website slow. Given a complex webpage where data can be loaded on-demand (for instance, only when a user selects a certain item will the data for the item be loaded), client side technology will actually speed up your website, since on-demand loading using AJAX (or similar technology) sure is a lot faster than an entire page reload (including resources).

    Regarding #9: OOP isn’t The Holy Grail. And your claim that “there is no good way to write substantial software in JavaScript” suggests to me that you’re just lacking experience. I’m having a great time developing complex, substantial webapplications using JS (both client side and server side), and development is much faster than what I used to develop with (Python/Django).

    Regarding #10: “Everything that is possible in JavaScript can be done on the server side”. Nonsense. Any form of user-interaction cannot be handled server-side, unless you are actually suggesting that — in case of a user filling in a form, for instance — each interaction requires a round trip to the server. This isn’t the 90’s anymore.

  5. Hay there…

    When I reached the part, when you said.. all the things that javascript can do, could be done with server side programing language, I immediately understand that you are not developer at all (sorry for the sharpness), how you supposed to work with events from server side?

    Also if no javascript, what else you suggesting to use? maybe pyton? or not use any client side language at all?

    Well, you said users don’t like to wait untill 1000 line will executed, I will say thet would not like when simple validation will take a page reload to say user that they typed existing username…

    How you planning to have cool features in your website, such es sliders, popups, calendars, dropdown menus (multi level) and hunderd of other things…

    About testing I will say shortly, if you have a little experience… the testing and bug finding/fixing is most primitive thing with javascript.

    About security, I would say it’s up to developer, not to language, so if you bad with it, you can left big security hole with php as well,

    so if you going to not use javascript, you websiites will be gloomy and uninteresting.


  6. @Maurits van der Schee : in CSS, you can’t change the color of an element when an other element is clicked… And how make a textarea that is saving the user input without reload the page, without AJAX and JavaScript ? It’s impossible just in HTML and CSS… If the JavaScript has been created, it’s because it can be used !

  7. I disagree with most of the points in this article, but #8 and #10 top them all.

    An applications like, for instance, google maps is a very clear example of why dynamic HTML and client side event processing are necessary. This cannot be replaced with server-side functionality and deliver the same ease of use and smoothness. At least, not in a browser-based online application over a HTTP like protocol.

    I am not saying javascript is the only language that could have delivered that. It just happened to be the language that got widely implemented that has all the features to make that possible.

    Most of the other points are not points against javascript, but against bad design in general.

  8. I agree with most points made in this post, and think many of the negative response were probably made by “Javascript developers” (“If we don’t develop the site using Javascript, what will the Javascript developers do?”). I have worked with most of the MVC frameworks mentioned, at the behest of clients, and have run into the same list of problems. When clients ask me to use one of these frameworks, I begin with the caveat: “We have used this framework, and are able to do what you’re asking. You’re going to have the following problems… ” I begin to explain all the problems listed in this post. The customer typically insists that we use the framework they’ve decided “everyone is using”, and we go on to make a product that works well for the most part (it often looks and feels great), but that takes a long time to develop and has footprint and performance issues related to the use of large Javascript libraries.

    I use Javascript all the time, along with my co-workers. I like a lot of things done in Javascript. I am a big fan of JQuery. I just think that the author has made some good points.

  9. Your post should instead have the title, “10 reasons to stop using JavaScript.” They are reasons, but they are not very good.
    Especially #9: your suggestion that OOP lacking in JavaScript implies that OOP is required for solid software architecture. That is incorrect. I use functional programming techniques and event-oriented code along with TDD for large JavaScript applications, and their architecture is more solid and successful than any server-side OOP code.

  10. Ah, didn’t know that. I’ll rewrite my node.js app using server-side technology.

    For those who wonder whether the post is spot on, try writing an IDE on the Web. Let’s start with having a text editor. , anyone?

    I’m sure Google Docs would benefit from converting all its JS. And Gmail for mobile, which loads parts of the app in JS as users activate them — for performance / memory reasons.

    No, it’s not just games.

  11. So what sites should stop using Javascript?

    These are mostly valid, well though out points, but they are presented pretty sensationally. I agree that a static, simple marketing site should probably not be written as an Angular app, for example. But I think the vast majority of sites and apps currently using these Javascript MVC frameworks are using them for very valid reasons. It just took me to the last sentence of point #10 to realize that I didn’t need to read this article.

  12. Let me just start by saying I truly agree with you. But you are saying the same as “Cars are bad for the environment, so STOP using cars!”. That is also a true statement but are cars the only reason the environment is hurt? And what is the alternative? Bikes? Boats?

    Let’s rephrase your title, instead of saying “stop using javascript” let’s say: “use javascript properly!”.

    1) JavaScript hurts your mobile visitors
    Indeed, having too much scripts on a page kills browser performance and indeed that applies more to mobile users because they simply have less computing power.
    But loading additional content asynchronously allows a mobile user to get to the content they want more quickly because, for example, the rest of the lay-out of the page doesn’t have to be reloaded and the response can be returned as a simple JSON object. This makes the experience much nicer! Now you say that loading content using JS kills SEO, i’ll come to that later. Of course things like animations or hover effects should be done using CSS. Computing the total price after you increase the number of items in your shopping cart, retrieving quick search results and auto completers and other things are examples of great improvements using JavaScript.
    So to conclude, too much of anything is always bad. When used properly mobile users can really benefit from some enhancements using JS.

    2) JavaScript hurts your robustness
    Again properly coding the enhancements makes sure not your entire page breaks when an error occurs.
    Funny thing here is that you are talking about progressive enhancement. That is still using JavaScript but in the proper way. When something is not supported, improve it and always fall back on native browser behaviours.

    3) JavaScript hurts your security (and your privacy)
    Again you’re saying that one technology is a cause of something else. XSS (Cross-site scripting) can be applied to websites with NO javascript at all, all you need is a form and a site that display’s everything you type without any escaping or filtering. This has nothing to do with JS at all but should be solved by properly escaping or filtering the visitor generated content and this is done server-side.

    4. JavaScript hurts your SEO
    Yet another example of you cutting corners. When used properly (see #1) loading content asynchronously greatly improves the experience of the user. For example you can load additional data when a user clicks a link. That link should be a REAL “a” element that links to a REAL page. With a simple check the server could see that the user supports JS (for example a parameter could be added dynamically to the href of the link like: href=”searchresults.php?page=2&ajax=true”) and then the server could return the next 10 results in the search result list without the extra lay-out etc.
    When a search engine sees the link it simply sees: href=”searchresults.php?page=2″ and visits the REAL page with a proper lay-out. This also makes sure that the link can be opened in a new tab so benefits everywhere.

    When a site is _dependent_ on JS, this hurts SEO but when used properly search engines will have a field day visiting your site.

    5) JavaScript hurts your development time
    If you’re code base is so complex then the problem is the person that created it. A decent programmer makes sure his code is properly testable and setup in such a way that errors can be easily debugged no matter what browser it runs in. This argument also says: don’t use PHP, or ASP or Java or whatever programming language is out there because if you don’t know how, debugging is hard.

    6) JavaScript hurts your testing costs
    See #5

    7) JavaScript hurts your website performance
    To much of anything is always a bad thing. Especially on mobile devices requests are costly. It takes more time to make the request than to actually download the content so multiple ajax calls to build a page are bad. But loading additional content on-demand can greatly improve the usability of a website.

    8) JavaScript hurts your software investment
    You’re comparing plug-in based technologies to a technology that is built-in in EVERY browser. These plug-ins fail because they are simply NOT accessible. JS is a complementary technology, it works on top of HTML (using the DOM) and therefore degrades gracefully to native behaviours. Please don’t compare apples and oranges.

    9) JavaScript hurts your software architecture
    Again with the comparing apples with oranges! For example PHP is not strict typed and Java is, therefore PHP is bad.. NO! It’s simply different! JavaScript is a different kind of programming language so implementing structures can be a little different but this doesn’t mean it’s a bad language?

    10) JavaScript is not needed
    You say:
    “Everything that is possible in JavaScript can be done on the server side.” – No it can’t, you can’t have direct interaction with your visitors.

    “We need “new” and “cool” technology don’t we? Otherwise we (web developers) would be bored.” – And what kind of argument is that? Never use ‘new’ technologies because.. it’s bad? How does that help the web forward?

    “But I ask you, can you look your boss straight in the eyes arguing that you “need JavaScript”?” – Can you sell to your clients that your entire page has to reload to simply show or hide a simple form element?

    “Is there a valid business case? Does this technology really pay off?” – I just gave you several examples how a client-side programming language can improve user experience, so YES.

    “Administrative applications definitely do not need JavaScript” – I can think of so many features a simple administrative application could have that would really improve them that I don’t know where to start. How about a simple + button that adds another row when inserting rows in a database. Or a check if a value matches a specific pattern or an autocompleter to select an employee from a list of thousands of employees. Are you really telling me that these are all doable server-side? Then I pity your clients.

    So I’m not convinced and I don’t think anyone is. You’re probably no JS hater but you really have chosen the wrong words to make your point. Your point which shouldn’t haven been to stop using JS but instead that too many websites implement JS the wrong way.


  13. I believe that JavaScript is a festering sore. The mere fact that supposedly conforming browsers can give widely different results for the same code make it an unreliable language. It’s lack of strong typing makes it an accident waiting to happen. It’s low level of support for object-oriented features means that nearly all object-oriented benefits are lost. The only salvation for those who want to create a rich user experience in the browser based on JavaScript is using libraries like JQuery. Admittedly, this can give relief to the individual programmer, who (potentially) can generate a rich user experience with very little originally coded JavaScript. Yet, this only pushes off the problems that I mentioned above to the library maintainers. While this is a practical short-term solution, it raises the risk of projects that use JavaScript by placing the issue of future application breakage into the hands of other parties.

    If we really want to create a rich user experience in the browser, I am convinced that we need a replacement for JavaScript. Or, perhaps we need a minimally more complex architecture where the jobs currently done with JavaScript are done with a small number of replacement tools (2 or 3 at most). Whatever tool or tools we choose, they have to give acceptably compatible results in all conforming browsers!

    I applaud Maurits for expressing a healthy list of practical reasons why JavaScript is problematic. Also, I agree with him that the short term solution is to use as little programmer-written JavaScript as possible. But, meanwhile, I am still waiting for someone to offer a replacement for JavaScript that I could use with a clear conscience.

    Best Regards,


  14. I suspect this whole post is some sort of trolling experiment, but just in case you’re actually serious, I have to assume you don’t have much experience working on high-volume, enterprise-sized web sites. Moving application features to the client-side can vastly improve the cachability of a complex and busy web page. Delivering the same JavaSript + CSS + HTML to every user, and rendering personalisation features purely on the client’s machine, for one example, can massively improve the actual and perceived speed of the site for the user: the fastest page delivery is the one that doesn’t have to requested because it’s already in the user’s cache. This would not be possible if your server had to crank out a whole new unique page for each and every page hit. State can be preserved in localstorage, and uncachable bits can be lazy-loaded with AJAX only when needed. You might have a point in specific cases (small, low traffic site, with a inexperienced developers — I note this page includes both jQuery and 2 additional JavaScript libraries) but your sweeping generalisations are just not true in many cases. And pointing out the fact that you are wrong is not the same as saying you are a “JavaScript hater.”

  15. “We need “new” and “cool” technology don’t we?”

    No we don’t. We need a technology that fits a purpose, everything else is prattle. JavaScript doesn’t suit you because of this and that ? Ok, fine, don’t use it. But you can’t throw to the ground what other have done simply because you don’t like the way they did.

    Ok, JavaScript has flaws, just like any other technology. If you think everything would be better just by deporting everything to the server side, think again.

  16. A whole load of nothing in this article. The majority of the points are either downright wrong (“JavaScript hurts your development time”) or are specific to CLIENT SIDE CODING – not JavaScript.

    the examples are mostly edge cases where one thing didn’t work once (like string.contains not being in FF18 – this could have easily been avoided with polyfills that check for functionality). This type of thing can happen in other languages as well, from what I’m getting is this is really about the environment and not the language.

  17. I am just curios are you are a programmer?
    Here you go I am contributing to you list.

    12. JavaScript is bad for the environment. (11 is already contributed)
    Web Developers use JS to create web applications and guess what them get paid for that.They spend the money to put petrol into their car which pollutes the environment => Javascirpt is bad.

  18. Reasons to stop using computers: paper is cheap, paper always “just works”, paper is mobile, paper is secure (you know where it is)
    Reasons to stop using paper: stone tablets are robust (they last literally ages)
    … and so on

  19. As a person who does JavaScript professionally every day, and whose specialty and focus is JavaScript – I could not agree with you more. I do think you should change the title to “client side JavaScript” though 😉

  20. This has—HAS—to be a giant troll attempt. There’s no way the author could be so stupid as to advocate for not having any sort of (preliminary) client-side validation, or not having any sort of ajax to load only updated fields, rather than re-posting the entire page.

    This seems like a 3-month-too-late April Fools attempt.

  21. this sentence “Everything that is possible in JavaScript can be done on the server side” is just a plain lie. I don’t mean to be disrespectful, but you should learn more about Javascript before going on risky accusations.

  22. First of all thanks for the game development exception, so glad I’m not wasting my time with JavaScript. Js is there to get some client-side magic done, so substituting that with server-side php sounds a little unconvincing, as many previous comments point out. That said I agree 100% with you, Js should not be. To make a website you have to know html, css, ajax, JavaScript and whatnot to get the client-side done. Why not have everything of the above in a single, one comprehensive easy to use object oriented programming language? We should have that. Then again we should have world peace too, right 🙂

  23. Oh My.

    I have been working with the “enterprise” .net for 20 years. Javascript does have its faults of course, but using a decent front end framework, a decent server and a decent database, that all use the same language and data format , all speaking similar Javascript / JSON is a real revelation.

    When you add the JS PaaS services and all the open source build deployment environments : well its a no brainer.

    I would encourage the author, to take one of the applications he runs, or supports, to rewrite it in a Java script way – maybe Angular / node and mongo, don’t really are, and then report.

    This is utter bullocks, and if it encourages people to keep the status quo its bad.

  24. Ahhh uuuu eeehheehehe hummmm, what can I say? I don’t agree with you man, sorry. Javascript is not useless, it’s like the loosen strain since IE 6 that held HTTP stateless troublesome alive. We learnt a lot, JS helped us, saved a few of us lives and I guess meanwhile you must’ve been writing COBOL or Fortran80 applications for the masses. Oh well, lets keep it like that, try and sell your mainframe icebergs and we keep chasing our fool mistakes continuously deploying web applications in the form of small pills. Hope to see you in heaven Bro.

  25. Only thing from this article that I accept is: JS performance is slow on some desktop browsers (IE).
    This is really big problem. Because unlike mobile application user expects full featured and fast application.

    About other things: I think that author is confused between 1) web-application and 2) web-site.
    Web-site without JS is OK, and I think nobody argues. But web-application without JS is very bad in various aspects (as developing, as user friendliness).

  26. This is coming from a ‘consumer’ – the biggest reason you shouldn’t use javascript? It’s fucking annoying – particularly the way ‘enterprise’ site owners are using it. I’m a desktop/laptop user (never mobile), and noscript is absolutely essential for security, because so many people use a giant pile of off-site scripts to make their website function. It’s wonderful that people are developing all this functionality like mouse-over events making buttons sparkle or whatever, but if I have to enable a dozen or so cryptically named sites just to make your site function, I’m not going to disable noscript. I’m just not going to use your site. Period.

    If you can’t spend the time and money making sure that your website works the way you want it to, and decide to trust outside vendors to develop your site’s functionality, I’m going to assume you don’t have a clue about how to make the transactions between them secure. No, I don’t care how professional your partners are, or how carefully you’ve vetted them. I can’t see that. There’s no way to convince me you have. And I don’t give two shits that it saves you bandwidth – if I can’t see clearly where my credit card data is being handled, it’s the equivalent to participating in an orgy. Sure, you might walk away without an STD, or your life may be ruined.

    Leaseweblabs, I applaud you for handling your own scripts. I enabled them knowing who to blame should this comment somehow be used to rob me blind 😉

  27. I have to disagree with you, for example javascript can be used for web acceleration, and the newer versions of google bots can read js now. Html pages are rendered in serial, but you can speedup that process with a javascript template system in the api (example: mustache)

  28. Although I agree some of the points, this article sucks. It is like “Stop using Internet cuz the Internet is not safe enough”. Or maybe the title is not right. It has to be “Reasons to use Javascripts properly” instead.

    This is the reason why the Browser version of Javascripts are made less powerful compared to other programming languages. This is the reason why WebGL is disabled by default on browsers. The entire TCP/IP, UDP, IPv4, IPv6 system we use today is not secure. Don’t just blame Javascripts cuz it has got nothing to do with just Javascripts. There is no such thing, bullet proof security. The easiest and the best thing you can do is make your websites less likely to be attacked.

    Imagine how vulnerable it would be if you could use other programming languages like Lua, C++, PHP, C#, Go etc instead of Javascripts.

  29. Uh, for all you “developers” who are defending JS, keep in mind that most, if not all, of the author’s points are correct. As both a developer and an user, I have all but stopped using the most popular sites (e.g., google) preciecely because of thier UNNECESSSARY insistance on using JS.

    Yes, there are things that can only be accomplished via JS, but those things should be the USER’s choice, not yours. If you can’t build a functioning website without JS, then don’t try to sell me that you actually know what you’re doing.

  30. I cannot believe that I am read this. If I tell in my company that we are going to do everything server side, I will get a kick in the bum so hard I will land in the moon. Learn JS and stop moaning, you cannot go to the server for each trivial transition.

  31. Dude. JavaScript is bad. Very bad. But I’m pretty sure you have no idea what you’re talking about. Doing everything JS does in CSS? Yea? Have you ever programmed a single line of code? Like seriously, what’s the point of your posting? What are you going to use instead of JavaScript to do implement any algorithms?

  32. This blog/page/post proves that the web is full of crap. And it proves that job titles, whether or not they are self-granted, do not have to mean a thing. I’ve never seen such nonsense.

  33. Cannot agree more with Frank.
    An apology post to close this sad thread is recommended.
    I would also fire the blogger, no matter the title.


  34. All of this is pure non-sense and you know it.

    “Javascript hurts” when it’s not properly implemented, period. Just like any other technology or, in this case, language. The moment the web stops using javascript, it means a newer protocol would have been implemented and everyone would have stopped using browsers and started using something else. This is a “chicken and egg” issue. Sorry but, with this assumptions you’ve made, you’re just making fool of yourself …

  35. This article seems to make the assumption that you will do everything in JS, or everything in CSS, or everything on server side. A good user experience will involved a smooth flow of all three. Some (not 1000 lines+) of JS, some CSS for styling, some server side support for heavy processing/db work. Loading you entire app into JS is stupid, but ignoring the features it provides is equally so. So you have 20 to 30 lines of JS code… so what… As long as the app functions equally well without the JS code, then when someone turns off their JS, they lose some slickness and a few bells and whistles. Their choice.

  36. This is an excellent blog post. As a user, I’m sick of having client-side scripts crammed down my throat. As a webmaster, I know that Javascript is not necessary and often counterproductive. As an IT professional, I know that the whole concept of client-side scripting is dangerous and doomed to fail. It’s long past time that people just started saying “no” to scripts. Internet will never be safe as long as users have to let every web site they may happen to use run whatever code the webmaster thinks is necessary on the user’s computer. It’s just a matter of web developers improving their HTML skills instead of relying of a concept that already is a proven failure.

  37. This is quite possibly the dumbest post I’ve ever read. It is 2014, almost 2015, the server is dead and the client reigns supreme. Any developer who’s current knows this. It appears the author has been living under a rock and still builds websites using the same technologies we used in the 90s.


    Why is it every fscking website requires Google scripting? – FSCK OFF.

    I would rather cancel my ISP connection than allow Google to run scripts on my machine – FSCK OFF

    Oh, And I am serious, why the fsck would I want to allow the OMNIPOTENT GOOGLE any access to my machine? – FSCK OFF

    Google.com / Google.co.uk / Googelapis.com / gstatic.com / google-analytics.com / googleadservices.com / googletagmanager.com – FSCK OFF

  39. I like how everyone is claiming you’re not a developer just because you don’t like JavaScript. Awfully inflammatory and juvenile in my opinion.

    I agree with most of the points you made. Personally, I feel like JavaScript is heavily overused on the Internet. Most websites have no real use for it. Kind of like the flash days o’ old with “buffering” or “loading” bars on the website. If your website contains static content, it doesn’t need to be that heavy. Pretty shine is nice, but there’s a line between tasteful shine and a “Boyd’s toast” style websites (http://theoatmeal.com/comics/design_hell).

    However, I think a distinction should be made here (this is where I disagree a bit). I think JavaScript has its place (though I still hate JavaScript), and that is in the case of sites like Google documents, web-based games, and generally browser-based applications. Those for the most part almost mandate the use of a client side language to gain the functionality they need yet server side processing doesn’t offer. However, I think people’s definition of a “browser-based application” is far too blurry, hence JavaScript’s heavy overuse.

    I think a third tier of website needs to be thrown in here, amongst [mostly] static content and browser-based applications, and that is static websites that use JavaScript for content augmentation. By that, I mean sites who’s primary content body is sent with the initial request (mitigates the SEO argument), but use JavaScript to make the page slightly more dynamic. For example, that might be a contact form with dynamically hiding/showing text boxes based on drop-down selection change events for a contact form. The content is all still there (albeit hidden), so search engines can still index, yet the client side isn’t sending and receiving for data on the server as things happen.

    Putting a technology in production (testing is a whole other matter) just because it’s cool is not often wise, scalable, supportable, cost effective, or “future oriented” (see what I did with that buzzword there?). Take a look at NoSQL for instance. It has its application, but it’s not nearly as broad as people originally used it for its early fad days. As time passed, people realized there are uses for NoSQL databases, and there is are uses for relational databases, and those are often not the same. I think JavaScript is similar. It’s useful, it just shouldn’t be used nearly as much. I think much of the time it’s a sledgehammer for a thumbtack kind of situation.

  40. This site, a WordPress blog, is using jQuery. The click trackers for the ads on this site us JS. Akismet, which you use for spam, uses JS. You’re a PHP fanatic running a PHP-based CMS, and you’ve written a post on a page that loads 7 separate scripts (and one inline) complaining about JS.

    But that’s none of my business.

    Nice clickbait, btw.

  41. Heroic action Kermit. I’m sure it must takes quite some guts to anonymously dismiss an article as clickbait without any arguments.

    IMHO the rage in the comments prove that teh author has made a good point. It is fueled by discomfort, because the arguments make sense.

    I enjoyed the article. Ignore the negativity and please keep writing!

  42. #1. 10,000 lines of JavaScript is ~60K, and not all lines are created equal. Perhaps the author’s understanding of JS algorithms and design patterns is incomplete. Angular 1.x excluded – they stink at memory management and performance in general.

    #2. “A single bug in your JavaScript can break the functionality of your entire website. Especially when you are relying on one of the above MVC frameworks.” Well-authored MV libraries (not frameworks, technically) are thoroughly tested and minimize these kinds of errors. But, to your point, a single bug in ANY piece of code can break a website. Next.

    #3. Blaming JS noobs’ security mistakes on JS itself is bad form.

    #4. Granted, but easily fixed. There are a zillion drop-in search engine fixes for client-side content loading for every server-side language imaginable.

    #5. “Debugging JavaScripts can be a very tedious task.” Unlike compiling, which is enjoyable and zippy. Seriously though, you can’t cherry pick your arguments. If you’re going to bring JS libraries into the conversation, what about the numerous unit testing environments and their associated workflows? Also, what about the absolutely brilliant debugging tools packaged with today’s browsers? JS has proven to scale well and, in the hands of a competent developer, be readily traceable.

    #6. “JS can only be tested using a browser” FALSE. This is so false. There are plenty of node specrunners. But to the greater point: imagine that – actually testing something in the environment that it is intended to run in, on the OSs it supports? Even if your wildest dreams come true and all JS disappears, you still need to test your html and css across browsers and OSs.

    #7. Well-authored JavaScript in coordination with smart APIs and architecture vastly improve performance and UX. Poorly-written JS and/or terrible architecture vastly degrade performance and UX. Just like every other application known to man.

    #8: comparing JavaScript to third-party browser plugins. Not sure if the author’s ignorance is willful here.

    #9. “The lack of any traditional OOP structures…” again, an ignorant statement. There is not a lack of OOP structures, there is simply a subset of them, to go along with the numerous functional programming design patterns that are available to the developer. In short: there is no shortage of design patterns in JS. I find it interesting that the author chose to name Backbone, and completely ignore Backbone’s reliance on OOP structures.

    #10. 1999 called, they want their web development philosophy back. I mean, we’re supposed to take this seriously: “Everything that is possible in JavaScript can be done on the server side.”

  43. with node.js everything in client and server side done with well, i think should write article 100 reason do not stop using javascript

  44. I need you to write me a single page application to manage my human resources department without resorting to page refreshes. I will pay you 1,000,000 dollars so long as you don’t resort to any JavaScript.

  45. Really mate. Nothing personal, but this post is total bullshit. Are you living in the past?

  46. @jaime: I think we are building single page applications for decades. We used to call them Java applets or Flash games. They did not rely on page refreshes either. Macromedia (later Adobe) was trying to get Flash to the corporate level with the Flex Builder and their mxml form language. Until Apple killed them… so sad.

  47. Thanks Maurits, for a very insightful article!

    To my surprise, there are some people who are finally waking up to this idea – but there is still an ever-growing army of lemmings who bristle at any suggestion that the javascript “Web 2.0 richness” has any flaws and that the only pie in the sky at the end of this rainbow is a plate of disgusting, cold spaghetti that some coder couldn’t keep down…. but I digress.

    I started coding HTML sites before javascript was born and remember how fast the internet used to be – even on weak hardware, by modern standards …

    And don’t get me started on Flash – more lemming madness, running off the cliff into the darkness of an SEO black hole. Being a musician, I am always amazed when I query a famous name and, instead of finding the ‘official’ web site, it is usually down the page, hidden behind a curtain of Flash, ready to blast music at you after it loads, even though your baby is sleeping in the same room .

    Oh but, wait, the madness gets worse still: apps

    On a web site, at least the user can view source, if only to reach for the barf-bag when they see what is actually under the hood.
    But now, the latest trend is away from even presenting the user any option of clicking away from a web site: just get them to install a ‘cool’ app that only serves up what you want them to see: AHA – CAPTURE, KA-CHING!

    Until the party ends.

  48. Regardless of the pros and cons of using JS, for me JS is necessary if you want a browser to feel like it is a rich application.

    Somewhere along the line the browser won through as how to deploy applications. If we wish to have rich applications runable without installing anything locally this currently means using a browser and the only way to achieve that without plugins is JS.

    Why browsers remain the first choice might be a bit outdated. Corporate IT policy that forbids installing software and the costs of re-deploying updates to that software were probably prime reasons why the browser offered a great cost saving, but with applications now able to self update from a single source (Chrome, tablet Apps etc) deployment and install over the web seems a better direction for really good applications rather than browser apps that either provide a poor lowest common denominator or expose themselves to security issues whilst trying to achieve richness.

    Many if the points given are broadly true – we just refuse to accept that the road we are travelling down (must use browser) is not the best option if you want the best user experience. Non-browser and web services would provide a much better experience at the cost of needing to install it to use it.

  49. I truely like javascript when it’s well-written.

    Since some years ago, I try not to use jQuery or Bootstrap actions when developing, and I focus more on vanilla JS, and if browser compatibility becomes an issue, I simply switch to a server-side solution. I mostly use jQuery for powerful AJAX requests, and “foreach” loops. So I really make a compromise between JS and no-JS.

    BUT, try to recreate a fast and powerful “Google Maps”-like application without any line of JS, and I’ll give you some reward.

  50. I can’t think of a better way to create a lightbox image gallery than with JavaScript. I’m not sure if this post was meant to be satirical but I’d like to think it at least partially is.

    I personally have not used any frameworks as of yet, though I plan to learn one soon. I would need to if I want to get hired anywhere. The only thing I’ve used as far as libraries and frame works is jQuery and it’s just totally necessary to me to keep things simple, rather than rewriting a headache.

  51. @author, @Greg, but exactly. How fast the Internet used to be.
    And taken oneself as the user – whatever takes longer than a super-short load – I leave the page with no return.
    JS? Turned off (no-script etc.) .. and it’s _that_ quick, again. Besides; security, of course. Being programmer myself; I don’t trust anyone producing a program. _and a JS_ is executed _on my machine_ .. oh; no. Really, not. My machine is mine; only.

    “changing a color” lovely, kindergarten hm. an argument, indeed, .. however, I favor speed. And security. JS will be off. – CHECK THE STATs folks. 10% of users are using no-script and therelike .. without JS, it was and is possible. “changing a color” .. “the feeling of rich apps” .. lovely. good luck folks
    and thanks the author.

  52. The article raises some decent points, but obviously javascript has its place. Try creating rich UI without javascript – you simply cannot do it.

    The web is ready for fully functional applications and javascript is required to do this. If you disagree, please suggest an alternative.

  53. This has got to be one of the most ridiculous blog posts on web dev I’ve ever encountered. What to use on the client side if not Javascript? Sure, some devs use Javascript where CSS could be used instead, but beyond those very very basic things, there’s literally no option, and that is only developer error and isn’t an inherent flaw in the language. If you are suggesting that a round trip should be made to the server with every interaction that Javascript would handle otherwise, then that is absolutely ludicrous.

    The author of this post obviously has zero experience developing feature and UI rich web applications. Turn back now if you are reading this.

  54. It seems that author realized how wrong it is by all this written. Javascript is everywhere present, everyone is using it, by many standards are based on javascript.

    So the value of this post today nil and only provides false information.

  55. Agree 100%. I would add that the only reasonable and necessary place is to make Ajax requests and receive CONTENT (that should be rendered on the server) and injected as child elements to existing CONTENT that had previously been rendered on the server.

  56. Dissent and you will be known.

    I was one of the people who believed that JavaScript will die, after VBScript, Flash, Silverlight, but during the last 20 years. But from what I saw during the last 20 years, all others died and JavaScript lived.

    So best thing to do, is learn it well and you’ll never loose.

  57. Title & argument shouldn’t haven been to stop using javascript (JS) but instead that too many websites implement JS the wrong way.

    Anyhow, those sites that implement JS the wrong way, the loading time takes way too long, and most site visitors would have conveniently closed the window instead.

  58. This article: I’m bad at using JavaScript and I think everyone will resort to silly plugin frameworks like I did so you shouldn’t use it either.

    Or: I don’t know the full functionalities of JavaScript and only know of those which are superfluous to server side programming languages.

    Or: I don’t know how to filter input.

    Or: I’m the worst debugger in the world.

    You’re just some tool who has never really created anything implementing JavaScript. Your entire base argument for “I’m no JS hater” is that you made some lousy MVC nonsense (and all of them are nonsense, as if JavaScript is even that hard).

    I like how people are still posting two years after this article to tell you that you’re wrong. lol.

  59. My mouth was gaping in disbelief as I read this article, but my jaw hit the floor at :-
    “These things frustrate professional and experienced programmers, since they are simply not used to write in functional languages. How many programmers that have a professional education actually know how to do functional programming? And how many are good at it?”

    Functional programming is the core of all programming, ultimately. No matter how OO you want to go, at some point, you’re going to have to flesh out an object’s methods (functions!). As soon as you do, you are programming a function (method).

  60. Using jQuery abort() you can cancel a running AJAX request forcefully before it ends as this hits several times within a short time period.

    This is usually in cases where the user might perform an action, based on AJAX request several times within a short time period.

    Here is details information:


  61. Come on now, let’s be honest with ourselves. We love JS because Closures are sooo awesome and useful. Also, I know I definitely like note being able to see the html produced when I run my precious AJAX. I also like like driving with my eyes closed in ice lol.

    JS has its place but it’s being pushed too far. Clever hacks can do cool stuff until you realize… they don’t work as promised.

    Maybe I’m not as awesome as some of you brilliant developers out there but I tend to go with common sense…

  62. I found this blog entry when searched the web for “javascript free css framework”. Totally agree with the blog. Unfortunately my english isn’t enough good to write more about me own points.

  63. I know that this is most likely a troll post, but just in case it isn’t and since it was written in 2013 (quite a while in web development years) I am genuinely curious about what opinion the author holds now, I won’t argue about why this post is mostly wrong since the points have already been told by other users but I also notice that the author has barely done nothing to prove he’s right, I would dare to say that he found out he was wrong, as someone already wrote, but the post hasn’t been updated with any explanation and in any debate not only the arguments have to be solid and discussed thoroughly but also there’s nothing bad in admitting that you are wrong, so please, state your current opinion, otherwise you will be contributing to the spread of misinformation (I found this post by pure chance).

  64. I’ve stumbled across this post 2 years late and would like to ask what your thoughts are on this now that Node.js & Isomorphic Javascript are on the rise?

  65. we are in 2015, come on guys you cannot be more stupid than that. its a shame see a post like these… really? being a Java developer I know that building web interfaces using JSF or Vaadin stuff just sucks, your development time, your patient, your money it drains everything you have. go for a real project to put some experience before post things like these.
    JS is on the way, none can stop it.

  66. This article was written out of ignorance. I don’t say that as an insult, I mean it purely as lack of knowledge. The Javascript engine in modern browsers is highly performant. Chrome’s V8 JS engine executes JS up to 80% the speed of *native* compiled code. That’s amazing.

    The author of this article has valid complaints about the various frameworks he’s mentioned. But he conflates JS with those frameworks. It’s like saying the iPhone sucks all he’s ever seen on it are a dozen crappy fart apps 🙂

  67. You are seriously posting this? Are you a self-acclaimed engineer or just that lucky that idiots hired you? I am sorry for sounding like a troll, but please take the opportunity to learn from your mistakes, and wake up to 2016.

    You’re posting this on a WordPress blog, who’s developer has mentioned that PHP will merely be a layer to the database in the future, and that he wouldn’t be surprised if everything else will be all JavaScript.

    It’s as if you are just taking articles from the 90’s and thinking “client side is bad! NO” and republishing it.

  68. I agree with the spirit of the article. JavaScript is the most over-used language. It was supposed to be a scripting language for doing some specific client-side magic and for that is good, but when you use for other things like server side applications is pure no-sense. Currently none can escape from javascript, but you can avoid it in most cases.

    Why you must avoid javascript IMO:
    -Non-standard implementations.
    -Interpreted, weak typed language.
    -Awful abstraction capabilities.
    -So many libraries that only provides nothing more than a new stupid fancy syntax.

  69. Great article. Not in technical insight, but in positioning. To invoke these many passionate comments is not always easy. Security and performance considerations sometimes slip because developers are pressured to deliver, but I am hard-pressed to see what would be a replacement for JS.

    Your article basically points out a list of critical software metrics that should be in the mind of every architect and developer, and turns them against JS and the frameworks. The negative connotation against JS is one way of positioning your article. I congratulate you on finding a “hot-button” to get SEO attention. Before this article, I had never visited or commented on your site.

    (OK, this is the part when you come out with the candid camera. You have our attention now.)


  70. @J.Reid: Thank you! Such a well written and kind comment is more than welcome. I hope you also enjoy the less controversial articles on this blog.

  71. Have to agree with others, this post is clickbait bullshit. I was expecting for some real points, not abstract thousand times disproved gibber.

    And while this was most likely your intention, I must say sir, this was weak minded idea which will keep me away from this site.

Leave a Reply

Your email address will not be published. Required fields are marked *