Brad Prymicz
Brad Prymicz / Development / June 30th, 2014

JSConf Made Me a Conference Convert

There’s nothing like a long road trip to get you in the mood to talk to people, and there’s no better reason for a road trip than for a conference. OK, that last part probably isn’t true, but after my first conference experience at JSConf – the ultimate JavaScript meetup – last month I’m pretty sure it might be.

Although I’ve worked as a developer for more than 10 years, I’d never been to a conference before, and I have to say: I’m a conference convert.

JSConf in Jacksonville

Before I dive into the specifics of the event, I need to apologize quickly to my former coworker Rich, who was always bugging me about going to events in San Francisco or Austin. He would return from his conference journeys with wild ideas and pictures of “So-and-So from the Angular.js team,” and I would roll my eyes at the big waste of time and money.

With heartfelt apologies to Rich, I now see the light. After JSConf outside Jacksonville two weeks ago, it was obvious that people – fresh off road trips of their own – came ready to talk, learn and get to know each other.

More than 700 JavaScript enthusiasts and their families were all over the hotel and surrounding area. They were on the streets, in the lobby, in the bar, in the pool and on the golf course (more on that later).

The glow of Macbooks was everywhere, and JavaScript on every screen.

jsconf
JSConf from @pgevol

The State of JavaScript

Unlike many of the other programming languages, there are many factions with-in the JavaScript community. There are many ways to achieve the same goals. There is Angular, Ember, and Backbone for developing single page apps.  There is Lodash vs Underscore for sorting and manipulating data. There is JavaScript in the client, on the server, and in the database. Each implementation and use case have their own opinions baked into them.  They each have scenarios that they are best suited, but unfortunately that means there is a learning curve on each one when trying to use best of breed for each application.

ECMAScript 6

The ECMAScript 6 (ES6) standard is still being finalized, but the community is hard at work trying to prepare for its adoption. Compilers, Macros, and Package Managers are all being developed to allow developers to be ready for ES6. The hope is that by the time that ES6 is fully supported by the browsers, developers are already familiar with the syntax and benefits of ES6. The package manager component of ES6 was there in many forms. On the server node.js has NPM and there are many trying to bring that to the client side as well.

Package Manager

On the client side, the talk of the conference seemed to be Browserify (browserify.org). Browserify allows you to build your client side JavaScript in modules. This allows for better re-use and portability, which will lead to faster coding and easier integration with past and future projects.  There is a lot of power in being able to quickly and easily import functionality modularly. Imagine being able to start up a new project by picking and choosing from the company modules. Without writing a single line of code, you have a base app that has all the hooks into company services.

Compilers and Macros

Compilers seem to be waning in interest, but they were touched upon for TypeScript and Closure. The overhead of the compiler and restrictions of following someone else’s standard seems to be driving the movement towards Macros. Macros seemed to have a much larger presence, at least in the talks.

The big two that were discussed were SweetJS (sweetjs.org) and Recast (github.com/benjamn/recast). These libraries allow you to write ES6 code or write your own language to then convert to whatever the new standard is at a later time. Code re-use is always in fashion, so the idea of being able to short hand some code and have the macro replace it with a consistent approach is appealing. Being able to change multiple implementations at a later time by changing the macro can really help in refactoring if, for example, a library you are using has become deprecated and replaced with another.

Once again, the learning curve and proper implementation is left up to the development team. This doesn’t absolve the team of following corporate standards, but it might go a long way to making it easier.

The JavaScript Community

Even with all the factions, it was very apparent that everyone there was ready to learn, challenge, and share their work. The JavaScript community is very open-source friendly, which seems to transfer over into the people as well.  They all agree that the future of JavaScript is bright, and that IE is the bane of their existence.

I got the opportunity to talk with many people from the industry. I was even able to golf in a scramble with one of the major contributors to Node.JS. Being able to talk shop in a casual manner and take out some frustration out on a little white ball was great. We talked about how Node.JS pushes forward towards the enterprise, private github, private npm, private everything.

It’s an exciting time to be using JavaScript. Even with all the various methods of doing things and the different philosophies on how to apply it, it is refreshing to know that the community behind it is so willing to help and collectively push JavaScript forward.

Conclusion

Leaving the conference, I was excited to get working on my next project. The JavaScript community is strong and excited, and that is contagious. Being new to 352, it gave me a great time to get to know a member of my new team, debate where we should go, and combine work and fun.

So if you’re on the fence about attending a conference, I highly recommend it. Go with a charged battery, a folder for all the new bookmarks you’ll want to follow up on later, and most importantly an open mind. Make contacts, make friends, and find inspiration.

Now, if you’ll excuse me, I need to go call and tell Rich how right he was about conferences.

 

Image credit: Digon3 CC BY-SA 3.0