Tag: development

The Kind of Development I Like

I’m turning 40 next year (yikes!) and even though I’ve been making websites for over 25 years, I feel like I’m finally beginning to understand the kind of development I like. Expectedly, these are not new revelations and my views can be summed up by two older Computer Science adages that pre-date my career.

  1. Composition over inheritance
  2. Convention over configuration

Allow me to take you on a short journey. In modern component-driven web development, I often end up with or see structures like this:

<ComponentA>   <ComponentB>     <ComponentC />   </ComponentB> </ComponentA>

Going down this route is a system where everything is nested child components and props or data are passed down from parent components. It works, but for me, it zaps the fun out of programming. It feels more like plumbing than programming.

Seeing Mozilla’s new ECSY framework targeted at 2D games and 3D virtual reality scenes, I immediately found myself gravitating towards its programming model where Components chain their behaviors onto objects called Entities.

EntityA   .addComponent('ComponentA')   .addComponent('ComponentB')

Hey! That looks like a chained jQuery method. I like this and not just for nostalgia’s sake. It’s the “composition” of functionality that I like. I know CSS is fraught with inheritance problems, but it reminds me of adding well-formed CSS classes. I gravitate towards that. Knowing I personally favor composition actually helped me resolve some weird inconsistent feelings on why I genuinely like React Hooks (composition) even though I’m not particularly fond of the greater React ecosystem (inheritance).

I think I must confess and apologize for a lot of misplaced anger at React. As a component system, it’s great. I used it on a few projects but never really bonded with it. I think I felt shame that I didn’t enjoy this very popular abstraction and felt out of sync with popular opinion. Now I think I understand more about why.

I should apologize to webpack too. As a bundling and tree shaking tool, it does a great job. It’s even better when all the configuration is hidden inside tools like Angular CLI and Nuxt. My frustrations were real, but as I learn more about myself, I realized it might be something else…

My frustrations with modern web development have continued to tumble downwards in levels of abstraction. I now think about npm and wonder if it’s somewhat responsible for some of the pain points of modern web development today. Fact is, npm is a server-side technology that we’ve co-opted on the client and I think we’re feeling those repercussions in the browser.

The Unix Philosophy encourages us to write small micro libraries that do one thing and do it well. The Node.js Ecosystem did this in spades. This works great on the server where importing a small file has a very small cost. On the client, however, this has enormous costs. So we build processes and tools to bundle these 46,000 scripts together. But that obfuscates the end product. It’s not uncommon that a site could be using fetch, axios, and bluebird all at the same time and all of lodash just to write a forEach loop.

In an “npm install your problems away” world, I feel like we do less programming and more configuring things we installed from the Internet. As dependencies grow in features and become more flexible, they allow you to configure some of the option flags. As a one-off, configs are a great feature. But cumulatively, even on a “simple” project, I can find myself managing and battling over a half dozen config files. One day while swimming in a sea of JSON configs it dawned on me: I don’t like configuration.

“Convention over configuration” was a set of ideals popularized by David Heinemeier Hansson (@DHH) and it guided a lot of the design of Ruby on Rails. While the saying has waned in popularity some, I think it sums up the kind of development I like, especially when frameworks are involved. Frameworks should try to be a collection of best practices, to save others from having to overthink decisions. I’ve said it before, but I think Nuxt does this really well. When I step into a system of predefined conventions and minor configuration, I’m much happier than the opposite system of no conventions and lots of configuration.

It’s a little weird to be turning 40 and discovering so much about the job I do on a daily basis. But it’s nice to have found some vocabulary and principles for what I like about development. Your list of things you like may be different than mine and that’s a good thing. I’d love to know more about the kind of development you like. What do you like to build? What are you optimizing for? What is your definition of success?

The post The Kind of Development I Like appeared first on CSS-Tricks.

CSS-Tricks

, ,

The Landscape of Cross-Platform App Development

I don’t track this stuff very well, but I get it. If you want a native app for Android and iOS, it sure would be nice to only have to write it once rather than two very different languages. Roughly double your reach without doubling the work. More and more of these things are reaching into desktop as well, meaning three targets for one.

Stuff like PhoneGap comes to mind. They say, “Reuse existing web development skills to quickly make hybrid applications built with HTML, CSS and JavaScript.” That’s obviously compelling for web developers who would have to learn minimal new things. My brain leans more toward, “Well if I’m going to write this thing in HTML, CSS, and JavaScript, why don’t I leave it at that?” Progressive Web Apps are doing great things. Still, I’m curious what the flagship PhoneGap apps are. Do I use any great ones and not even know it?

If you’re going to layer on a framework, but still stay in JavaScript-land, I’d think the biggest player is React Native. I hear it’s almost always used with Expo these days, which apparently has a thing to help React Native work on the web. Plus, there is literally React Native for Web.

In React-land, there is another new player: Ionic React. It targets all three platforms (iOS, Android, and Desktop) right out of the gate. Ionic isn’t new though — it’s long been a framework that does this in JavaScript (alternatively in Angular) and is apparently coming soon to Vue. Compelling. Nader Dabit has a first-look blog post that is pretty well done.

This all starts to get confusing to me as apparently Ionic ultimately uses Cordova under the hood… just like PhoneGap does? Or something? But now Ionic is moving to their own thing? I guess it makes sense that there are some low-level interpreter things that translate web primitives to native primitives and that people build developer tooling on top of that.

Google’s got a stake in this game with Flutter. Flutter is about hitting all three targets and helping you build the UI. Material design, animation and performance are all first-class citizens. It’s all in Dart though. Dart can compile to JavaScript (so it can be used for web stuff) but it also compiles to machine code. I imagine Flutter apps are compiled that way when they become native apps for bonus performance. I don’t have a good sense of how popular Dart is, but I’d assume web developers really won’t care what they’re writing in if great performance on all three targets is the outcome.

Ever further outside my wheelhouse is Xamarin, which is Microsoft’s take on unifying development on multiple platforms. The languages involved here are .NET and C#. It has all the same promises as everything else: build with this and it works everywhere! This is for developer convenience! It’s fast and you will make amazing things with it!

I’m always of two minds with all this stuff. Some part of me is envious of really nice native apps. Most of my favorite apps on my phone feel very native, although I’m not sure I could spot which framework created them, if any. For example, I have a Dribbble app on my phone and I quite like it. It’s simple and nice. I open it up and I’m logged in, which is usually not the case when I open a web app. It feels fast and has all the in-page animation stuff you expect from a native app. I totally wish we had an app like that for CodePen. Maybe if we were starting over today we’d write it in some cross-platform framework that targets all three platforms and maybe gives us some cool competitive advantage. Another part of me is like, meh, I’m a web guy on purpose. I think the native open web is the place to be and has the most longevity. A codebase that serves that well will be the least regrettable over time.

The post The Landscape of Cross-Platform App Development appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

Why Parcel Has Become My Go-To Bundler for Development

Today we’re gonna talk about application bundlers — tools that simplify our lives as developers. At their core, bundlers pick your code from multiple files and put everything all together in one or more files in a logical order that are compiled and ready for use in a browser. Moreover, through different plugins and loaders, you can uglify the code, bundle up other kinds of assets (like CSS and images), use preprocessors, code-splitting, etc. They manage the development workflow.

There are lots of bundlers out there, like Browserify and webpack. While those are great options, I personally find them difficult to set up. Where do you start? This is especially true for beginners, where a “configuration file” might be a little scary.

That’s why I tend to reach for Parcel. I stumbled upon it accidentally while watching a tutorial on YouTube. The speaker was talking about tips for faster development and he heavily relied on Parcel as part of his workflow. I decided to give it a try myself.

What makes Parcel special

The thing I love the most about this bundler: it doesn’t need any configuration. Literally, none at all! Compare that to webpack where configuration can be strewn across several files all containing tons of code… that you may have picked up from other people’s configurations or inherited from other projects. Sure, configuration is only as complex as you make it, but even a modest workflow requires a set of plugins and options.

We all use different tools to simplify our job. There are things like preprocessors, post-processors, compilers, transpilers, etc. It takes time to set these up, and often a pretty decent amount of it. Wouldn’t you rather spend that time developing?

That’s why Parcel seems a good solution. Want to write your styles in SCSS or LESS? Do it! Want to use the latest JavaScript syntax? Included. Need a server for development? You got it. That’s barely scratching the surface of the large list of other features it supports.

Parcel allows you to simply start developing. That’s the biggest advantage of using it as a bundler — alongside its blazing fast compiling that utilizes multicore processing where other bundlers, including webpack, work off of complex and heavy transforms.

Where using Parcel makes sense

Parcel, like any tool, is not a golden pill that’s designed as a one-size-fits-all solution for everything. It has use cases where it shines most.

I’ve already mentioned how fast it is to get a project up and running. That makes it ideal when working with tight deadlines and prototypes, where time is precious and the goal is to get in the browser as quickly as possible.

That’s not to say it isn’t up to the task of handling complex applications or projects where lots of developers might be touching code. It’s very capable of that. However, I realize that those projects may very well benefit from a hand-rolled workflow.

It’s sort of like the difference between driving a car with an automatic transmission versus a stick shift. Sometimes you need the additional control and sometimes you don’t.

I’ve been working on a commercial multi-page website with a bunch of JavaScript under the hood, and Parcel is working out very well for me. It’s providing my server, it compiles my Sass to CSS, it adds vendor prefixes when needed, and it allows me to use import and export in my JavaScript files out of the box without any configuration. All of this allowed me to get my project up and running with ease.

Let’s create a simple site together using Parcel

Let’s take Parcel for a test drive to see how relatively simple it is to make something with it.

We’re going to build a simple page that uses Sass and a bit of JavaScript. We’ll fetch the current day of the week and a random image from Unsplash Source.

The basic structure

There’s no scaffolding we’re required to use or framework needed to initialize our project. Instead, we’re going to make three files that ought to look super familiar: index.html, style.scss and index.js. You can set that up manually or in Terminal:

mkdir simple-site cd simple-site touch index.html && touch style.scss && touch index.js

Let’s sprinkle some boilerplate markup and the basic outline into our HTML file:

<!DOCTYPE html> <html lang="en"> <head>   <meta charset="UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1.0">   <meta http-equiv="X-UA-Compatible" content="ie=edge">   <link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">   <link rel="stylesheet" href="style.scss">   <title>Parcel Tutorial</title> </head> <body>   <div class="container">     <h1>Today is:</h1>     <span class="today"></span>     <h2>and the image of the day:</h2>     <img src="https://source.unsplash.com/random/600x400" alt="unsplash random image"> </div> <script src="index.js"></script> </body> </html>

You may have noticed that I’m pulling in a web font (Lato) from Google, which is totally optional. Otherwise, all we’re doing is linking up the CSS and JavaScript files and dropping in the basic HTML that will display the day of the week and a link from Unsplash that will serve a random image. This is all we really need for our baseline.

Marvel at Parcel’s quick set up!

Let’s run the application using with Parcel as the bundler before we get into styling and scripts. Installing Parcel is like any thing:

npm install -g parcel-bundler # or yarn global add parcel-bundler

Let’s also create a package.json file should we need any development dependencies. This is also where Parcel will include anything it needs to work out of the box.

npm init -y # or yarn init -y

That’s it! No more configuration! We only need to tell Parcel which file is the entry point for the project so it knows where to point its server. That’s going to be our HTML file:

parcel index.html

If we open the console we’ll see something like this indicating that the server is already running:

Server running at http://localhost:1234

Parcel’s server supports hot reloading and rebuilds the app as change are saved.

Now, heading back to our project folder, we’ll see additional stuff,that Parcel created for us:

What’s important for us here is the dist folder, which contains all our compiled code, including source maps for CSS and JavaScript.

Now all we do is build!

Let’s go to style.scss and see how Parcel handles Sass. I’ve created variables to store some colors and a width for the container that holds our content:

$ container-size: 768px; $ bg: #000; $ text: #fff; $ primary-yellow: #f9f929;

Now for a little styling, including some nested rulesets. You can do your own thing, of course, but here’s what I cooked up for demo purposes:

*, *::after, *::before {   box-sizing: border-box; }  body {   background: $ bg;   color: $ text;   font-family: 'Lato', sans-serif;   margin: 0;   padding: 0; }  .container {   margin: 0 auto;   max-width: $ container-size;   text-align: center;    h1 {     display: inline-block;     font-size: 36px;   }    span {     color: $ primary-yellow;     font-size: 36px;     margin-left: 10px;   } }

Once we save, Parcel’s magic is triggered and everything compiles and reloads in the browser for us. No command needed because it’s already watching the files for changes.

This is what we’ve got so far:

Webpage with black background, a heading and an image

The only thing left is to show the current day of the week. We’re going to use imports and exports so we get to see how Parcel allows us to use modern JavaScript.

Let’s create a file called today.js and include a function that reports the current day of the week from an array of days:

export function getDay() {   const today = new Date();   const daysArr = ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday'];   return daysArr[today.getDay()]; }

💡 It’s worth a note to remember that the getDay function returns Sunday as the first day of the week.

Notice we’re exporting the getDay function. Let’s go into our index.js file and import it there so it gets included when compiling happens:

import { getDay } from './today';

We can import/export files, because Parcel supports ES6 module syntax right out of the box — again, no configuration needed!

The only thing left is to select the <span> element and pass the value of the getDay function to it:

const day = document.querySelector('.today'); day.innerHTML = getDay();

Let’s see the final result:

Webpage with black background, heading that includes the day of the week, and an image below.

Last thing is to build for production

We’ve created the app, but we want to serve it somewhere — whether it’s your personal server or some zero-configuration deployment like Surge or Now — and we want to serve compiled and minified code.

Here’s the one and only command we need:

parcel build index.js
Terminal output after a successful build.

This gives us all of the production-ready assets for the app. You can read more about Parcel’s product mode for some tips and tricks to get the most from your environment.


I’ve said it several times and I’ll say it again: Parcel is a great tool. It bundles, it compiles, it serves, it pre- and post-processes, it minifies and uglifies, and more. We may have looked at a pretty simple example, but hopefully you now have a decent feel for what Parcel offers and how you might start to use it in your own projects.

I’m interested if you’re already using Parcel and, if so, how you’ve been using it. Have you found it works better for some things more than others? Did you discover some neat trick that makes it even more powerful? Let me know in the comments!

The post Why Parcel Has Become My Go-To Bundler for Development appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]

Get the Complete Intro to Web Development and Intro to React (with Hooks!) with Brian Holt 🎣

(This is a sponsored post.)

Hey, Marc here from Frontend Masters — excited to support CSS-Tricks ❤️!

Have you checked out Brian Holt’s courses yet? His most popular courses are the “Complete Intro” courses which give you the lay of the land in Web Development as well as the entire React ecosystem.

Complete Intro to Web Development, v2

This Complete Intro to Web Development assumes no prior coding knowledge, taking you from not knowing how websites are made to writing code for your own sites in HTML, CSS, JavaScript…all the way to building a server with Node.js!

You’ll learn to…

  • Setup the tools you need to write code.
  • Write HTML and CSS to put content on a websites and make them look aesthetically pleasing.
  • Make websites interactive with JavaScript, the de facto programming language of the web.
  • Use Git and other modern development tools through your computer’s terminal to save your work and pull in code libraries.
  • Use JavaScript via Node.js to serve your own website from a server.

Complete Intro to React, v5

In the Complete Intro to React course, you’ll start from the ground up, getting all the way to using the latest features in React, including hooks, effects, context, and portals. Throughout the course, you’ll piece together tools from the entire React ecosystem (like Reach Router) to build a full application to browse adoptable pets.

You’ll learn to…


  • Use the new hooks and effects methods to handle state in function components.

  • Understand how React works by writing React with and without JSX.

  • Package client-side applications with Parcel.

  • Leverage Prettier and ESLint to maintain high-quality code.

  • Route to pages and search results with Reach Router.


  • Grab API data and update state asynchronously in an effect.

Intermediate React, v2

The Intermediate React, v2 course is a modular course where you can pick and choose the various pieces of the react ecosystem you want to learn.

You’ll learn to…


  • Learn all the types of hooks, including useReducer, useCallback, useRef and more.

  • Make CSS local to your JavaScript components using the Emotion library.

  • Load your apps fast using code splitting, Suspense React and server-side rendering.

  • Use TypeScript for writing scalable apps with superior developer experience.

  • Redux for state management

  • Test your React applications using Jest.

You’ll love Brian’s awesome courses!

Join Now

Direct Link to ArticlePermalink

The post Get the Complete Intro to Web Development and Intro to React (with Hooks!) with Brian Holt 🎣 appeared first on CSS-Tricks.

CSS-Tricks

, , , , , , ,
[Top]

Using DevTools to Improve the UX Design to Development Process

I’d like to tell you how I see code and design intersect and support one another. Specifically, I want to cover how designers can use code in their everyday work. I suggest this not because it’s a required skill, but because even a baseline understanding of coding can make designs better and the hand-off from design to development smoother.

As a UX Designer, I am always looking for good ways to both explore my UX design problems and communicate the final designs to others. Over the past 30 years, my work has always involved working alongside developers, but generally there has been a great divide between what I do and what developers do.

I can code at a basic level. For example, I’ve helped teach C to undergraduates back when I was a post-graduate student. I’ve worked on the usability of JDeveloper Oracle’s Integrated Development Environment (IDE) for Java. I also worked for a very short while on simplifying the UX of a WordPress content management environment to make it accessible to less technical users. This required a good understanding of HTML and CSS. I also volunteered on the design of the PHP website and had to develop some understanding of the server side of web development.

But even given these experiences, I am not a developer in any true sense of the word. If I happen to be looking at code, it’s in a “just in time” learning model — I look up what I need and then hack it until it works. Learning this way has often been frowned upon, a bit like learning to drive without lessons. You pick up bad development habits but maybe that’s OK for the work I do.

So, no I don’t develop or write code. My day-to-day work is mostly been spent drawing, talking and gathering requirements. As far as design goes, I’ll start by sketching concepts in a notebook or using Balsamiq. Then I draw up UX wireframes and prototypes using tools like Axure, Adobe XD, InVision Studio, Figma and Sketch. By the time I’m ready to hand off my deliverables to development, all the visual assets and documentation have been defined and communicated. But I don’t step over the line into code development. That is just not my area of expertise.

So, why should designers know code?

We’ve already established that I’m no developer, but I have recently become an advocate for designers getting a good feel for how design and code interact.

In fact, I’d call it “playing with code.” I am definitely not suggesting that UX designers become developers, but at the very least, I think designers would benefit by becoming comfortable with a basic understanding of what is currently possible with CSS and best practices in HTML.

Being experimental is a huge part of doing design. Code is just another medium with which we can experiment and build beautiful solutions. So, we’re going to look at a couple of ways designers can experiment with code, even with a light understanding of it. What we’re covering here may be obvious to developers, but there are plenty of designers out there who have never experimented with code and will be seeing these for the first time.

So, it’s for them (and maybe a refresher for you) that we look at the following browser tools.

DevTools: The ultimate code playground

One of the concerns a UX designer might have is knowing how a design holds up once it’s in the browser. Are the colors accurate? Are fonts legible throughout? How do the elements respond on various devices? Will my grey hover state work with the white/grey zebra striping on my application grids in practice? These are some of the styling and interaction issues designers are thinking about when we hand our work off for development.

This is where DevTools can be a designer’s best friend. Every browser has its own version of it. You may have already played with such tools before. It’s that little “Inspect” option when right clicking on the screen.

Entering the wonderful world of DevTools can be done from any webpage.

What makes DevTools such a wonderful resource is that it provides a way to manipulate the code of a live website or web application without having to set up a development environment. And it’s disposable. Any edits you make are for your eyes only and are washed away the very moment the browser refreshes.

Editing code in DevTools makes changes to the page on the fly.

Further, DevTools can mimic other devices.

Need to see how a page or changes to it look on other devices? DevTools can give you an idea.

And, if you haven’t seen it yet, Firefox released a wonderful new shape path editor that’s very valuable for exploring interesting designs.

Over the past few months, I have been working on a complex web client for an enterprise-level application. Last sprint, my UX design story was to explore the look of the entry page of the web application and how to introduce a new color scheme. It was hard to envision how the changes I was making were going to impact the tool as a whole as some of the components I was changing are used throughout the product.

One day, when discussing a design decision, one of the developers tested out my suggested change to a component using the latest DevTools in his browser. I was amazed by how much DevTools has grown and expanded since I last remember it. I could immediately see the impact of that change across our whole web application and how different design decisions interacted with the existing design. I started to experiment with DevTools myself and was able to preview and experiment with how my own simple CSS changes to components would impact the whole web application. Super helpful!

However, it was also a little frustrating to not be able store my experiments and changes for future reference. So, I went exploring to see what else was out there to support my design process.

Chrome browser extensions

DevTools is are amazing right out of the box, but experimenting with code gets even more awesome when browser extensions are added to the mix. Chrome, in particular, has a couple that I really like.

Chrome Extension 1: User CSS

User CSS is a Chrome browser extension that allows you to save the changes you make in DevTools in an editable CSS code tab. These CSS changes are automatically executed on that page if User CSS is enabled. This means that you can set up CSS overrides for any page on the web, view them later, and share them with others. This can be an incredible tool when, say, doing a design review of a staging site prior to release, or really any design exploration for a web application or website that is viewable in a browser.

The first thing I do with User CSS is make the changes in the Chrome elements panel. Then, I simply cut and paste the CSS changes from Chrome’s DevTools to the User CSS code tab as I am going along. This video shows in detail the different ways to edit CSS, HTML and Javascript in Chrome DevTools and how I use UserCSS.

User CSS has a nice built-in code editor, so my code is always well formatted and includes syntax highlighting so I don’t have to worry about that sort of thing. I particularly like the fact that overrides are executed immediately so you can see changes on the fly. It also has a useful switch that allows you to turn your overrides on and off. This makes it very simple to demonstrate a set of changes to a team. This extension has allowed me to easily present a comparison between an existing page design and proposed changes. I’ve even used it to make a simple video demonstrating the proposed design changes.

In this video I make some simple edits to my web page and then show how I can turn on and off the edits by simply clicking the on/off button on User CSS:

This extension is a perfect if you all you need to do is edit CSS, particularly if you have some very simple design changes to make want to those changes to persist. However, the complexity of a design increases, I have found myself wanting to save more than one snippet of code at a time. Copying and pasting code in and out of the User CSS editor was becoming a pain. I wanted something with more flexibility and freedom to experiment. I also wanted to be able to look at simple changes to the HTML of my web application and even play with a bit of JavaScript.

That’s where the next extension comes into play.

Chrome Extension 2: Web Overrides

The second Chrome extension I found is called Web Override and it provides a way to override HTML, CSS and JavaScript. All of them! This is presented as three tabs, much the same way CodePen does, which makes it a very powerful tool for creating rough working design prototypes.

Web Overrides also allows you to save multiple files so that you can switch different parts of a design on or off in different combinations. It also quickly switches between the different options to show off different design concepts.

This video shows how I added an HTML element into a page and edited the new element with some basic CSS:

Using the HTML tab makes it possible to edit any element on the page, like swap out a logo, remove unnecessary elements, or add new ones. The JavaScript tab is similar in that I can do simple changes, like inject additional text into the website title so that I can test how dynamic changes might affect the layout — this can be useful for testing different scenarios, such as differences with internationalization.

These edits may be trivial from a coding perspective, but they allow me to explore hundreds of alternative designs in a much shorter time and with a lot less risk than scooting pixels around in a design application. I literally could not explore as many ideas as quickly using my traditional UX prototyping tools as I can with this one extension.

And, what is more, both me and my team have confidence in the design deliverables because we tested them early on in the browser. Even the most pixel-perfect Photoshop file can get lost in translation when the design is in the browser because it’s really just a snapshot of a design in a static state. Testing designs first in the browser using these extensions prove that what we have designed is possible.

On the flip side of this, you might want to check out how Jon Kantner used similar browser extensions to disable CSS as a means to audit the semantic markup various sites. It’s not exactly design-related, but interesting to see how these tools can have different use cases.

What I’ve learned so far

I am excited about what I have learned since leaning into DevTools and browser extensions. I believe my designs are so much better as a result. I also find myself able to have more productive conversations with developers because we now have a way to communicate well. The common ground between design and code in rapid prototypes really helps facilitate discussion. And, because I am playing around with actual code, I have a much better sense about how the underlying code will eventually be written and can empathize a lot more with the work developers do — and perhaps how I can make their jobs easier in the process.

It has also created a culture of collaborative rapid prototyping on my team which is a whole other story.

Playing with code has opened up new ideas and encouraged me to adapt my work to the context of the web. It’s been said that getting into the browser earlier in the design process is ideal and these are the types of tools that allow me (and you) to do just that!

Do you have other tools or processes that you use to facilitate the collaboration between design and code? Please share them in the comments!

The post Using DevTools to Improve the UX Design to Development Process appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]

Using Jetpack to Accelerate WordPress Development

(This is a sponsored post.)

[Geoff:] I’ve built a fair number of WordPress sites in my day. It’s been my go-to since the 2.x-ish days because it works for any site, big or small. That’s the sort of solution and flexibility you like to have as a freelancer.

Boy, I wish I had Jetpack available in those early days.

Like WordPress itself, Jetpack is a good solution for many, many of the types of things clients are looking for from a WordPress site. I used to spend hours researching the right plugin for a specific feature, whether that was for comment filtering, asset caching, beefier search functionality, creating custom post types on the fly… you name it. All of that — and a heckuva lot more — is included in Jetpack right out of the box.

Here’s what I’m talking about. A friend of mine runs a pop-up gallery here locally. She displays paintings, photographs, sculptures… basically anything super artsy from super talented locals. That includes events, socials, performances and screenings. The wild thing is that it “pops” up in different spots, based on what she’s showing and what public space is available. So, you get how a website would be helpful for visitors to keep tabs on what’s coming up and where things are going to take place, not to mention getting a recap on past events.

We’ve all made sites for friends, right? It’s the kind of thing you do for free on the side. That makes it something you want to do well, but not necessarily spend a ton of time making. That’s where Jetpack really helped me out in this case.

If Jetpack is new to you, it’s a WordPress plugin that, as part of what it does, is bring features from WordPress.com and makes them available on your self-hosted WordPress sites.

For example, my friend really needed to showcase work. This is less of a content site and more of a visual experience, so media plays a big role. Photos, video, audio. You get it. Good thing Jetpack has a “Portfolio” custom post type at the ready.

That’s a perfect start for showing things off, but my friend also needed a carousel to allow visitors to browse photos from events and artist works. This would’ve been something I probably would have turned to the WordPress plugin directory for in the past, or perhaps some (back then) jQuery plugin, but thankfully Jetpack had my back there, too.

While we’re on the topic of media, we know that heavy image files are a recipe for slow sites. There’s a ton of WordPress plugins that can help with caching, gzipping, and even lazy loading, but all that’s already in Jetpack. Why go reinvent the wheel, especially on what’s supposed to be a pretty quick build?

I think you catch my drift. The fact is that Jetpack is an effective way to supercharge a self-hosted WordPress site, connecting it to many of the same powerful services that you’d otherwise need to go to WordPress.com — or gobs of third-party plugins — to get. Plus, it’s built by Automattic, so you know it integrates seamlessly with WordPress. No better confidence than going with something the primary maintainers of WordPress are willing to slap their name on!

Sure, we’ve only looked at a very simple example of how powerful Jetpack is for a small site. But don’t be fooled: Jetpack is capable of handling the needs of large-scale sites as well. In fact, we love Jetpack here at CSS-Tricks because it powers so much of what you see on the site, from social sign-in and automated sharing, to downtime monitoring and site search. It’s robust, dependable, and just gosh darn delightful to use.

And, hey, there’s a free tier you can start using right away and it includes a generous number of features that help with security, performance, analytics, and theming… and it only goes up from there. 🚀

Get Jetpack

Direct Link to ArticlePermalink

The post Using Jetpack to Accelerate WordPress Development appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]

Corvid by Wix: Accelerated Development of Web Applications

(This is a sponsored post.)

It’s been interesting to watch Wix evolve from a website builder into a full-fledged platform for developing web applications. It’s still just as easy for anyone to spin up a website with the visual builder that’s always been there, but Wix Code was introduced a little while back as a way to give developers more hands-on control of the code under the hood to make custom sites.

Well, that evolution continues as Wix Code recently became Corvid by Wix.

Why the name change? It’s totally understandable when you see just how many new features and tools are available for developers. There are literally 28 features in all, from a payment API and custom forms to CRM functionality and a Node.js server for writing JavaScript for both the front and back end. There’s a ton of control and power and it’s certainly worth checking out.

But what we really want to spotlight here are the brand-new features the Wix team rolled out along with the name change earlier this month.

Connect to External Data Sources

Wix has provided a built-in database for a while, but now Corvid works with external data. That means you get even more control over the data on a Wix site and moer opportunities to fetch and optimize data. We’ve talked about the numerous ways to use spreadsheets as data sources before. Now, that same concept can be brought into the Wix ecosystem!

Testing and Deploying Changes

Want to see if changing the color of a button from green to purple increases conversion? Or maybe you’re trying to decide between two new page layouts and aren’t sure which one will work best? Corvid lets you have it both ways with a feature to create a release candidate and serve it to a percentage of visitors before rolling it out to everyone. It’s native A/B testing, which is a powerful marketing technique, not to mention a solid way to test user experience.

Local Development

The front-end visual editor in Wix makes building and editing sites an easy experience. It’s especially great for those who don’t work with code often or even at all.

But many CSS-Tricks readers like yourself enjoy working with code and are good at it. Corvid brings a built-in IDE to the table. Or, if you prefer, pull your Wix project files into your local environment and use the code editor of your choice.

So, whether you’re more comfortable working with a visual interface, a built-in editor, or locally, Corvid has got you covered.

App Monitoring

Need access to console logs, HTTP functions, and web module functions? Yep, Corvid offers all of that, too. The system continually monitors Wix sites and logs activity all the while so you know when an error takes place and what caused it. Those of you who have worked with monitoring services before know how great it is to have error logs for quickly finding and fixing the source of an issue — and now it’s built right into Wix.

Speaking of working with monitoring services, Corvid will integrate with those as well so you never have to interrupt things or make a switch if you don’t want to. So nice!

Start Playing with Corvid!

What we’ve covered here is merely the tip of the iceberg when it comes to Corvid and all that it offers for a complete development platform and framework. Plus, there’s so much more to come, so definitely keep an eye out for new updates and releases as they’re announced… which we’ve seen moves at a fast pace.

Meet Corvid

Direct Link to ArticlePermalink

The post Corvid by Wix: Accelerated Development of Web Applications appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Make it hard to screw up driven development

Development is complicated. Our job is an ongoing battle between getting the job done and doing that job in a safe, long-lasting way.

Developers say things like, “I’m just going to do this quick and dirty first,” because it’s taken as fact that if you code anything quickly, it not only will be prone to mistakes, but that you’ll be deliberately not honoring established conventions and skipping tasks that make for more solid code.

There is probably no practical way to make it impossible to write sloppy, bad code, but it is fascinating to consider how tooling has evolved to make it harder.

Let’s get all Poka-yoke on development.

The obvious ones are automated code quality tools.

Say you’re writing JavaScript. ESLint is a mega-popular tool that looks at your code as you are writing it and lets you know about issues.

ESLint is configurable and those configurations can be enforced to a team’s liking. If you’d prefer to use some strong and established conventions, I believe the most popular out there is AirBnbs configuration.

There are alternatives to everything, of course. This post isn’t so much about a comprehensive tooling list as it is about considering the types of tools that help us push us toward writing better code. That said, stylelint is good for CSS, PHP_CodeSniffer is good for PHP, and Rubocop is good for Ruby.

Prettier is in a similar, but unique category. It is like a “beautifier” for your code, in that it helps you reformat it not only to look good but to follow team conventions (e.g. single quotes! Two space indentions!) as well. The most common way to use Prettier is that it runs as you save the file. So perhaps you write quickly and don’t worry about formatting as much, because it happens for you the second you save. There is an interesting side-benefit of quality here as Prettier can fail, and if it does, you have a problem in the syntax of your code you need to fix. Super useful.

Prettier failing.

I’m intrigued by tools like Sonarlint, Code Climate, and Resharper that look, to me, essentially like linters, but deliver only a best-practice analysis rather than configuring things yourself. It also claims to understand your code at a deeper level. Webhint and Deepscan look similarly interesting. Feel free to correct me if I have this wrong because I haven’t gotten a chance to use any of them yet.

Taking linting a step further, you can make passing lint tests a requirement before files can even be committed into Git. Git hooks are the ticket here, and the most popular tool for managing them is Husky.

Similarly, actual tests are powerful preventers of bad code.

It’s always smart to write tests. Deploying code that breaks features is embarrassing, a waste of time, and can negatively impact your business. Yet we do it all too often. The whole point of tests is to prevent that.

Things like Jest for JavaScript and RSpec for Ruby are useful, and considered unit testing. It’s work! You manually write functions that expect certain results. I expect that if I call a function with these parameters it returns this value!

Test-Driven Development (TDD) is a practice in which you write the test before you write the actual code that does the thing you’re trying to do. It’s a nice way to work if you can pull it off, as you’ve got code coverage from the get-go.

Another type of automated testing is integration (also known as end-to-end) testing. I’m a fan of Cypress for that. It simulates a user actually using a browser. Go to this URL! Click this! Fill out this field and submit the form! Does this thing exist now? Is the URL what it’s supposed to be? Is this other thing visible? That kind of testing is powerful in that a lot of things have to be going right for these to pass, so there is a ton of implied testing.

As a CSS kinda guy, I’m also a fan of tests that watch to make sure the site looks how it’s supposed to look and there aren’t unintended consequences of styling changings. Percy is awesome for that (see our video).

And while we’re talking about all the different types of automated testing you can do, there are all sorts of tools to automate some level of accessibiilty testing. Plus, there are tools like Calibre and SpeedCurve that automate Lighthouse for watching performance.

Languages and language features that help us, wittingly or not

Take JSX, for example. It’s entirely possible to write bad HTML in JSX, but you can’t write broken HTML. The component will error out entirely and you’ll know as you’re working. That’s not even close to the reason JSX exists, but I find it an interesting side effect. I’ve fixed many bugs in my career that had to do with malformed HTML causing problems, ranging from tiny side effects to massive layout blunders.

Prettier is catching the problem here, but we’d see an error in the console if this compiled and went to the browser.

Similarly, a tool like Emmet can help generate valid HTML. I use Emmet all the time, and didn’t even think of that until it was mentioned to me.

I also think of React features, like PropTypes, that throw errors when missing or unexpected data is thrown at them. Not to mention you can configure your linter to yell at you if you’re missing the PropType. That’s pretty powerful testing to be enforced for a fairly small amount of labor (compared to, say, writing a test). You can even force them to help with accessibility.

It would be impossible to not mention TypeScript here. One of the major points of using TypeScript is code safety. The fact that it’s getting huge (listen to Laurie Voss on this) points to the fact that we want to enforce that safety. I remember when Angular 2 came out, there were long, solid explanations as to why. People also talk about the tooling improvements you get with TypeScript: advanced autocompletion, navigation, and refactoring. They are all, in a way, also about code safety — having the editor help you write correct file names and function names. TypeScript or not, any sort of autocomplete/IntelliSense is great to have.

The whole idea of this post came from me thinking about how GraphQL has this “you can’t screw it up” quality to it. You can’t ask for data that isn’t there, as it will error right as you’re working with it — and then you’ll fix it. And you can’t get back data that you aren’t expecting, as you’ve described exactly what you want back and that’s what GraphQL does. It’s not that you can’t write bad code that uses GraphQL or write a bad GraphQL implementation, but the technology sort of encourages better code and I’m fascinated by that.

CSS-in-JS, while that’s probably too broad a term generally, applies to this discussion. Most of the solutions on that spectrum involve some kind of style scoping, and style scoping provides this “you can’t screw it up” topic we’re focusing on. You can’t cause unintended side effects when the selector you’ve just written compiles to something you’ve never hand-written, like .SpecificComponent_root_34lkj4x.

Your co-workers are an awesome line of defense

First, give y’allselves a system. Nothing goes to the master branch directly, and everything has to be a Merge/Pull Request. That gives you a spot to talk about code quality — not to mention a place where you can run a suite of automated tests before the code is dangerously close to production.

GitLab has a concept of approvers for a Merge Request. You pick some people that have to approve the branch before it can be merged.

GitHub has the same concept with protected branches. Perhaps the best thing you can do to prevent bad code is to widen the responsibility. There is always a risk this just becomes a glance-at-the-code-for-two-seconds-and-give-it-a-👍 motion, but that’s on y’all to make sure reviews are taken seriously. I’ve seen lots of value in a requirement that many sets of eyeballs need to be on code before it goes out. “Given enough eyeballs, all bugs are shallow” and all that.


We’ll always be screwing up code, but we can also always be finding ways not to.

The post Make it hard to screw up driven development appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

A Site for Front-End Development Conferences (Built with 11ty on Netlify)

I built a new little site! It’s a site for listing upcoming conferences in the world of front-end web design and development. In years past (like 2017), Sarah Drasner took up this daunting job. We used a form for new conference submissions, but it was still a rather manual task of basically manually editing a blog post. I wanted to keep doing this, as I think it’s valuable to have a simple reference page for conferences in our niche slice of the web, but I wanted the site to be able to live on year after year with lower maintenance-related technical debt.

So this is what I did!

I wanted to get it on GitHub.

So I put it there. Part of the beauty of GitHub is that it opens up the idea of collaboration through pull requests to really anyone in the world. You need to have a GitHub account, but that’s free, and you need to understand Git at least on some minor level (which is a barrier that I’d like to resolve in time), but it invites more collaboration than something like just asking people to email you content and ideas.

I wanted the content in Markdown in the Repo.

The Front Matter format, which is Markdown with some data the the top, is such a useful and approachable format. You need almost zero knowledge, not even HTML, to be able to create/edit a file like this:

Having the actual conference data in the repo means that pull requests aren’t just for design or features; more commonly, they will be for actual conference data. The work of making this site full of all the best conferences is the work of all of us, not just one of us.

At the time of this writing there have already been 30 closed pull requests.

I used 11ty to build the site.

11ty is almost fascinatingly simple. It looks in one directory for what it needs to process or move to another directory. It supports my favorite templating system out of the box: Nunjucks. Plus front matter Markdown like I mentioned above.

I was able to essentially design a card that displays the data we get from the Markdown files, and then build the homepage of the site by looping over those Markdown files and applying the templated card.

11ty is based on Node.js, so while I did have some learning-curve moments, it was comfortable for me to work in. There definitely is configuration for doing the things I wanted to be doing. For example, this is how I had to make a “collection” of conferences in order to loop over them:

config.addCollection("conferences", function(collection) {   let allConferences = collection.getFilteredByGlob("site/conferences/*.md");   let futureConferences = allConferences.filter(conf => {     return conf.data.date >= new Date();   });   return futureConferences; });

The site is hosted on Netlify.

One reason to use Netlify here is that it’s incredibly easy. I made a site site in Netlify by connecting it to the GitHub repo. I told it how to build the site (it’s a single command: eleventy) and where the built site files are (dist), and that’s it. In fact, that’s even part of the repo:

Now whenever I push to the master branch (or accept a pull request into master), the site automatically rebuilds and deploys. Just takes seconds. It’s really amazing.

Better, for each pull request, Netlify makes sure everything is in order first:

My favorite is the deploy preview. It gives you an (obscure) URL that will literally last forever (immutable) and that serves as a look at the built version of this site with that pull request.

So, not only is it extremely easy to use Netlify, but I get a bunch of stuff for free, like the fact that the site is smokin’ fast on their CDNs and such.

I’m also excited that I’ve barely tapped into Netlify’s features here, so there is a lot of stuff I can dig into over time. And I intend to!

I use Zapier to re-build the site every day.

There is a bit of a time-sensitive nature to this site. The point of this site is to reference it for upcoming conferences. It’s less interesting to see past conferences (although maybe we can have a browse-able archive in the future). I like the idea of ripping off past conferences for the homepage. If this was PHP (or whatever), we could do that at runtime, but this is a static site (on purpose). Doing something like this at build time is no big deal (see that code snippet above that only returns conferences past today’s date). But we can’t just waiting around for pull requests to re-build the site, nor do I want to make it a manual thing I need to do every day.

Fortunately, this is easy as pie with Zapier:

Phil Hawksworth took this to the extreme once and built a clock website that rebuilds every minute.


This site wasn’t just an experiment. I’d like to keep it going! If you’re part of running a conference, I’m quite sure it doesn’t hurt to add it to add yours, just so long as it has an enforcable and actionable Code of Conduct, and is within the world of front-end web design and development.

The post A Site for Front-End Development Conferences (Built with 11ty on Netlify) appeared first on CSS-Tricks.

CSS-Tricks

, , , , , ,
[Top]

Using Dotfiles for Managing Development and Many Other Magical Things

Howdy folks! 🎉 I’m Simon Owen, and over the years, I’ve loved being a part of and learning from the dotfiles community. I spend a lot of time teaching developers and running workshops. In those sessions, demonstrating how I set up my development environment is often one of things that folks appreciated the most.

Dotfiles are a key part of my development environment. Haven’t heard of them? Well, even if you have, it’s a good idea to walk through what they are and the benefits of using them.

Last year, I set myself a goal to create a screencast series. If you like this article and want to find out more, please subscribe to the mailing list and get the download link. If you really like it, you can also 🦄 donate here! 🦄

A dot-what-file?

If you’re hearing about dotfiles for the first time, it’s totally fine to be confused about what they are and what they do. I recall that it took me a considerable amount of time before I realized a dotfile is simply a file that has a dot in front of the file name!

There are two common examples of dotfiles. First, the ones you might already be familiar with are those often found at the root of many open source projects — for example, .editorconfig contains code editor preferences to help maintain consistent coding styles for a project. You may also have seen .stylelintrc and .eslintrc floating around, which set CSS and JavaScript rules, respectively.

Second (and the ones we’re looking at today), are dotfiles that can live at the root level of a user directory (i.e. /Users/<username> ). One such dotfile is .aliases, which contains custom named commands that can speed up work in the Terminal. Another is .bash_prompt, which is used to change the $ in Terminal to something a little more fun. In my case, I set it so this dude pops up to make me smile when things get tough:

༼ つ ◕_◕ ༽つ

Hopefully, you’re already starting to get a good sense of how useful dotfiles can be. They’re sort of like hidden gems (literally, since they’re hidden from views by default) that unlock superpowers for your machine to help with development. We’re talking about automation, optimizations, and efficient workflows, among other things.

First, I want to give props to the dotfiles community

Before we dig into dotfiles, it’s worth calling out how great the community behind them is. When I first forked Paul Irish’s dotfile repo, there was a lot going on in there I didn’t understand. Mathias Bynens and Paul Irish helped me immensely by answering questions about the code and it was their willingness to help that served as one of the reasons I became drawn to both the concept and the community.

Sometimes, I’ll post something to the community that I’d like to automate, but can’t figure it out for the life of me. And, without fail, I’ll get a helpful reply. Case in point: Eric Czarny wrote an app for me to automate my Spectacle settings and Mathias also contributed a code snippet. How cool is that?!

Then there are things like macOS updates. The dotfiles community is often on top of this and provide useful advice on GitHub comments regarding anything that no longer works or other useful information. You can then amend your dotfiles accordingly, such as adding the following code that increases the sound quality for Bluetooth headphones/headsets:

defaults write com.apple.BluetoothAudioAgent "Apple Bitpool Min (editable)" -int 40

Digging into dotfiles

The code example above might look a bit familiar to you. It’s along the same lines as this often-used one to show hidden files:

defaults write com.apple.finder AppleShowAllFiles -bool true

…or this one to add spaces to the dock:

defaults write com.apple.dock persistent-apps -array-add '{"tile-type"="spacer-tile";}'; killall Dock

These commands can be pasted directly into the Terminal. As you might expect, something like -bool true will change a boolean value from false to true and reset the command for later use.

If you’e like me and have a lot of these commands, then this is where the .macos (previously .osx) dotfile becomes especially useful. Instead of copying and pasting each command individually, we can automate and run all of them in one go.

Let’s walk through some examples

There are so many awesome things we can do in dotfiles. Here are some practical use cases that I rely on for my day-to-day work.

Setting aliases for default commands (.aliases)

Navigating between directories in the Terminal can be cumbersome and it’s easy to get lost in cd madness.

We can replace the standard “change directory” (cd) command with a custom command in the .aliases dotfile. For example, use this alias to ditch the cd prefix altogether when using the command cd .. to move up a directory in favor of .. by itself.

alias ..="cd .."

Sure, it’s only dropping two letters, but how much easier is that to remember?

An animated screenshot of a Terminal window typing two periods instead of the full cd command to move up a level in the directory.

We can do the same thing to make shortcuts to certain directories:

alias dl="cd ~/Downloads"

Or, create aliases for shorthand command tasks:

alias hs="hexo serve"
An animated screenshot of a Terminal window typing a command called hs instead of typing out hexo serve in full.

Oh, here’s another one! List only directories:

alias lsd="ls -lF $ {colorflag} | grep --color=never '^d'"

Make a custom bash prompt for a personal touch to the Terminal (.bash_prompt)

I referenced this a little earlier, but here’s how I turned my bash prompt ($ ) into a little dude that’s way more fun to look at it. This is done directly in the .bash_prompt dotfile.

PS1="༼ つ ◕_◕ ༽つ"

Create Git shortcuts to speed up commits (.gitconfig)

We can make it a little more efficient to commit all changes at once in the .gitconfig dotfile. Using ca is a lot more concise than !git add -A && git commit -av .

ca = !git add -A && git commit -av

Another handy shortcut: find commits by commit message.

fm = "!f() { git log --pretty=format:'%C(yellow)%h  %Cblue%ad  %Creset%s%Cgreen  [%cn] %Cred%d' --decorate --date=short --grep=$ 1; }; f"

Automate common Homebrew tasks (brew.sh)

Use Homebrew for package management? Although not strictly a dotfile (it doesn’t have a dot before the file name), Homebrew gives us the brew.sh shell script file. This file automates the installation and management of Apps and Tools:

brew install git brew install tree brew cask install google-chrome brew cask install iterm2 brew cask install sublime-text

Protect your Git credentials (.extra)

Hide information you don’t want to share publicly in one file in a private repo and bring it in for you alone. For example, a good idea for this file is anything that’s specific to you, such as your Git credentials. This will prevent people from cloning, running your dotfiles, then committing as you!

# Git credentials # Not in the repository, to prevent people from accidentally committing under my name GIT_AUTHOR_NAME="Simon Owen" GIT_COMMITTER_NAME="$ GIT_AUTHOR_NAME" git config --global user.name "$ GIT_AUTHOR_NAME" GIT_AUTHOR_EMAIL="<ADD-YOUR-EMAIL-HERE>" GIT_COMMITTER_EMAIL="$ GIT_AUTHOR_EMAIL" git config --global user.email "$ GIT_AUTHOR_EMAIL"

Write custom functions for tasks (.functions)

Dotfiles are more than shortcuts and aliases. We can also make custom functions in .functions that do more advanced lifting. For example, create a new directory and change directory to it:

function mkd() {   mkdir -p "$ @" && cd "$ _"; }
An animated screenshot of a Terminal window typing mkd new to trigger the creation of a new folder and navigating to it.

Or, we can open a given location in Finder with a one-letter command (o):

function o() {   if [ $ #-eq 0 ]; then     open .;   else     open "$ @";   fi; }

Specify your $ PATH and keep private (.path)

$ PATH allows the running of executable files. Instead of navigating to each path manually in Terminal, here we can set the file paths so they can run the executable files directly. It might be the case that this file contains sensitive information. As such, this file is often kept in a private repo.

Here’s an example adding ~/utils to the $ PATH:

export PATH="$ HOME/utils:$ PATH"

Force Vim to use a particular theme (.vimrc)

Editor config files are great for ensuring consistent formatting across projects, but we can also tell a Vim editor to use a specific theme in a .vimrc file:

" Use the Solarized Dark theme set background=dark colorscheme solarized let g:solarized_termtrans=1

Bonus: Helpful Terminal recipes for macOS

OK, so here’s a little bit of a bonus for Mac users that isn’t related to dotfiles, but are things we can do in the Terminal to give macOS superpowers to do pretty awesome things that make day-to-day use a little easier and more pleasant.

First off, we can show hidden files by default in the Finder so dotfiles are visible all the time by typing this into the Terminal:

defaults write com.apple.finder AppleShowAllFiles -bool true

Find the way that scrollbars toggle on and off in Finder jarring? Let’s make them visible at all times:

defaults write NSGlobalDomain AppleShowScrollBars -string "Always"

By default, macOS checks for software updates once per week. But maybe we want to check once a day or at some other interval:

defaults write com.apple.SoftwareUpdate ScheduleFrequency -int 1

You know how holding down on a keyboard key repeats that character? Well, it repeats at a determined speed that we can supercharge to blazingly fast:

defaults write NSGlobalDomain KeyRepeat -int 0

Some people love the way macOS includes a box shadow when taking a screenshot of a window. Others don’t. Here’s how to turn it off:

defaults write com.apple.screencapture disable-shadow -bool true

And, in this example, we can automate the size of icons in the Dock:

defaults write com.apple.dock tilesize -int 36

This is only the tip of the iceberg! In my screencast series I go over more than one hundred of them.

Conclusion

Web development is increasingly more complicated as time goes on. We all have ways of making our development workflow a little easier and comfortable based on personal preferences.

You may be a seasoned developer and aware of such things as Node, npm, and Git but still find yourself stuck in a Terminal window with a bunch of errors. Or, you might be starting out and find these, and other tools, complex and tough to grasp.

Either way, hopefully knowing more about dotfiles and what they’re capable of doing gives you a new weapon in your arsenal to make your development environment tailored to you, speed up your workflow and give your machine added superpowers!

As a reminder, my screencast series will give you more tips and tricks, plus a good idea of how to get your development environment set up. This is the first in the series. Going forwards, I’m going to look at expanding on it, so please let me know if there’s anything else you’d like me to cover!

The post Using Dotfiles for Managing Development and Many Other Magical Things appeared first on CSS-Tricks.

CSS-Tricks

, , , , , ,
[Top]