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:

javascript_logo

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

Convinced?

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.

55 Responses to “10 very good reasons to stop using JavaScript”

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

  • Maurits van der Schee (Innovation Engineer):

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

  • Sjakie:

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

  • Robert Klep:

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

  • Arman:

    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.

    Thanks

  • Antoine:

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

  • Nope:

    Cool story, BRO.

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

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

  • Duck:

    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.

  • espadrine:

    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.

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

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

    Greetings,
    Johan

  • Guess JS also caused my comment not to be escaped properly? /sarcasm

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

    Kevin

  • TanS:

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

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

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

  • Lol:

    This #$%$# site runs JavaScript……..

  • Ilia Shakitko (Innovation Engineer):

    11th reason: phpunit browser does not work with JavaScript

  • […] programming language available. A former colleague of mine recently showed me an article claiming 10 reasons why you should not use JavaScript. JavaScript, like every language, has its strengths and weaknesses, but what is interesting about […]

  • kaneel:

    Very good troll to promote your own framework.

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

  • Your Grandma:

    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

  • Michael Benin:

    This is only true if you are using JS wrong.

  • 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 ;)

  • Adam Rackis:

    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.

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

  • joud:

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

  • DAve Ash:

    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.

  • Bruno Trevisan:

    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.

  • Andr:

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

  • Eagleon:

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

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

  • Chris King:

    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.

  • Sam:

    This is extremely backwards.

  • […] was recently pointed to the article "10 Very Good Reason To Stop Using Javascript" It sure sounds like link bait to me, but I do think about some of the things so why not? […]

  • Shawn:

    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.

  • WhatTheHeck:

    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.

  • Ingo:

    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?

  • kumar:

    Learn JavaScript and JQuery. Wort post ever…period!

  • Frank:

    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.

  • kenny:

    let’s go back to using font tags

  • Claudio:

    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.

    Best

  • rafael:

    hahahahahaha. funny!

  • Banus Williams:

    ahahaha (…)

  • Croky:

    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 …

  • Somebody:

    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.

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

  • Gregory:

    Andrew.. you nailed it! Excellent comment..

  • Jonathan:

    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.

Leave a Reply