Saltar para: Post [1], Comentar [2], Pesquisa e Arquivos [3]

O castelo do Camelo.

O castelo do Camelo.

New tech, same old mistakes...

People keep doing the same mistakes but with "new" technology.

Few years ago people started using Java and Flash for client side web, and they broke the Web on many ways. People are now falling into the same mistake with Javascript.

I'm not against Javascript. It's a very useful technology. But it needs to be used wisely, to improve the Web, not to break it.
We can use Javascript to massively upgrade the user experience, while also increasing the server side response capability. However, Javascript has also a potential for revive many problems.

Do use Javascript to build upon existing server side capabilities, and to complement them. Use progressive enhancement/graceful degradation approaches. This will improve fault tolerance while empowering users to use what they want how they want, when they choose to.

Are we really evolving software or are we just increasing the technology dependency and complexity threeshold, to do even the most simple things we already used to be able to do easly and many time with a lower technical and economical cost!?
In "1998", we used to be able to read a text, using just a simple HTML document. But nowadays on many websites, you won't be able to read text or to see a thumbnailed picture (frequently pre-generated static content), unless you execute their (and often also severall third parties) Javascript frameworks and scripts. How is this any better? Isn't this just over engineering?

Is Javascript bad?
No way!!
Besides improving the traditional web experience, javascript can enable us to fully use brand new awesome web features that I love, like: websockets, web Vídeo and Audio, scripting canvas, scripting WebGL, Web RTC, synchronize "live/dynamic" multi-media content (just look at Mozilla Popcorn.js), access to local storage for some client side persistent data. And many other cool things. But while we should enable people and content providers with this features. I can say you should use them wherenever it's possible, but also don't depend on them whenever it's possible.

Ask yourself, some of this questions:

  • Should a user have to trust your and third code, enable him to access your content/functionalities, that can be achieved without Javascript?

  • Are you sure that the third party JS framework aren't on compromised servers?
    Have you ever used JQuery, while including the code from JQuery servers?
    (If your answer is yes, you've already exposed your users to code on compromised servers)

  • Do you believe your site will never fail if a third party hosted framework for some reason is not accessible or becomes broken on some user-agent you haven't tested (nowadays it's common on mobile environments)?

  • Do you want your content to be indexed by search-engines?

  • Do you want your content to be preserved for the future by the Internet Archive and others?

  • Do you think it's fair that your server does way less processing and you use less traffic, but the client loads way more content and has to process much more, even much more than it will need to do simple very thinks that can be achieved without Javascript to access static content, or content that isn't even client side generated? Or you think the users should be allowed to make their own choices, even if the experience becomes somewhat inferior (but still useful for their purposes)?

  • Do you believe it's fair to impose the user more processing of untrusted code, just for the sake of "eye candy"?

  • Besides doing Javascript, can you also provide any alternative application (as Free Software) and/or any alternative web version?

Think about those questions before using javascript for something, and find good technical case-by-case compromises for you, your users and the Web. And keep in mind that people care mostly about content and simple and useful functionality. So use Javascritp to provide more of that, not to prevent it.

Maybe these other articles can explain better, or complement my point:



Se preenchido, o e-mail é usado apenas para notificação de respostas.

Mais sobre mim

Subscrever por e-mail

A subscrição é anónima e gera, no máximo, um e-mail por dia.


  1. 2016
  2. J
  3. F
  4. M
  5. A
  6. M
  7. J
  8. J
  9. A
  10. S
  11. O
  12. N
  13. D
  14. 2015
  15. J
  16. F
  17. M
  18. A
  19. M
  20. J
  21. J
  22. A
  23. S
  24. O
  25. N
  26. D
  27. 2014
  28. J
  29. F
  30. M
  31. A
  32. M
  33. J
  34. J
  35. A
  36. S
  37. O
  38. N
  39. D