Blog

Reflecting Back on the Forward 4 Web Summit

By Ian McPhail on March 17, 2016

This past month I was fortunate enough to attend the Forward 4 Web Summit (also known as ForwardJS), which is single-day, multi-track conference hosted in San Francisco.

Forward4(2)

Collaborating before the keynote. Photo courtesy of Forward Web Summit.

Although the official event is just one day, the rest of the week is stacked full with hands-on workshops taught by industry leaders. The conference speakers and attendees addressed a broad range of topics relevant to front-end developers.

While the event didn’t focus on any specific area of development, I noticed a few overarching themes emerge after reflecting back on my experience.

JavaScript is Everywhere

Beginning with the first keynote address by Kassandra Perch, developer evangelist and NodeBots enthusiast, the impact of Node.js on the JavaScript community is not to be understated.

Node.js has extended the reach of JavaScript to beyond the web browser, enabling the language to be run on the server side. Being available on the server has introduced JavaScript to a whole host of other platforms, including robotics, physical computing, and the Internet of Things.

As the JavaScript language continues to grow and expand to more platforms, so does the community surrounding it. A community that was once largely comprised of webmasters and script kiddies now attracts back-end developers from other languages, makers, and hardware hackers.

Despite the changes to the language and the community going forward, one can hope the culture of openness and knowledge sharing will continue into the next decade and beyond.

Use the Right Tool for the Right Job

With its increase in popularity and availability on multiple platforms, the JavaScript tooling ecosystem has exploded over the past couple of years. New libraries, frameworks, and build tools are announced every day.

There has been an interesting paradigm shift from using JavaScript as an object-oriented language to a more functional one, with libraries such as React and RxJS gaining popularity. Presentations on applications built with Electron and React Native demonstrated the power of JavaScript hooking into native APIs to deliver sleek desktop and mobile experiences.

During one of the panels, a debate arose over convention versus configuration. Is it better to rally behind a handful of well-built, well-tested, opinionated libraries and frameworks, or to create software architectures that play well with others and allow for more interoperability? Inundated with so many boilerplates, tools, and configurations to go with each, it is easy to feel overwhelmed by the amount of decisions to be made. This sentiment was shared across the board.

One of the panelists offered a practical solution to this dilemma: remember to use the appropriate tool on case-by-case basis, evaluate the requirements of the task at hand, and then determine what your technology stack will be. You may not need the shiny new thing on every project, and sometimes sticking to familiar foundations is the best thing to do.

Code for Humans, Not Machines

Out of all the topics discussed, the one that resonated with me the most was the importance of writing code for the people reading it, and not for the computer compiling it. Too often I find myself writing code in such a way that it is optimized for the engine that will run it (preferring for loops over forEach, for example), but not always for other developers who will inevitably interact with my code.

Code should be written in a way that is readable and accessible to developers of varying skill levels. Conventions used solely for the sake of convenience (i.e. short and undescriptive variable names) and other forms of “tribal knowledge” should be avoided. The use of comments in the code to explain why and how instead of what is also key to helping others understand your code.

These are just some of the important tips I took away from the conference, and I am looking forward to attending again next year.