Last week, I attended the JS.GEO event in Philadelphia. In this post, I offer a brief recap of what I saw. It is brief for two reasons. First, it has already been ably covered in detail by others. I went on family-related travel immediately afterward and could not sit down to collect my thoughts until the latter part of this week. The existing posts cover the blow-by-blow well. Second, due to the aforementioned travel, I had to leave the event shortly after lunch.
I’d like to first state that the event was very professionally coordinated and organized by Chris Helm and Brian Timoney. The choice of Philadelphia was a masterstroke as it is easily accessible from Boston to Richmond. The venue was a short walk from the train station so getting to it took only slightly longer than a regular commute by car into DC. My company was one of the sponsors and we are happy to have supported it. We’ve made quiet use of varying permutations of JavaScript and geospatial tools for well over a decade and felt like sponsoring JS.GEO was a good way to give back and support the community.
The one-day, no-fluff model of JS.GEO is one that should be emulated more often. The small time commitment makes it easy to fit into a schedule and the low cost is accessible to a wide variety of budgets (student, local government, etc.). The tight schedule was a positive to me. There was a lot of good technical content without a lot of the marketing fluff that comes with other, larger industry events. The fact that that JS.GEO is vendor and philosophy-neutral is refreshing. While there is a heavy contingent of open-source tools being discussed, it is not specifically an open-source (or closed-source, for that matter) event. Those types of outlooks were checked at the door and the pace of the content didn’t really allow them to surface. As a result, the audience was able to focus on the merits of the solutions and approaches being presented. Our industry could use more of that.
As for the content itself, I will discuss it thematically. When I attended the first JS.GEO three years ago, JavaScript was already in wide use in the geospatial community, with plug-ins quickly on their way out. Node was on the radar but I wouldn’t have called it ubiquitous at that time. There were numerous applications shown and discussions of various JavaScript frameworks and an observer could see an upward trend.
This year’s event makes it clear that JS.GEO is no longer the name of an event but rather a proven stack implementation concept. Node is clearly the application server of choice and this year’s talks featured some that discussed full devops and deployment workflows. The applications shown were not cobbled together from frameworks but were quite recognizable to anyone who has deployed enterprise-scale applications using other technologies. JavaScript has come a long way in the geospatial community in a very short time.
This kind of rapid change is bound to shake things up a bit, which brings me to a technology that did not exist at the first JS.GEO but was ubiquitous at this year’s event: Turf. Usable on either the server (Node) or in the browser, Turf provides advanced spatial analysis capability, with the ability to do so in the browser being the most appealing to me. Turf was mentioned so often in the presentations I saw that I began to wonder if I was at a landscaping convention. It’s been on my to-do list for a while but I cracked it open since I’ve gotten home and plan to rework some previous applications to use Turf.
My brief stay at JS.GEO was informative and motivating. Thanks to Chris, Brian, all of the presenters, and all of the other sponsors for making it such a worthwhile event. I am looking forward to next year.
