Agile CSS and frontend testing at the JavaScript Days

We attended the JavaScript Days (JSDay) in Verona and I summarized my favorite talks for you to enjoy. After the opening chat by the GrUSP guys – did you know they not only organize PHPday and JSday, but a number of other smaller conferences like better software and kerning? – the madness started:

Metaprogramming in JavaScript

Massimiliano Mantione, who previously worked on v8 team at Google, starts the day off on a skeptic note: “We all know that JavaScript is powerful but it can be a really terrible language when misused. It lacks several advanced features that are taken for granted in other languages. One technique that is overlooked is metaprogramming.” Mantione developed Metascript taking the best bits of Coffeescript, Typescript, Lispyscript, Clojurescript, Lisp and Haskell. Code that can modify your code, that compiles to JavaScript…

Metascript has a readable syntax and at the same time allows for lisp-style metaprogramming (macros that can manipulate the AST). Lisp-like languages have a ‘clean’ syntax per definition: they explicitly use parenthesis everywhere to express the grouping of expressions. Metascript uses a combination of parenthesis, indentation and infix operators to ensure that the syntax is similar to a number of mainstream programming languages, and can be used interchangeably. The next steps for Metascript would entail completing the compiler and the metaprogramming system. Writing standard macros and publishing a module on GitHub are also on the road map. As is implementing a type system. One to watch.

NSA.js – really tracking user interaction

Danni Friedland (eBay IIC) dislikes how current tracking solutions are sub-optimal. Charts, graphs and heatmaps are too abstract. There’s no up-close-and-personal with your user. What if you could see what the user sees? You’ll have to record everything and add an Eventlistener to scrollObserver, mouseObserver, ViewportObserver (screen sizes), TestSelectionObserver, track focus in/out, URL changes, the open or closing of a popup… (more…)

anynines Beta is drawing to an end

They grow up so fast…

At anynines we are shaping up to leave Beta. Besides good times, this means that we have updated our Cloud Foundry system so that it’s compatible with the command line utility (CLI) v6. Have a look at this article to get a more detailed description of the changes.

The CLI v6 has been completely rewritten and is much faster and easier to install than the previous versions. What is more is that the new CLI allows you to tail the application logfiles, so you can see what happens to your applications in realtime. Read here how to install the new CLI.

The new Cloud Foundry setup is more stable with multiple instances of important CF components in different availability zones.

As soon as we will remove the Beta label from our website we will offer trial periods of 30 days to our new customers. Existing beta customers will automatically enter the trial period. More information on the beta and the trial period can be found here.

Please don’t hesitate to ask us any questions you might have regarding the updated Cloud Foundry version, or us leaving the beta phase. We are happy to help.

We attended – the frontend conference in Austria

Being a member of the organizing team, I spend last weekend in Linz for, a frontend conference counting 3 tracks and no less than 26 speakers. I led one of the tracks at the Johannes Kepler Universität and still got to enjoy some other talks and highlights. To summarize…

Architecting Resilient Frontends

Andy Hume works in the engineering team at Twitter and pointed out to a full room how ‘companies spend hundreds of thousands of dollars on the uptime of their server infrastructure and yet real world websites are slow and failing all the time’. The web is inherently unreliable, yet resilient. So how do we fix that?

Hume says that loading content first, before getting to the (JavaScript) enhancements (and then all other leftover styling elements) is preferable. “If everything after content fails, you at least have that.” Improving the ‘time to screen’ – getting content to the page as soon as possible with fewer http requests – will make your site seem faster. Hume also suggested to eliminate whatever blocks DOM construction, like fetching a remote script that needs to be executed synchronously. Using an inline script node that waits for the relevant stylesheet match instead, with the script tag in your HTML (although it hurts newer browsers and excludes you from using the HTML pre-parser feature of modern browsers) will make you website (appear to) load faster. (more…)