Your SlideShare is downloading. ×
T4T Training day - NodeJS
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

T4T Training day - NodeJS

399

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
399
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. T4T Trainingsday NodeJs Tim Sommer
  • 2. Content • About me • Common Js • Node Js • Demo(s) ! • Grunt Js • Demo !
  • 3. About me Super Sommer !
  • 4. About me Tim Sommer (@sommertim) >3 years @ T4T Passion for Front-End Development http://blog.timsommer.be https://github.com/timsommer
  • 5. Learning JavaScript used to mean you weren't a serious software developer. Today, not learning Javascript means the same thing. - Tim O'Reilly
  • 6. History of JavaScript
  • 7. Server side JavaScript? • Has been around for a long time • Very fragmented: • Netscape started server-side scripting (SSJS), December, 1994 • Mozilla Spidermonkey, C, Firefox > 3.5, GNOME (started at Netscape), first engine ever, 1996 • Mozilla Rhino, Java, 1997 (started by Netscape for navigator) • Google V8, Chrome, September 2, 2008. • SquirrelFish (AKA JavaScriptCore), Webkit, June 2, 2008
  • 8. Server side problems? • No compatible standard library. • No standard interface to connect to a database. • No standard method to insert different modules. • No method for packaging code for distribution and installation. • Module storage of a common package that solves dependency is necessary.
  • 9. Commonjs ? • Kevin Dangoor, January 2009 • Spec • JavaScript ecosystem for web servers, desktop and command line apps and in the browser. • CommonJS-compliant systems: • Server-side JavaScript applications • Command line tools • Desktop GUI-based applications • Hybrid applications (Titanium, Adobe AIR)
  • 10. Why Server Side js? • Familiar and universal • Same language on server and client (code sharing) • Notions from Self, Scheme, and Prototype - all with a C/C++/Java-like syntax. • Server side JavaScript has the potential to significantly outperform other common dynamic languages.
  • 11. Why Server Side js?
  • 12. Common Spec? • Modules • Binary strings and buffers • Charset encodings • Binary, buffered, and textual input and output (io) streams • System process arguments, environment, and streams • File system interface • Socket streams • Unit test assertions, running, and reporting • Web server gateway interface, JSGI • Local and remote packages and package management
  • 13. Common Spec?
  • 14. Common Spec?
  • 15. AMD? • Asynchronous module definition • Started as offspin (fork) of CommonJs • Failed to reach an agreement in discussions with CommonJS about using JavaScript module in an asynchronous situation. • Evolved in own module definition API • The difference in the module specifications defined by the two territories are in module load.
  • 16. Implementations • ArangoDB (V8): NoSQL • CouchDB (SpiderMonkey): NoSQL • AkShell (V8): browser based IDE • Narwhal (V8, Rhino): JavaScript platform • Requirejs (Web Browser): module loader • Curljs (Web browser): resource loader • Whenjs (Web browser): async promises library • … • Nodejs (V8)
  • 17. Nodejs?
  • 18. Nodejs? • Event-driven • Flow is determined by events • Event loop • Non-blocking I/O (AKA asynchronous I/O) • I/O processing while permitting other processing to continue • Parallel I/O • You can do other things while waiting. • You can wait on more than one thing at a time. • CommonJS • V8
  • 19. What makes nodejs Fast? • Node.js is fast by design • Never blocking on I/O means less threads. • This means YOU handle scheduling.
  • 20. Node – Java runtime? Java : Node : Concurrent Requests Avg Response time (ms) Requests/second 10 23 422 50 119 416 100 243 408 150 363 411 Concurrent Requests Avg Response time (ms) Requests/second 10 19 509 50 109 453 100 196 507 150 294 506
  • 21. Node – Apache runtime? Apache (PHP)
  • 22. Node – Apache runtime? Node
  • 23. Programming in NodeJs
  • 24. CPU intensive computations • Node -> single threaded execution model • Fibonacci function = one event tick • Blocking your node server completely • IO (DB, Filesystem) is the bottleneck, These calls are completely async
  • 25. CPU intensive computations
  • 26. CPU intensive computations • NPM Modules: • ‘flow’, ‘async’, ‘step’ and ‘Q’. • ‘Threads a GoGo’ natively utilizes threading inside the V8 engine (and therefore relies on a newer release of node.js) • ‘Webworkers’
  • 27. Programming in NodeJs
  • 28. Programming in NodeJs
  • 29. Demo! Node CPU intensive computations
  • 30. NPM • NPM (Node Package Manager) • express • async • grunt • mocha • helmet • socket.io • underscore • ……… (> 50.000)
  • 31. Demo! Building a web-app with Express
  • 32. Gruntjs
  • 33. Gruntjs • Task runner in Node • Automation • Minification, compilation, unit testing, linting, .. • Custom tasks! • Commonjs Compliant
  • 34. Gruntjs People will always want to do stupid things, and luckily for those people, there's JSHint -Douglas Crockford
  • 35. Demo! Automated tasks with Gruntjs
  • 36. Q&A ?

×