This document summarizes strategies for transforming unmaintainable front-end code ("Disaster CodeTM") into organized, high-quality code through proper planning, separation of concerns, performance optimization, and stakeholder communication. It outlines how the author's team improved their codebase ("Neptune") by adopting modular patterns like MVC, optimizing page load times, and collaborating on standards. The document stresses that upfront planning, separation of functionality, and ongoing maintenance are crucial to developing software that is sustainable, performant, and a pleasure to work with.

1. Transforming Front-end
Disaster Code™ Into a
Maintainable Masterpiece
@dangribbin

2. Hi, I’m Dan Gribbin
Software Engineer
brand networks
Web Development Teacher
rochester brainery

3. front end
js + css + html

4. design is critical to the
development process

5. .psd

6. design (a plan)

8. best available solution
| constraints

9. get requirements → write code → ship?

10. get requirements → write code → ship?
no.

11. plan system→ then write code
yep

13. disaster!

14. alpine

15. alpine
*internal name - not actual thing name

16. initial launch
- tight deadlines
- limited front-end resources

17. - good
- fast
- cheap
(pick two)

18. our plan lacked detail it
needed for the
future of the front-end

19. Technical Debt
poor engineering complicates
future work

20. software entropy
complexity will increase unless
an effort is made against it

21. we set our front end
up for failure

22. alpine launch → SDLC
2 week sprints
requirements → code →release

23. sprint : function() {
technicalDebt++;
},

24. performance

25. page load times
15 seconds
:(

26. poor engineering →
poor user experience

27. effects on our page load
- render-blocking scripts
- loading all resources on all pages
- lots of code, no minification

28. maintainability

29. Time and ease of…
- fixing a bug
- developing a new feature

30. impact?

31. ↑ feature work dev time
↓ velocity

32. costs of an unmaintainable codebase to
you and your stakeholders
- time
- money
- frustration

33. influences on maintainability
JS
- globals
- intermixed functionality

34. SASS/CSS
- long, overly specific selectors
- confusing naming conventions

35. - Styles not logically separated
- Hitting IE9 selector limit

36. morale
entropic products affect the
teams that work on them

37. our software problems don’t
just belong to one person

38. your disaster is your team’s
disaster too.

39. disasters affect morale
(relationships), motivation,
and productivity

40. initial fixes

41. initial fixes
… mostly unsuccessful
:/

42. we needed a do-over

43. 1UP

44. design!

45. neptune

46. much of our JavaScript wasn’t
terrible, just terribly organized

47. reorganization was top priority

48. separation, actually

49. MVC

50. Some MVC frameworks
ember, backbone, angular, knockout, dojo, YUI, CanJS, Maria, Polymer, React, cujo,
Montage, Ext, Sammy, Stapes, Epitome, soma, DUEL, Kendo UI, PureMVC, Olives,
Plastron, Dijon, rAppid.js, Deft, Aria, Exoskeleton, Atma, Ractive, ComponentJS

51. MVC frameworks
ember, backbone, angular, knockout, dojo, YUI, CanJS, Maria, Polymer, React, cujo,
Montage, Ext, Sammy, Stapes, Epitome, soma, DUEL, Kendo UI, PureMVC, Olives,
Plastron, Dijon, rAppid.js, Deft, Aria, Exoskeleton, Atma, Ractive, ComponentJS
was one of these right for us?

52. constraints
time + experience

53. AMD + RequireJS
define([’controllers/article-controller.js’],
function(ArticleController) {
ArticleController.init();
}
);

54. neptune’s front end stack

55. results
cut page load time by 80%
cut JS per-page by 70%
cut CSS per-page by 75%

56. -huge maintainability gains
-framework for future work
-testable code

57. where did we suck?

58. estimation.
seriously. ouch.

60. awesome team-building
experience

61. Things you can do right
now to clean up your
front end

62. Cleaning up means…
-optimizing for performance
-promoting maintainability
-ensuring reliability

63. optimize for performance

64. developer tools are your
best friends

67. using an image sprite?
you should be!
!
one request → all your icons

69. no <script>’s in your <head>
<head>
<title>Bad Ideas, Inc.</title>
<script src=“main.js”></script>
</head>

70. Instead…
…
<script src=“main.js”></script>
</body>

71. get some help optimizing
use a build tool

72. In the beginning, was
make

73. then, this guy stuck
his nose in

74. a challenger
appears?

75. which one should
you use?

76. whichever
one makes
you happy.

77. minimize and defer
resource loading
!

78. track down unused CSS
grunt-uncss
gulp-uncss

79. minify & combine
grunt-contrib-concat
grunt-contrib-uglify
!
gulp-uglify
gulp-concat

80. optimize images
grunt-contrib-imagemin
gulp-imagemin
!
or, use an app like ImageOptim
for manual operations

81. cache jQuery selections in your code
var galleryItems = $(‘.gallery-item’)
http://training.bocoup.com/screencasts/the-importance-ofcaching-jquery-selections/

82. promoting maintainability

83. a hallmark of a maintainable
codebase is organization

84. short term fixes

85. Check your styles
using less/sass?
be careful of the nesting trap.

86. instead of
!
li {
display: block;
}
!
li img {
width: 50px;
}

87. you can write
!
li {
display:block;
!
img {
width: 50px;
}
}

88. which is awesome! but be careful.

89. the following Disaster SASS™
is real code pulled from alpine
viewer discretion is advised

90. body.single {
.outer-wrapper {
#content{
#content_column{
ul {
li{
a{
img {
width: 50px !important;
}
}
}
}
}
}
}
}

91. which compiles to…
body.single .outer-wrapper #content #content_column ul li a img
{
width: 50px !important;
}

92. to override that, we’d need a selector
with a higher specificity and importance

93. see how this might get
out of hand quickly?

94. what if all your styles were so
messy? ours were.

95. how about this instead?
.gallery img {
width: 50px;
}
readable, reusable, maintainable

96. also, don’t use !important
if you need !important, you
have bigger problems to solve

97. Collaborate on a
standards document

98. helpful for getting the entire team
thinking about quality and consistency

99. involvement increases buy in
collaboration can be an effective
and positive teamwork experience

100. long term goals

101. organization through separation
(and avoiding their opposites)

102. modularize
JavaScript - AMD / MVC
CSS - SASS/LESS

103. modular code will help you
create extensible features

104. enforce separation of:
-style
-presentation
-behavior

105. use class names for on-the-fly
style adjustments

106. .addClass(‘error’)
instead of
.css(‘border’, ‘red’)

107. ✓ reusable
✓ consistent
✓ maintainable
o/

108. keeping JavaScript out of HTML means only
having to look in one filetype

109. el.on(‘click’, doThing)
instead of
onclick=“doThing()”

110. navigating stakeholder relations

111. clear, understandable communication
how is what you’re saying relevant to business goals?

112. the quicker solution will often
lead to more cost down the road

113. negotiation

114. great client relationships
are possible!

115. remember
this is effort against
complexity

116. making effort against complexity benefits:
- you
- future you
- your team
- your stakeholders

118. make future-you
love past-you

119. the perfect
!
tool/framework/library
!
does not exist

120. plan & design software
for the situation at hand

121. thanks!
slides here: @dangribbin