Tag descriptor

Static site generators

An article, posted more than 3 years ago filed in ssg, jekyll, jamstack, javascript, api, markup, markdown & static site generators.

Static site generators mix the maintainability of dynamically rendered sites with the speed and ease of hosting of static sites. It comes at a cost, which is interactivity. Hence typically static sites are enriched client side JavaScript communicating with API's, which has been labeled JAMstack by an org pushing this market.

I’m currently in the process of selecting a static site generator. Based on Github stars this is the current top 10 at Jamstack.org’s overview of static site generators:

  1. Next.js (JS/React)
  2. Hugo (Go) (Smashing Magazine was made with Hugo)
  3. Gatsby (JS/React)
  4. Jekyll (Ruby/Liquid) (powers Github Pages) (my review of Jekyll)
  5. Nuxt (JS/Vue)
  6. [Hexo](ht…

Continue reading...

Using Tippy.js with Turbolinks

An article, posted about 4 years ago filed in library, javascript, html & TurboLinks.

Tippy.js is a nice library to show popups. It may, however, not always be obvious how to use Tippy.js with Turbolinks (or any other library that modifies the DOM). The basic ingredient is somewhat hidden in the docs: deffered. But loading a HTML template requires a slight adaptation of what is presented in their documentation to make loading of these templates deferred.

From beginning to start. Add the library:

$ yarn add tippy.js

Add a CSS-class for your templates to be hidden by default:

.tippy-template-content {
  display: none;
}

And then add the following to your application.js (or equivalent in your setup):

import {delegate} from 'tippy.js';

delegate('html', {
  content(reference) {
    const id = reference.getAttribute('data-tippy-template');
    if (id) {
      const template = document.getElementById(id);
      return template.innerHTML;    
    }
  },
  allowHTML: true,   ...

Continue reading...

Considering online generation of certificate requests

An article, posted about 5 years ago filed in certificates, browser, javascript, ssl & tls.

Recently I’ve been researching what other Certificate Authorities do within the domain of online generation of certificate requests (and related private keys).

It is tricky territory: JavaScript and Crypto. Or more generic, webapplications and crypto. But with the advance of the WebCryptoAPI some issues that were raised (e.g. insufficient random number generation) by security experts have been addressed, but still: the WebCryptoAPI entry on MDN starts with a fair warning: “If you're not sure you know what you are doing, you probably shouldn't be using this API.”

Why think about a web implementation at all to create a certificate request? Typically tools to generate certificates are hard to use. Just look at the list of options a user has to generate certificates, which are typically all of…

Continue reading...

Bad CSS in JS

An article, posted more than 5 years ago filed in css, react, style, javascript, standards, simple, simplicity, npm, packages & coffeeandorange.

I tried to understand the argument made for styled components vs. ‘traditional’ CSS. But when reviewing these arguments I found out that they typically use bad code as proof for their point.

See e.g. the following SCSS code:

$blue = #5DBCD2;

@mixin button-styles($bg-color, $color) {
  background: $bg-color;
  color: $color;
  border: none;
  border-radius: 0.20em;
  &:hover{
      background: darken($bg-color, 6%);
      cursor: pointer;
  }
}

.button {
  @include button-styles(#ddd, black)
}

.button--primary {
  @include button-styles($blue, white)
}

To pair with a simple component along the lines of:

const Buttons = props => (
  
    Default
    Primary
  
)
export default Buttons

The suggested alternative is:

import themeVars from "myTheme"
import styled from "styled-components"
import { darken } from "polished"

const B...

Continue reading...

Lazy loading the lazy way

An article, posted almost 6 years ago filed in images, web, optimization, javascript, html & coffeeandorange.

Below is a simple, lazy, technique I applied in a collection management tool where its users wanted to browse over 10.000 images without scroll-hijacking or pagination. Sure, only the HTML weight several MB’s at once, but for this particular application used by professionals it is worth the weight. But performance was too heavily affected by downloading all these separate images.

So let’s have a look how I solved this.

What does the code below do?

You rightly guessed that it won’t display any image to say ~95% of the users. The 5% who have disabled Javascript however, will see it.

The 95% who do have Javascript can enjoy the image simply by moving the img tag out of the noscript tag using a bit of JavaScript:

ELEMENTS_QUERY = "noscript[data-lazy=\"lazy-load\"]"

decode_entities = (encodedString)->
   ## required for IE and Safari
   textArea = document.createElement('textarea')
   t...

Continue reading...

Getting started with Cypress - a modern frontend testing framework

An article, posted about 6 years ago filed in ci, testing, frontend, ui, gui, javascript, npm, yarn & selenium.

Cypress is a new, open source integration test runner for modern JS applications (its development is sponsored by their online dashboard that allows you to record test-runs). It doesn’t require setting up Selenium, or other browser plugin, manually. Add it to your package.json and everything you need will be set up:

npm install cypress --save-dev

You can open even a GUI using:

./node_modules/.bin/cypress open

Alternatively, you can run the tests headless using the run command:

./node_modules/.bin/cypress run

Running the test will leave you with video recordings of what has been happening visually on the frontend for further review.

Ok. All nice, but you're right, these are tests running against a locally run server. So let's move the examples directory out of scope of the test runner:

mv cypress/integration/examples cypress/integration-examples

*(when exploring a new framework, I typically like …

Continue reading...

Really concise guide to package.json scripts

An article, posted about 6 years ago filed in yarn, npm, package, javascript, development & scripts.

Being unable to find a really concise description at a stable endpoint, the "scripts"-section of package.json, central to node/npm/yarn/euh. JavaScript-development these days, here it is.

The package.json is a json file which typically contains things like version and name of a project, the typical metadata. It also contains the dependencies of a project. But this is about the scripts-section. Completely optional, but so convenient that typically your project has one already:

{
  "name": "hello world",
  "version": "0.0.1",
  "main": "index.js",
  "scripts": {
  }
}

The "scripts"-section contains snippets of code that you typically run using npm or yarn:

So let's say you're typing git add . && git commit -m "wip" && git push a lot (totally not recommended), you could do:

{
  "name": "hello world",
  "version": "0.0.1",
  "main": "index.js",
  "scripts": {
    "wipitup": "git add . && ...

Continue reading...

The `matches` operation

An article, posted more than 6 years ago filed in jquery, underscore, prototype, live, Events & javascript.

I’m slowly migrating projects away from jQuery. It has served me really well in the past, and it still works, but it is no longer necessary. One of the few things that have been bothering me though was the lack of ‘live’-attaching of EventListeners. jQuery allows you to bind an onsubmit event listener to any , evens that haven’t been added to the DOM yet. It used to be called live() (from version 1.3 to 1.9), but the functionality was later reintroduced with on(). You would bind the event listener not to a `` directly, but to a container (up to document).

$(document).on('click', 'p.alert', function(e){ 
  confirm("Did you read this carefully?"); }
);

Moving away from jQuery, we use the ‘standard’ addEventListener(): but it has no easy way of delegating the events.

Introducing matches

Element.querySelector(".CSS.selector.here") is probably quite well known by know, but I was …

Continue reading...

JavaScript & Rails: a `webpacker` evaluation

An article, posted more than 6 years ago filed in javascript, ruby, rails, ruby on rails, programming, es2015, coffeescript, gem & assets.

Webpacker is still opt-in for new Rails projects. But this might change. The JavaScript ecosystem is moving fast and new JavaScript frameworks are pushing customer’s expectations to higher levels. To use these frameworks with your Rails app, you had a few options:

  • Include the JavaScript manually; which requires you to manually copy the files in place
  • Use a gem-wrapper to to install the JavaScript library; but this required quite some maintenance on the Gem-author’s side.
  • Try to mangle npm or yarn into the asset pipeline yourself
  • Use Rails Assets (an automagic Gem-wrapper)

A small praise for Rails Assets

I have been using rails-assets.org the past few years to keep my JavaScript dependencies up to date. It thought it was smart solution; instead of requiring individual developers to maintain Gem-wrappers, Gem wrappers are created on the fly by RailsAssets.org. It was smart and light weight on the developers side and worked perfectly with the Rails' Asset p…

Continue reading...

Developing Keycloak templates with Docker

An article, posted almost 7 years ago filed in docker, keycloak, template, javascript, development, css & html.

I haven't had much need for isolating services, something that Docker is really good at. Most dependencies of my Rails apps are covered by Gemfile anyway (and packages.json for JavaScript) and reasonably isolated with rbenv. I don't experience version related issues very often, as I try to stay reasonably up to date and not rely too much on the very state of the art. For temporary projects, however, Docker is a great solution, even for me :o I don’t want an entire JBoss suite running on my machine, so when I had to develop a Keycloak template I knew that Docker would be the right tool. While I’m going to discuss the specifics of getting started with a Keycloak image, the workflow described is replaceable by any other.

So what about Keycloak? Keycloak is a role based authorization and authentication tool …

Continue reading...

Unit-testing your front-end code in a Rails project: Yarn, Tape & Rails

An article, posted more than 7 years ago filed in yarn, coffeescript, javascript, testing, rails, ruby, homebrew & Tape.

I like Rails, but one thing that Rails falls short in is Javascript dependency management.

While Rails Assets, a proxy that allows for listing Bower packages in your Gemfile makes managing front-end libraries good enough for most front-end work, RailsAssets itself is mainly addressing asset management; it doesn’t allow for integrated management of additional development tools and binaries, useful for e.g. JavaScript-testing (besides the fact that Bower is kind of considered to be deprecated these days).

There are different ways of bundling Javascript, but since Rails 5.1, yarn is the defacto choice for Rails.

Installing Yarn

You can install yarn either trough npm npm install -g yarn, or if you’re on a mac, using homebrew: brew install yarn. I chose the latter.

To prepare your rails project run rails yarn:install.

Add tape for testing JavaScript & Coffeescript

There are [different testing fram…

Continue reading...

Should I use React or Angular?

An article, posted more than 7 years ago filed in react, angular, javascript, framework, ecmascript, es2015, html, frontend & vue.

To put it in some context: these days recruiters call you whether you know this or that framework. Well not really, really well. But it is just JavaScript. Or ECMAScript (or a flavour of it by Microsoft called TypeScript). But above all it is just a tool to get stuff done. Not every job needs a bulldozer. And besides the bulldozers React and Angular there is Vue.js and plenty more. Choose your tools wisely.

Continue reading...

Try not using Javascript first

An article, posted about 8 years ago filed in javascript, web, front-end, development, html, css, internet, rest & kiss.

My guiding principle in web-development is (still): Always make things work without (client side) JavaScript first.

Aside from offering a graceful degradation of the experience by progressively enhancing it leads to better code. Three reasons why:

  1. it forces you as a developer to think about logical endpoints for your form submits, your data requests etc. Typically this leads to fewer cases of overloading a resource with all kinds of unrelated functionality (yep, I'm a big REST-first advocate).
  2. your application will probably be more web-native, and hence more future proof, more easily cache-able, etc.
  3. the front-end JavaScript to enrich the experience will typically also be less complex and can be generalized more easily.

Yes, I do shiver when I hear things like CSS in JS, KISS!

Photo by [Dmitry Baranovskiy](https://www.flickr.com/photos/dmitry-baranovsk…

Continue reading...

Making block elements link

An article, posted about 14 years ago filed in html, snippet, jquery, code, handy, link, block & javascript.

There is no standard way of linking block elements to pages in HTML. But sometimes you do need it. The <a>-element doesn't support any block elements inside (such as <div> etc.). I solve the problem with a jQuery snippet that allows me to simply add 'js_blocklink' to a block elements class and the jQuery code deals with the rest. It does assume that the first link is the 'main link' (also needed for graceful degradation when Javascript for some reason is not available). A bonus feature is that other links may still exist, and stay working. function enableJsBlockLinks() {     $(".js_blocklink").each(function() {         $(this).click(function() {             $(this).find("a").each(function(index) {                 a = $(this).attr("href");                 if (a…

Continue reading...

murb blog