Dan Newcome on technology

I'm bringing cyber back

Archive for the ‘Uncategorized’ Category

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


leave a comment »

I’m trying to distill some design wisdom I’ve come across over the years doing front-end work. There’s always this phase of any project where designers have a system of styles and components in Sketch or Illustrator. Sometimes this system is ad-hoc and sometimes it’s quite premeditated and referential. Either way the system must be translated to code by developers.

In the code world, we strive to define things as few times as possible (ideally once) and reuse things where we can while still allowing us to easily break out of the defaults where we need to without much effort.

Getting this all set up is easier said than done and many times the system is quite clean until part way through the project where it gets messy all of a sudden when some assumption made earlier suddenly doesn’t apply after all.

I’m being deliberately general here since what I want to do is put forth a few simple rules to derive the specifics from. These are:

Avoid semantic styles

When I was first introduced to atomic CSS I started to realize how problematic commonly created custom CSS rules like `button` and `top-navigation` were. This is the root of unmaintainable and impossible to reuse styling. Atomic CSS espouses composition of small rules. If `button` is a rounded corner box with a border and gradient it’s better to have rules for the border style and background applied separately to form a component called `button` rather than describing the styling directly in CSS.

Themes are pulled instead of pushed

It’s tempting to create page-level rules that define things like font sizes and colors. This is dangerous because it’s hard to prevent unwanted side effects in the components to which the rules are applied. It’s also tempting to create top-level rules that affect only certain things on the page but not others by pure coincidence such that later changes will cause undesirable effects that need to be locally overridden. Theme elements should be available globally but applied locally. I’m referring to this as “pulling” values from a global context rather than having the CSS engine “pushing” things down automatically from the stylesheet.

Themes consist of a fixed set of attributes

Decide on a fixed set of things that are part of a theme. This includes colors, sizes, border radii, etc. Provide default values in the theme. Having well-known theme elements will avoid confusion and allow re-theming to be done smoothly without errors.

Use sequences/functions (scales) for sizes

I learned a secret about layout from a CSS library called Tachyons. The idea here is that you don’t need that many pixel sizes to make a well-designed layout. In fact the sizes/proportions that aren’t used are just as important as the ones that are. Make omission part of the design. An example here (I never used this, and it probably looks bad but it illustrates the point) is to use a Fibonacci sequence for margin sizes [1,1,2,3,5,8,13…]. I think of these like a musical scale. There are certain notes (sizes) in the scale but some are omitted.

Distill intent

It’s important to specify the meaning of layout and positioning. What I mean by this is that sometimes designers will nudge spacing around elements to that they line up in some way that isn’t explicit by looking at the design. For example an element might be two-thirds of the way down its parent but looking at the Sketch layout we see that it’s 235 pixels or something like that. It’s easy to see centering and sometimes the tools support notions like that but often implicit layouts are hard for developers to pick out.

The only answer here is to design with these intent rules in mind and call them out or reverse-engineer them with the help of design by asking “what did you mean here?”. Which brings us to the last point:

Specify exceptions

Not everything fits into a neat box and sometimes design is akin to kerning text where we need to take visual weight or color or any one of a hundred different subtle factors into account when doing layout. Exceptional cases should be called out and reused if possible. This is kind of an anti-theme. The things that apply once instead of the things that apply always.

I’m thinking of calling this CSStem (CSS System). I’m not sure what form it will take. Probably a document and some examples along with tooling for generating a style guide/gallery/storybook type of web page as output.

Written by newcome

August 23, 2017 at 5:33 pm

Posted in Uncategorized

Sprint tactics versus strategy

leave a comment »

At work right now we have moved from a one week sprint to a two week sprint. This didn’t seem like a big deal at the beginning. The idea was that we spent a lot of the time as a percentage of the work week doing sprint planning and retrospectives. We thought that a two week sprint would let us get an ideal ratio of work to planning.

The reality is a bit different. What we saw was that we had to do a mid-week correction after things didn’t go as planned in the first week. This arose on Tuesday standup of the second week as we looked at the burndown chart.

I’ve been a few places now where we wanted to change the sprint length, and I think I’m starting to see a pattern. The stakeholders see sprint planning as a strategic tool, and the implementers see it more as a tactical tool. Strategically it is advantageous to see out two weeks in advance, but tactically it’s more useful to look at the next few days. I think a lot of conflict and misunderstanding around agile stems from this split.

So is a sprint a strategic tool or a tactical one? I’m still not sure.

Written by newcome

May 16, 2017 at 9:53 am

Posted in Uncategorized

React Native

leave a comment »

I’ve started a major React Native app recently after doing a bunch of “regular” react stuff. I had pretty early access to React Native when it first came out, but really didn’t check back in on it until I started using it in earnest recently. It turns out I had some preconceptions about it that aren’t really accurate and I thought it would be interesting to talk a little bit about that here.

Write once, run anywhere

We’ve heard this one before. The first for me was Java applets, but some form of this narrative seems to pop up in different forms over and over. The Web is pretty close to this but it’s more like “write once run most places sort of”, which is honestly a little bit better than “write once crash and do nothing in 10% of target environments”.

How does this relate to React Native? Well, in the back of my mind I thought of the project this way. Write React components and use them on mobile and the Web. Well, it doesn’t take long to realize that there are no divs in React Native. In fact apart from the same jsx syntax, the components are all different. What about CSS? That’s there sort of, with slightly different attribute names. Oh and layout is centered (no pun intended) around flexbox.

Components and Composition

Ok, this one I actually had right. The basic ideas around composing an interface translate pretty well, just without much ability to share components between Web and native.


Getting from screen to screen is totally different using React Native’s own navigation components. This makes sense since the target is different, but again, it’s a major difference between a Web app done in React and a React Native app. Apparently react-router now supports React Native as well but from my cursory looks it’s not clear how standard app navigation transitions work in that context.

That’s it for now. I’ve been super busy lately but more React Native stuff to come.

Written by newcome

May 15, 2017 at 2:13 pm

Posted in Uncategorized

React reactions

leave a comment »

One of my past articles commenting on the future of Web development has gotten consistent traffic in the years since I wrote it, and now I feel the need to follow it up because I think I was way off about a few things.

Just to be clear up front, Reactjs is eating the Web when it comes to front-end development. I’m aware that Angular and Emberjs hold sway in many shops, but I think that the virtual DOM model that react is based on will eventually become a standard way of dealing with front-end Web development.

Most frameworks and methodologies in the past have centered around data binding or observers of some sort to implement some variant of the MVC stack. React really just implements views. The difference is that the views are much simpler than the average MVC view (in which case the view really has some complicated state-management code along with it that makes it more like a view+viewmodel to handle updates to its state).

React views still have state, but the view is re-rendered fully every time the state changes, rather than having some kind of JS functions for things like adding/removing items from a list. This fact makes the nuts and bolts of keeping a dynamic view up to date trivial. No sequence of add/remove/updates need to be tracked in order to manipulate the DOM into the state needed to accurately reflect the current application state.

This isn’t without its problems though, since many things in the DOM don’t like to be manhandled (iframes). Also, React basically has full control of your DOM. If you don’t want React to mess with something on the page, you are out of luck unless you want to put it outside of the React render tree.

Apart from views, the Reactjs model is a little more ambiguous. Facebook prescribes the Flux architecture, which essentially leaves everything up to you other than the enforcement of single-direction data flow.

I’m going to save Flux for another article, but just to give you a teaser I think that functional programming is finally winning. Neckbeard nerds have been blabbing about functional forever now (I love me some Clojure) but I think that when the tide turns (as it has) away from Ruby-style mixins to higher-order components we are going to see things really starting to shift.

Written by newcome

November 6, 2015 at 1:46 pm

Posted in Uncategorized

Quantified blogging

with 2 comments

I’m starting to look through my blog stats after a while of not paying much attention to them. I posted the first post in over a year recently and it has only garnered two views. This basically tells me that nearly 100% of the traffic here is residual via search and maybe old Hacker News link juice.

The funny thing is that even after not posting for a while, I’m still getting traffic. It probably takes quite a while for traffic to fully taper off, if ever. As long as Google has some of these articles indexed, I think there will probably be traffic indefinitely.

Anyway, there seemed to be a lot of pressure in the past to hit my high water marks, but now I guess the best thing to do is just get a cadence back and see where things go. Just as a parting note, here is what WordPress is telling me about my best traffic day ever. I think it’s worth posting since this is what an artificial bump gets you, and it’s 100% unrealistic to live up to something like this without Hacker News or maybe Reddit.

Screen Shot 2015-11-06 at 1.16.26 PM

Written by newcome

November 6, 2015 at 1:23 pm

Posted in Uncategorized