Dan Newcome on technology

I'm bringing cyber back

Archive for January 2018

Editing Javascript

leave a comment »

One of the things I heard over and over again when I first started doing large applications with Javascript was “which IDE do you use?”. At the time I was using Visual Studio. Believe it or not, ancient Visual Studio had pretty good debugging capabilities with Internet Explorer. Everyone knows now that duo did not last.

There was a long stretch of time where I was using the editor of the month. Sublime text or something along those lines. Extensible editors were the rage but it didn’t feel like Javascript was a first-class citizen. I used to tell people that I didn’t use an IDE, which was not really true looking back. I had (and still have to some extent) a collection of VIM scripts that did things like open my editor windows and manage files on the left side. Searching open files and switching buffers. Compared to event to the old Visual Studio it was a little crude. But it was fast and it worked.

Later on I worked for a startup doing Python development. Intellij’s PyCharm was the IDE that we used there and it was amazing. Just every little thing catered to the language and I realized that the shortcuts from their Java IDE were the same. Later when I moved back to doing JS I tried out WebStorm and was hooked.

WebStorm is an amazing IDE. JetBrains did a great job at making it a seamless and consistent experience. Over time I think I kept buying it and extending the license. I ended up using Atom on a team at Yahoo along with the other devs and forgot about WebStorm for a while. Atom was a good editor. It was cool because it was written in Javascript. It was a JS app. While this had a certain appeal, there were some limitations that irked me like speed and opening large files. Coming from VIM this is kind of hard to compete with but it bothered me nonetheless.

I joined a new startup and loaded up WebStorm for the first time in a few months and realized my license had expired again. Not wanting to expense this on my first day of a new job, I opened up MS Visual Studio Code (VSCode). I had it installed out of curiosity that MS was doing an open cross-platform editor written in JS like Atom of yore.

I installed some plugins and started using it. Some people at work asked me what I was using immediately. People started using it. It was catching on for some reason. One guy found that it had a plugin for Emmet HTML generation and he was hooked. People were starting to use it and it seemed like overnight everyone was there. I never even advocated for it, it just happened.

Whatever the case JS is a first class citizen and there are tools out there that rock for dealing with it. The days when I tell people I don’t use an IDE for Javascript are over.

Written by newcome

January 15, 2018 at 1:25 pm

Posted in Uncategorized

Front-end trends

leave a comment »

The last few years have seen an incredible acceleration in the JS and general front-end ecosystem. However, the more things change, the more that they stay the same. The general problem that the Web is solving is still the promise of write-once run most places in some compatible way and without pre-installation. The paradigm is so strong that even native app development is trying to get in on the action.

In the last few months I’ve been involved with a production React Native iOS app and a Chrome extension and a “regular” React JS app. Javascript is everywhere and the tooling has become so fluid that we end up with new tools and best practices between projects only months apart.

When I was working on the Yahoo homepage, the decision to use React had just been made. The Media organization did a full turn to embrace it. The Web framework being used was called Touchdown. The “old” touchdown used Jade templates believe it or not. This had been pretty cutting edge only a year or two ago. Since we had control over this framework we went full steam into converting everything to use React.

However, there were a few old-timers around still that would just open up debugging tools or run things through a proxy and point out all of the issues we were ignoring about page weight, multiple requests, slow rendering, web fonts, and a litany of other issues. This is the old school web. The browser makes requests. CSS comes down the wire. Things block. JS is parsed. Rendering happens. Repaints, reflows, DOM thrashing.

React was created to solve a problem. The problem was how to make rendering UI based on data mutations predictable and easy. That’s really it. It didn’t tackle any of these other issues of content delivery or page performance other than to make disposing and updating DOM very fast and efficient. Effectively re-render for (almost) free. There were some leaks in this abstraction that could be patched manually with things like ShouldComponentUpdate.

Already there are serious competitors to React like Vue and Marko. Web Components have been on the horizon for some time now. We will likely learn the lessons of react and move on.

The JS ecosystem can be likened to learning how to learn or designing a process to produce and artifact faster rather than producing the actual artifact. Babel is ubiquitous so we are transpiling our code everywhere. I wonder if JS is even going to remain. Once browsers support a more general virtual machine and we transpile our JS to that VM, nothing is stopping us from replacing JS wholesale in this ecosystem.

Which brings me back to my initial point. The more things change the more they stay the same. Web front end has nothing to do with JS specifically. It’s HTTP requests and assets. DOM and styling. Browser rendering engines.

Written by newcome

January 15, 2018 at 11:48 am

Posted in Uncategorized