We’re still in suuuuuper early days with container queries. Too early for broad browser support, but Chromium already supports it, Safari started supporting it in version 16, and Firefox is presumably not far behind.
Most early days conversations revolving around container queries usually compare the syntax to media queries.
/* Stacked flex container */ .post { display: flex; flex-direction: column; } /* Change direction when viewport is 600px or wider */ @media(min-width: 600px) { .post { flex-direction: row; } }
/* Define the container */ .posts { container-name: posts; container-type: inline-size; } .post { display: flex; flex-direction: column; } /* Query the container's min-width */ @container posts (min-width: 600px) { /* Change styles when `posts` container is 600px or wider */ .post { flex-direction: row; } }
Both of these are making queries for min-width: 600. The difference is that the media query is looking at the viewport’s width to trigger those style changes while the container query is looking at the computed width of the .posts element. Sweet!
But after listening to CSS Podcast Episode 59, Una and Adam poked at the future of container queries: style queries! The current working draft of the CSS Containment Module Level 3 spec defines container style queries:
A container style query allows querying the computed values of the query container. It is a boolean combination of individual style features (<style-feature>) that each query a single, specific property of the query container.
But no examples on syntax just yet — only a brief description:
The syntax of a <style-feature> is the same as for a declaration, and its query is true if the computed value of the given property on the query container matches the given value (which is also computed with respect to the query container), unknown if the property or its value is invalid or unsupported, and false otherwise. The boolean syntax and logic combining style features into a style query is the same as for CSS feature queries. (See @supports.)
So, yes, given time we should expect to pull off something like this:
.posts { container-name: posts; } @container posts (background-color: #f8a100) { /* Change styles when `posts` container has an orange background */ .post { color: #fff; } }
That’s a pretty dumb example. One thing to note is that the container-type is no longer based on the container’s inline-size but by style. We could delcare that like so:
Alternate dark mode approach: Instead of basing it all on a body class change that re-assigns custom property values, maybe we can change an entire color palette if, say, the body background changes color.
More complex query conditions: Like, say, we want to apply styles when the sizeandstyle conditions for a container are met.
Una also mentioned in the CSS Podcast that container style queries could help prevent some awkward styling situations, like if we happen to have italicized text in an already italicized blockquote:
blockquote { container-name: quote; } @container quote (font-style: italic) { em, i, q, address { font-style: normal; } }
Amazon has a vision with AWS Amplify. First, a premise:
As browsers have become faster and more powerful over the last decade, front-end developers are building web apps that are more feature-rich and performant for both desktop and mobile devices. To implement these features, front-end developers are increasingly becoming full-stack developers who have to think about not just the UI but the cloud services they are adopting to get to market faster.
That premise comes from conversations I’ve had with Amazon about what they are doing with AWS Amplify, which is informed by their own research.
Sound familiar? I’ve been saying for years that us front-end developers have been morphing into full-stack developers. And for the most part that’s great. It’s empowering to see our base skillset become fully capable of building and hosting entire websites, even full-blown web apps with authentication, data models, media handling, and more — thanks to tooling that that has made these things much more accessible.
The AWS Amplify vision keeps this going. Full-stack apps should be easier and faster to build. More, it can help teams work together better, specifically designer/developer collaboration. And finally, you shouldn’t have to give up any power, control, or opinions.
AWS Amplify is delivering on all that. You get the power of everything AWS offers and can build products that would have taken months in days.
AWS Amplify has always been a useful tool, then last year took a big leap up with the launch of the Admin UI. It’s an amazing part of Amplify, bringing a self-hosted dashboard to your projects that gives you a visual way to model data, orchestrate your auth, and deal with other aspects of your app in a way that, frankly, is awfully friendly to front-end developers like me.
Now they are taking another big leap forward with…
AWS Amplify Studio
This is a brand new release. AWS Amplify Studio is an evolutionary leap of the Admin UI. It’s a renaming — Amplify Studio is the new name for all of this, including all the new features. So you’re still doing things like building your data model, but you’re taking that even further by building and customizing components (!!) and wiring up those components to real data (!!!). Oh and one more thing: those components are quite literally mapped to Figma, so designers can iterate on the components in Figma and sync them back to Studio as real React components (!!!!).
The one-minute video is worth a watch here:
Building an app from scratch is extremely quick as AWS Amplify Studio helps you scaffold out the app.
AWS Amplify Studio is accessible outside of the AWS Management console, so you and your team can log in and quickly get started.
Modeling data is a visual experience, making this kind of work much more accessible.
Connecting data to components is equally easy data mapping.
You can also connect mobile and web apps to app backends created in AWS Amplify Studio using Amplify Libraries for iOS, Android, Flutter, React Native, and web (JavaScript).
You’re not on your own to create those components, AWS Amplify Studio now ships with a bunch of pre-built components you can use right away.
There are dozens of these from smaller atomic elements like buttons, to larger UI elements like cards and forms, to large page sections like headers and news feeds.
Notably, you’ll need to deploy to AWS to get the UI library experience. But you’ll likely be doing that anyway as the point of Amplify is leveraging the full AWS integrated experience.
The components are also provided as a Figma template which you can (and this is very impressive new tech here) literally keep in sync between Figma and AWS Amplify. Meaning you tweak designs in Figma and pull the updated components right into the app.
Manage and ship your app
Once you’re ready to ship your app, you can deploy and host with AWS Amplify Hosting, which lets you deploy and host any React, Vue, or Next.js web app with built-in continuous integration and continuous deployment (CI/CD) workflows, testing, pull request previews, and custom domains. You can let your team members manage users and groups, application content, and files in AWS Amplify Studio, since it’s accessible outside the AWS Management Console.
You can easily add AWS services not available within AWS Amplify Studio using the AWS Cloud Development Kit (CDK). For example, if your app backend needs an SQS queue to process order fulfillment events, you can run the amplify add custom command to add any resource from more than 175 AWS services to their Amplify app using AWS CDK.
More
Stayed tuned for an upcoming blog post getting into more detail on the Figma integration and designer/developer collaboration.
If I’m thinking of this bit of HTML as a “component”, it’s nice to be able to write styles for it that are very explicitly just for it. That’s what @scope is for, so…
This bit of CSS is very explicitly for this media component. It reads like that and can be maintained like that.
I didn’t have to come up with a name and class for the <img>. I’m applying styling there without it “leaking out” to other images.
But wait, isn’t this just like prepending selectors with the parent class?
It kind of is… like we could also write:
.media { } .media img { } .media content { }
And now we’ve scoped things internal to the media component. That’s rather repetitive, but with native CSS nesting on the way, it’s just this:
.media { img { } .content { } }
So yes, I’d say nesting takes care of some basic types of scoping, but there are some things that are very unique to this new scope proposal.
One unique feature is “donut scope”, meaning I stop the scoping where I want to. Maybe I want my scoping to stop at a particular class:
@scope (.media) to (.content) { p { } }
Now I can write styles that won’t mess with areas that I don’t want them to mess with, perhaps:
<div class="media"> <img alt="Proper alt." src="..."> <p>This is stylable in scope.</p> <div class="content"> <p>This is NOT styleable in scope.</p> </div> </div>
But that’s not the only unique problem this new spec solves. I think the “nearest ancestor” situation that Miriam lays out is perhaps the most interesting thing. I’ll send you over to the blog post to read about that — it’s pretty wild that we don’t have a good tool for that yet.
There is a lot to wrap your mind around here, especially as you think of more complex situations like multiple overlapping scopes and how the nesting syntax might interplay with scoping. Fortunately, Miriam is blogging these things very clearly.
Caution: Terrible sense of humor ahead. We’ll talk about practical stuff, but the examples pretty much all involve zombies and silly jokes. You have been warned.
I’ll be linking to individual Pens as I discuss the lessons I learned, but if you’d like to get a sense of the entire project, check out 60 days of Animation on Undead Institute. I started this project to end on August 1st, 2020, coinciding with the publication of a book I wrote featuring CSS animation, humor, and zombies — because, obviously, zombies will destroy the world if you don’t brandish your web skills and stop the apocalypse. Nothing puts the hurt on the horde like a HTML element on the move!
I had a few rules for myself throughout the project.
I would hand-code all CSS. (I’m a masochist.)
The user would initiate all of the animation. (I hate coming upon an animation that’s already halfway through.)
I would use JavaScript as little as possible and never for animation. (I only ended up using JavaScript once, and that was to start audio with the final animation. I have nothing against JavaScript, it’s just not what I wanted to do here.)
Lesson 1: Eighty days is a long time.
Uh, doesn’t the title say “sixty” days? Yes, but my original goal was to do eighty days and as day one approached with less than twenty animations prepared and a three day average for each production, I freaked out and switched to sixty days. That gave me both twenty more days till the beginning date and twenty fewer pieces to do.
Lesson 1A: Sixty days is still a long time.
That’s a lot of animation to do with a limited amount of time, ideas, and even more limited artistic skills. And while I thought of dropping to thirty days, I’m glad I didn’t. Sixty days stretched me and forced me to go deeper into how CSS animation — and by extension, CSS itself — works. I’m also proudest of many of the later pieces I did as my skills increased, and I had to be more innovative and think harder about how to make things interesting. Once you’ve used all the easy options, the actual work and best results begin. (And yes, it ended up being sixty-two days because I started on June 1 and wanted to do a final animation on August 1. Starting June 3 just felt icky and wrong.)
So, the real Lesson 1: stretch yourself.
Lesson 2: Interactive animations are hard, and even harder to make responsive.
If you want something to fly across the screen and connect with another element or appear to start another element’s move, you must use either all standard, inflexible units or all flexible units.
Three variables determine when and where an animated element will be during any animation: duration, velocity, and distance. The duration of the animation is set in the animation property and cannot be changed in relation to screen size. The animation timing function determines the velocity; screen size can’t change that either. Thus, if the distance varies with the screen size, the timing will be off everywhere except a specific screen width and height.
Look at Tank!. Run the animation at wide and narrow screen sizes. While I got the timing close, if you compare the two, you’ll see that the tank is in a different place relative to the zombies when the last zombies fall.
To avoid these timing issues, you can use fixed units and a large number, like 2000 or 5000 pixels or more, so that the animation will cover the width (or height) of the screen for all but the largest monitors.
Lesson 3: If you want a responsive animation, put everything in (one of the) viewport units.
Going halfsies on unit proportions (e.g. setting width and height in pixels, but location and movement with viewport units) will lead to unpredictable results. Don’t use both vw and vh either but one or the other; whichever will be the dominant orientation. Mixing vh and vw units will make your animation go “wonky” which I believe is the technical term.
Take Superbly Zomborrific, for instance. It mixes pixel, vw, and vh units. The premise is that the Super Zombie is flying upward as the “camera” follows. Super Zombie smashes into a ledge and falls as the camera continues, but you wouldn’t understand that if your screen was sufficiently tall.
That also means that if you need something to come in from the top — like I did in Nobody Here But Us Humans —you must set the vw height high enough to ensure that the ninja zombie isn’t visible at most aspect ratios.
Lesson 3A: Use pixel units for movements within an SVG element.
All that said, transforming elements within an SVG element should not use viewport units. SVG tags are their own proportional universe. The SVG “pixel” will stay proportional within the SVG element to all the other SVG element children while viewport units will not. So transform with pixel units within an SVG element, but use viewport units everywhere else.
Lesson 4: SVGs scale horribly at runtime.
For animations, like Oops…, I made the SVG image of the zombie scale up to five times his size, but that makes the edges fuzzy. [Shakes fist at “scalable” vector graphics.]
I learned to set their dimensions to the final dimensions that would be in effect at the end of the animation, then use a scale transform to shrink them down to the size for the start of the animation.
In short, the revised code moves from a scaled-down version of the image up to the full width and height. The browser always renders at 1, making the edges crisp and clean at a scale of 1. So instead of scaling from 1 to 5, I scaled from 0.2 to 1.
Lesson 5: The axis Isn’t a universal truth.
An element’s axes stay in sync with the element, not the page. A 90-degree rotation before a translateX will change the direction of the translateX from horizontal to vertical. In Nobody Here But Us Humans… 2, I flipped the zombies using a 180-degree rotation. But positive Y values move the ninjas towards the top, and negative ones move them towards the bottom (the opposite of normal). Beware of how a rotation may affect transforms further down the line.
Lesson 6. Separate complex animations into concentric elements to make easier adjustments.
When creating a complex animation that moves in multiple directions, adding wrapper divs, or rather parent elements, and animating each one individually will cut down on conflicting transforms, and prevent you from becoming a weepy mess.
For instance, in Space Cadet, I had three different transforms going on. The first is the zomb-o-naut’s moving in an up and down motion. The second is a movement across the screen. The third is a rotation. Rather than trying to do everything in a single transform, I added two wrapping elements and did one animation on each element (I also saved my hair… at least some of it.) This helped avoid the axis issues discussed in the last lesson because I performed the rotation on the innermost element, leaving its parent’s and grandparent’s axes in place.
Lesson 7: SVG and CSS transforms are the same.
Some paths and groups and other SVG elements will already have transforms defined on them. It could be from an optimization algorithm, or perhaps it’s just how the illustration software generates the code. If a path, group, or whatever element in an SVG already has an SVG transform on it, removing that transform will reset the element, often to a bizarre location or size compared to the rest of the drawing.
Since SVG and CSS transforms are the same, any CSS transform you do replaces the SVG transform, meaning your CSS transform will start from that bizarre location or size rather than the location or size that is set in the the SVG.
You can copy the transform from the SVG element to your CSS and set it as the starting position in CSS (updating it to the CSS syntax first, of course). You can then modify it in your CSS animation.
For instance, in Uhhh, Yeah…, my tribute to Office Space, Undead Lumbergh’s right upper arm (the #arm2 element) had a transform on it in the original SVG code.
This process is harder when the tool generating the SVG code attempts to “simplify” the transform into a matrix. While you can recreate the matrix transform by copying it into the CSS, it is a difficult task to do. You’re a better developer than me — which might be true anyway — if you can take a matrix transform and manipulate it to scale, rotate, or translate in the exact way you want.
Alternatively, you can recreate the matrix transform using translation, rotation, and scaling, but if the path is complex, the likelihood that you can recreate it in a timely manner without finding yourself in a straight jacket is low.
The last and probably easiest option is to wrap the element in a group (<g>) tag. Add a class or ID to it for easy CSS access and transform the group itself, thus separating out the transforms as discussed in the last lesson.
Lesson 8: Keep your sanity by using transform-origin when transforming part of an SVG
The CSS transform-origin property moves the point around which the transform happens. If you’re trying to rotate an arm — like I did in Clubbin’ It — your animation will look more natural if you rotate the arm from the center of the shoulder, but that path’s natural transform origin is in the upper-left. Use transform-origin to fix this for smoother, more natural feel… you know that really natural pixel art look…
Transforming the origin can also be useful when scaling, like I did in Mustachioed Oops, or when rotating mouth movements, such as the dinosaur’s jaw in Super Tasty. If you don’t change the origin, the transforms will use an origin point at the upper left corner of the SVG element.
Lesson 9: Sprite animations can be responsive
I ended up doing a lot of sprite animations for this project (i.e., where you use multiple, incremental frames and switch between them fast enough that the characters seem to move). I created the images in one wide file, added them as a background image to an element the size of a single frame, used background-size to set the background image to the width of the image, and hid the overflow. Then I used background-position and the animation timing function, step(), to walk through the images; for example: Post-Apocalyptic Celebrations.
Before the project, I always used inflexible images. I’d scale things down a little so that there would be at least a little responsive give, but I didn’t think you could make it a fully flexible width. However, if you use SVG as the background image you can then use viewport units to scale the element along with the changing screen size. The only problem is the background position. However, if you use viewport units for that, it will stay in sync. Check that out in Finally, Alone with my Sandwich…
Lesson 9A: Use viewport units to set the background size of an image when creating responsive sprite animation
As I’ve learned throughout this project, using a single type of unit is almost always the way to go. Initially, I’d set my sprite’s background size using percentages. The math was easy (100% * (number of steps + 1)) and it worked fine in most cases. In longer animations, however, the exact frame tracking could be off and parts of the wrong sprite frame might display. The problem grows as more frames are added to the sprite.
I’m not sure the exact reason this causes an issue, but I believe it’s because of rounding errors that compound over the length of the sprite sheet (the amount of the shift increases with the number of frames).
For my final animation, It Ain’t Over Till the Zombie Sings, I had a dinosaur open his mouth to reveal a zombie Viking singing (while lasers fired in the background plus there was dancing, accordions playing and zombies fired from cannons, of course). Yeah, I know how to throw a party… a nerd party.
The dinosaur and viking was one of the longest sprite animations I did for the project. But when I used percentages to set the background size, the tracking would be off at certain sizes in Safari. By the end of the animation, part of the dinosaur’s nose from a different frame would appear to the right and a similar part of the nose would be missing on the left.
The dinosaur on the left is missing part of his left cheek and growing a new one next to his right cheek.
This was super frustrating to diagnose because it seemed to work fine in Chrome and I’d think I fixed it in Safari only to look at a slightly different screen size and see the frame off again. However, if I used consistent units — i.e. vw for background-size, frame width, and background-position — everything worked fine. Again, it comes down to working with consistent units!
Lesson 10: Invite people into the project.
While I learned tons of things during this process, I beat my head against the wall for most of it (often until the wall broke or my head did… I can’t tell). While that’s one way to do it, even if you’re hard-headed, you’ll still end up with a headache. Invite others into your project, be it for advice, to point out an obvious blind spot you missed, provide feedback, help with the project, or simply to encourage you to keep going when the scope is stupidly and arbitrarily large.
So let me put this lesson into practice. What are your thoughts? How will you stop the zombie hordes with CSS animation? What stupidly and arbitrarily large project will you take on to stretch yourself?
Eighteen years into this game, I love to reminisce back to the good ol’ days of the early to mid-2000s when there was an explosion of creativity on the web. It felt fresh and unbridled, with boundaries expected to be pushed at every turn, and they were. This was mainly down to one thing, the thing of nightmares to some, Flash! It, of course, had some big inherent flaws, but love it or hate it, certainly helped pave the way for what we expected from the open web. Sure, it was probably a more drawn-out process than we’d hoped for, but with some savage new advancements made over the last few years, I now feel that things are really starting to get proper juicy.
Several things come to mind that get me excited these days in designing and developing for the web, some widely adopted now like SVG (even though technically old) and WebGL animation, which draw some obvious parallels to the Flash era. Certainly, CSS Grid stood up and made itself known, shouting from the parapets about how the shackles of layout are now a thing of the past. Kudos to awesome people like Rachel Andrew and Jen Simmons for their serious efforts in educating us mere mortals in this area, helping make the learning curve and adoption that bit more palatable and accessible.
Looking around today you can see how advancements like Grid have helped elevate the rise of more asymmetric layouts, with design styles like Brutalism design going through a bit of a trend over the last year or so. But over time it felt as though typography might have taken the back seat a tad with all the other successes happening in pushing the web forward. Now enter variable fonts 🥳
Variable fonts have certainly piqued my interest this past year or so. Not only do they give us the obvious boost in performance with fewer https requests and smaller sizes compared to the bundles of web fonts we all inject into our pages, but we also gain more control over typography in terms of readability and accessibility. Say goodbye to cheekily adding muddy sacrificial faux bold or italic styles to our CSS!
Taking this further, I feel that variable fonts have really unlocked the door to new creative possibilities that we’re only just scratching the surface of. Having the ability to interpolate between different values of the axes just screams out for animation. We have the standardized set of 5 registered axes like font-weight, font-stretch, font-style, etc. which are straight forward enough to appreciate, but when it comes to custom axes via font-variation-settings, things start getting crazy and fun. Type designers can use the interpolation in custom axes to create some really off the wall things beyond, well… text. Just check out Typearture’s fab variable font experiments to see what I mean.
A few months back I was privileged to be invited to experiment with and test Greensock’s newly released GSAP 3, which I’m also most definitely excited about. It boasts a new simplified API and 50+ new features, yet is only about half the file size as the previous version. This is currently my catnip though: layering GSAP on top of variable fonts in CodePen to create some lovely kinetic typography in the DOM. This kind of magic, until now I guess, has been more attributed to WebGL, Processing and After Effects. Now, throw some GSAP plugins on top again, and you can definitely create some very cool and unique stuff. I would suggest, however, that you use this new creative power of animating variable fonts in whichever way you do it sparingly, as reflow could become an issue with jank.
I’m excited to see what people will create using variable fonts over the next year as it becomes more widely adopted. Not just limited to typographic treatments in layouts, but also in terms of animation and micro-interactions. It looks like a big undertaking for designers in creating such fonts, but credit to them. I’m sure we’ll be all the more appreciative. Thanks in advance type designers!
I recently drew up a wireframe for a code beautifier. The next day, I decided to turn it into a real tool. The whole project took less than two days to complete.
I’d been thinking about building a new code beautifier for a while. The idea isn’t unique, but every time I use someone else’s tool, I find myself reapplying the same settings and dodging advertisements every single time. 🤦🏻
I wanted a simple tool that worked well without the hassle, so last week I grabbed some paper and started sketching one out. I’m a huge fan of wireframing by hand. There’s just something about pencil and paper that makes the design part of my brain work better than staring at a screen.
I kicked off the design process by hand-drawing wireframes for the app.
I was immediately inspired after drawing the wireframe. The next day, I took a break from my usual routine to turn it into a something real. 👨🏻💻
I knew I wanted the code editor to be the main focus of the tool, so I created a thin menu bar at the top that controls the mode (i.e. HTML, CSS, JavaScript) and settings. I eventually added an About button too.
The editor itself takes up most of the screen, but it blends in so you don’t really notice it. Instead of wasting space with instructions, I used a placeholder that disappears when you start typing.
The Dark Mode UI is based on a toggle that updates the styles.
At the bottom, I created a status bar that shows live stats about the code including the current mode, indentation settings, number of lines, number of characters, and document size in bytes. The right side of the status bar has a “Clear” and “Clean + Copy” button. The center has a logo shamelessly plugging my own service.
I don’t think many developers really code on phones, but I wanted this to work on mobile devices anyway. Aside from the usual responsive techniques, I had to watch the window size and adjust the tab position when the screen becomes too narrow.
I’m using flexbox and viewport units for vertical sizing. This was actually pretty easy to do with the exception of a little iOS quirk. Here’s a pen showing the basic wireframe. Notice how the textarea stretches to fill the unused space between the header and footer.
If you look at the JavaScript tab, you’ll see the iOS quirk and the workaround. I’m not sure how to feature detect something like this, so for now it’s just a simple device check.
Handling settings
I wanted to keep the most commonly used settings easy to access, but also expose advanced settings for each mode. To do this, I made the settings button a popover with a link to more advanced settings inside. When a setting is changed, the UI updates immediately and the settings are persisted to localStorage.
The most common settings are contained in a small panel that provides quick access to them, while advanced settings are still accessible via a link in the panel.
I took advantage of Vue.js here. Each setting gets mapped to a data property, and when one of them changes, the UI updates (if required) and I call saveSettings(). It works something like this.
function saveSettings() { const settings = {}; // settingsToStore is an array of property names that will be persisted // and "this" is referencing the current Vue model settingsToStore.map(key => settings[key] = this[key]); localStorage.setItem('settings', JSON.stringify(settings); }
Every setting is a data property that gets synced to localStorage. This is a rather primitive way to store state, so I might update the app to use a state management library such as Vuex later on.
To restore settings, I have a restoreSettings() function that runs when the app starts up.
function restoreSettings() { const json = localStorage.getItem('settings'); if (json) { try { const settings = JSON.parse(json); Object.keys(settings).forEach(key => { if (settingsToStore.includes(key)) { this[key] = settings[key]; } }); } catch (err) { window.alert('There was an error loading your previous settings'); } } }
The function fetches settings from localStorage, then applies them one by one ensuring only valid settings in settingsToStore get imported.
The Advanced Settings link opens a dialog with tabs for each mode. Despite having over 30 settings total, everything is organized and easy to access so users won’t feel overwhelmed.
Clicking the “Advanced Settings” link opens up language-specific preferences and shortcuts.
Applying themes
Dark mode is all the rage these days, so it’s enabled by default. There’s also a light theme for those who prefer it. The entire UI changes, except for popovers and dialogs.
I considered using prefers-color-scheme, which coincidentally landed in Firefox 67 recently, but I decided a toggle would probably be better. Browser support for the color theme preference query isn’t that great yet, plus developers are weird. (For example, I use macOS with the light theme, but my text editor is dark.)
The app with Light Mode UI enabled.
Defining features
Coming up with feature ideas is fairly easy. It’s limiting features for an initial release that’s hard. Here are the most relevant features I shipped right away:
Beautifies HTML, CSS, and JavaScript code
Syntax highlighting with tag/bracket matching
Paste or drop files to load code
Auto-detects indentation preference based on pasted code or dropped file
Light and dark themes
Clean and copy in one click
Keyboard shortcuts
Most JS Beautify options are configurable
Settings get stored indefinitely in localStorage
Minimal UI without ads (just an unobtrusive plug to my own service) 🙈
I also threw in a few easter eggs for fun. Try refreshing the page, exploring shortcuts, and sharing it on Facebook or Twitter to find them. 😉
The tools and libraries I used
I’m a big fan of Vue.js. It’s probably overkill for this project, but the Vue CLI let me start building with all the latest tooling via one simple command.
vue create beautify-code
I didn’t have to waste any time scaffolding, which helped me build this out quickly. Plus, Vue came in handy for things like live stats, changing themes, toggling settings, etc. I used various Element UI components for things like buttons, form elements, popovers, and dialogs.
The editor is powered by CodeMirror using custom styles. It’s a well-supported and fantastic project that I can’t recommend enough for in-browser code editing.
The library that does all the beautifying is called JS Beautify, which handles JavaScript, HTML, and CSS. JS Beautify runs on the client-side, so there’s really no backend to this app — your browser does all the work!
JS Beautify is incredibly easy to use. Install it with npm install js-beautify and run your code through the appropriate function.
import beautify from 'js-beautify'; const code = 'Your code here'; const settings = { // Your settings here }; // HTML const html = beautify.html(code, settings) // CSS const css = beautify.css(code, settings) // JavaScript const js = beautify.js(code, settings)
Each function returns a string containing the beautified code. You can change how each language is output by passing in your own settings.
I’ve been asked a few times about Prettier, which is a comparable tool, so it’s worth mentioning that I chose JS Beautify because it’s less opinionated and more configurable. If there’s enough demand, I’ll consider adding an option to toggle between JS Beautify and Prettier.
I’ve used all of these libraries before, so integration was actually pretty easy. 😅
This project was made possible by my app, Surreal CMS. If you’re looking for a great CMS for static websites, check it out — it’s free for personal, educational, and non-profit websites!
Oh, and if you’re wondering what editor I used… it’s Visual Studio Code. 👨🏻💻
