Uploaded byTim Sommer
T4T Training day - NodeJS
This document provides an overview and summary of Node.js. It discusses: 1) The history and implementations of server-side JavaScript including CommonJS and AMD specifications. 2) The benefits of Node.js including its event-driven and non-blocking I/O architecture which allows for high performance and parallel processing. 3) How to program in Node.js including handling CPU intensive tasks and popular Node packages like NPM, Express, and Grunt. 4) Live demonstrations of building a web app with Express and automating tasks with Grunt.
More Related Content
![[Blibli Brown Bag] Nodejs - The Other Side of Javascript](https://cdn.slidesharecdn.com/ss_thumbnails/i9sycn9mqmawqhdzv0i6-signature-6c4174f35aa29065af3a8befc1a3a39ca764f84b5c082116486141991cd72c8c-poli-160225041632-thumbnail.jpg?width=640&height=640&fit=bounds)
![Grand Central Dispatch and multi-threading [iCONdev 2014]](https://cdn.slidesharecdn.com/ss_thumbnails/icondev-gcd-140326100357-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to T4T Training day - NodeJS
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
T4T Training day - NodeJS
- 1.
- 2. Content • About me •Common Js • Node Js • Demo(s) ! • Grunt Js • Demo !
- 3.
- 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 usedto mean you weren't a serious software developer. Today, not learning Javascript means the same thing. - Tim O'Reilly
- 7.
- 8. 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
- 9. 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.
- 10. Commonjs ? • KevinDangoor, 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)
- 11. Why Server Sidejs? • 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.
- 12.
- 13. 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
- 14.
- 15.
- 16. AMD? • Asynchronous moduledefinition • 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.
- 17. 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)
- 19.
- 20. Nodejs? • Event-driven • Flowis 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
- 21. What makes nodejsFast? • Node.js is fast by design • Never blocking on I/O means less threads. • This means YOU handle scheduling.
- 22. Node – Javaruntime? 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
- 23. Node – Apacheruntime? Apache (PHP)
- 24. Node – Apacheruntime? Node
- 25.
- 26. 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
- 27.
- 28. 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’
- 29.
- 30.
- 31.
- 32. NPM • NPM (NodePackage Manager) • express • async • grunt • mocha • helmet • socket.io • underscore • ……… (> 50.000)
- 33. Demo! Building a web-appwith Express
- 35.
- 36. Gruntjs • Task runnerin Node • Automation • Minification, compilation, unit testing, linting, .. • Custom tasks! • Commonjs Compliant
- 37. Gruntjs People will alwayswant to do stupid things, and luckily for those people, there's JSHint -Douglas Crockford
- 38. Demo! Automated tasks withGruntjs
- 39.