The Node.js movement has transformed the landscape of UI development. In this session we'll look at how Node.js can be leveraged on multiple layers of the web application development lifecycle. Attendees will learn how incorporating Node.js into your front-end build process can optimize code, allow you to use use new and upcoming JavaScript features in your code today, and to improve your asset delivery pipeline. This session will also cover how Node is changing the template rendering landscape, allowing developers to write "isomorphic" code that runs on the client and server. Lastly we'll look into using Node to achieve developer zen by keeping the codebase clean and limiting the risk of changes to the code causing unknown errors.

1. Modern UI
Development
With Node.js

2. @bittersweetryan

5. 1990 1991
Sir Tim Berners-Lee
writes HTML, URI, and
HTTP
Worlds first web page
launched
CSS
Re

6. 2011
e Brehm coins the
m “isomorphic”
om/isomorphic-javascript-future-web-apps/
2015
Michael Jackson says
“universal” is better
https://medium.com/@mjackson/universal-javascript-4761051b7ae9

7. <code>

8. Step
0

9. Use. Modules.
http://mattsbrickgallery.tumblr.com/post/48739663720

10. An IIFE is not a
module!
ES6 or CommonJS

11. ES6 Modules
ECMA spec
browsers will (eventually) implement
strict mode default
named exports and imports

12. ES6 Modules
spec had been under churn
browser support coming along slowly
transpolation can get messy
cannot conditionally load them

13. CommonJS
Node.js default module system
A single syntax for all the modules
conditional loading

14. CommonJS
No strict mode default
different syntax for browser and node
conditional loading is a double edge sword

15. The code you
write today is
the code that will
be copied tomorrow.
https://pixabay.com/p-26556/?no_redirect

16. ES6

17. ES2015

18. What is the first thing developers do
when they start coding in a new
project?

20. ⌘+c

21. ⌘+v
⌘+c

22. Babel now!

23. classes

24. ui components as classes

27. These aren’t even mixins!

28. They should be modules!

29. UI components are modules

33. <build>

34. The build
pipeline is the
foundation
modern UI
projects are
built on.
http://mdti.net/wp-content/uploads/2014/10/exterior-wall-crack-cropped.jpg

35. Your build chain is your development lifeline.
Treat it accordingly

36. Each step is a module.

37. Each module does one thing
(demo)

38. If you have to require more than one
plugin you might want to create another module.
Rule of thumb

39. Tip!
Save your globs in a separate JSON file and
require them into your build modules.

40. Use your build
tool to automate
mundane tasks.
http://www.companiesandmarkets.com/Content/DynamicMedia/cms-uploaded/X-20140605161048330.jpg

41. testing

42. just do it

43. Test as you code

44. Test as you code
Test before you push

45. Test as you code
Test before you push
Test in you CI Server

46. Tip!
Make testing easy and people will do it.

47. Easy is…
fast
automated
easy to bootstrap
having a culture of testing

48. Code
Quality

49. eslint

50. Why lint?
catch common errors
catch oops moments (console.log, debugger)

51. Why eslint?
Style checker
Pluggable
Future friendly: ES6, JSX
configure rules [ignore, warn, error]

52. csslint

53. Nesting
is the worst thing to happen to CSS.

54. You should never see this in css!

55. Don’t let
lint errors in your
repos.
https://odetojoandkatniss.files.wordpress.com/2013/12/gc-nope.png

56. How?

57. push hooks

58. http://www.sitepoint.com/introduction-git-hooks/
pre-commit
pre-push
pre-rebase
commit-msg
post-update
post-checkout
post-merge
For GIT
Add these files to your .git directory’s hooks folder

59. http://www.sitepoint.com/introduction-git-hooks/
pre-commit
pre-push
pre-rebase
commit-msg
post-update
post-checkout
post-merge
This is your “Nope” button

60. git push --no-verify

62. Continuously Lint & Test
Add your testing and linting
as part of the build process and in your CI tool.

63. Public shaming is
a great motivator.

64. Automate Adding Hooks

66. <serve>

67. business logic, maybe some sql

68. business logic, maybe some sql
php/jsp/asp/erb/etc

69. business logic, maybe some sql
php/jsp/asp/erb/etc
run some JS on the client

70. RESTful API’s

71. RESTful API’s
JS template on the server

72. RESTful API’s
JS template on the server
interactive JS on the client

73. There is a large cost to context switching.

74. Proceed with Caution!
Let node do what it’s good at, nothing more.
Don’t block
Don’t implement business logic
fire & forget, take advantage of the message queue

75. Make calls to async services
Compose a template
Send the response

76. Some things have to be
synchronous.
Keep as many of those at startup as you can.

77. Be aware of the “hot”
path!
Code that will run with EVERY request.

78. Keep your functional programming
off the hot path.

79. But what if?

80. RESTful API’s

81. RESTful API’s
JavaScript

82. Isomorphic!

83. Unimorphic!

84. Isomorual!

85. Universal!

86. Don’t let the demos fool you!
Universal JS is hard!

87. Calling a template with some data to
produce HTML is easy

88. De-hydrating data in Node and
re-hydrating client in the browser is
HARD.

89. Getting your data can
be really hard.

90. Don’t

91. Do

92. Use meta data to tell other modules what data the UI needs.

93. In React, statics are perfect for this.

95. Bind Falkor paths

96. Load i18n strings

97. Webpack &
Browserify

99. Eac

100. Node code vs Browser code
Client code is bundled, node code isn’t.

101. Why not run bundles in Node?
It only takes a few configuration tweaks
http://jlongster.com/Backend-Apps-with-Webpack--Part-I

102. 0) Collect your node_modules

104. Not a “hot” code path

105. 1) Add another config to webpack.config.js

106. Export an array

107. Have multiple targets

108. 2) Tell web pack to ignore your requires for node_modules
AND your CSS

109. No Node node_modules

110. No css

111. $> node build/server.js

112. Next level
Stuff

113. Weback dev server & hot module
swapping.
(demo)

114. Last thoughts…

115. Start Small When Transitioning
There are lots of learnings to be had from a single page

116. Legacy
ServiceServiceService
Routing Layer
( /path match )
Node

117. Iterate on Modules
Modules don’t have to be perfect at first
learn & refactor

118. Keep your code clean
Don’t let bad code infect your repository.

119. Automate
People are lazy. They will do the easy things and
ignore the hard things.

120. http://webdesign.tutsplus.com/articles/a-brief-history-of-the-world-wide-
web--webdesign-8710
http://www.evolutionoftheweb.com/
http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
http://jlongster.com/Backend-Apps-with-Webpack--Part-I
References

121. Questions?

122. Thank You.
ranklam@netflix.com
ryan.anklam@gmail.com