Best practices for JavaScript RIAs Carlos Ble | www.carlosble.com | @carlosble Thanks to MadridJS.org January 2013
Jan 15, 2015
Best practices for JavaScript RIAs
Carlos Ble | www.carlosble.com | @carlosble
Thanks to MadridJS.org
January 2013
Know the history
Table of contents● Is it an application or is it a website?
● Is it a library, a framework, or application code?
● Am I test-driving the code or not?
● Testing tools
● Testing techniques
● Design patterns and architecture
● Client-Sever?
What kind of JavaScript are you writing?
● For frameworks and libraries:
if (someVariable === undefined)...
● For applications, without automated tests:
● Test-first JavaScript: if (someVariable)... - Duck typing is OK. - No need for lots of JavaScript patterns. - Write code for humans.
● Functional or Object Oriented? Just make it SOLID
TDD with JavaScript
● Tddjs.com
● DirigidoPorTests.com/el-libro
Testing tools
There are new tools every day!
Some tools I use, thanks to @pasku1 & @eamodeorubio (follow these guys):
Jasmine/Mocha Jasmine-node Chai – chaijs.com CasperJS / PhantomJS JsTestDriver
Believe me, tools are there to support concepts, they are not important themselves!
Testing Rules &
Test-First Rules
● Test-first is absolutely different from testing.
● Do not mock artifacts you don't own.
● Use stubs for queries and mocks/spies for actions.
● Exploratory testing is always necessary.
Widgets are objects, not pictures
Events: DOM level 0 – Traditional model(one2one: a nice kind of dependency injection)
Events: Observer (one2many) & Pub/Sub (many2many)
Passive View
http://martinfowler.com/eaaDev/PassiveScreen.html
Factory
Singleton
More patterns: http://addyosmani.com/resources/essentialjsdesignpatterns/book
Singleton
Optimal code for machinesis hard to read for humans
● Don't write code for machines, write it for humans
● Do you really have performance metrics?
● Google Closure Compiler
● CoffeeScript
● Do performance testing often
Smart client, dumb server● Let the client side application contain all the business logic you can.
● Keep the server just as an event bus for clients to interact with each other.
● Examples: - TeamMonitor in LiveTeamApp.com - Skype and TeamViewer clients can connect directly between them (OK, this is not JavaScript).
● Advantages: - Ease of testing. - Ease of maintenance. - Scalability.
Sample app: LiveTeamApp
Conclusions● JavaScript is too big. Consider the context to make decisions.
● Retrieve best practices from the desktop development age, those days back in the 90's.
● Read books, the good ones don't get old.
● Try to understand the concepts, not just the tools.
● You usually don't need frameworks you need libraries.
● Care about your code and your tests . Test-drive your code.