CSS-Tricks is 12 years old! Firmly into that Early Adolescence stage, I’d say 😉 As we do each year, let’s reflect upon the past year. I’d better have something to say, right? Otherwise, John Prine would get mad at me.

How the hell can a person go to work in the morning
And come home in the evening and have nothing to say.
– Angel From Montgomery

See the Pen
Fireworks! by Tim Severien (@timseverien)
on CodePen.

Easily the biggest change this year was design v17

We redesign most years, so it’s not terribly shocking I suppose that we did this year, but I think it’s fairly apparent that this was a big one. The biggest since v10.

Here’s a writeup on v17.

I still get happy emails about it.

The aesthetics of it still feel fresh to me, 6 months later. There are no plans at all yet for what the next version will be. I imagine this one will last a good couple of years with tweaks along the way. I’m always working on it. Just in the last few days, I have several commits cleaning things up, adding little features, and optimizing. That work is never done. v18 might just be a more thorough scrubbing of what is here. Might be a good release to focus on the back-end tech. I’ve always wanted to try some sort of MVC setup.

In a way, things feel easier.

There is a lot going right around here. We’ve got a great staff. Our editorial workflow, led by Geoff, has been smooth. There are ebbs and flows of how many great guest posts are in the pipeline, but it never seems to run dry and these days we stay more ahead than we ever have.

We stay quite organized with Notion. In fact, I still use it heavily across all the teams I’m on. It’s just as fundamental as Slack and email.

We’re still working with BuySellAds as a partner to help us sell advertising and sponsorship partnerships. We’ve worked with them for ages and they really do a good job with clean ad tech, smooth integration workflows, and finding good companies that want to run campaigns.

On the 10th anniversary I wrote:

If you do all the work, the hope is that you just keep to keep on keeping on. Everyone gets paid for their effort. This is not a hockey-stick growth kind of site. It’s a modest publication.

Yep.

Check out a year over year chart from Google Analytics:

I can look at that and celebrate the moments with growth. Long periods of 20% year over year growth, which is cool. Then if you look at just this last month, we’re more even or a little bit under 2018 (looking at only pageviews). Good to know, kinda, but I never put much stock in this kind of generic analytics. I’m glad we record them. I would want to know if we started tanking or growing hugely. But we never do. We have long slow steady growth and that is a comfortable place for me.

Thinking on ads

The world of advertising is tightly integrated around here, of course. I’m sure many of you look at this site and go JEEZ, LITTLE HEAVY ON THE ADS, EH? I hope it’s not too big a turnoff, as I really try to be tasteful with them. But another thing you should know is that the ad tech is clean. No tracking stuff. No retargetting. No mysterious third-party JavaScript. There might be an impression-tracking pixel here and there, but that’s about it. No slew of 100’s of requests doing god-knows-what.

That’s not by accident. It’s clear to me now how to go down that other road, and that road has money on it. Twice as much. But I look at it as what would be short term gains. Nobody is going to be more mad at me than you if I slap 80 tracking scripts on this site, my credibility amongst devs goes out the window along with any hopes of sustaining or growing this site. It’s no surprise to me that on sites without developers as an audience, the tendency is to go down the golden road of tracking scripts.

Even the tech is easier.

Just starting in July I’ve gotten all my sites on Flywheel hosting, and I’ve written about that here just today. Flywheel is a new sponsor here to the site, and I’m equally excited about that as I am in actually using it. Between using Local for local WordPress development, GitHub for repos, Buddy for deployment, Cloudflare for DNS/CDN… everything just feels smooth and easy right now.

The way I feel about tech at the moment is that nearly anything is doable. Even stuff that feels insurmountable. It’s just work. Do a bunch of work, get the thing done.

Fancy posts

One thing that we snuck in this year is the idea of posts that have special design applied to them. The term “Art-directed articles” seems to be the term that has stuck for that, for better or worse, and we’ve added to that.

There are posts like The Great Divide that I intentionally wanted to make stand out.

And now we’ve taken that and turned it into a template. The point of an art-directed article is to do something unique, so a template is a little antithetical to that, but I think this strikes a nice middle ground. The template assumes a big full-width header with background image under big title and then is otherwise just a centered column of type on white. The point is to use the template, then apply custom styles on top of it as needed to do something special for the post. I have a good feeling we’ll keep using it and have fun with it, and that it won’t be too burdensome for future designs.

Elsewhere

Last year at this time I was just settling into living in Bend, Oregon. It still feels that way. I’m in a new house now, that we’ve bought, and it feels like this is a very permanent living situation. But we’re less than a year into the new house so there is plenty of dust to settle. I’m still honeymooning on Bend as I just love it here so much. My daughter is just over a year and a half now so stability is very much what we’re after.

Professionally, most of my time is on CodePen, of course. There is a lot of overlap, like the fact that we work with BuySellAds on both sites and often sell across both. Plus working on CSS-Tricks always has me in CodePen anyway ;). Miraculously, Dave Rupert and I almost never miss a week on ShopTalk Show. Going strong after all these years. Never a shortage of stuff to talk about when it comes to websites.

Thank you

A bit hearty thanks from me! Y’all reading this site is what makes it possible.

The post The Twelfth Fourth appeared first on CSS-Tricks.

I first heard of Flywheel through their product Local, which is a native app for working on WordPress sites. If you ask around for what people use for that kind of work, you’ll get all sorts of answers, but an awful lot of very strong recommendations for Local. I’ve become one of them! We ultimately did a sponsored post for Local, but that’s based on the fact that now 100% of my local WordPress development work is done using it and I’m very happy with it.

Now I’ve taken the next step and moved all my production sites to Flywheel hosting!

Full disclosure here, Flywheel is now a sponsor of CSS-Tricks. I’ve been wanting to work with them for a while. I’ve been out to visit them in Omaha! (? at Jamie, Christi, Karissa, and everybody I’ve worked with over there.) Part of our deal includes the hosting. But I was a paying customer and user of Flywheel before this on some sites, and my good experiences there are what made me want to get this sponsorship partnership cooking! There has been big recent news that Flywheel was acquired by WP Engine. I’m also a fan of WP Engine, being also a premium WordPress host that has done innovative things with hosting, so I’m optimistic that a real WordPress hosting powerhouse is being formed and I’ve got my sites in the right place.

Developing on Local is a breeze

It feels like a breath of fresh air to me, as running all the dev dependencies for WordPress has forever been a bit of a pain in the butt. Sometimes you have it going fine, but then something breaks in the most inscrutable possible way and it takes forever to get going again. Whatever, you know what I mean. At this point, I’ve been running Local for over a year and have had almost no issues with it.

There are all kinds of features worth checking out here. Here’s one that is very likely useful to bigger teams. Say you have a Flywheel account with a bunch of production sites on it. Then a new person starts working with you and they have their own computer. You connect Local to Flywheel, and you can pull down the site and have it ready to work on. That’s pretty sweet.

Local doesn’t lock you into anything either. You can use Local for local development and literally use nothing else. Local can push a site up to Flywheel hosting too, which I’ve found to be mighty useful particularly for that first deployment of a new site, but you don’t have to use that if you don’t want. I’ll cover more about workflow below.

Other features that I find worthy of note:

• Spinning up a new site takes just a second. A quick walkthrough through a wizard where they ask you some login details but otherwise offer smart-but-customizable defaults.
• Dealing with HTTPS locally is easy. It will create a certificate for you and trust it locally with one click.
• You can flip on “Live Link”, which uses ngrok to create a live, sharable URL to your localhost site. Great for temporarily showing a client or co-worker something without having to move anything.
• One click to pop open the database in Sequel Pro, my favorite free database tool. Much easier than trying to spin up phpMyAdmin or whatever on the web to manage from there.

Flywheel’s Dashboard is so clear

I love the simple UI of Local, and I really like how that same design and spirit carries over into the Flywheel hosting dashboard.

There are so many things the dashboard makes easy:

• You need an SSL cert? Click some buttons.
• Wanna force HTTPS? Flip a switch.
• Wanna convert the site to Multisite? Hit a button.
• Need to edit the database? There is a UI around it built in.
• Want a CDN? Toggle a thing.
• Need to invite a collaborator on a site? Go for it.
• Need a backup? There are in there, download it or restore to that point.

It’s a big deal when everything is simple and works. It means you aren’t burning hours fighting with tools and you can use them doing work that pushes you forward.

Workflow

When I set up my new CSS-Tricks workflow, I had Flywheel move the site for me (thanks gang!) (no special treatment either, they’ll do that for anybody).

I’ve got Local already, so my local development process is the same. But I needed to update my deployment workflow for the new hosting. Local can push a site up to Flywheel hosting, but it just zips everything up and sends it all up. Great for first deployment but not perfect for tiny little changes like 95% of the work I do. There is a new Local for Teams feature, which uses what they call MagicSync for deployment, which only deploys changed files. That’s very cool, but I like working with a Git-based system, where ultimately merges to master are what trigger deployment of the changed files.

For years I’ve used Beanstalk for Git-based deployment over SFTP. I still am using Beanstalk for many sites and think it’s a great choice, but Beanstalk has the limitation that the Git-repo is basically a private Git repo hosted by Beanstalk itself.

During this change, I needed to switch up what the root of the repo is (more on that in a second) so I wanted to create a new repo. I figured rather than doing that on Beanstalk, I’d make a private GitHub repo and set up deployment from there. There are services like DeployHQ and DeployBot that will work well for that, but I went with Buddy, which has a really really nice UI for managing all this stuff, and is capable of much more than just deployment should I ultimately need that.

Regarding the repo itself, one thing that I’ve always done with my WordPress sites is just make the repo the whole damn thing starting at the root. I think it’s just a legacy/comfort thing. I had some files at the root I wanted to deploy along with everything else and that seemed like the easiest way. In WordPress-land, this isn’t usually how it’s done. It’s more common to have the /wp-content/ folder be the root of the repo, as those are essentially the only files unique to your installation. I can imagine setups where even down to individual themes are repos and deployed alone.

I figured I’d get on board with a more scoped deployment, but also, I didn’t have much of a choice. Flywheel literally locks down all WordPress core files, so if your deployment system tries to override them, it will just fail. That actually sounds great to me. There is no reason anyone from the outside should alter those files, might as well totally remove it as an attack vector. Flywheel itself keeps the WordPress version up to date. So I made a new repo with /wp-content/ at the root, and I figured I’d make it on GitHub instead just because that’s such an obvious hub of developer activity and keeps my options wide open for deployment choices.

For the same kind of spiritual reasons, during the the move, I moved the DNS over to Cloudflare. This gives me control over DNS from a third-party so it’s easy for me to point things where I need them. Kind of a decentralization of concerns. That’s not for everyone, but it’s great for me on this project. While now I might suffer from Cloudflare outages (rare, but it literally just happened), I benefit from all sorts of additional security and performance that Cloudflare can provide.

So the workflow is Local > GitHub > Buddy > Flywheel.

And the hosting is Cloudflare > Flywheel with image assets on Cloudinary.

And I’ve got backups from both Flywheel and Jetpack/VaultPress.

The post CSS-Tricks on Flywheel appeared first on CSS-Tricks.

Back in April, jQuery 3.0 was released with all the pomp and ceremony of a British monarch on the 4th of July (happy Independence Day to all our American readers). There have been a flurry of minor releases since then, with the current version being 3.4.1.

We’ve had a few weeks to poke around, and check out the new features, and more importantly the now deprecated features. What we found was a modern library that defied a few of our expectations.

It’s Not Bloated

There are quite a few myths built up around jQuery, not least that it is bloated and slow. There’s some sense to this, containing as it does code that you probably won’t need. However this is true of all libraries, frameworks, and 3rd party scripts; unless you’re using something so niche that there is nothing superfluous wrapped up in the code, then there will always be a few bytes here and there that aren’t required.

But let’s keep this in proportion: the raw, minified, production version of jQuery is 88kb, if you opt for the slim version without Ajax and the effects, then it’s just 71kb.

If you’re working to a strict size quota it’s relatively simple to squeeze 71kb out of a few images. Better yet, drop a jpg and you’ll probably have room to spare.

It’s (Probably) Not Cached

One of the greatest benefits of jQuery circa 2014, was that it was all but ubiquitous. Almost every site took advantage of this by linking directly to the jQuery CDN meaning that more often than not it was cached in the user’s browser – you could, in effect, use it for zero size cost.

jQuery usage has dipped in recent years, thanks in part to rival libraries, and thanks in part to the belief that vanilla JavaScript is superior. Fewer sites are linking to the CDN, fewer browsers have the file cached, and so it will probably need to be downloaded before it’s available.

The problem is compounded by the release for version 3, because although plenty of legacy sites are still loading jQuery from the CDN, by their nature they aren’t linking to the current version. The jQuery team have gone to great lengths to help you upgrade but project cycles and code adoption means that jQuery 3.n is probably at least several years away from comprehensive coverage.

You Don’t Need to Know Vanilla JavaScript

One of the most oft-repeated myths – or perhaps I should say ‘untruths’ in this case – is that you should learn vanilla JavaScript before you can use jQuery well.

I detest this view. I understand the logic; if you learn the underlying logic of the language, you’ll understand what’s happening behind the scenes and have a nuanced understanding of your code. People who perpetuate that view have forgotten what it feels like to be trawling Stack Overflow at three in the morning struggling to understand why document.getElementsByClassName needs a [0] on the end.

Yes, you do need to understand language basics, like variables, loops, conditionals, operators, and so forth; you’ll need to know those with or without jQuery. View jQuery as a set of training wheels, it does the hard stuff for you, so the easy stuff has a chance to become second nature.

I would argue that if you want to learn JavaScript, you should learn jQuery first. It will hold your hand through the tougher tasks (like Ajax) while you practice your fundamentals. And I say that as someone who spends a great deal of time coding vanilla JavaScript.

There’s No Longer a Rich Ecosystem

There was a time when jQuery developers were queuing up to deliver time-saving, feature-pushing, bolt-ons. That’s no longer the case.

The web has moved on, and the gun-for-hire developers are chasing more lucrative markets, like Shopify, or WordPress. Legacy jQuery plugins (should) still work, and in the case of version 2.n plugins – thanks to the jQuery team’s commitment to backwards compatibility – will (probably) not break using 3.n. (Do make sure to test with the development version of jQuery and check your console, if you’re going down this route.)

There will undoubtedly be some kind of market for jQuery 3.n plugins, and those developers who deem it financially worthwhile to update their code will do so. So for plugins, the release of jQuery 3.0 may actually prompt a long-overdue cull.

Should You be Using jQuery 3?

For many of us, jQuery is a tool we used years ago, and have since moved on. There are better tools for handling Ajax; jQuery still doesn’t play nice with SVG, making its use for DOM manipulation increasingly limited; there are copycat libraries that mimic the best aspects of jQuery, like the selectors, without packaging up everything else.

jQuery isn’t going to challenge Vue.js, or AngularJS. jQuery is no longer the must-befriend big kid on the block. What jQuery does is simplify JavaScript’s verbosity and enable inexperienced JavaScript coders to maximize their use of the language.

If you’re new to JavaScript, or if you’ve tinkered with it before without ever being able to do anything really cool, then jQuery is still exactly what you’re looking for.

Featured image partly via Unsplash.

Source

Flyout menus! The second you need to implement a menu that uses a hover event to display more menu items, you’re in tricky territory. For one, they should work with clicks and taps, too. Without that, you’ve broken the menu for anyone without a mouse. That doesn’t mean you can’t also use :hover. When you use a hover state to reveal more content, that means an un-hovering state needs to hide them. Therein lies the problem.

The problem is that if a submenu pops out somewhere on hover, getting your mouse over to it might involve moving it along a fairly narrow corridor. Accidentally move outside that area, the menu can close, and it can be an extremely frustrating UX moment.

We’ve covered this before in our “Dropdown Menus with More Forgiving Mouse Movement Paths” article.

The most compelling examples that solve this issue are the ones that involve extra hidden “hit areas.” Amazon doesn’t really have menus like this anymore (that I can see), and perhaps this is one of the reasons why. But in the past, they’ve used this hit area technique. We could call them “dynamic hit areas” because they were drawn based on the position of the parent element and the submenus:

I haven’t seen a lot of implementations of this lately, but just recently, Hakim El Hattab included a modern implementation of this in his talk at CSS Day 2019. The implementation leverages drawing the areas dynamically with SVG. You don’t actually see the hit areas, but they do look like this, thus forming paths for that prevent hover-offs.

I’ll include a YouTube embed of the talk starting at that point here:

The way he draws the hit area is so fancy it makes me all kinds of happy:

The live demo of it is up on the Slides.com pattern library thingy.

The post Menus with “Dynamic Hit Areas” appeared first on CSS-Tricks.

Hey, let’s create a functional calendar app with the JAMstack

I’ve always wondered how dynamic scheduling worked so I decided to do extensive research, learn new things, and write about the technical part of the journey. It’s only fair to warn you: everything I cover here is three weeks of research condensed into a single article. Even though it’s beginner-friendly, it’s a healthy amount of reading. So, please, pull up a chair, sit down and let’s have an adventure.

My plan was to build something that looked like Google Calendar but only demonstrate three core features:

1. List all existing events on a calendar
2. Create new events
3. Schedule and email notification based on the date chosen during creation. The schedule should run some code to email the user when the time is right.

Pretty, right? Make it to the end of the article, because this is what we’ll make.

The only knowledge I had about asking my code to run at a later or deferred time was CRON jobs. The easiest way to use a CRON job is to statically define a job in your code. This is ad hoc — statically means that I cannot simply schedule an event like Google Calendar and easily have it update my CRON code. If you are experienced with writing CRON triggers, you feel my pain. If you’re not, you are lucky you might never have to use CRON this way.

To elaborate more on my frustration, I needed to trigger a schedule based on a payload of HTTP requests. The dates and information about this schedule would be passed in through the HTTP request. This means there’s no way to know things like the scheduled date beforehand.

We (my colleagues and I) figured out a way to make this work and — with the help of Sarah Drasner’s article on Durable Functions — I understood what I needed learn (and unlearn for that matter). You will learn about everything I worked in this article, from event creation to email scheduling to calendar listings. Here is a video of the app in action:

You might notice the subtle delay. This has nothing to do with the execution timing of the schedule or running the code. I am testing with a free SendGrid account which I suspect have some form of latency. You can confirm this by testing the serverless function responsible without sending emails. You would notice that the code runs at exactly the scheduled time.

Tools and architecture

Here are the three fundamental units of this project:

1. React Frontend: Calendar UI, including the UI to create, update or delete events.
2. 8Base GraphQL: A back-end database layer for the app. This is where we will store, read and update our date from. The fun part is you won’t write any code for this back end.
3. Durable Functions: Durable functions are kind of Serverless Functions that have the power of remembering their state from previous executions. This is what replaces CRON jobs and solves the ad hoc problem we described earlier.

See the Pen
durable-func1 by Chris Nwamba (@codebeast)
on CodePen.

The rest of this post will have three major sections based on the three units we saw above. We will take them one after the other, build them out, test them, and even deploy the work. Before we get on with that, let’s setup using a starter project I made to get us started.

Project Repo

Getting Started

You can set up this project in different ways — either as a full-stack project with the three units in one project or as a standalone project with each unit living in it’s own root. Well, I went with the first because it’s more concise, easier to teach, and manageable since it’s one project.

The app will be a create-react-app project and I made a starter for us to lower the barrier to set up. It comes with supplementary code and logic that we don’t need to explain since they are out of the scope of the article. The following are set up for us:

1. Calendar component
2. Modal and popover components for presenting event forms
3. Event form component
4. Some GraphQL logic to query and mutate data
5. A Durable Serverless Function scaffold where we will write the schedulers

Tip: Each existing file that we care about has a comment block at the top of the document. The comment block tells you what is currently happening in the code file and a to-do section that describes what we are required to do next.

Start by cloning the starter form Github:

git clone -b starter --single-branch https://github.com/christiannwamba/calendar-app.git

Install the npm dependencies described in the root package.json file as well as the serverless package.json:

npm install

Orchestrated Durable Functions for scheduling

There are two words we need to get out of the way first before we can understand what this term is — orchestration and durable.

Orchestration was originally used to describe an assembly of well-coordinated events, actions, etc. It is heavily borrowed in computing to describe a smooth coordination of computer systems. The key word is coordinate. We need to put two or more units of a system together in a coordinated way.

Durable is used to describe anything that has the outstanding feature of lasting longer.

Put system coordination and long lasting together, and you get Durable Functions. This is the most powerful feature if Azure’s Serverless Function. Durable Functions based in what we now know have these two features:

1. They can be used to assemble the execution of two or more functions and coordinate them so race conditions do not occur (orchestration).
2. Durable Functions remember things. This is what makes it so powerful. It breaks the number one rule of HTTP: stateless. Durable functions keep their state intact no matter how long they have to wait. Create a schedule for 1,000,000 years into the future and a durable function will execute after one million years while remembering the parameters that were passed to it on the day of trigger. That means Durable Functions are stateful.

These durability features unlock a new realm of opportunities for serverless functions and that is why we are exploring one of those features today. I highly recommend Sarah’s article one more time for a visualized version of some of the possible use cases of Durable Functions.

I also made a visual representation of the behavior of the Durable Functions we will be writing today. Take this as an animated architectural diagram:

A data mutation from an external system (8Base) triggers the orchestration by calling the HTTP Trigger. The trigger then calls the orchestration function which schedules an event. When the time for execution is due, the orchestration function is called again but this time skips the orchestration and calls the activity function. The activity function is the action performer. This is the actual thing that happens e.g. “send email notification”.

Create orchestrated Durable Functions

Let me walk you through creating functions using VS Code. You need two things:

1. An Azure account
2. VS Code

Once you have both setup, you need to tie them together. You can do this using a VS Code extension and a Node CLI tool. Start with installing the CLItool:

npm install -g azure-functions-core-tools

# OR

brew tap azure/functions
brew install azure-functions-core-tools

Next, install the Azure Function extension to have VS Code tied to Functions on Azure. You can read more about setting up Azure Functions from my previous article.

Now that you have all the setup done, let’s get into creating these functions. The functions we will be creating will map to the following folders.

Start with the trigger.

1. Click on the Azure extension icon and follow the image below to create the schedule function
   

   

2. Since this is the first function, we chose the folder icon to create a function project. The icon after that creates a single function (not a project).
3. Click Browse and create a serverless folder inside the project. Select the new serverless folder.
4. Select JavaScript as the language. If TypeScript (or any other language) is your jam, please feel free.
5. Select Durable Functions HTTP starter. This is the trigger.
6. Name the first function as schedule

Next, create the orchestrator. Instead of creating a function project, create a function instead.

1. Click on the function icon:
   

   

2. Select Durable Functions orchestrator.
3. Give it a name, scheduleOrchestrator and hit Enter.
4. You will be asked to select a storage account. Orchestrator uses storage to preserve the state of a function-in-process.
5. Select a subscription in your Azure account. In my case, I chose the free trial subscription.
6. Follow the few remaining steps to create a storage account.

Finally, repeat the previous step to create an Activity. This time, the following should be different:

• Select Durable Functions activity.
• Name it sendEmail.
• No storage account will be needed.

Scheduling with a durable HTTP trigger

The code in serverless/schedule/index.js does not need to be touched. This is what it looks like originally when the function is scaffolded using VS Code or the CLI tool.

const df = require("durable-functions");
module.exports = async function (context, req) {
  const client = df.getClient(context);
  const instanceId = await client.startNew(req.params.functionName, undefined, req.body);
  context.log(`Started orchestration with ID = '${instanceId}'.`);
  return client.createCheckStatusResponse(context.bindingData.req, instanceId);
};

What is happening here?

1. We’re creating a durable function on the client side that is based on the context of the request.
2. We’re calling the orchestrator using the client’s startNew() function. The orchestrator function name is passed as the first argument to startNew() via the params object. A req.body is also passed to startNew() as third argument which is forwarded to the orchestrator.
3. Finally, we return a set of data that can be used to check the status of the orchestrator function, or even cancel the process before it’s complete.

The URL to call the above function would look like this:

http://localhost:7071/api/orchestrators/{functionName}

Where functionName is the name passed to startNew. In our case, it should be:

//localhost:7071/api/orchestrators/scheduleOrchestrator

It’s also good to know that you can change how this URL looks.

Orchestrating with a Durable Orchestrator

The HTTP trigger startNew call calls a function based on the name we pass to it. That name corresponds to the name of the function and folder that holds the orchestration logic. The serverless/scheduleOrchestrator/index.js file exports a Durable Function. Replace the content with the following:

const df = require("durable-functions");
module.exports = df.orchestrator(function* (context) {
  const input = context.df.getInput()
  // TODO -- 1
  
  // TODO -- 2
});

The orchestrator function retrieves the request body from the HTTP trigger using context.df.getInput().

Replace TODO -- 1 with the following line of code which might happen to be the most significant thing in this entire demo:

yield context.df.createTimer(new Date(input.startAt))

What this line does use the Durable Function to create a timer based on the date passed in from the request body via the HTTP trigger.

When this function executes and gets here, it will trigger the timer and bail temporarily. When the schedule is due, it will come back, skip this line and call the following line which you should use in place of TODO -- 2.

return yield context.df.callActivity('sendEmail', input);

The function would call the activity function to send an email. We are also passing a payload as the second argument.

This is what the completed function would look like:

const df = require("durable-functions");

module.exports = df.orchestrator(function* (context) {
  const input = context.df.getInput()
    
  yield context.df.createTimer(new Date(input.startAt))
    
  return yield context.df.callActivity('sendEmail', input);
});

Sending email with a durable activity

When a schedule is due, the orchestrator comes back to call the activity. The activity file lives in serverless/sendEmail/index.js. Replace what’s in there with the following:

const sgMail = require('@sendgrid/mail');
sgMail.setApiKey(process.env['SENDGRID_API_KEY']);

module.exports = async function(context) {
  // TODO -- 1
  const msg = {}
  // TODO -- 2
  return msg;
};

It currently imports SendGrid’s mailer and sets the API key. You can get an API Key by following these instructions.

I am setting the key in an environmental variable to keep my credentials safe. You can safely store yours the same way by creating a SENDGRID_API_KEY key in serverless/local.settings.json with your SendGrid key as the value:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "<<AzureWebJobsStorage>",
    "FUNCTIONS_WORKER_RUNTIME": "node",
    "SENDGRID_API_KEY": "<<SENDGRID_API_KEY>"
  }
}

Replace TODO -- 1 with the following line:

const { email, title, startAt, description } = context.bindings.payload;

This pulls out the event information from the input from the orchestrator function. The input is attached to context.bindings. payload can be anything you name it so go to serverless/sendEmail/function.json and change the name value to payload:

{
  "bindings": [
    {
      "name": "payload",
      "type": "activityTrigger",
      "direction": "in"
    }
  ]
}

Next, update TODO -- 2 with the following block to send an email:

const msg = {
  to: email,
  from: { email: 'chris@codebeast.dev', name: 'Codebeast Calendar' },
  subject: `Event: ${title}`,
  html: `<h4>${title} @ ${startAt}</h4> <p>${description}</p>`
};
sgMail.send(msg);

return msg;

Here is the complete version:

const sgMail = require('@sendgrid/mail');
sgMail.setApiKey(process.env['SENDGRID_API_KEY']);

module.exports = async function(context) {
  const { email, title, startAt, description } = context.bindings.payload;
  const msg = {
    to: email,
    from: { email: 'chris@codebeast.dev', name: 'Codebeast Calendar' },
    subject: `Event: ${title}`,
    html: `<h4>${title} @ ${startAt}</h4> <p>${description}</p>`
  };
  sgMail.send(msg);

  return msg;
};

Deploying functions to Azure

Deploying functions to Azure is easy. It’s merely a click away from the VS Code editor. Click on the circled icon to deploy and get a deploy URL:

Still with me this far in? You’re making great progress! It’s totally OK to take a break here, nap, stretch or get some rest. I definitely did while writing this post.

Data and GraphQL layer with 8Base

My easiest description and understanding of 8Base is “Firebase for GraphQL.” 8Base is a database layer for any kind of app you can think of and the most interesting aspect of it is that it’s based on GraphQL.

The best way to describe where 8Base fits in your stack is to paint a picture of a scenario.

Imagine you are a freelance developer with a small-to-medium scale contract to build an e-commerce store for a client. Your core skills are on the web so you are not very comfortable on the back end. though you can write a bit of Node.

Unfortunately, e-commerce requires managing inventories, order management, managing purchases, managing authentication and identity, etc. “Manage” at a fundamental level just means data CRUD and data access.

Instead of the redundant and boring process of creating, reading, updating, deleting, and managing access for entities in our backend code, what if we could describe these business requirements in a UI? What if we can create tables that allow us to configure CRUD operations, auth and access? What if we had such help and only focus on building frontend code and writing queries? Everything we just described is tackled by 8Base

Here is an architecture of a back-end-less app that relies on 8Base as it’s data layer:

Create an 8Base table for events storage and retrieval

The first thing we need to do before creating a table is to create an account. Once you have an account, create a workspace that holds all the tables and logic for a given project.

Next, create a table, name the table Events and fill out the table fields.

We need to configure access levels. Right now, there’s nothing to hide from each user, so we can just turn on all access to the Events table we created:

Setting up Auth is super simple with 8base because it integrates with Auth0. If you have entities that need to be protected or want to extend our example to use auth, please go wild.

Finally, grab your endpoint URL for use in the React app:

Testing GraphQL Queries and mutation in the playground

Just to be sure that we are ready to take the URL to the wild and start building the client, let’s first test the API with a GraphQL playground and see if the setup is fine. Click on the explorer.

Paste the following query in the editor.

query {
  eventsList {
    count
    items {
      id
      title
      startAt
      endAt
      description
      allDay
      email
    }
  }
}

I created some test data through the 8base UI and I get the result back when I run they query:

You can explore the entire database using the schema document on the right end of the explore page.

Calendar and event form interface

The third (and last) unit of our project is the React App which builds the user interfaces. There are four major components making up the UI and they include:

1. Calendar: A calendar UI that lists all the existing events
2. Event Modal: A React modal that renders EventForm component to create a component
3. Event Popover: Popover UI to read a single event, update event using EventForm or delete event
4. Event Form: HTML form for creating new event

Before we dive right into the calendar component, we need to setup React Apollo client. The React Apollo provider empowers you with tools to query a GraphQL data source using React patterns. The original provider allows you to use higher order components or render props to query and mutate data. We will be using a wrapper to the original provider that allows you query and mutate using React Hooks.

In src/index.js, import the React Apollo Hooks and the 8base client in TODO -- 1:

import { ApolloProvider } from 'react-apollo-hooks';
import { EightBaseApolloClient } from '@8base/apollo-client';

At TODO -- 2, configure the client with the endpoint URL we got in the 8base setup stage:

const URI = 'https://api.8base.com/cjvuk51i0000701s0hvvcbnxg';

const apolloClient = new EightBaseApolloClient({
  uri: URI,
  withAuth: false
});

Use this client to wrap the entire App tree with the provider on TODO -- 3:

ReactDOM.render(
  <ApolloProvider client={apolloClient}>
    <App />
  </ApolloProvider>,
  document.getElementById('root')
);

Showing events on the calendar

The Calendar component is rendered inside the App component and the imports BigCalendar component from npm. Then :

1. We render Calendar with a list of events.
2. We give Calendar a custom popover (EventPopover) component that will be used to edit events.
3. We render a modal (EventModal) that will be used to create new events.

The only thing we need to update is the list of events. Instead of using the static array of events, we want to query 8base for all store events.

Replace TODO -- 1 with the following line:

const { data, error, loading } = useQuery(EVENTS_QUERY);

Import the useQuery library from npm and the EVENTS_QUERY at the beginning of the file:

import { useQuery } from 'react-apollo-hooks';
import { EVENTS_QUERY } from '../../queries';

EVENTS_QUERY is exactly the same query we tested in 8base explorer. It lives in src/queries and looks like this:

export const EVENTS_QUERY = gql`
  query {
    eventsList {
      count
      items {
        id
        ...
      }
    }
  }
`;

Let’s add a simple error and loading handler on TODO -- 2:

if (error) return console.log(error);
  if (loading)
    return (
      <div className="calendar">
        <p>Loading...</p>
      </div>
    );

Notice that the Calendar component uses the EventPopover component to render a custom event. You can also observe that the Calendar component file renders EventModal as well. Both components have been setup for you, and their only responsibility is to render EventForm.

Create, update and delete events with the event form component

The component in src/components/Event/EventForm.js renders a form. The form is used to create, edit or delete an event. At TODO -- 1, import useCreateUpdateMutation and useDeleteMutation:

import {useCreateUpdateMutation, useDeleteMutation} from './eventMutationHooks'

• useCreateUpdateMutation: This mutation either creates or updates an event depending on whether the event already existed.
• useDeleteMutation: This mutation deletes an existing event.

A call to any of these functions returns another function. The function returned can then serve as an even handler.

Now, go ahead and replace TODO -- 2 with a call to both functions:

const createUpdateEvent = useCreateUpdateMutation(
  payload,
  event,
  eventExists,
  () => closeModal()
);
const deleteEvent = useDeleteMutation(event, () => closeModal());

These are custom hooks I wrote to wrap the useMutation exposed by React Apollo Hooks. Each hook creates a mutation and passes mutation variable to the useMutation query. The blocks that look like the following in src/components/Event/eventMutationHooks.js are the most important parts:

useMutation(mutationType, {
  variables: {
    data
  },
  update: (cache, { data }) => {
    const { eventsList } = cache.readQuery({
      query: EVENTS_QUERY
    });
    cache.writeQuery({
      query: EVENTS_QUERY,
      data: {
        eventsList: transformCacheUpdateData(eventsList, data)
      }
    });
    //..
  }
});

Call the Durable Function HTTP trigger from 8Base

We have spent quite some time in building the serverless structure, data storage and UI layers of our calendar app. To recap, the UI sends data to 8base for storage, 8base saves data and triggers the Durable Function HTTP trigger, the HTTP trigger kicks in orchestration and the rest is history. Currently, we are saving data with mutation but we are not calling the serverless function anywhere in 8base.

8base allows you to write custom logic which is what makes it very powerful and extensible. Custom logic are simple functions that are called based on actions performed on the 8base database. For example, we can set up a logic to be called every time a mutation occurs on a table. Let’s create one that is called when an event is created.

Start by installing the 8base CLI:

npm install -g 8base

On the calendar app project run the following command to create a starter logic:

8base init 8base

8base init command creates a new 8base logic project. You can pass it a directory name which in this case we are naming the 8base logic folder, 8base — don’t get it twisted.

Trigger scheduling logic

Delete everything in 8base/src and create a triggerSchedule.js file in the src folder. Once you have done that, drop in the following into the file:

const fetch = require('node-fetch');

module.exports = async event => {
  const res = await fetch('<HTTP Trigger URL>', {
    method: 'POST',
    body: JSON.stringify(event.data),
    headers: { 'Content-Type': 'application/json' }
  })
  const json = await res.json();
  console.log(event, json)
  return json;
};

The information about the GraphQL mutation is available on the event object as data.

Replace with the URL you got after deploying your function. You can get the URL by going to the function in your Azure URL and click “Copy URL.”

You also need to install the node-fetch module, which will grab the data from the API:

npm install --save node-fetch

8base logic configuration

The next thing to do is tell 8base what exact mutation or query that needs to trigger this logic. In our case, a create mutation on the Events table. You can describe this information in the 8base.yml file:

functions:
  triggerSchedule:
    handler:
      code: src/triggerSchedule.js
    type: trigger.after
    operation: Events.create

In a sense, this is saying, when a create mutation happens on the Events table, please call src/triggerSchedule.js after the mutation has occurred.

We want to deploy all the things

Before anything can be deployed, we need to login into the 8Base account, which we can do via command line:

8base login

Then, let’s run the deploy command to send and set up the app logic in your workspace instance.

8base deploy

Testing the entire flow

To see the app in all its glory, click on one of the days of the calendar. You should get the event modal containing the form. Fill that out and put a future start date so we trigger a notification. Try a date more than 2-5 mins from the current time because I haven’t been able to trigger a notification any faster than that.

Yay, go check your email! The email should have arrived thanks to SendGrid. Now we have an app that allows us to create events and get notified with the details of the event submission.

The post Hey, let’s create a functional calendar app with the JAMstack appeared first on CSS-Tricks.

I was just chatting with Dave and he told me about Haunted. It’s hooks, but for native web components! Pretty cool. I think the existence of stuff like this makes using web components more and more palatable — particularly in that totally-native no-build-step-needed-at-all kinda way.

I get that there are all sorts of issues with web components, but the things that typically turn me away from them are a lack of nice templating and rerendering and no state management.

But we can knock those two out right quick these days…

First, making a component like is perfectly comfortable:

import { html } from "https://unpkg.com/lit-html/lit-html.js";
import { component } from "https://unpkg.com/haunted/haunted.js";

function App() {
  return html`
    <div class="module">
      Hello, World!
    </div>
  `;
}

customElements.define("my-app", component(App));

Then we could add some state with hooks:

import { html } from "https://unpkg.com/lit-html/lit-html.js";
import { component, useState} from "https://unpkg.com/haunted/haunted.js";

function App() {
  const [name, setName] = useState("Chris");
  return html`
    <div class="module">
      Hello, ${name}!
    </div>
  `;
}

customElements.define("my-app", component(App));

The CodePen Challenge this week is using the Star Wars API, so let’s make a fetch request and use that to fill state. That’s a great use case for useEffect.

import { html } from "https://unpkg.com/lit-html/lit-html.js";
import { component, useState, useEffect } from "https://unpkg.com/haunted/haunted.js";

function App() {
  
  const [planets, setPlanets] = useState([]);
  useEffect(() => {
    fetch('https://swapi.co/api/planets/?page=2')
      .then(response => {
        return response.json();
      })
      .then(data => {
        let planets = data.results;
        // remove ones with no diameters
        planets = planets.filter(planet => planet.diameter !== "0");
        setPlanets(planets);
      });
  }, []);

  return html`
    <style>
      /* Shadow DOM styles */
    </style>
    <div class="all-planets">
      ${planets.map(planet => html`
        <div class="planet" style="--dia: ${planet.diameter}px">
           <span class="planet-name">
              ${planet.name}
           </span>
        </div>
      `)}
    </div>
  `;
}

customElements.define("my-app", component(App));

That’s a proper little web component!

See the Pen
Star Wars API with Haunted.js by Chris Coyier (@chriscoyier)
on CodePen.

The post Haunted: Hooks for Web Components appeared first on CSS-Tricks.

Just imagine it, you walk into your office, and you get a notification: your client has just dropped everything you need into your cloud storage provider of choice. The copy brings tears of joy to your eyes, the images are crisp, clean, and huge. The logo is a work of art, and the client has sent a note saying, “Actually, we don’t need you to finish up for another three months, but why don’t I just pay you double right now?”

And then you wake up.

The truth is that your deadline is the same, but they’re “just wondering if you could speed things up a little”, the provided images are 640×480 and just blurry enough to be annoying, the logo is an abomination made in Word, and the brand’s colors remind you of those awful school uniforms you used to wear.

Okay, now I’m just being mean, but it’s a sad reality that we often have to work with sub-par assets in web design projects. Logos don’t always look great, and some people have a talent for picking the absolute worst shades of brown, yellow, and green for their brand. It’s enough to make you throw your hands in the air flamboyantly and shout, “I just can’t work with this!”

But what about all those times when you don’t have a choice, and your clients refuse to let you completely redo their branding? You know, most of the time. Well, you do have a few options.

Ugly Logos

Just kind of ignore the logo as much as you can, really. I mean, obviously, it needs to be there, probably in the upper-left, or in the upper-middle. But just sort of… leave it there. There’s not much you can really do about a logo. The users need to see it, and the client will definitely be annoyed if it’s not there.

However, if there was ever a time to push back when the client asks you to make the logo bigger, this is it. And where a lot of sites will incorporate the logo mark into other aspects of the design, this time, it’s staying in its designated spot. Maybe if the rest of the site looks drastically better than the logo, it will give the client pause, and perhaps even a reason to get it redone.

Thankfully, few logos are ever truly that ugly, at least among clients who can afford you. Overcomplicated and hard to see at small sizes? Yes. Generic and boring? Sure. But WordArt-ugly? Thankfully that’s not as common as it once was.

Ugly Colors

Colors are another story, and for every color combination that sparks joy, Marie Kondo-style, there’s a combination that sparks nausea. But hey, brand guides are brand guides, and you gotta follow the brand guide.

The best thing to do is to use the colors, but as sparingly as possible. Many colors are only truly terrible when they’re in close proximity to each other, so use some (probably literal) white space to your advantage. Keep them apart, and use them only for emphasis.

Will your client ever demand that you make the entire background puke-green? It’s possible. Even then, maybe you could get away with using a gradient to minimize any negative effects.

Low-Quality Images

Once again, embrace the white space. If all you have to work with are a bunch of very small images, make that small size look intentional. Make those tiny images the center of attention, and pray most of your users aren’t using retina screens. You can get away with a lot if you make it look like you planned it all from the very beginning.

Another way to do this is to use the images as large, blurry backgrounds. This works best with landscapes and macro shots, though. That company “team portrait” doesn’t work as well for background material, sadly.

Lastly, if Instagram has taught us anything, it’s that excessive filtering can make any old photo look like it’s supposed to be art. Sometimes. Add some film grain, desaturate the photos, and maybe throw in some harsh, spotty lighting. Users can’t judge what can barely be seen.

I’m only half joking.

Legacy UI Elements & Widgets

Now this is a rare situation, but on occasion, a client might have some leftover UI assets that they really, really love. Maybe they designed their first shiny Web 2.0 button in Xara 3D nearly twenty years ago, and they just have to use it. Maybe they have a favorite graph showing how their business works.

Again, this isn’t common, but you may find yourself having to work around it. For the example of the graph, I’d put a full-on skeuomorphic, photo-realistic picture frame around it. I’d treat it like a piece of the company’s history. An approach like this could also work for the example of the button.

When All Else Fails, Lean Into the Ugly

Brutalism is a thing. It’s like I said before: you can get away with a lot if you make it look like you fully intended to use butt-ugly color palettes, low-quality images, or even ‘90s clipart. That’s right, you can make clipart work. I’ve seen people do it.

Embrace the aesthetic, and call it retro, or call it ironic, I don’t care. I mean—and I admit, this is the example I use every time I talk about less-than-pretty design—people still love Craigslist. Making the website work is more important than making it beautiful. Giving the user what they want, when they want it, is worth a million high-resolution photos, and Jon-Hicks-designed logos.

Featured image via Unsplash.

Source

// frame.vue
<template>
  <div class="frame">
    <slot></slot>
  </div>
</template>

// app.vue
<template>
  <frame><img src="an-image.jpg"></frame>
</template>

// frame.vue
<template>
  <div class="frame">
    <slot>This is the default content if nothing gets specified to go here</slot>
  </div>
</template>

// app.vue
<template>
  <frame />
</template>

// titled-frame.vue
<template>
  <div class="frame">
    <header><h2><slot name="header">Title</slot></h2></header>
    <slot>This is the default content if nothing gets specified to go here</slot>
  </div>
</template>

// app.vue
<template>
  <titled-frame>
    <template v-slot:header>
      <!-- The code below goes into the header slot -->
      My Image's Title
    </template>
    <!-- The code below goes into the default slot -->
    <img src="an-image.jpg">
  </titled-frame>
</template>

// current-user.vue
<template>
  <span>
    <slot v-bind:user="user">
      {{ user.lastName }}
    </slot>
  </span>
</template>

<script>
export default {
  data () {
    return {
      user: ...
    }
  }
}
</script>

// app.vue
<template>
  <current-user>
    <template v-slot:default="slotProps">{{ slotProps.user.firstName }}</template>    
  </current-user>
</template>

// app.vue
<template>
  <current-user v-slot="{user}">
    {{ user.firstName }}
  </current-user>
</template>

<!-- my-button.vue -->
<template>
  <button class="btn btn-primary btn-lg">
    <slot>Click Me!</slot>
  </button>
</template>

<!-- somewhere else, using my-button.vue -->
<template>
  <my-button>
    <img src="/img/awesome-icon.jpg"> SMASH THIS BUTTON TO BECOME AWESOME FOR ONLY $500!!!
  </my-button>
</template>

<!-- my-modal.vue -->
<template>
<div class="modal" tabindex="-1" role="dialog">
  <div class="modal-dialog" role="document">
    <div class="modal-content">
      <div class="modal-header">
        <slot name="header"></slot>
        <button type="button" class="close" data-dismiss="modal" aria-label="Close">
          <span aria-hidden="true">×</span>
        </button>
      </div>
      <div class="modal-body">
        <slot name="body"></slot>
      </div>
      <div class="modal-footer">
        <slot name="footer"></slot>
      </div>
    </div>
  </div>
</div>
</template>

<!-- somewhere else, using my-modal.vue -->
<template>
  <my-modal>
    <template #header><!-- using the shorthand for `v-slot` -->
      <h5>Awesome Interruption!</h5>
    </template>
    <template #body>
      <p>We interrupt your use of our application to
      let you know that this application is awesome 
      and you should continue using it every day for 
      the rest of your life!</p>
    </template>
    <template #footer>
      <em>Now back to your regularly scheduled app usage</em>
    </template>
  </my-modal>
</template>

<!-- my-modal.vue -->
<template>
<div class="modal" tabindex="-1" role="dialog">
  <div class="modal-dialog" role="document">
    <div class="modal-content">
      <div class="modal-header">
        <slot name="header"></slot>
        <button type="button" class="close" data-dismiss="modal" aria-label="Close">
          <span aria-hidden="true">×</span>
        </button>
      </div>
      <div class="modal-body">
        <slot name="body"></slot>
      </div>
      <div class="modal-footer">
        <!--
          using `v-bind` shorthand to pass the `closeModal` method
          to the component that will be in this slot
        -->
        <slot name="footer" :closeModal="closeModal"></slot>
      </div>
    </div>
  </div>
</div>
</template>

<script>
export default {
  //...
  methods: {
    closeModal () {
      // Do what needs to be done to close the modal... and maybe remove it from the DOM
    }
  }
}
</script>

<!-- somewhere else, using my-modal.vue -->
<template>
  <my-modal>
    <template #header><!-- using the shorthand for `v-slot` -->
      <h5>Awesome Interruption!</h5>
    </template>
    <template #body>
      <p>We interrupt your use of our application to
      let you know that this application is awesome 
      and you should continue using it every day for 
      the rest of your life!</p>
    </template>
    <!-- pull in `closeModal` and use it in a button's click handler -->
    <template #footer="{closeModal}">
      <button @click="closeModal">
        Take me back to the app so I can be awesome
      </button>
    </template>
  </my-modal>
</template>

<template>
  <transition name="fade" v-bind="$attrs" v-on="$listeners">
    <slot></slot>
  </transition>
</template>
<style>
.fade-enter-active,
.fade-leave-active {
  transition: opacity 0.3s;
}
.fade-enter, .fade-leave-to {
  opacity: 0;
}
</style>

<!-- promised.vue -->
<template>
  <span>
    <slot  name="rejected"  v-if="error" :error="error"></slot>
    <slot  name="resolved"  v-else-if="resolved" :data="data"></slot>
    <slot  name="pending"  v-else></slot>
  </span>
</template>

<script>
export  default {
  props: {
    promise:  Promise
  },

  data: () => ({
    resolved:  false,
    data:  null,
    error:  null
  }),  

  watch: {
    promise: {
      handler (promise) {
        this.resolved  =  false
        this.error  =  null

        if (!promise) {
          this.data  =  null
          return
        }

        promise.then(data  => {
          this.data  =  data
          this.resolved  =  true
        })
        .catch(err  => {
          this.error  =  err
          this.resolved  =  true
        })
      },
      immediate:  true
    }
  }
}
</script>

<template>
  <div>
    <promised :promise="somePromise">
      <template #resolved="{ data }">
        Resolved: {{ data }}
      </template>
      <template #rejected="{ error }">
        Rejected: {{ error }}
      </template>
      <template #pending>
        Working on it...
      </template>
    </promised>
  </div>
</template>
...

render () {
  if (this.error) {
    return this.$scopedSlots['rejected']({error: this.error})
  }

  if (this.resolved) {
    return this.$scopedSlots['resolved']({data: this.data})
  }

  return this.$scopedSlots['pending']()
}

Git is command-line-driven software, but that doesn’t mean you have to use the command line to make it work. There are lots of options! Some of the deepest programmer nerds I know prefer to use GUIs for Git (Graphic
User Interface, or you know, software you can see things and click stuff), and some near pure-designers I know prefer working with the command line for Git. Swear to Git.

Lemme round up what look like the major players for Git GUIs these days.

No matter how much you love the CLI, don’t GUI-shame. Lots of perfectly amazing programmers like working with GUIs, and it’s perfectly fine.

There’s some weird gatekeeping tendencies centered around the command line. #DevDiscuss

— Ben Halpern ? (@bendhalpern) November 28, 2018

Tower

I’ve used Tower for ages and it’s the one used the most. I’m not sure the exact release dates of all these, but I feel like Tower was an early player here. They’ve been around a long time and continuously improve, which I always respect.

Fork

It’s free and actively developed, incredibly.

GitHub Desktop

This is a 2.0 of the original GitHub Desktop. I had some gripes with the 1.0 version in that its terminology was weird (to me) and seemed to vastly deviate from Git, which was more confusing than it was worth (again, to me). This version cleans most of that up. It’s deeply integrated into GitHub so it makes GitHubb-y things (e.g. pull requests) feel like first-class citizens, but it will still happily work with any Git repo.

GitKraken

I’m pretty intrigued by this one. Upgrading (monthly cost) to get the in-app merge conflict tool seems worth it, but you also have to upgrade to access private repos. It seems highly feature rich, but I think my favorite part is the dark-with-rainbow-accent-colors theme.

Sourcetree

You might be compelled by Sourcetree if you’re a big Bitbucket user because they are both Atlassian products. I know it works for any Git repo though. I imagine there is some smooth Bitbucket integration stuff with this, similar to the GitHub/GitHub Desktop connection.

Coda

You don’t really think of Coda as a version control tool (it’s more of a direct-to-FTP thing), and even though I’d argue the support for it is fairly half-baked, it does work! Seems likely the next evolution of Coda will address this.

VS Code

Having version control right in your IDE like this, to me, feels like kind of a tweener between GUI and CLI. There are a lot of features here, but it’s not really a full-blown GUI to me, but you’ve got a terminal built in right there so it almost encourages that. A lot of Git usage is pretty basic pulling, committing, and pushing — so having this right within the app is kinda sweet.

(I imagine there are lots of other IDEs that offer version control features. PHPStorm, etc.)

The post Graphical User Interfaces for Git appeared first on CSS-Tricks.