Pony Foo

Ramblings of a degenerate coder

Fast-forwarding the Web Platform

reading time: , published

Peter-Paul Koch – or @ppk – has once again published a rupturing article titled “Stop pushing the web forward” that is surely going to set the agenda for this week in terms of blog posts and twitter traffic. Already, Christian Heilmann – or @codepo8 – wrote a brief article mentioning how the conversation can get lost in the Twittersphere and how it’s better to lay out your thoughts in your own blog, particularly if you’re trying to make a thoughtful argument against something that’s not just going to meaninglessly spread like wildfire – but without any real substance to it.

In his post, @ppk argues something that I’ve heard before, that we would do good to consider pacing down on new developments – and how we should focus on improving the most rudimentary things that are still so very impossible to work with on the web. While I don’t think a moratorium, nor slowing down the pace are proper answers – the problem is unquestionably there:

How did we get to the point where we are able to have realtime bi-directional peer-to-peer communication between visitors to our site, yet we can’t determine the styles for a measly <select> input, we can’t customize form elements like <input type='check'>, we can’t use pseudo-selectors like :before or :after on certain elements like <img> or <input>, because these are “replaced elements”what the hell is that?

To me, the problem is not that we are moving too fast on cutting-edge technologies such as WebRCT, HTTP 2.0, enforcing TLS, Service Workers, ES6, ES7, WebP, Web Audio, WebGL and countless others. Rather, the problem is that we are making no effort whatsoever to fix things that have been broken forever, like being able to give basic styling to form elements in a non-over-engineered way.

I vehemently agree that constraints drive innovation, as @ppk points out in his post. I think the web platform is constrained enough as is, though. However, I do get what ppk is trying to get out there – we are worrying too much about these complicated things and missing out on the essential. For us to keep on focusing on the complicated problems we all know and love, we should deal with the inexcusable pain points of the web, such as how lousy form elements behave, how lame native form validation is (where by the way, you can’t style the validation errors consistently nor effectively), and how JavaScript ends up becoming the de-facto excuse for all of this “well you can do it with jQuery”, “well, it works if you add some JavaScript sugar cones on top”. Problem is, this is as rudimentary of an excuse as “it works on my machine”, and we all know by now that’s a terrible excuse.


Read the full article

Composable UI

reading time: , published

Most often, web UI libraries fall under one of two categories. They may be part of a “framework”, or a grouping of UI components that share an appearance, a similar API, or are otherwise cohesive. Another category is usually the standalone library. Regardless of whether a standalone library depends on jQuery (I’m singling out this scenario because of its prevalence), they aren’t directly related to other UI components, which means they set their own terms with regard to API, appearance, and other conventions. Components that are part of a framework are usually hard to integrate with anything that’s not part of said framework, resulting in vendor lock-in. Components that aren’t part of a framework tend to be easier to integrate with other things, but most often they’re not designed to that effect. Composability is a much better alternative, and something we’ll explore in depth in this article.

Before I go any further, dragula now has over 7500 stars on GitHub and was even featured on The Next Web! I’ll need a few moments to wrap my head around that! Wow.

If you’ve never seen dragula, check out the demo to get an idea of what it does.

Instead of having an autocomplete, a drop down list, a combo box, and a select box, it’s nice when you can do all of that with a single component. That’s reusability, you get to use the same component for many different use cases. Another form of reusability is composability, the ability to integrate a few different components into a cohesive user experience. It’s an often overlooked factor when developing UI components, but I think good UI components must be highly composable.

Composability can also go the opposite direction. Some programs are notoriously modular, and it gets quite a few bits and pieces (otherwise called “modules”) to get to something that “works”. One such example is woofmark. This library provides an editor on top of browser HTML <textarea> elements. I’m not using woofmark on ponyfoo quite yet, because I haven’t had the time to integrate it here, but I did implement some of the underlying modules. For instance, woofmark uses megamark under the hood to parse Markdown strings into HTML strings. Megamark is really an abstraction layer on top of markdown-it, which adds a couple of minor niceties such as syntax highlighting in code blocks, and the ability to use <mark> DOM elements to highlight a “fancy” piece of text. Woofmark also uses domador to convert DOM trees or HTML strings back to Markdown, and that has a extensibility structure in place allowing one to extend their understanding of how HTML should be converted into Markdown. If you had custom Markdown -> HTML directives, it’s only logical that you implement the reverse for a HTML -> Markdown conversion. With all this converting going on, it’s probably insane to try and sanitize the inputs and outputs on your own, so a specialized library takes care of sanitization at the HTML level.

I’ve already mentioned a few modules, each in charge of a different portion of the rich-editing experience in woofmark. Here’s a list of the modules I’ve mentioned, plus a few others even deeper in the dependency chain.

  • markdown-it is one of the lowest-level modules used in this use case, and it parses CommonMark-compliant markdown into HTML strings
  • megamark is a wrapper around markdown-it which ties it with highlight.js, a syntax highlighting module and insane, the HTML sanitizer
  • domador parses HTML or DOM nodes back into Markdown, and can be extended to match the extensions provided to megamark, so that the output stays consistent both ways
  • woofmark ties everything together and provides a nice <textarea> upgrade that allows entering Markdown, HTML, and WYSIWYG input in exchange for plain Markdown
  • Plenty of other low-level modules are at work, such as crossvent for dealing with DOM events in a cross-browser manner; he, which deals with unicode; and jsdom, which deals with creating a window context on the server-side; and many others

As you can probably imagine, trying and cramming all of this functionality into a single module would be a dreadful endeavour, not to mention a waste of productivity, time, and hence, ultimately, money. In contrast, keeping the functionality in separate modules enables us to reuse them across our stack, across our projects, and out on the open-source world, where people find it way easier to contribute patches if the code is small, self-contained, and does one thing well.

Read the full article

Testing JavaScript Modules with Tape

reading time: , published

I held a survey last monday where I asked for feedback about the kinds of things you want me to write about. It was quite useful, and one of the topics that seem to interest quite a few people is regarding module testing. Using tape, proxyquire, and sinon is the best possible combination of modules when it comes to testing JavaScript applications, regardless of them being server-side or front-end code.

In this article well get an in-depth look at these three modules (tape, proxyquire, and sinon), learn why they are better than the competition, how to use them, what each of them is good for, and how they complement each other to provide the ultimate “testing harness”, figuratively speaking, no test harness is actually needed!

While everything else in the JavaScript universe seems to be moving at blisteringly fast speeds, and accelerating, testing is in this weird place where globals are mystically okay. Frameworks like mocha and jasmine dominate the field, while they require a test harness, litter the global object with variables, and generally go against established best practices. I’ve always found it kind of really weird that test frameworks, which are supposed to be used to improve the code quality around a codebase, may end up doing the exact same opposite by encouraging the usage of globals and awkward monkey patching.

Nevertheless, let’s jump into the awesome world of testing with tape, proxyquire, and sinon, right after a brief note about the survey I ran last monday.

A Quick Note About the Survey

Many thanks to everyone who took the time to answer the survey. You gave me a few ideas about the kind of content I could write, and I also got some very useful insight into what people reading this blog enjoy (and dislike) the most.

I suppose the results themselves aren’t that interesting to anyone that’s not myself, but here they are anyways, for the sake of transparency. In general, people would like to learn more best practices, guidelines, code quality, tutorials, and in-depth articles, and not so much about rants.

What type of content is liked the most

I’ll do my best to keep the rants in check, but keep in mind the tagline of this blog!

Read the full article

The Progressive Web

reading time: , published

I've blogged very little about Taunus since I first released it, roughly a year ago. Back then, it only powered, but now there's a few cases in the wild where it's being used, and I even got to do some consulting in a project where they're using Taunus! In the year since its release, it has had a whooping 174 releases, but not a whole lot has changed, and its API has remained stable for the most part. Its feature-set grew quite a bit, although it remains fairly light-weight at 18.8kB after gzip and minification. Today, it's able to figure out how to submit forms via AJAX automatically, as long as they already work as plain HTML, and it has support for WebSockets via a plugin.

If I were to define Taunus in "elevator pitch" style, I would say:

Taunus is the logical step forward after server-side MVC web frameworks such as Rails or ASP.NET MVC. It turns server-side rendered apps in Node.js (or io.js?) into single-page applications after the initial page load by hijacking link clicks, form submissions, and defining a format you can leverage for realtime communications.

Building an app in a Server-First fashion is important because then you aren't taking a huge leap of faith in assuming that your customers have a browser capable of supporting all the bleeding edge features your dedicated client-side application demands.

After the initial load, which should be blazing fast so that your customers are happier (tons of research point to this fact), you can should turn to a single page application, hijacking links, making AJAX requests that ask for the bare minimum (view models) and then rendering those view models directly in the client-side.

Why Server-First Matters

Server-First matters because it's the exact opposite of breaking the web. You establish a bare minimum experience that you know most people can access, a baseline, and you go from there. This baseline isn't just there for SEO purposes or to be more amicable to people turning off JavaScript.

Think of the ways in which your app is shared on the web. What other places is it rendered to? Services that crawl around it. With client-side rendering, Twitter and Facebook display a pile of garbage instead of descriptive metadata and a thumbnail whenever someone links to your site. Humans might think your site is bogus and not even click on links leading to it, because the description on their Facebook feed just shows a bunch of Mustache templates and gibberish.

Search engines other than Google are completely oblivious to your content. Even Google is not as good at crawling client-side rendered apps as you think they are. Often times, you also get penalized for not being fast enough.

Mobile performance degrades substantially in client-side rendered applications as opposed to those server-side rendered. Both because the connection is slower, and because the scripts you depend on to actually render your site take a long time to download. When they do, mobile devices take longer to parse them and execute them, because they're not as powerful as the Mac Book Pro you use during development.

Demand Progress!

Not doing server-side rendering might be just as bad as not designing a website to be responsive.

It's about time we .shift() "SEO purposes and <noscript>" from our list of excuses for not doing server-side rendering anymore.

Read the full article


reading time: , published

Peter-Paul Koch (@ppk) recently wrote an article that generated noticeable turmoil. One of the best responses was Jeremy Keith (@adactio)'s article, "Instantiation", where he graced us with a flurry of responses from different bloggers, as well as a timeline and his analysis of the situation as a whole.

Earlier today, @ppk published a follow-up post, where he mentioned Tim Kadlec (@tkadlec)'s article on "Choosing Performance". Tim rightly asserts that the web is not inherently slow, and that if a site is slow it's merely due to the fact that performance wasn't prioritized by the site's maintainers. Similarly, Jeremy posited that services such as Instapaper or Pocket shouldn't have a reason to exist. Besides being well-designed products that many of us use and love, that shouldn't be the case, websites should offer that degree of usability, and accessibility on their own, Jeremy argues.


What if we were to focus just on the content? Are any prominent "apps" as ad-dollar hungry as the screenshot above?

Everyone seems to agree that the crux of the issue stems from media deals and dollar-hungry marketers who have little interest in much else than profits. I tend to agree with that view. Most consumer-facing media rely directly on ad revenue, have little to no regard for their typical user when it comes to the effects these ads have on their experience (hey, we call them "users" for a reason, right?), and simply keep on piling on advertisement.

Sure. There's definitely some excellent original work in there — in the middle of all those ads and self-links and chrome and value-added "journalism."

I don't see this trend being anywhere close to slowing down, quite the contrary. Video advertising is becoming more and more prominent, huge unoptimized hero images and annoying interstitial dialogs that want you to download a mobile app that's supposed to do what the site you're already on should be doing, along with ridiculous laws, are all becoming lingua franca in web publishing.

All of this wouldn't affect us as web workers if it weren't for the fact that all the extra cruft is being blamed on the web platform itself, as @ppk and @tkadlec point out. It's not even just the bloat, but we also keep on breaking the web by trying to mimic mobile applications, in one of those desperate attempts to become successful by imitating aspects of a business (e.g Google's 80-20 rule) that have very little to do with their actual success. Scrolljacking, irritating banners that only frustrate the hell out of users who don't want to install your app for no good reason, and similar tactics to drive mobile app usage have done nothing but hurt.

It's time for the web to step up.

Read the full article

Designing Front-End Components

reading time: , published

Last monday I published an open-source library to easily take control of drag & drop in the front-end, dragula, and it has amassed over 2000 stars on GitHub in under a week. Previously I had published a date picker component, Rome, that's somewhat popular among the nerds. In this article we'll discuss how you can build and isolate components that have a simple API.

Dragula had a much faster growth rate than rome did, and that's mostly due to the fact that there were basically zero proven libraries that solve drag & drop (and drag & drop alone) while being flexible and simple. I emphasize the fact that it does less as a feature, and not a problem. In my experience, I've found that the best pieces of code I've ever used tend to follow the UNIX philosophy of doing one thing very well. Having that kind of focused approach to front-end modules typically isn't the case. Instead, we often develop solutions that are only useful in our specific use. For example, we may put together an entrenched AngularJS directive that uses other directives or relies on data-binding provided by Angular.

What's worse, most often we don't just limit ourselves to the scope of the libraries we're currently using, but to the specific scope of the one project we're working on. This means that now our library can't be extricated from that database without considerable work. For instance, consider that one time you developed a UI component where the user would type tags in plain text and after typing a delimiter (a comma or a space), they would get visual feedback into the tag being accepted. Something like the screenshot below.

Screenshot of Insignia in action

Except for the fact that, unless you found what you needed on the open web in the form of a decoupled module, we sometimes commit the crime of tightly coupling the tagging feature to the framework we're using. Or to a library. Or to our application. Or to a specific part of our application.

It would be best if were able to identify what it is that we're trying to accomplish (in this case, improve the UX on an input field for tags), isolate that into its own module, and come up with the simplest possible API. Coming up with a simple API is often a dreadful task, and in this article I'll try to put together advice and explain my thought process while designing them.

Read the full article