Texas JavaScript 2013

I was very happy to have the opportunity to check out the Texas JavaScript 2013 conference while I was back home in Austin, visiting with family. There were some really good speakers, and while some have complained about the lack of focused talks, I enjoyed the diversity of topics at this conference. I will definitely try to make it there sometime in the future. Below are my notes from the conference, but there is also videos up on the TXJS 2013 vimeo channel:

Harper Reed (@harper) — Keynote

View Video

“Build a great team, practice failure, facilitate community”

• “Hacker” == sharing, openness, collaboration
• Take advantage of crowdsourcing: its all about letting the community do the hard-work
• Focus on product, not technology; Focus on what simply solves the problem
• UX Designers are your products first line of defense; communicate with them
• There’s a difference between functional and usable
• Preparing for game day is all about practicing for failure (write tests!)
• “Manage by your outbox. Not by your inbox” — Larry Bacow; often we wait for people to email us, instead we should be proactive emailers
• ABC = Always Be Closing; (A hires A’s, B’s hire C’s)
• Improve your team by measuring everything, seeking diversity, and focus on shipping
• Work at being terrible at failing!
• The movie Groundhogs Day was all about multivariate testing 😛
• Always roll forward, never roll back (rolling back is lazy)
• Discuss fail safe/error states with users; users shouldnt be stuck in an error state
• Community is the power behind your brand & is often underestimated: authenticity, purpose, empowerment, safety/trust

Dave Rupert (@davatron5000) — HTML, Do We Really Need the ‘L’

View Video

“We’re really bad at assumptions; no one would ever visit _____ on a _______.” — Every Developer Ever.”

• The mobile web is in trouble: “Theres a common perception that mobile web experiences are inferior to native mobile experiences. Many companies are building native experiences instead of web experiences. That’s simply not always the case.”
• New “Home base” for the front-end: tiny screens, slow connections, and touch interfaces
• Across hardware devices, there’s more touch interfaces than click interfaces
• The internet is mobile (responsive & performant) by default; we’ve screwed it up by touching it
• Accessibility is hard :( but we need to put in the effort; together we can incrementally make the internet a better place

Nicole Sullivan (@stubbornella) — SASS and OOCSS in a tree, K-I-S-S-I-N-G

View Video

• We need SASS, but we also need strong architecture
• OOCSS: a way of writing CSS that avoid duplicating code by separating styles into layered abstractions; it also encompasses a philosophy of working with CSS arther than against it
• SASS: an extention of CSS
• DRY SASS != DRY OOCSS
• Use @extend to duplicate OOCSS inheritance; Use @include for mixins
• OOCSS is what you want to say; SASS is how you say it.
• The Inception Rule (applied to SASS): never go more than 3 levels deep
• When you want to extract something that won’t be used in SASS, use % instead of ‘.’
• Relentlessly focus on the output, make sure that both the SASS and the CSS make sense
• “SASS why for the CSS Guy”

Chris Coyier (@chriscoyier) — CSS is for Computers, Preprocessors is for Authors

View Video

• Websites are alot more complicated these days; as the capabilities of the web grow, we take advantage of every last bit of it. Complexity goes up
• Stepping up our abstractions makes things easier.
• SASS can concatenate and compress into CSS for you
• global.scss (is your table of contents)
• Variables are coming to CSS, but the preprocessor implementation makes more sense
• Convincing the team to use preprocessors: SASS simplifies development and lowers the complexity of your site
• Transitioning to SASS: all .css is valid .scss; inch your way through the different features
• With a little “dev-ops”, SASS can be easier than CSS
• CSS is awesome, but it is becoming increasingly less productive to author directly in that layer

Trek Glowacki (@trek) — Beyond Front-end Developer

“Making websites in photoshop is tool abuse”

• The closer you can marry expression to intent is the ideal
• Specialized skills have developed from a lack of proper tools
• HTML & CSS is the medium you are working, not photoshop
• This is the era of applications, not documents, running in the browser
• The time for front-end developers who only know HTML, CSS, & jQuery is over.You need to become a generalist.
• The third path for front-end developers: hand crafted interactive documents (ex. Path to the White House)
• The Avalanche at Tunnel Creek

Rebecca Murphey (@rmurphey) — JavaScript apps that build themselves

View Slides | View Video

• In configuration-driven development, there are 3 key problems to solve: flexibility, interactivity, speed
• RequireJS: The JavaScript Module Loader

Frances Berriman (@phae) — Culture Change

View Video

“When you are designing/developing, there’s only one goal: It needs to be good for users or GTFO”

• Use plain english — mandatory for all sites
• Buzzwords become cliche’s very quickly
• If you want your culture to change, you have to be careful about the language you use
• Instead of talking about ‘user experience’, talk about what you want from it (improved brand/usability, better interaction design, etc.)
• We shouldn’t be talking about ‘responsive design’, because what we want is ‘context aware design’
• The term ‘browser support’ is misleading; ‘verified browsers’ is more semantic in terms of what we are doing
• Put things in context of the user; let data win your arguments