This blog hadn’t a redesign for a decade. It was driven by self-made CMS, which naturally has become, say the least of it, outdated. So some time ago I ripened for a remastering. Instantly I started by looking for a CMS or a headless CMS. Then I realized, the blog is actually static – I don’t have here any forms or services, it’s all about representation of content. Why not to go with a site generator?
Nowadays nobody would argue the importance of automated testing. Yet end-to-end tests are often hard to write and even harder to maintain. There are many solutions to help with it. Puppetry is a test constructor, which allows you building test suites without any coding. QA-engineer can record user scenario in a built-in browser, extend the generated test case with browser commands and assertions, manage the suite structure (like drag’n’drop) and run tests.
Images in HTML, what could be easier? However when you have many of them on a page, they do not appear immediately. That depends on caching strategy and bandwidth, but still if you don’t take a special care it may look quite ugly. Basically we need to fill in the slots with something appropriate while images are loading. In other words we need placeholders. Probably the most prominent technique here is LQIP (low quality image placeholder).
Functional testing isn’t something new. We all do it, less or more, with different tools and approaches. However when it comes to flows, where transactional emails (signup confirmations, password resets, purchase notifications and others) involved that may still bring questions. For example, we instruct the testing tool to navigate to the registration page, fill out the form and press the submit button. The web-application sends email with activation link. So we need the testing tool to read the email message, parse it and navigate the link.
Eventually Puppetry 2.0 was released. The development took for a while, yet it contains a lot of changes. In fact the branch 1.x was basically a GUI for Puppeteer/Jest, but the tool grew up into a fully-fledged testing environment. Now Puppetry has a built-in templating engine, which supports environment-dependent variables and expressions, what brings a great potential. Just consider: you have test/stage service, which never resets. The only way to test, let’s say, signup flow is to create a new (no-yet-existing) user account.
In software engineering we try to discover and eliminate bugs as soon as possible. One of most important heuristics here is validation of input/output on functions and methods. If you are going with TypeScript or Flow, you are fine. But if not? Then we have to manually validate at least input (arguments). But what would be the best way doing it? First comes to mind aproba library. It’s “ridiculously” light-weight and equally popular:
A sound application architecture doesn’t resist to changes, but welcomes them. Yet it still doesn’t guarantee that the code is unbroken after we implement new features, making fixes or refactoring. Here we run automated tests to ensure that the app integrity didn’t suffer. So we write unit-tests to check if separate objects, methods, functions work property independently. With integration tests we ensure they play as designed together. Eventually we create system tests to find out if the entire system meets our business requirements.
When we talk about user input within a web app we often think first of HTML forms. Web forms have been available with the very first editions of HTML. Apparently the feature was introduced already in 1991 and standardized in 1995 as RFC 1866. We use them everywhere, with almost every library and framework. But what about React? Facebook gives a limited input on how to deal with forms . Mainly it’s about subscribing form and controls for interaction events and passing state with “value” property.
I’ve been working with PHP since 2000 and with JavaScript even longer. Over last decade JavaScript evolved drastically. It had a promising design from the very beginning and gained its current incredible shape with the shift to ES2015 (Harmony). PHP though didn’t change that much. Apparently it’s doomed always to suffer from its own legacy. It arrived in middle 90s as a simple CGI app to maintain Rasmus Lerdorf’s home page and have been more like spontaneously developing ever since.
I observe as some people still write ancient ES5 syntax of JavaScript and it’s disheartening. I wonder what keeps them from moving forward. Some must be driven by psychological inertia, but some likely just find it to complex to make their new syntax running in a wide range of browsers. In fact, nowadays we may not fear about it anymore. One can set up a dev environment where tools decide what transformations requires the code and what polyfills to load depending on selected target (list of user agents to support).
What do you do when you need a widget-like functionality? At the present there is a whole generation of developers who with as a rule are googling for ready-made jQuery plugin. Can’t we do better than that? With advance of web-components we are expected to compose UIs from these building blocks. They are many. One can find one for almost any task. They are highly customizable. One can reuse the functionality, but with own original representation.
Before modules Historically JavaScript had neither a module system, nor facilities to load sources from within the code. In order to understand what have now, let’s take a retrospective look. I remember in the past a number of libraries where the code-base was split into a separate files which were concatinating during the build process. As simply as that it didn’t help with module isolation, but improved maintainability by organizing the code in files of meaningful names.