Best practices for JavaScript RIAs
Upcoming SlideShare
Loading in...5
×
 

Best practices for JavaScript RIAs

on

  • 3,206 views

 

Statistics

Views

Total Views
3,206
Views on SlideShare
2,224
Embed Views
982

Actions

Likes
7
Downloads
11
Comments
0

4 Embeds 982

http://www.carlosble.com 977
http://prlog.ru 2
https://twitter.com 2
http://abtasty.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Best practices for JavaScript RIAs Best practices for JavaScript RIAs Presentation Transcript

  • 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 toolsThere 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 dont 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
  • Optimal code for machines is hard to read for humans● Dont 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 businesslogic you can.● Keep the server just as an event bus for clients tointeract with each other.● Examples: - TeamMonitor in LiveTeamApp.com - Skype and TeamViewer clients can connect directlybetween 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 makedecisions.● Retrieve best practices from the desktop developmentage, those days back in the 90s.● Read books, the good ones dont get old.● Try to understand the concepts, not just the tools.● You usually dont need frameworks you need libraries.● Care about your code and your tests . Test-driveyour code.