warpedvisions.org

programming

2017 was a good year for JavaScript. The newer language features are now part of our daily routine. Tightly integrated CI and packaging scripts are the norm, and we have a huge sea of libraries and tools available to us. The core JavaScript frameworks have settled down and matured to the point that we can be confident in JS as the base for large-scale commercial projects.

Here are a few of the main JavaScript things that impressed me this year:

GraphQL for Node.js is the most exciting library of 2017. GraphQL (the QL stands for query language) is a natural evolution of APIs: it makes it easier to ask a web service questions without having to work as hard for the answers. While RESTful APIs provided a clean way to publish and present data, building APIs based on static object definitions force a lot of work on the things that need the data, which is wasteful and complex (as you end up with much more data than you need). And while including the concept of server-side queries isn't new to APIs, GraphQL does it with a simple syntax that fits nicely into the JS world.

React had a great year as well, with a major feature release and some sweeping licensing changes. I think the combination of these changes and the vitality of the React ecosystem have pushed it well past AngularJS this year. Redux has gained a bunch of ground over Flux this year too, though Facebook could undo that in 2018 with their partial-kinda-sort-of replacement QL/Flux hybrid Relay. The next version of React Fiber has already landed in v16 and will be core to significant improvements to React applications in 2018.

One of the ways to gauge the success of a UI framework is in what gets built with it. This Fall I found a solid spreadsheet component. I've also been using SemanticUI and its React bindings, though I am a bit worried about their slow pace of updates. There are a few commercial UI kits, like ExtReact and Webix that have some legs, though I'd love a richer open kit that we could all contribute to.

I've worked to improve how we develop software this year with things like deeper CI, better Lint and formatting tools, and better practices. In our quest for improvement, I found Prettier, a JavaScript code formatter that is pretty smart about line lengths and readable code. You can use it in your build scripts, CI, or your favourite editor.

Speaking of editors, I switched to Visual Studio Code this year, which is built on Electron (Node, Chromium, and V8). VSC replaces both Atom and Sublime, as well as my older favs Coda and Espresso. Visual Studio Code plays well with all of the recent linters, CI, build tools, and other gizmos. It performs well for coding tasks in JS and the various web formats I use regularly. When I work with larger text files, however, I'll still switch to the Vim of Mac (TextMate), or actual Vim (though I'm getting pretty rusty with that these days).

There was a time when I couldn't imagine Microsoft as a leader in OSS or web tech, but they've found their mojo with VSC and have a steady release cadence that's downright impressive.

One of the best things about JavaScript in 2017 was the huge selection of mature and featureful libraries.

Formatting dates in JavaScript, for example, has always been a bit of a pain, but libraries like date-fns make it a breeze. Similarly, CLI apps have always felt a bit clunky to build with NodeJS, but I found that by using Ink, a React-like library and components for CLI apps, I write a lot less fiddly console.log() code. Ink also makes it easy to write more complex CLI tools, which could be especially good for the ecosystem.

In terms of packaging tools, I haven't sided on a single bundler this year. That said, I do find webpack easy to set up and use. It's one of the current generation of build tools, and has simpler, clearer configuration than its predecessors. ParcelJS is on my radar as a simpler way to bundle JS applications, but I haven't had a chance to use it on anything big yet.

And while there are too many JS libraries to mention, the exciting thing is that there are huge communities and tools for recommending great libraries, like MicroJS and JavaScript weekly.

Storybook is one of those unexpected tools: it's a mature UI builder for ReactJS, that feels about the way a UI builder should feel these days. I didn't find myself getting lost in a tonne of automated code generation (i.e., it felt surprisingly lightweight). I haven't used it in production yet, but I'm looking for ways to make it part of my prototype toolchain for early 2018.

And finally: as JS matures past ES6 and ES7, the language is getting easier to teach (and learn). Here are some resources to help you learn more about the evolution of JavaScript:

#JavaScript #Programming

I'm a bit surprised that the argument over tables versus semantic layout is still floating around. It ignores the obvious:

  • Any set of nodes can be rendered like a table
  • Any table node can be rendered like a non-table node

There is no difference between a <div> and a <td>, except for the default layout settings and nesting. The major browsers support the distinction with the display: table-cell; and its important variants, so it's a matter of how you want to organize your data.

The argument is really semantics versus easy pixel perfection. Sub arguments include, “Do I really want my site to adapt to various handheld sizes?” and, “Screw accessibility, I like my pixel perfect layouts, thank you very much.”

The whole discourse ignores where the W3C is aiming HTML5, which is to use things like section, article, header, footer, and nav. These tags are much nicer than <div> or <td> soup, at least to me.

But screw semantics, you want your perfect little px layouts.

The complaint about pages that use positioned or floated blocks is the “difficulty” in rendering the classic column layouts. You know, the column layouts that don't behave like newspapers (text doesn't flow between columns). And guess what? These classic column layouts are based on—-wait for it—-the table layouts of the 1990s. HTML1, without any stinkin' CSS. We did what we could then, with the tools we had.

Of course real column layouts are possible now with CSS3, where text and headlines can flow between proper columns, where you can control flow (roughly at least), and where you can make the columns look like real print columns. And reasonable faux-tabloid-sidebar-content-sidebar layouts are easy to build without table blocks, if you absolutely must have them, and you're still free to use table block rendering if you're so inclined.

But people want their pixel perfect, hey-look-I-can-use-Photoshop layouts, without having to work for it. These people miss the point of putting stuff in a browser, which is, “Hey, look, people can view this stuff in browsers of all sorts on hundreds of different hardware and software platforms!” You get a huge potential audience at the cost of easy pixel perfect layouts.

You can still churn out perfect layouts with all sorts of hacks and caveats, but the argument for putting things in tables is mostly unrelated. There are other ways to get the same effect, while making your content make sense to your future self and automated tools of all sorts. And there are better ways to get a good effect while supporting a wider range of browsers and tools. Fluid layouts are way more interesting anyway, as they work in more browsers, more usefully, and with less work.

Tables have their place, of course, for things that are actually tables of data. Even then, you could use paragraphs and headings if it made more sense for the content.

So it's really pixel-perfect and familiar versus ubiquitous, useful, and semantically meaningful.

It ends up it's all about the data. Make the data obvious, and everything else falls into place. HTML5 has enough semantic and layout expressiveness to wrap data in a way that is obvious and easy to make look good.

</rant>

#CSS #Programming