JavaScript

The Top 10 Lessons Learned from Enterprise JavaScript Development

A week ago I presented a talk at Atlanta’s ConnectJS conference.

The title of the talk was “The Top 10 Lessons Learned in Enterprise JavaScript.” Because it was a JavaScript-focused talk I decided to author the presentation in JavaScript using one of Google’s Html5 projects.

You can view The Top 10 Lessons from Enterprise JavaScript Development and also browse the source.

The deck features frames that load live content to make certain points, so it may take some time to initialize in your browser and may flash some warnings. I took snapshots of the slides with dependencies in case you have trouble loading it.

top5lessons[8]

In the purest sense, Enterprise JavaScript is simply JavaScript used in applications that serve the enterprise, typically via line of business applications. It is typical for these projects to be larger than direct-to-consumer or “brochure site” code bases. Some projects span years and involve hundreds of thousands of lines of code. Another important aspect that differentiates this class of application is the size of the team. I’ve worked on teams with 25 developers simultaneously working in the same code base, and even larger teams exist.

To summarize the deck, after working with JavaScript in the enterprise for nearly two decades I’ve learned these lessons:

  1. Yes We Can! – although JavaScript began as a scripting language to glue Java applets to the DOM, we can absolutely build complex mission critical line of business apps now that the language and supporting frameworks have evolved.
  2. Dynamic Requires Strict Measures – when you are working with large teams the dynamic nature of the language can quickly turn the code into a nightmare. It makes a lot of sense to use languages like CoffeeScript or TypeScript to add form and structure when dealing with larger teams or code bases.
  3. Forget Java and C# – not really, they will still have a place, but with the advent of technologies like NodeJS you can truly write your full stack with one language.
  4. DOM stands for “Demonic Object Matrix” – I’ve found that a lot of the blame JavaScript receives isn’t because of the language itself, but the inconsistent implementation of the Document Object Model across browsers. That is why it is more important than ever to leverage libraries like jQuery and Bootstrap to “normalize” access to the DOM, styles, and behaviors.
  5. Live on the Edge – yes, there was a funeral for IE6. But then things got worse. In this day and age I fight as hard as I can to get out of the rut of writing backwards compatible software for older versioned browsers. Instead, I ask that companies live on the edge versions.
  6. TypeScript is like Coffee – no, not like CoffeeScript. I’ve witnessed the before and after or a team working in pure JavaScript and then migrating to TypeScript and it’s like hitting the nitro button in a race car. Even JavaScript purists on teams I’ve lead have told me after using it they really see the value and are glad we made the switch.
  7. Frameworks Save Lives – I’ve witnessed more than a few heated discussions in forums about sticking with pure JavaScript and avoiding frameworks like the plague. Typically it is the high and mighty architect pontificating about how they mastered the language and everyone should either become an expert or not write code. That’s great for forums and maybe to catch the eye of recruiters but in the real world time is money and frameworks help us scale and deliver applications more quickly. I can ramp an Angular developer onto an Angular project far more quickly than I could on a project that features “Jeremy’s super ultra perfect because he knows JavaScript proprietary framework.”
  8. Don’t Just Write It. Build It! – this simply means we no longer have to use NotePad to author JavaScript. It is integrated well into IDEs but more importantly we now have excellent frameworks like Gulp and Grunt to help build JavaScript and web-based applications. Use them! ASP.NET MVC 5 embraces this approach out of the box. Microsoft’s Visual Studio Online build process now features specific build steps for installing Node packages and using package manages like Bower to pull down dependencies, then build apps using Grunt or Gulp.
  9. Be Testy. Be Very Testy. – the day and age when JavaScript testing was difficult is long gone. There is no excuse not to test your JavaScript code and do it in an automated fashion that gates check-ins and runs in continuous integration and continual delivery processes. If you’re not testing, you’re not serious about your app.
  10. XML is Dead. Long live JSON! – do I really have to qualify this one? Let’s finally put to rest that chapter of SOAP and XSLT that we all participated in and were glad to move on from. JSON practically writes itself.

I’m done. There is a lot more detail in the deck so please view The Top 10 Lessons from Enterprise JavaScript Development and also browse the source.

Jeremy Likness

Jeremy Likness is a principal architect at iVision, Inc. He has been building enterprise applications using the Microsoft stack for 20 years with a focus on web-based solutions for the past 15. A prolific author and speaker, Jeremy's mission is to empower developers to create success in their careers through learning and growth.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Back to top button