The different browsers today are pretty forgiving when it comes to HTML and CSS. They have become good at rendering the markup, even if it‘s invalid HTML and will cause HTML validation to fail. While we should always strive to write valid HTML markup, mistakes do happen, and luckily the browsers do a pretty good job at rendering the code without breaking the layout completely. But, we still have invalid HTML, and our goal was to address these issues by making a low-level HTML markup quality assurance tool with CSS.

Going from an empty folder to a living React project can feel like a daunting task. As we pointed out in our precursor, if you have been overwhelmed by certain ejected configs or underwhelmed by zero-config tools, it’s time to learn how to set up pragmatic, powerful and customisable configs. For this, we will be using, but not explaining, Node, npm and the terminal. We will also reference CSS, JS and React, but in no way provide primers.

The way frontend is done today, knowing how to configure bundling tools has become as relevant as knowing CSS, HTML and JS. For most of us, the code we write, with or without a framework, involves some level of processing. This is the precursor to our Webpack tutorial. It’s meant to prove a point that the tools used for learning things like React, mostly fail to give an impression of a realistic configuration. By learning the basics of a bundle configuration, we are able to make better apps, more efficient configs and work with other bundlers and libraries.

What’s the design system documentation without a dedicated page for colours? In our case, it’s clearer and with fewer palette detours.

There are loads of tools aiming to help developers secure that their code works as expected. Cypress is one of these tools but stands out by being an end-to-end framework. This means that Cypress allows you to test that your application is performing the way you designed it, from start to finish. End-to-end testing is especially useful to test the features and the end user’s workflow. In React it also helps to ensure that dependencies and data is passed correctly between the different components.

When I set out to solve responsive tables, I figured it would take a whole team a couple of weeks and we would build a microscopic component to provide clever shuffling of <div> elements. Instead, my conclusion led me to the opposite. Responsive tables are less about making them responsive and more about presenting them in responsive environments. The principle Use the <table> element for things that it would make sense to copy and paste into a spreadsheet. This means that a table should be used when the data is best presented as such, and the alternatives are inferior. Which in turn means that responsiveness should be about presenting tables more or less as they are. That is, without distorting or rearranging them or the surrounding layout in a way that makes either lose meaning.

Regardless of how enthusiastic you are laying the first bricks of a project, at some point you’ll realise that the stack of bricks, look suspiciously like a wall, or something different than originally pictured. The wall can be many things. It can be slow code reviews or a growing list of tasks and features that prevent deployment. It can also be a bug that seem to only appear when the stars are aligned and you press a button too quickly after filling in a form. The common thing is that it makes you feel like you’re either very far from your goal, or that the thing standing between you and the finish line is insanely boring.

It has been more than a year we started using Sentry.io to identify the user experience and UI failures one year ago. I thought of sharing What have we learnt about it so far and our experience with it. 📄 Intro 🏊‍♀️ Why do you need Sentry? Sign In and create a project Integrate Sentry in app First error tracking Use Sentry with API Endpoint When and what to log in Sentry Why do you need Sentry? 🏊‍♀️ we are interested in real time error tracking in production which would happen due to security bug, invalid data or etc and understand the end customer experiences

Also published in Norwegian @ kode24.no: Kode som overlegent designverktøy Have you ever thought about the fact that the users are never really in direct contact with what designers make? User interfaces are built by developers who are experts on the users’ environment, but the decisions are made elsewhere, by people that use entirely different tools. Sounds suboptimal, doesn’t it, keeping technical knowledge and user knowledge apart like this. And are those kinds of expertise really that clearly separated? Or are we seeing more and more people starting to cover both fields?

Some years back a few people in the web department headed off for Galdhøpiggen 🎒🥾, not very well equipped. Weather was bad, and they didn’t manage to reach the summit. But that hike was the beginning of a tradition with yearly trips to different summits. 🏔 This year 18 people headed off with the train 🚝 to Otta, for a nice weekend at Rondvassbu and where the goal was Veslesmeden. The hike to Veslesmeden was not planned to be that hard, but snow ❄, heavy wind 💨 and a lot of different weather 🌧 made it a tough challenge.

Our frontend team hit the ground running one year ago. What have we learnt about supporting the vertical teams? What do we mean when we say it’s horizontal? Technology Specialists 🏊‍♀️ The deepest depths of the technology stack are best left to divers — while we are the fast swimmers at the surface. Vertical teams are responsible for every single moving part of applications they own. When building a logistic system for business customers, this covers everything from database to UI design and all layers between. Developers write CSS in the morning, and debug production issues in PostgreSQL after lunch. They handle a whole range of wildly varying technologies. Not every individual member needs to wield them all to the same extent (that’s what teams are for, working together!) But as a unit; the vertical team is full stack.

“This is bug, please say hello.” There are many ways to introduce bugs. Adding CSS as dependencies is one of them. True story Let’s say you add a small and simple css reset dependency to your project. A somewhat opinionated and best practice-based stylesheet that has thousands of weekly downloads. It serves as your baseline for every new project and it’s easy to keep up to date.