Ben Frain just made some notes about the switch from Gulp to Parcel, a relatively new “web application bundler” which, from a quick look at things, is similar to webpack but without all the hassle of setting things up. One of the things I’ve always disliked about webpack is that you kinda have to teach it what CSS, HTML and JS are before making whatever modifications you want to those files. However, Parcel does a lot of the asset management and configuration stuff for us which is super neat — hence, Parcel claim that it requires “zero configuration.”
If you’d like to learn more about Parcel then there’s a great post by Indrek Lasn that details how to get started and even shows off a little bit about how Parcel is often faster than alternatives like webpack. We also just published a post by Kingsley Silas that explains how to use Parcel with React.
Ivan Akulov has collected a whole bunch of information and know-how on making things load a bit more quickly with preload and prefetch. That’s great in and of itself, but he also points to something new to me – the as attribute:
Supposedly, this helps browsers prioritize when to download assets and which assets to load.
My favorite part of this post is Ivan’s quick summary at the end which clearly defines what all these different tags can be used for:
<link rel="preload"> – when you’ll need a resource in a few seconds <link rel="prefetch"> – when you’ll need a resource on a next page <link rel="preconnect"> – when you know you’ll need a resource soon, but you don’t know its full url yet
Make sure to check out our own post on the matter of prefetching, preloading, and prebrowsing, too. Adding these things to our links can make significant performance improvements and so check it out to add more resources to your performance toolbox.
WooCommerce recently made an entire overhaul of its highly visible dashboard screen in the WordPress admin available as a new plugin that can be downloaded free from the WordPress Plugin Directory. The new design is gorgeous, of course. I mean, anytime WooCommerce touches an admin screen, other plugin developers really pay attention because it influences they way many of them approach UI in WordPress.
But the real reason the new dashboard struck me is the sheer amount of data WooCommerce provides users. As someone who has worked on a fair share of WooCommerce (and non-WooCommerce) online stores, reporting is something that comes up quite frequently and it’s nice to know WooCommerce not only bakes it right into their product, but designs it so well that it’s easy to glean insights about sales, products and customers at a glance.
If you’ve had to integrate custom reporting into an online store a la Google Analytics or some other tooling, you’ll know that it requires a fair amount of setup and know-how to make sure data is feeding into the right places, certain clicks or actions are getting tracked, and that the reports themselves are solid, including things like filtering by date and other variables. That’s a lot of work considering we can get that and more, directly from the makers of the e-commerce platform.
As Woo mentions in its post, the dashboard changes contained in the feature plugin are merely a preview of what’s to come and we have a lot of other fine features to look forward to, including new types of reports, activity feeds and more. There’s a lot of power and flexibility to be gained if setting up an online store is in your cards, then the fact that WooCommerce and these features are completely open source and free of charge in the WordPress ecosystem practically make it a no-brainer.
Have you ever created a well-intentioned, thoughtful design system only to watch it grow into an ever-increasing and scary codebase? I’ve been working in sort of the opposite direction, inheriting the scary codebase and trying to create a thoughtful system from it.
Here’s Alex Sanders on the topic, explaining how his team at The Guardian has tackled the task of creating design systems while combating complexity:
Systems that try to contain complexity over long periods of time by convention will inevitably tend toward entropy, because one significant characteristic of convention is that it is trivially simple to break one.
You do not even need to be malicious. A convention is not a line in the sand. You can have a very good case for breaking or stretching one, but once a convention is no longer fully observed, subsequent cases for breaking or stretching it are automatically stronger, because the convention is already weakened. The more this happens, the weaker it gets.
Complexity and entropy can be two outcomes in the same situation, but need not be mutually exclusive. Interesting to think that our best intentions to guard against complexity can be somewhat destructive.
I also love how Alex explains why it’s not possible for their team to use a Tachyons-esque approach to writing styles because of the way that their development environment is kinda slow. It would be painful for the team to make that switch, despite how it could solve some other problems. This reminded me that measuring problems in this way is why there can never be a single way to write CSS. We need that inherent flexibility, even at the expense of introducing inconsistencies. Hence, conventions being less of a line in the sand and more of a guide post.
On a separate note, I really like how Alex describes styles and attributes as the reasons why his team is writing those styles. It’s about aligning with business objectives:
…tens of thousands of rules that are intended to describe a maintainable set of responses to business and design problems.
That’s interesting since I don’t think we spend much time here talking specifically about the business side of CSS and the functional requirements that a styled user interface needs to accomplish.
And perhaps thinking about that can help us write better styles in the long term. Is this line of CSS solving a problem? Does this new class resolve an issue that will help our customers? These are good questions to keep in mind as we work, yet I know I don’t spend enough time thinking about them. I often see the design I’m turning into code as a problem to be solved instead.
Perhaps we should expand the way we styling a webpage because maybe, just maybe, it will help us write more maintainable code that’s built to solve a real business objective.
High fives to Wufoo, our long-time sponsor here on CSS-Tricks. It’s powered the vast majority of forms I’ve built over the past decade. If you’ve never used it or heard of it: it’s a form builder. It makes the arduous task of implementing forms trivially easy. Building a form on Wufoo means you’ll get a form that does everything right UX-wise, gives you full design control, integrates with anything, and that you can put anywhere.
The feature list is too long to cover in the confines of a single post, so I always like to cover little bits that I’ve used recently and liked.
Don’t forget they have a robust API. I used the API to submit form entries on a form just the other day. I wanted to do some special things on a form, like be able to react to the DOM event of submitting the form. That’s not really possible when the form is in an <iframe>, but just fine when you host the form yourself and submit via API. Worked great.
What we tend to forget is that the environment websites and web apps occupy is one and the same. Both are subject to the same environmental pressures that the large gradient of networks and devices impose. Those constraints don’t suddenly vanish when we decide to call what we build “apps”, nor do our users’ phones gain magical new powers when we do so.
It’s our responsibility to evaluate who uses what we make, and accept that the conditions under which they access the internet can be different than what we’ve assumed. We need to know the purpose we’re trying to serve, and only then can we build something that admirably serves that purpose—even if it isn’t exciting to build.
That last part is especially interesting because it’s in the same vein as what Chris wrote just the other day about embracing simplicity in our work. But it’s also interesting because I’ve overheard a lot of engineers at work asking how we might use CSS-in-JS tools like Emotion or Styled Components, both of which are totally neat in and of themselves. But my worry is about jumping to a cool tool before we understand the problem that we want to tackle first.
Jumping on a bandwagon because a Twitter celebrity told us to do so, or because Netflix uses tool X, Y or Z is not a proper response to complex problems. And this connects to what Jeremy says here:
Just – yikes. This makes me very excited for the upcoming articles in the series.
Jake Archibald looks at the websites of Formula One race teams and rates their performance, carefully examining their images and digging into the waterfall of assets for each site:
Trying to use a site while on poor connectivity is massively frustrating, so anything sites can do to make it less of a problem is a huge win.
In terms of the device, if you look outside the tech bubble, a lot of users can’t or don’t want to pay for a high-end phone. To get a feel for how a site performs for real users, you have to look at mid-to-lower-end Android devices, which is why I picked the Moto G4.
Poor performance can, and does, lead to exclusion. This point is extremely well documented by now, but warrants repeating. Sites that use an excess of resources, whether on the network or on the device, don’t just cause slow experiences, but can leave entire groups of people out.
Anyway, back to Jake’s post about Formula One websites. I love that Jake writes in such a way that his points aren’t insulting to those who work on these sites, but hones in on what we can learn about the myriad issues that lead to bad web performance. Subsequently, Jake provides us all with a ton of useful ideas for fixing performance issues like annoying layout changes, scripts that block rendering, unused CSS issues that also block rendering, and loading states.
Oh, and this reminds me that Chris noted a while back that the loading experience for most websites can be vastly improved:
Client side rendering is so interesting. Look at this janky loading experience. The page itself isn't particularly slow, but it loads in very awkwardly. A whole thing front-end devs are going to have to get good at. pic.twitter.com/sMcD4nsL98
Deploying a website to the server in 2019 requires much more effort than 10 years ago. For example, here’s what needs to be done nowadays to deliver a typical JS app:
split the app into chunks
configure webpack bundle
minify .js files
set up staging environment
upload the files to the server
Running these steps manually takes time, so an automation tool seems like an obvious choice. Unfortunately, most of contemporary CI/CD software provide nothing more than infrastructure in which you have to manually configure the process anyway: spend hours reading the documentation, writing scripts, testing the outcome, and maintaining it later on. Ain’t nobody got time for that!
This is why we created Buddy: to simplify deployment to the absolute minimum by creating a robust tool whose UI/UX allows you configure the whole process in 15 minutes.
This is a delivery pipeline in Buddy. You select the action that you need, configure the details, and put it down in place—just like you’re building a house of bricks. No scripting, no documentation, no nothing. Currently, Buddy supportsover 100 actions: builds, tests, deployments, notifications, DevOps tools & many more.
Buddy’s deployments are based on changesets which means only changed files are deployed – there’s no need to upload the whole repository every time.
Configuration is very simple. For example, in order to deploy to SFTP, you just need to enter authentication details and the target path on the server:
Buddy supports deployments to all popular stacks, PaaS, and IaaS services, including AWS, Google Cloud, Microsoft Azure, and DigitalOcean. Here’s a small part of the supported integrations:
Faster Builds, Better Apps
Builds are run in isolated containers with a preconfigured dev environment. Dependencies and packages are downloaded on the first execution and cached in the container, which massively improves build performance.
Buddy supports all popular web developer languages and frameworks, including Node.js, PHP, Ruby, WordPress, Python, .NET Core and Go:
Docker for the People
Being a Docker-based tool itself, Buddy helps developers embrace the power of containers with a dedicated roster of Docker actions. You can build custom images and use them in your builds, run dockerized apps on a remote, and easily orchestrate containers on a Kubernetes cluster.
Buddy has dedicated integrations with Google GKE, Amazon EKS, and Azure AKS. You can also push and images to and from private registries.
Sign up to Buddy now and get 5 projects forever free when your trial is over. The process is simple: click the button below, hook up your GitHub, Bitbucket or GitLab repository (or any other), and let Buddy carry you on from there. See you onboard!