DEV Community: Lukas Trumm

Making sense of Web features

Lukas Trumm — Thu, 12 Sep 2024 00:00:00 +0000

There is a huge amount of features on the web. The Browser Compatibility Data project lists more than 14000 of them! How to make sense of it all?

This is a question that has been unanswered for a long time. Yes, every web developer uses caiuse.com. Or they google or maybe ask chatgpt. The problem is that these tools have answers to specific questions, but lack a bigger picture or links to the source of truth.

The WebDX Group

Not anymore! The WebDX group is now doing an incredible job of organizing, categorizing, and naming things (← this is the hard part, as you know) around the web platform. They are trying to improve the overall developer experience with the web and browsers in a coordinated way.

WebDX is a community group that is part of the W3C. You can see what they are cooking in their repositories. The most interesting output for me is the web-features repo. What they have done is to categorize a huge amount of specific features into a more understandable set of higher level features.

For example, one of the newly available features is Set methods. Any new method for manipulating a set could be a single feature. However, it becomes much more useful if it is communicated and documented as a single high-level feature.

The documentation

The other part is how to find detailed information about a feature. Well, this is where the Open Web Docs initiative came in. While MDN has always been a great reference, there has been a lack of hands-on content. The Open Web Docs group is trying to change that. They are cranking out a ton of new tutorials, guides, and explainers for MDN web documentation, as well as updates to the underlying data — BCD (Browser Compat Data).

One example is a page on MDN about Relative colors. It is cleanly mapped to a high-level web feature. It provides much better understanding and context around that feature than the individual reference pages for each color feature.

The surveys

What is really nice about the above effort is that they really want to collaborate. They take input from surveys like The State of HTML and The State of CSS, and later they can use the same set of names for web features to track survey results about them.

And by the way, while you are filling out these surveys, you can click the “Add to Reading List” button. It will present you with links to MDN where you can learn more about exactly the things you didn’t know.

The Reality

Great, but is the Web getting better? Hell, yes it is!

The initiative to close the gap between desired features and actual availability across browsers is evident. Namely, the Interop project ensures that a set of features is implemented as fully as possible in all major browsers. There is a new iteration of this project every year.

How much and how well these features are implemented is measured using Web Platform Tests. The same set of tests is run against all browsers. That is why we have these nice percentages that reflect the actual state of the features in the browsers.

The Baseline

The moment when a feature is implemented in all major browsers is a very important moment. And since we have nicely grouped the features as described above - the only thing missing is a name for the moment. And there we have it: A feature is Baseline Newly available when it is supported by all major browsers. And a feature is Widely available when two and a half years have passed since it was Newly available.

You can read more about the Baseline idea on web.dev since it was initiated by Google.

The visual dashboards

Everything starts to make more sense when you can see it in a more visual way. Well-designed tables, graphs, handy links to resources right there…

This is baked into a few attempts to create useful dashboards. Check them all out, each one is a different take on the subject:

You can use them from time to time to catch up on what is new in general or what is new in the Wide adoption status. It is also a good reference when you are starting a new project and deciding what set of features is actually available and supported enough.

Web Features Explorer display the information in a clean way

Webstatus.dev shows real progress on features in terms of passed web platform tests in graphs

My Web Platform Features dashboard allows filtering and sorting features

The future

Some features have recently been implemented in all browsers rather quickly. But some may not even be considered a good idea by some browser makers. You can find detailed information about what may or may not be coming at the following sites:

Conclusion

Watching the web platform evolve is fascinating. The feedback loop is improving. Interoperability is getting better in many areas.

I have wanted to have a useful dashboard with web features for a long time, and suddenly the data is of such nice quality that I managed to build my own in a couple of evenings.

Working with correct versions of tools in the JavaScript ecosystem

Lukas Trumm — Mon, 03 Apr 2023 00:00:00 +0000

The ideal is to have the desired version of every tool at every situation during both development and deployment. Docker might be the answer for someone, but it might not be practical to use it all the time. Let’s analyze the situation.

There is an initiative called devcontainers to improve the practicality of the docker solution, but I’m not going to discuss that in this article.

Definitions

By tool, I mean the runtime (like nodejs), package manager (like pnpm), and others (docker, git, and other CLI tools).

By situation, I mean running your first command after git clone, running a command after switching git branch, or running a command in a CI/CD pipeline.

There are several levels of perfection

Nothing. When something breaks, someone might fix it.
Documentation. README.md. After following the docs carefully, a developer should be on the correct version of tools. Extra communication is necessary when updating versions.
Enforcement. There is configuration in place which forces certain tool versions and refuses to operate otherwise.
Automagic. The environment (either local or in CI) is set up in such a way, that it automatically uses (and installs before) correct versions of tools as configured. Might be harder to achieve without extra maintenance and documentation.

Based on these options, I think there is no ideal solution.

For small or personal projects (1) may be enough. For projects, that are not actively developed, (2) may be appropriate. When issues with incorrect versions occurs, it is time to make some safeguards (3). For larger teams or larger amount of projects per developer, it might be beneficial to invest into automation (4).

How to

A lot of the times it is enough to specify the major version. Like node 18, yarn 1 etc. I personally run into most issues because of switching between projects that uses different major versions of tools.

Use the correct version in CI/CD

CI/CD needs to be configured in code, ideally in the same repo as the rest of the application code. That way, the definition of versions are closer between local and production environment. One might choose to use docker to make sure, that the whole environment is the same, but it is not always practical (might be slower for local development, might not fit the app architecture, might require unnecessary know-how).

Use the correct version of the runtime

I will focus on nodejs versions. One might soon need to deal with other runtimes like deno or bun, but leave that for another time.

To enforce a valid version you can use the engines field in package.json.

"engines": { "node": ">=18" }

That will inform you about wrong version, but it does not do anything about it. What you want is a tool that installs and/or switches to the correct version whenever you switch directories on your command line.

First, you configure the desired version. Something like this (I use this with fnm, but different tools need different configuration):

node --version > .node-version

And then setup a tool and your command line shell. Some options:

fnm is simple
volta can manage node, package manager and other tools from NPM
asdf is good when you need to handle more languages

Use the correct package manager

You can go far with a set of shell aliases or functions. I have recently switched to using @antfu/ni and it is way better. You can stop warring about the package manager a given project is using from now.

Use the correct version of the package manager

This is more tricky, but using the engines field in package.json can enforce a version range.

"engines": {
  "node": ">=18",
  "pnpm": ">=7"
}

Corepack (mentioned below) should improve this point in the future.

Use the correct versions of formatting, linting and building tools

Define them as devDependencies and use them via scripts. Like nr build from @antfu/ni.

Careful about running them ad hoc, there are a lot of details behind commands like npm exec, npm x, npx , pnpm dlx, pnpm exec, …

Alternatives and the future

Helper NPM packages

There are NPM packages that might help (e.g. only-allow). The problem is that it might not work all the time (looking at GitHub issues…) and it is an extra dependency.

Package manager policies

If you are using yarn a lot, it might be worth looking it its version enforcement solution, which is documented here.

Corepack

Corepack probably will be the way to go—it will manage the versions of package managers for you, using "packageManager" field in package.json. It is still experimental and various tools might not work with it yet.

Conclusion

The JavaScript ecosystem is moving fast. If you want to be up to date you need tooling that help you keep your sanity. With tooling that I have described in this article, you can forget about some aspects of dependency management—and that is a good thing.

77+ questions about a web project

Lukas Trumm — Wed, 08 Feb 2023 00:00:00 +0000

You were asked to build a website? Does it seem it will be a larger one? It might be the case it will actually not be a website but a webapp. It might need a team to actually do it. Well, better prepare answers for these couple of questions :-)

Table of content

Vision and requirements
Communication
Technical environment
Infrastructure
Users
Code
Runtime
SEO
Performance, UX, a11y
Design
Legal
Maintenance
Marketing and sales
The bottom line

Vision and requirements

Is there a short document explaining why this piece of software should exist and a concise description how it would accomplish that?
Do we have a place for collecting and prioritizing requirements?
Are non-functional requirements written somewhere?
Do we have a schedule or milestones which describes at least roughly what will be done when?

Communication

Can you think of any expectations that are not described by current requirements?
Will the customer collaborate with us on a regular basis?^[1]

Technical environment

Does anyone from the team have a specific know-how which is necessary / effective to leverage for successful completion of the project?
Will there be a reasonable return of investment from learning and implementing new technologies? Would it be easier to hire new people with such skills?
Are there existing systems like CMSes or APIs that needs to be integrated?
Are there existing URL addresses or domains that needs to be redirected to new ones once the new website will be released?

Infrastructure

Is there a possibility that currently running systems will be negatively impacted after deploying this new application on target domain?
How will we host our website or application? Is it possible to change it now or in the future?
What are the pros and cons of chosen hosting environment over some more traditional choice?

Users

Do we have some existing analytics data?
How many users do we expect first day, first month, first year?
Which browsers and their versions are going to be supported?
Would the project suffer from missing accessibility features? Is it a subject of regulation?
Is it any good to provide users with a chatbot and is it worth the effort and possible performance issues?
Are there any use cases for our website/application to be used without JavaScript enabled?

Code

What is/will not be in a version control system? (like secrets, documents, etc.)
Is there a README.md file which has enough information for any developer to run the application, test it or prepare it for production?
Does every developer have an automatic way of formatting new code? (in editor on save, precommit hook)
Is there a process in CI that checks common code style issues for every change? (i.e. linting)
Is there a process in place that ensures that all code is checked for quality? (code reviews, automated tests and checks)
Does every developer know when and how a code review is needed and when it is appropriate to merge? ^[2]
Are there some automated checks for security? ^[3]
Is there a CI/CD pipeline that deploys every change? (continuous deployment)
Is there a preview environment for every change and is it practical to have them?
Do we have know-how when and how to use unit testing , integration testing or end-to-end testing?
Do we use the right programming language for the job?
Which framework do we use, what it solves and what problems it does not solve?
Is there a way to generate some boring boilerplate code?
Do we have a set of testing data?
Can we develop against this data set without even running the database?

Runtime

Does the web app handle redeployments of static assets seamlessly?
How will the web app handle a breaking change in backend APIs while an old version of frontend code is still running on the client side?
How is the cache on the CDN level invalidated?
Do we send correct security headers?
Do we send correct cache headers for HTML, data requests and assets?

SEO

Does every page have its canonical URL? ^[4]
Does our canonical URLs end with or without a slash? Do all redirects, sitemap items and links target this canonical URL?
Do our domain default to www prefix?
Do we need more control over Google results, and will we use Google search console? Will we use structured data?
Which website analytics solution will be used? Will we try to project for missing data (blocked by users or usage before consent) and how?
Do we have a complete sitemap?
Do we have a robots.txt? Does it contain only necessary records?
Do we have a page on the site for every frequent search term?
How are we managing third party scripts? Do we need Google Tag Manager? How much will be the performance influenced by third party scripts?
Does the application respond with correct response codes? An unknown URL should be 404 etc.

Performance, UX, a11y

Is it OK to display loading spinners for 10 seconds on a 3G network before displaying the content?
Will we have to do image preprocessing? Will it be a hosted solution? Do we care about resolutions and formats of those shipped images?
Is it useful to measure Core web vitals regularly/automatically?
Will we use progressive enhancement techniques? Does our team have knowledge to do so?
Are we going to optimize the amount of generated CSS? How?
Can be the desired set of fonts optimized in order to prevent Flash of unstyled fonts for most users?
Which level of accessibility will be our target? Do we have someone who understands accessibility on this level?
Do we have a plan for hallway usability testing?^[5]

Design

How does our design process look like? How are responsibilities distributed among designers, developers, marketers, product or UX people?
Do we need our own design system?
Which tools and techniques we will use (preprocessing, postprocessing, feature detection, polyfills, CSS structure and layering, scoping, reset, RTL support…)?
How will we approach responsive design? Mobile or desktop first , strict set of media queries or more fluid techniques, leverage container queries?
Which set of icons we will use? Will it play well with our framework of choice?
Do we have a live web with our style guide?

Legal

Is it necessary to have a cookie consent on the website?
In case we need a cookie consent would it be beneficial to use a third party solution? Will we use the analytics from that solution for something?
Do we need to implement something extra in order to comply with privacy laws like GDPR?

Maintenance

Where will we track tasks and bugs?
How can our customers report bugs?
Do we have an automated system for reporting runtime errors?
How are our production systems backuped? When was the last time we have done a restoration from those backups?
How often there is a change in some data or source code? For how long will our system handle the increasing frequency of change?
Which types of changes would our architecture allow easily and which would be hard?
Do we have a place for writing down maintenance procedures? (E.g. updating dependencies, data schema migration, adding redirects, etc.)
Who manages credentials and how? Do we need to use an external service for them? Do we need to rotate them?
Is there a single place (like a URL) which anybody from the team can visit and see important links or other useful information about the project? (I call this a project signpost )
Do we need to track special events in the system, like conversions?
Do we have a way to automatically check for links that accidentally targets PAGE NOT FOUND?
Does our monitoring, logging and tracking solution solve real problems?

Marketing and sales

How does marketing or sales strategy correspond to a release date of our product?
Do we focus enough on feedback from users, developers, investors?

The bottom line

This is not an exhaustive list, although I was trying to be complete—based on my experience. BUT keep in mind that it is also critical to maximize the amount of work that does not need to be done! ^[6]

Notes

From Agile manifesto: Customer collaboration over contract negotiation ↩︎
One nice strategy for this is called Ship / Show / Ask ↩︎
For example GitHub has tools for automated checks of dependencies and static code analysis ↩︎
There are quite a few rules for canonical URLs so it is best to consult Google search documentation ↩︎
Hallway usability testing is mentioned for example in the famous Joel’s test ↩︎
Again a quote from Agile manifesto ↩︎

Power management on Ubuntu and Pop!_OS

Lukas Trumm — Wed, 16 Dec 2020 00:00:00 +0000

Is it possible to hibernate a Linux machine? What is the difference between sleep, suspend, stand-by and hibernation? Why isn’t my machine waking up after pressing keys on my keyboard?

What is going to happen?

I can finally answer these questions after a long time wondering why something does not work. Let me explain some of the concepts first.

Power management concepts #

These concepts are general but what I’m describing here might be specific for Ubuntu based Linux systems.

Sleep and suspend #

These terms are used interchangeably. The state of your machine is saved to RAM and the computer puts as much as it can to some low power consumption mode. Energy is still consumed and there is a risk of losing unsaved work in case energy is no longer available (e.g. empty battery). The advantage is, that suspending and waking up is fast (couple of seconds in my experience).

Hibernate #

When a computer hibernates it saves its state to hard drive and then shuts down. Someone might call it suspend to disk. When it wakes up it restores its state from hard drive into memory. You need space on your hard drive in other to save the state.

Hibernation has most issues, probably because it is dependant on the combination of hardware and operating system. You might not need hibernation—sleep might save enough energy and power off might be fast enough.

Power off #

Is a normal process of properly shutting down a computer. Halting a computer might be slightly different. As I understand it powering off is a more complete process.

Lock screen #

When you manually lock your computer or when you are away for some time it provides you with a prompt for password—your computer is locked. The same happens when the computer is waking up.

Log out #

Shuts down your running applications (it might not stop all of the background processes) and effectively locks the screen.

Idle time #

Is a time when the computer evaluates that it is doing nothing. From the practical point of view the computer can be configured to do something useful after some specific time of beiing idle and it might lock the screen or suspend itself.

Standby and awake #

I believe you can’t directly force your computer to go into those states, those are probably internal. In awake state all components are running, while in standby state harddisks and other peripherials might be turned off.

Shutting down #

Or rather sleeping down because at least for me, suspending is way more convenient (read: faster) way of ending my work. I usually hit a dedicated key on my keyboard (a cheep Cherry keyboard). Another way is to let your machine sleep after a specific time. In Gnome settings there is an item called Automatic suspend (Settings ➙ Power), where you can set it up. Wierdly enough you need Gnome Tweaks to set the suspend action after closing a lid of your notebook (it is in General section there).

Waking up #

A reasonable way to wake up your computer is to hit some key on a keyboard. It might sound simple, but there are issues with external keyboards for notebooks or wireless keyboards. In my case I have checked askUbuntu and my BIOS settings and found a disabled option. Now I can wake up my notebook (from sleep) using keyboard (not mouse—but I like it) which is connected via USB dongle.

Sources #

Flexbox zombies

Lukas Trumm — Fri, 20 Nov 2020 00:00:00 +0000

Recently I have finished the Flexbox zombies game. The way the author forces you to deliberately practice a skill is great.

Flexbox zombies is an online course that teaches you the display: flex css property. It presents quite a boring topic - placing items on a screen - in a very atractive way.

Even if you think you know css flexbox I would still recommend it, because it is interesting how it is presented directly inside a browser and everything is interactive. And you will probably find out you don't know everything. I have found a couple of new facts and following are some notes about it.

Start with display: flex

The number of times one have to write display: flex in the course is overwhelming, but at the end, it was worth it. As the author said - it is about deliberate practice.

Lets define a class with display: flex and a couple of other properties.

.flex-container {
  display: flex;
  width: 300px;
  height: 100px;
  background: rebeccapurple;
}

.flex-item {
  color: white;
  background: darkcyan;
}

Flexible width

Width is flexible - who would guess?

<style>
  .my-box {
    width: 200px;
    min-width: 150px;
    max-width: 250px;
    flex-basis: 225px;
  }

  .item-1 {
    flex-shrink: 1;
  }

  .item-2 {
    flex-grow: 1;
  }
</style>
<div class="flex-container">
  <div class="flex-item">Fits the content</div>
</div>
<div class="flex-container">
  <div class="flex-item my-box">Flex-basis wide</div>
</div>
<div class="flex-container">
  <div class="flex-item my-box item-1">No need to shrink</div>
</div>
<div class="flex-container">
  <div class="flex-item my-box item-2">Grow stops at 250px</div>
</div>

Flex shorthand

Shorthand property flex combines flex-grow, flex-shrink and flex-basis. When you omit the last one, flex-basis became 0 instead of auto.

<style>
  .flex-basis-auto {
    flex-basis: initial;
  }

  .flex-basis-zero {
    flex: 0 0;
  }
</style>
<div class="flex-container">
  <div class="flex-item flex-basis-auto">Flex-basis auto</div>
</div>
<div class="flex-container">
  <div class="flex-item flex-basis-zero">Flex-basis 0</div>
</div>

Align content

In the following example the align-content property pushes all the items to the vertical center of the container while align-items to the center of their lines.

<style>
  .content-aligned {
    flex-wrap: wrap;
    align-content: center;
  }

  .items-aligned {
    flex-wrap: wrap;
    align-items: center;
  }

  .content-aligned > *,
  .items-aligned > * {
    flex-basis: 140px;
    text-align: center;
  }
</style>
<div class="flex-container content-aligned">
  <div class="flex-item" style="background: darkcyan">Item 1</div>
  <div class="flex-item" style="background: darkgreen">Item 2</div>
  <div class="flex-item" style="background: cadetblue">Item 3</div>
</div>
<br />
<div class="flex-container items-aligned" style="background: purple">
  <div class="flex-item" style="background: darkcyan">Item 1</div>
  <div class="flex-item" style="background: darkgreen">Item 2</div>
  <div class="flex-item" style="background: cadetblue">Item 3</div>
</div>

New properties

There are new properties available in some browsers that are not mentioned in the Flexbox zombies course.

One is gap:

<style>
  .flex-with-gap {
    gap: 20px;
  }
</style>
<div class="flex-container flex-with-gap">
  <div class="flex-item">Item 1</div>
  <div class="flex-item">Item 2</div>
  <div class="flex-item">Item 3</div>
</div>

Another one is place-content a shorthand for justify-content and align-content:

<style>
  .flex-centered {
    flex-wrap: wrap;
    place-content: center;
  }

  .flex-centered > * {
    width: 120px;
  }
</style>
<div class="flex-container flex-centered">
  <div class="flex-item">Item 1</div>
  <div class="flex-item">Item 2</div>
  <div class="flex-item">Item 3</div>
</div>

Conclusion

The Flexbox zombies is a great course and great game at the same time. That's rare!

I don't remember if the course mentioned a very useful value of justify-content: space-evenly. Other than that it is very thorough. I highly recommend this style of learning!

More interactive (you can live edit the code) version of this article is on my website.