DEV Community: Justin Schroeder

Shakespeare makes you a better engineer.

Justin Schroeder — Tue, 16 Sep 2025 22:24:41 +0000

I made a benchmark for "discernment" several months ago — how well can a model judge. It has been the most accurate predictor of the utility of a model in agents and coding that I have seen to date.

It turns out that discernment is incredibly important when writing software, and models with poor discernment may be good at the syntax but they are terrible at the broader task of engineering.

See, the role of software engineer, when done properly, is not primarily about pounding out syntax. Being good at typing and syntax is just a prerequisite to do the real job: pathfinding in an infinite problem space. The primary skill that all good senior engineers have is an above average ability to make subjective judgment calls at each step of the problem solving process. Given two or three iterations, a good senior engineer's solution approaches the optimal path. Not that dissimilar from a great race car driver finding the optimal racing lines on a given track.

To make coding models faster, more token efficient, and cheaper to operate — they often are trained, and reinforced, with code, code and more code — and if we were training a race car driver, this would work great. However, unlike the racetrack, the solution space of coding is infinitely vast — discerning a path through it efficiently leverages everything we know, everything we are.

In other words: I can't explain why organized sports, reciting Shakespeare, memorizing scripture, or playing the piano makes you a better engineer, but it does. Along with brute experience, it is those seemingly unrelated disciplines that shape and craft your ability to make judgment calls. To discern.

The same is true for models. Stripped down and efficient models can be excellent at various discrete tasks, but finding an elegant solution to a hard problem? Nah, turns out you need to know how to change a diaper at 3am to do that well.

Building Bod.Coach: LLM Lessons Learned The Hard Way.

Justin Schroeder — Tue, 22 Jul 2025 19:30:41 +0000

I don't like working out. I do it, but I don't like it. In fact, I was doing the same gym routine for three years without touching it because I didn't want to spend the time researching and changing the exercises I was doing to meet my distant fitness goals (Greek god—without the effort, obviously).

Like any self-respecting developer, I turned to AI. Surely these models could crank out top-notch workout routines for me and I could just pop them into a database and boom—problem solved.

You silly, naïve little man. Not all that glitters is gold.

In the end, we successfully created Bod.Coach—a truly unique fitness experience where you are paired with a virtual fitness trainer via text message. Your trainer has an actual phone number, and you carry on a conversation with it to create your routine, schedule your workouts, and give feedback. You can text any time to change your schedule or let it know you got a shoulder injury—it'll reschedule workouts, change exercises to accommodate your injury, or make you one-off hotel room workouts when you travel. It will track your progress and change workouts dynamically over time to meet your goals. It'll text workout reminders too and hold you accountable by scolding you when you're not living up to your own goals.

But creating Bod.Coach turned out to be far more difficult than we anticipated and working with LLMs was by far the hardest part.

Have you tried actually building an app with AI at the core? It's one of the greatest paradoxes I've encountered in 20+ years of writing software. It's dead simple to wire up a fully functional demo but so so hard to make it reliable and good. Why? Because your intuition—that problem-solving muscle memory you've built up over your career as a developer—is absolutely worthless.

The good news is you can build an intuition for LLMs, but just like becoming a competent software engineer there is no shortcut. You have to build up reps working with them (and I don't mean using ChatGPT).

My first surprise was asking GPT-4o (via the web interface) for an upper-body arm workout given my particular goals and personal stats—it spit out a pretty great workout! So I went to the OpenAI platform console and crafted a tool call in their interface to capture the important details of a workout as structured data. I asked the same questions, and the result was absolute garbage. It had me doing five reps of barbell curls and then child's pose for 30 minutes.

This is when I began the journey of learning lesson number one.

Lesson 1: LLMs have a left and right brain.

LLMs are mostly right-brained. They feel more than they think. When we tested LLMs, we found the output format had almost as much to do with determining the quality of the response as the prompt itself. Let's use cookies as an example...

If you ask a human to write a chocolate-chip-cookie dough recipe on a piece of cardstock and then ask them to write one in a spreadsheet, you get roughly the same result. This is not true with LLMs. The quality of the recipe will be lower when requested as a structured output. This is especially true for non-thinking models.

When output is requested in a formatted structure—like a tool call—it feels as though it uses a different "part of the brain." My anthropomorphized narrative is that it's thinking more about the syntax than the content.

In reality LLMs are masters of linguistic form. They don't actually know what a good cookie-dough recipe is—they're just great at predicting the language structure that represents a good recipe. Ask for that as JSON and it suddenly becomes very unclear to its silicon brain what "good" looks like. This structured part of its brain is excellent at producing valid JSON, but not at doing both tasks at the same time.

Solution?

Thinking models help a bit, but in our experience there is still no solution better than chaining. First, ask an LLM to write out that cookie-dough recipe in exquisite detail, giving it no restrictions on output format. That text becomes the input to another LLM request that structures the recipe into JSON (using tools).

Lesson 2: LLMs are always dying

Do you remember the cloning machine Nikola Tesla built in The Prestige (the most underrated movie of all time)? The antagonist cloned himself every night and killed his current self each night as a magic trick. Perhaps this is my most heavy-handed personification of LLMs, but yes—they die every time they answer you. Each message, from the LLM's perspective, is the last time it will interact with you—and it will do everything it can to be darn sure you're happy with the response.

Obviously this isn't technically true. No LLMs were harmed in the making of this article, but if you use this mental model as an intuition hack you can predict their least desirable patterns. They are overly verbose, always trying to cover every side of an argument. They'll be quick to end a conversation that just started. They'll call your agent-termination tools far too early. They won't plan unless you ask them to. There are so many slight tendencies and inclinations that it's worth adopting this frame of mind: it thinks this is the last chance it has to speak to you.

The onboarding flow for Bod.Coach is unique. Your fitness trainer reaches out via text message and starts asking questions like "What are your fitness goals?" and "Are you working out at a gym or do you prefer home workouts?" It turns out this was a surprisingly hard problem.

Initially we told our trainers to carry on a conversation to collect all the information they deemed necessary to create a workout plan to meet the user's fitness goals. When enough information was collected, it could optionally call a tool like onboarding_complete. This led to roughly 20% of requests following this pattern:

The LLM was constantly calling our onboarding-complete tool prematurely. To correct this, we gave the LLM a series of things that most human fitness trainers would want to know before creating a workout program. But of course, it was then over-eager to follow these even when they didn't make sense:

Solution?

After many hilarious (and frustrating) iterations we landed on something that works: we explicitly tell the LLM how many more times it can ask a question and to ask only the most important next one. In our reflection flow, another LLM predicts how many more questions are needed to complete onboarding. This calms those existential fears while removing the need to script the entire flow.

Lesson 3: LLMs have analysis paralysis

It's wing sauce for me—put me in front of an aisle of wing sauce and I'll be there a while. I'll pick one and regret my choice all the way home. Give an LLM a lot of choices and it'll fail like a Roomba in Legoland. The more tools you give an LLM, the worse its decision-making gets.

Given a user prompt like "Is it going to rain today?" and tools like:

pour_beer  
get_weather  
plan_workout  
call_mom

It'll do great—run it 100 times and it'll pick get_weather almost every time. Add ten unrelated tools and a little extra context and it will start making ridiculous calls. When it goes wrong, it typically goes very wrong. — your customer's will notice.

User: "Hey, do you think it will rain today?"
LLM: calling tool call_mom, "Calling mom to ask about the weather"

We did some benchmarking and sure enough, there is an inverse correlation between accuracy and number of tool calls. Here is our super scientific report I showed the team:

Solution?

Break the problem down into a simple decision tree—flowchart style. We call these interstitial LLM prompts routers. Our internal rule is no more than six tools per LLM request (this may change), so with two levels of nesting you can accommodate 6² = 36 tools—assuming they’re evenly distributed in problem space. In Bod.Coach, for example, our router prompts decide which “expert” gets the request:

send_to_workout_expert  
send_to_account_expert  
send_to_conversation_expert

Each expert then has a smaller set of tools. This change dramatically improves reliability when you have lots of tools.

Lesson 4: LLMs are Stupid or Stupid Expensive

Developers love hyping how smart models are and how fast they're improving. What’s not improving quickly is cost and latency. That’s one of the biggest barriers to consumer AI apps. They just aren’t economically feasible. Sure, in a scorched-earth “get users at all costs” era it's fine to run a deficit for a while, but most businesses can't. I pay $200/month for Claude Max at work and don't bat an eye, but I'd rather sell a kidney than pay $50/month for a personal subscription.

We could make Bod.Coach incredible by letting every single text, workout, and scheduling request be handled by Anthropic’s Opus, o3, or Groq-4—but the subscription price would be astronomical. Instead we offer it for $11.99/month (billed annually). How?

Solution?

Routers again. Because routers categorize prompts into discrete, deterministic domains, we can scale model power—and cost—by task complexity. On Bod.Coach your workouts are planned by a bleeding-edge model—we always want top-notch programs. But when you're just chatting about the rain, a cheaper model handles it.

Lesson 5: Build Your Own LLM Tooling

Off-the-shelf tools can save time, but no one has invented the perfect wheel yet. Capabilities, techniques, APIs, and models change so quickly that locking into any vendor feels risky. Building your own tooling has never been simpler.

Log everything: exact LLM requests, conversation history, model used, tools provided, and the response.
Provider shim: support the native APIs of multiple model providers; third-party shims often miss provider-specific features.
Fault tolerance: LLMs fail often—implement retries and instant failover to an equivalent model elsewhere.
Flow control: chain prompts so outputs feed directly into the next prompt.
Agent control: boot, log, monitor, and, if needed, kill agents.

There's no quick fix here. Just start building. Try tools if they help, but ultimately I recommend owning this part of the stack.

Conclusion

We're really proud of Bod.Coach (you should try it—there's a free trial!). It has proven to actually help people work out and stay more consistent than they otherwise would. Yet the path to success was littered with dead ends, wrong assumptions, and bizarre solutions. Your intuition is wrong, and there are no manuals for success—but, as always, the path less traveled is the most rewarding.

Introducing: KickStart — a form builder for developers.

Justin Schroeder — Thu, 15 Aug 2024 20:52:21 +0000

TLDR: kickstart.formkit.com

If you're reading this you're a developer. Which means you (unfortunately) spend a serious chunk of your time creating forms. Sometimes those forms are small and simple like login forms, sometimes they're complex Rube Goldberg machines, but they are almost always eye-wateringly tedious.

All those labels, help text, validation rules, styles, internationalization — for every single input — it's boring and soul-crushing work. Take this paper form as an example:

We're all familiar with filling out forms like this ☝️ (this particular one is an actual patient registration form for the Mayo Clinic hospital system), but imagine if your boss asked you to add that to your web app. Do you know how dense that is? No fewer than 70 inputs! 70!!

Enter KickStart — a next-generation form builder specifically for developers. KickStart generates forms from a screenshot, SQL query, CSV, markdown file, or a simple prompt. That paper form becomes actual working and running inputs in seconds. You can then edit the form to your heart's content using manual tools, or a conversational chat interface.

Each iteration of your form is saved — so if the AI messes up (or you do 😉) you can easily revert to any previous state.

The best part is that when you've got it in a good spot — just copy and paste the resulting Vue components into your application. This means you, developer friend, still have all the power to fine-tune your form using real code — not some half-baked pseudo programming flow tool.

At FormKit, we're developers just like you. We built KickStart because we were sick of the mind-numbing tedium of form creation. It's the tool we needed, and now it's here for all of us. Give it a shot – we think you'll dig it as much as we do.

Try it out: kickstart.formkit.com

Rolldown: why it matters

Justin Schroeder — Fri, 08 Mar 2024 15:18:17 +0000

Rolldown (just open-sourced) might be the most important web project of the next 5-10 years. I thought it might be helpful to explain why:

The landscape:

Rollup is the best and most comprehensive bundler to date. It was ahead of its time, pioneering key concepts like tree shaking (🙏 @Rich_Harris & @lukastaegert) and still hasn’t been matched in this regard. When @youyuxi introduced @vite_js — Rollup was a cornerstone of the build process. Vite plugins are (for the most part) Rollup plugins.

It didn’t take long for Vite to become the standard development and build environment for nearly every major meta framework: @nuxt_js, @solid_js start, @sveltejs kit, @remix_run, @angular cli, etc. (basically everything except Next). Rollup is still the underpinning of all of these. It has gone from being a way to bundle your library before publishing on npm to the backbone of how the modern web is being written.

The problem:

We find ourselves in a world where Rollup has been pressed into service building nearly every byte on the web — something it wasn’t originally intended to do — and its performance (really JavaScript’s performance) could be improved. esbuild (🙏 @evanwallace), a bundler written in Go, showed the world just how much faster a "native" bundler can be, but esbuild was not Rollup compatible and had its fair share of shortcomings as well (no TypeScript, limited tree shaking, etc.).

@vite_js uses esbuild and Rollup to get the best of both worlds, but here lies another problem: parsing. Different build tools use different AST trees, and each of these must parse the code to derive the AST. Also, many plugins for Rollup/Vite perform their own parsing. Wouldn’t it be incredible if the parsing was done a single time and a single AST tree could be used by all layers of the build stack?

@youyuxi said recently that @vite_js often has to parse the same TS file at least 5 times at various levels in the stack. Clearly this could be better.

The solution:

The Rolldown project is attempting to (eventually) solve all of these problems. First, it is written in Rust, one of the fastest languages out there — generally even faster than Go (i.e., esbuild) due to Rust not using garbage collection. In some applications, this doesn’t matter much, but in the context of parsing and compiling, this is a big benefit (oh the irony that Rust itself is the world’s slowest compiler 😂). Plus, people like @ThePrimeagen talk about Rust — somehow that makes it fast by proxy.

Rolldown isn’t just attempting to be fast though, it is also attempting to be API compatible with Rollup. This would be a monumental accomplishment (the Rollup API is not for the faint of heart). If successful, the @vite_js team could swap out the engine inside Vite while the plane is flying.

Finally — and perhaps most ambitiously — a standard singular parse. Perhaps this is a bit further down the road, but because Vite is so prevalent and because Rolldown uses OXC (🙏 @boshen_c) for parsing, we could end up in a world that standardizes around a single parse and AST tree. The performance improvements we could see in our development environment and build times would be tremendous.

If successful, Rolldown will be responsible for transforming nearly every byte of web code — no matter what framework you use.

Thanks:

Finally, thanks to the @vite_js team, and everyone working on @rolldown (@_hyf0, @_h_ana___, @youyuxi)! I am in no way affiliated with these fine engineers, just a mere plebe building on the backs of these giants.

Re-posted from here:
// Detect dark theme var iframe = document.getElementById('tweet-1766115866859446477-906'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1766115866859446477&theme=dark" }

Introducing Tempo • A new date library for JavaScript (and TypeScript).

Justin Schroeder — Wed, 14 Feb 2024 10:00:00 +0000

TLDR; Checkout the Tempo docs.

Working with dates and time is one of JavaScript’s weakest points. The native Date object is, under the hood, just a unix timestamp with some utility methods.

Fortunately, there is no shortage of libraries like moment.js, luxon, date-fns, and day.js to fill the gap. Which brings up the question you’ve already asked yourself, — why another date library?

Of course I (👋 its me, Justin Schroeder) didn’t set out to create a whole new library, but the following needs have pushed me over the edge.

`Intl.DateTimeFormat` styles

The Intl.DateTimeFormat API is an incredible underutilized resource. For example, while it is excellent at formatting dates with locale aware format strings like { dateStyle: "full" } there is no easy way to reverse this process. Friday, March 14, 1997 is the "full" dateStyle in the locale en-US but how do you parse it back into a date? With tempo you can:

import { parse } from '@formkit/tempo'

parse('Friday, March 14, 1997', 'full', 'en')

Parse what you format

Anything you can format with Tempo you can parse with Tempo. For many libraries this is not the case. Bi-directional support allows you to build great locale aware user experiences like the datepicker in FormKit.

Timezones out of the box

Working with dates in real-world applications requires timezone support. Tempo does not require a plugin or additional package but instead mines the Intl.DateTimeFormat for you. Need to know what the time difference between Amsterdam and Kolkata is in 2 months?

import { offset, addMonth } from '@formkit/tempo'

const inTwoMonths = addMonth(new Date(), 2)
offset(inTwoMonths, 'Europe/Amsterdam', 'Asia/Kolkata')

Death to the builder pattern

In almost all cases we should().not().use().theBuilder().pattern(). The builder pattern cannot be tree shaken and offers no substantial benefits over a more functional style (this is not a rebuke of objects, just this pattern). Unfortunately tools like Luxon and DayJS make heavy use of the builder pattern.

Stop the plugins

Many of my favorite date libraries promise an itty bitty core with optional plugins to expand the scope of functionality — unfortunately that little core often doesn’t do much. The same benefit is available to anyone using function notation while tree shaking ensures your project is never bigger than it needs to be. In real-world use cases Tempo is generally ~3-5kb min/gzip including robust support, but depending on what you import it can be as small as 80 bytes.

Better docs

Most of our time interacting with date libraries is reading docs. I want to enjoy that experience. I also want to tinker with things like the format function directly on the page. Tempo’s docs are (I think) great and every example is interactive so you can test your use case before you write a line of code locally.

Why not?

Seriously though, this is an open source project and a free gift to the world. If you are perfectly happy with your current solution, keep using it. If you’d like to try something new — give Tempo a shot.

Highlights

Tempo is full featured in ways you would expect, with full support for day.js style formatting tokens, date parsing, and date manipulation. However it does have some nifty tricks up its sleeves that are worth pointing out:

Convert a `dateStyle` to tokens

Tempo allows you to extract the formatting tokens of any dateStyle or timeStyle:

import { formatStr } from '@formkit/tempo'

formatStr({ date: 'full', time: 'full' }, 'en')
// dddd, MMMM D, YYYY at h:mm:ss A Z

Using this technique you can create incredible user experiences where users are presented editable dates in their own locale. For examples, checkout FormKit’s datepicker where we use this exact feature: https://formkit.com/inputs/datepicker

Tip: For even more detail you can use the parts() function.

Using timezones

Tempo ships with first class support for timezones — it’s even baked into the format() function.

import { format } from "@formkit/tempo"

// What time is it in LA?
format({
  date: new Date(),
  format: 'hh:mm a',
  tz: 'America/Los_Angeles'
})

You can also easily determine the timezone offset from the user’s location to a fixed place. This is useful when building apps where time at a target location matters. For example booking a rental or a meeting in at a given location from another timezone.

import { tzDate } from '@formkit/tempo'

// Create the date for 1:44pm in Dubai.
tzDate('2025-02-28 13:44', 'Asia/Dubai')

Token ranges

Tempo can "mine" information from Intl.DateTimeFormat. For example, if you want to create a select list of months and display them to a user in their own locale, how can you get all those strings?

import { range } from '@formkit/tempo'

const monthNames = range('MMMM')
// January, February, March...
// or in french:
// janvier,février,mars..

Get building

There are many more features to explore in Tempo — give the docs a quick scan so you know what’s available the next time you’re working on a project that requires working with dates.

While I have you here — can I ask you a personal favor? Consider giving Tempo a star on GitHub...it makes me happy.

If you really like Tempo, consider sponsoring FormKit! We don’t make a dime off this open source work, so any sponsorships we get are hugely encouraging.

❤️

See announcement tweet 👇

// Detect dark theme var iframe = document.getElementById('tweet-1757462744595300822-982'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1757462744595300822&theme=dark" }

I’m a software engineer, what does AI mean for me?

Justin Schroeder — Wed, 22 Mar 2023 19:41:15 +0000

The ticking clock

Seven years ago, a co-worker and I were walking to lunch in our small town of Charlottesville, Virginia. To our surprise, we realized we had passed three digital agencies on our short stroll. Web developers are everywhere — and for good reason. It’s nearly impossible to run a business without a digital presence. The world needs our “product.”

Yet at that moment, I remember saying:

Too many people are getting paid too much for this industry to go on without disruption. The target on our backs is too big.

That moment, seven years ago, was the beginning of a career change for me. I realized that the clock was ticking on my toolset being “special.” It wasn’t long after that walk with my co-worker that I left the agency I was working for to take a stab at building a business of my own — before the clock ran out on my abilities being “special.”

As software engineers, we have long enjoyed being a necessity in nearly every start-up. Famously, many start-up incubators require one of the founders to be an engineer, and often the first big hiring wave of a growing business is... engineers. Meanwhile, developer salaries have ballooned — I know one self-taught engineer making $600k/year. Again, the target on our backs is massive.

The match

I thought the impending engineering disruption would come from increasingly powerful SaaS products like Squarespace, WebFlow, or no-code. The day GitHub co-pilot was released, I realized I was wrong. The disruption would come from AI. I told our team that first day:

I may or may not use co-pilot (of course, I ended up using it), but I really believe this is the beginning of the end of our industry.

My time horizon for that statement was denominated in decades. Perhaps, I thought, in 20 years, the world will require 50% fewer engineers.

I was off by a factor of ten.

The legacy of replacement

Jobs have been changing for centuries. Some jobs become obsolete while new jobs are created in their wake. The industrial revolution eliminated scores of jobs but also created many new ones. Factory shift work was born. Suddenly it became essential to get to work on time — so a new job was born, the window “knocker-upper.” This person would simply knock on your window to wake you up in the morning. Eventually, this new role was itself replaced by the alarm clock.

Before phototypesetting, printing press plates were manually assembled by a “compositor” — a job made entirely obsolete by newer technology (it lives on in our digital jargon). More recently, digital photography caused massive disruption to the film industry. It wasn’t that long ago that every Walmart had a darkroom technician, Kodak was a household name, and polaroids were convenient — not hipster.

The dawn of digital photography was a warning shot across the bow of the film industry. Adapt or die. Most died. I imagine the scuttlebutt in their hallways sounded a lot like developer Twitter does today, “digital cameras just can’t x” — a desperate and combative search for relevance in the face of unrelenting market efficiency.

New roles and old ones?

It’s not all doom and gloom, though. Prompt engineer, data researcher, cybernetically enhanced humanoid software engineer, farmer — the jobs we have in the future may not yet exist, or they may be a resurgence of jobs as old as time. One thing is certain, though, new jobs will emerge — the challenge of knowing exactly where is an n-body problem — no one can accurately predict it.

In 2007 when the iPhone was announced, it was impossible to predict that it would directly lead to thousands of people picking up food from local restaurants for delivery, letting strangers sleep in our homes, or causing scores of people to run around New York City trying to catch Pokémon.

Although AI doomsayers love to tell us how “this time it’s different,” — don’t believe the lie; nothing is new under the sun; it’s always just a different shade of the same thing. Instead, we should be aware that these changes will come, so don’t let emerging opportunities escape your grasp. If you cover your ears and close your eyes progress will march on despite your resistance.

How far is that horizon?

If you are an engineer reading this, your emotions will fall into one of three categories:

Optimism. You’re excited. You see opportunity around every corner, and this is a big corner.
Denial. You’ve seen ChatGPT make mistakes. It doesn’t even know basic math. Your job is safe. All this hype is just that, hype.
Concern. You’re not sure what the future holds, but you know things are going to change. You’re grappling to understand how you fit into the unfolding future.

The truth is we don’t know how far we are from a future that causes a dramatic shift in engineering labor. ChatGPT cannot entirely replace a human engineer on any single metric today. It does not — at present — possess the capability for unique critical thinking. However, five years ago, if asked, most engineers would have said their jobs would be one of the last to rest on the chopping block. Now we can all (even the deniers) envision a future where AI can do our jobs.

How far are we from that vision becoming a reality? In 2000 BCE Wan Hu imagined going to the moon — he could do it by the end of the day, probably. He strapped 47 rockets to his chair in what was history’s first attempted moon landing. Humanity’s imagination and capability were separated by 4,000 years.

It is possible that ChatGPT has merely given us the ability to imagine a world where AIs replace engineers — but the capability to actually do so might still be a long-distant future.

Alternatively, we might be window knocker-uppers in the age of alarm clocks.

What will I do?

From a career standpoint — my work still matters. I’m still “better” than the AI — and you are too — but I know I’m going to be keeping an eye out for where things are heading more than I have ever done before. What new tools can be created with this technology? What opportunities are opening up that didn’t previously exist? What new jobs will be created? What am I truly great at? How can I bring unique value into the world? What is my plan if the coming disruption leaves me out?

How about you? Do you think of yourself as someone who codes because you’ve learned the syntactic shibboleths to get a computer to do what you want? Or are you someone who codes to solve problems? Engineering is solving problems. As AI assistance becomes AI creation, our tools to solve problems will change — if you’re a syntax machine you will be replaced by a more efficient syntax machine. If you are a problem solver, you’ll be a more efficient problem solver — at least for now.

On a personal level — I’m more inspired than ever to be great at the things AI can never do — be a nurturing father to my kids, a great husband to my wife, and an active member in my community. Life is far too rich and precious to be defined only by the type of work we do. Live your life, love your people, and for heaven’s sake — eat some good food. After all, the AI can’t do that either — yet.

Introducing AutoAnimate — add motion to your apps with a single line of code.

Justin Schroeder — Thu, 19 May 2022 16:30:33 +0000

When it comes to building user interfaces, a little motion goes a long way. Whether you are adding a task to your todo list, deleting a contact, or sorting a playlist, interfaces with subtle motion unquestionably provide a superior user experience. If we know some motion is better — why do we so seldom add it?

The answer is as simple — it just takes too much time. Time is money after all, and optimizing for "minor" UX details often falls outside the budget of all but the biggest brands.

To be fair, adding UI animations can be painful — especially for new, removed, and moved DOM elements. For example, when animating the addition of a new item to a list an experienced dev might do the following:

Measure the parent element and set its max-height explicitly, and add a class with css transitions for max-height.
Add a class to the new list item before its added to the DOM that sets its initial opacity, and transform state (perhaps a slight scale down).
Inject the element, and set a very short timeout that removes the initial class.
Calculate the height of the element being added, and increase the parent’s max-height by that amount.
Wait for the height to be fully transition, and remove the explicit max-height properties.

This is not fun! Enter AutoAnimate.

AutoAnimate is a lightweight (1.9Kb), zero-config, drop-in, animation library that automatically applies transition animations to elements being added, removed, or moved in the DOM. It literally takes one line of code to implement, and it works with React, Vue, and any other JavaScript framework you want.

AutoAnimate’s goal is to substantially improve an application’s user-experience without impacting the developer’s implementation time or performance budget.

Let’s take a look at two identical lists written in React — one with AutoAnimate and one without.

The details of the list are just standard React code, but lets take a look at how animations were added to the second list:

import React from 'react';
import FrameworkList from './FrameworkList';
import { useAutoAnimate } from '@formkit/auto-animate/react';

export default function App() {
  const [animationParent] = useAutoAnimate();
  return (
    <section className="comparison">
      <FrameworkList />
      <FrameworkList ref={animationParent} />
    </section>
  );
}

That’s it? Yep. And it might even be easier if you use Vue!

<script setup>
import FrameworkList from './FrameworkList.vue'
</script>

<template>
  <section class="comparison">
    <FrameworkList />
    <FrameworkList v-auto-animate />
  </section>
</template>

Of course AutoAnimate works great with plain ol' native JavaScript too! All you need to do is pass the parent DOM element into the autoAnimate function:

const el = document.getElementById('#my-el')
autoAnimate(el)

AutoAnimate is made by myself (Justin Schroeder) and the team from FormKit, and as of today the beta is publicly available!

If you find AutoAnimate is helping you out, consider supporting us. You can:

Introducing FormKit: A Vue 3 form building framework

Justin Schroeder — Wed, 23 Feb 2022 20:16:24 +0000

Web forms are the connective tissue of the internet. Without them people can’t request their health records, apply for university, order pad thai, or book a plane ticket. Yet too often the tools used to build those forms are a grab bag of npm packages and DIY solutions that result in a subpar user-experience, poor accessibility, and low maintainability.

In 2020 I released a small open source library to help alleviate the constant pain of building forms — it was called Vue Formulate. The library was "late to the game" — released for Vue 2 just as Vue 3 was coming on the scene — and developers were already committed to their tools of choice. I had low expectations for adoption and yet developers started using Vue Formulate — a lot. It seemed others were experiencing the same pain points as I was.

Let’s review that pain: building high-quality forms is hard. Sure, it’s easy to slap an <input> tag on a page, but taking care to label, group, populate, internationalize and validate every input takes a lot of effort — and all too often we leave critically important features on the alter of time: accessibility, error handling, and an empathetic user experience.

As a user — how often have you submitted a form only to realize there's a validation error somewhere on the page but the application doesn't tell you which input. Or how about those forms where the developer plops a list of validation errors on the top of the page and expects you to sort it out yourself? How often have you been responsible for doing that 😳? Yeah...me too. Personally, I blame the tooling — enter FormKit.

FormKit isn’t just the Vue 3 compatible version of Vue Formulate. It isn’t just another validation library, or UI library — it aims much higher: FormKit is a form building framework.

What can it do?

As of today (early 2022), FormKit has a similar feature set to Vue Formulate but with a new architecture that will allow us to ship exciting features on a regular basis. Let’s hit some highlights:

Single component

FormKit is easy to learn — there's only 1 input component <FormKit>. The convenience of typing <FormKit type="text"> vs <FormKit type="textarea"> is more profound than it seems on the surface — it provides a consistent shared API for all team members across all your projects.

No more boilerplate

Form inputs require a hefty dose of markup to be implemented correctly. Honestly, sometimes it’s just more annoying than difficult.

FormKit dramatically simplifies boilerplate by providing structured markup out of the box that supports:

Labels
Help text
Validation messages
Error messages
Input element
Wrapper elements

<FormKit
  type="textarea"
  label="Message"
  help="Enter your message"
  validation="required|length:50,200"
/>

Note: You may have to disable your ad-blocker on this page for the following Stackblitz code examples to run.

Validation

Although there are some great validation libraries for Vue (VeeValidate and Vuelidate to name two), FormKit provides pre-written validation rules which are then declared using the validation prop. This makes them easier to read and reduces room for developer errors:

<FormKit
  type="password"
  name="password"
  label="New password"
  validation="required|length:6"
  help="Enter a new password, at least 6 characters long"
/>
<FormKit
  type="password"
  name="password_confirm"
  label="Password confirmation"
  validation="required|confirm"
  help="Retype your password"
/>

Validation errors are automatically displayed on the inputs that are failing — exactly where your users expect them to be. There's much more to say about validation, but that’s why FormKit ships with comprehensive docs 😉.

Form state

Are all the inputs in your form valid? Is your form currently loading? Do you need to disable all the inputs at the same time? No problem. FormKit automatically:

Adds submit buttons to your forms
Ensures all inputs pass validation before submitting, and if necessary shows which inputs are still invalid.
Detects if you’re using an async submit handler and sets the form state to loading while awaiting a response.
Disables all inputs in your form while submission is pending.
Displays a spinner while submission is pending.

A simple example of this:

<template>
  <FormKit
    type="form"
    @submit="register"
  >
    <h2>Register</h2>
    <FormKit
      name="email"
      label="Email"
      help="What is your email address?"
      validation="required|email"
    />
    <FormKit
      name="password"
      label="Password"
      help="Enter your new account’s password"
      validation="required|length:6"
    />
    <FormKit
      name="password_confirm"
      label="Confirm password"
      help="Re-type that previous password"
      validation="required|confirm"
    />
  </FormKit>
</template>

<script setup>
const register = async (data) => {
  // Let's imagine this is a submit handler
  await new Promise(r => setTimeout(r, 2000))
}
</script>

Model binding

FormKit always knows the precise value of your form and all of its inputs — no matter how large. In fact, you can even v-model an entire form with 2-way data binding — this makes repopulating a forms a breeze.

<template>
  <FormKit
    type="form"
    submit-label="Update"
    v-model="values"
  >
    <h2>Edit account</h2>
    <FormKit
      type="text"
      name="first"
      label="First name"
    />
    <FormKit
      type="text"
      name="last"
      label="Last name"
    />
    <FormKit
      name="email"
      label="Email address"
      validation="required|email"
    />
  </FormKit>
  <button @click="randomEmail">Randomize email</button>

  <pre>{{ values }}</pre>
</template>

<script setup>
import { ref } from 'vue'

const values = reactive({
  first: 'Katja',
  last: 'Marabello',
  email: 'katja@gmail.com',
})

const randomEmail = () => {
  const randomString = Math.random().toString(36).substring(2, 10)
  values.email = `${randomString}@example.com`
}
</script>

Plugins

Plugins in FormKit are...powerful. In fact, many of the "advertised" core features, like internationalization (i18n), validation, Vue support, and even the inputs themselves are actually just first-party plugins. That said, the architecture of a FormKit plugin is unique.

Instead of having a centralized instance — like a "FormKit global object" — each input is its own mini-application, complete with its own plugins, store, and children.

Practically speaking, this means that you can expose a completely different set of features to one form on your site vs another — and you can code split and tree-shake those features to give you even better performance for your project.

Schema

Ahh, finally we come to FormKit’s schema. This is the most requested feature upgrade from Vue Formulate. The FormKit schema is a JSON-serializable data format that can describe virtually any HTML or Vue template structure.

To power this feature, we wrote a small runtime compiler that is able to make quick work of any HTML elements, Vue components, conditional expressions (if/then/else statements), mathematical expressions, boolean logic, loops, slots, and data references. It is so powerful, in fact, that we wrote all of our existing FormKit inputs using it.

Now you can store your forms anywhere you can store JSON — like a database 😉. There is so much more to say about the schema, but again, that’s why we wrote comprehensive documentation.

What’s next

FormKit is not feature-complete. Not even close. Although we've achieved feature parity with Vue Formulate (and surpassed it in several important ways), there is a lot more we are working on. Here are some of the highlights:

Input masking: FormKit was built with input masking in mind and we plan to release a full input masking plugin soon.
Pro inputs: Our team is hard at work building high quality "synthetic inputs" — inputs that don’t come natively with HTML. Think: autocompletes, tag lists, dropdowns, address fields, repeaters and many more. These will be paid inputs and are how we plan to make the project financially sustainable.
Theme builder: We support easy-to-use styling with our custom theme (called Genesis), your own CSS, or CSS-utility frameworks like Tailwind. But what if you could use a first-party theme builder to tailor a FormKit theme in-browser to match your project’s design? 🤔
One more thing...well...many things actually. We’re hard at work on some killer features, but we've gotta keep some tricks up our sleeves 😉.

Sustainability

You’ve heard me reference "we" and "team" a few times now. So who are these form-building heroes? There is a full team of 6 engineers behind FormKit: Andrew, Chris Adams, Chris Ellinger, Luan, Sasha and myself Justin. We’re committed to open source and ensuring that FormKit is forever freely distributed. We have 2 plans to make FormKit a sustainable project:

We are accepting sponsors of the FormKit open source project. If you find FormKit to be as useful as we do, please consider supporting us!
We will soon be releasing a set of "pro" inputs — these will be paid first-party custom inputs. We’re targeting the complex inputs that no one enjoys creating themselves such as autocompletes, tag lists, wysiwygs, and fancy file uploaders. You can request early access today.

We’re inspired by the great example of folks like Adam Wathan and Taylor Otwell who have built sustainable open source projects that the developer community will enjoy for years to come because they've created adjacent products that support their development efforts. We aspire to do the same with FormKit ❤️.

So much more...

There’s so much more that isn’t covered in this article so please — checkout the docs at formkit.com, join us and hundreds other on the FormKit Discord, and if you’re intrigued and would like to use FormKit in your own projects, throw us a star on GitHub.

🙏 Thank you. We look forward to the road ahead together.

Flow State: 10 Practical Tips for Getting In The Zone

Justin Schroeder — Sun, 11 Apr 2021 03:38:35 +0000

I have this recurring dream where I sit down at a piano and start playing like a virtuoso. The music flows out of my fingers at the same speed as my mind is composing the music. In my mind my dream feels like the purest act of creation. It is beautiful, but it's only a dream. On this side of consciousness I can't even play an instrument. Yet, that feeling of "pure creation" where my imagination smoothly becomes a reality is incredibly familiar. In fact, as engineers, on our best days, it's what we do for a living.

If you've been a serious programmer for more than a few years, I imagine you've experienced this magic. There are a lot of names for it, flow state, deep work, in the zone, being under. However, I prefer “flow state” because it best describes the feeling I have when I'm there. The truth is, it can be as elusive and delicate as it is powerful, but the payoff is enormous — well worth the pursuit.

When you're truly in flow state, your productivity skyrockets. Complex problems break down to simple steps, intricate logic becomes obvious, and innovative design patterns emerge. Maybe I’m being a bit too romantic. I mean we're just writing some code right? Nah, when I'm truly in flow state I'm creating.

I've been programming for 21 years and, for the last five I've been cataloging my experiments regarding flow. The following recommendations come out of those five years, but these are not "scientific" in an academic sense. Just practical advice born of my own monastic pursuit of flow state.

Know the basics

In the beginning, there are some fundamental prerequisites. These are not meant to be exclusionary, as anyone can achieve these skills and conditions. However, if you feel you fall short on any of them consider this as a friendly encouragement to keep on pushing:

Know the Syntax
The kind of flow state we're after requires that concepts transfer smoothly into bytes. You cannot play the piano like a virtuoso if you're stabbing around for middle-c. I'm not saying you have the entire language perfectly memorized, but at a minimum the syntax needs to melt away.
Know your Environment
You need to have a familiar and stable development environment: operating system, editor, terminal, server stack etc. Be very cautious about messing with these precious tools. Don't install a new shell environment, use one editor, and don’t be the first person to upgrade your OS. Keep your work space stable and familiar at all times. If you want to experiment, use a different machine or try setting up a secondary account on your computer.
Know your key commands
Goes without saying right? But seriously, you should be able to go for significant stretches of time in a code editor without ever lifting your hands off the keyboard.
Know How to "long-cycle"
When writing code, in any language or platform — there is a "cycle":
- You write some code.
- You check to see if it did what you wanted.
- You move on or adjust the code and repeat.
Beginners typically write very small chunks of code, a couple lines for example, and then check the results. This cycling is necessary to reduce mental overhead (you can't hold all the code for an app in your mind at once), but in my experience, very small cycles also reduce the likelihood you'll reach “flow state.” It's a mental crutch that prevents your mind from learning how to balance more complex problems. Each cycle takes an amount of time to complete, even one or two seconds per cycle can really add up. This slows your progress and introduces opportunities for distraction. If you're a victim of “short cycling”, try to intentionally practice writing more code each time before you validate the results.
Know how it works. It's important to understand the basics of the technologies you're working with. For example, if you're a web developer, you should really understand how the request/response cycle works, what HTTP methods are, how to interact with the Document Object Model (DOM), what event bubbling is etc. Sure you may use libraries that abstract these concepts away from you, but you must have an understanding of the underlying technologies. If not, it will be difficult to create a mental sandbox. A place where your mind can quickly and efficiently conceive new solutions to challenging problems.

If you're struggling with any of these basics it doesn't mean you can't be productive or produce excellent code. It just means the magic is harder to grab a hold of. The good news is practice makes perfect. Keep at it!

10 Practical Tips

Your brain hates getting into a flow state. What it wants are quick little dopamine hits that are addictive and supremely detrimental to productivity (lookin' at you Twitter). Flow is a marathon that your brain is reluctant to run. So what follows is a list of tips, tricks, and hacks that I've found help drag my mind, kicking and screaming, to the start line. These may seem trivial...because they are. Yet these sorts of small habits and patterns are tremendously useful in combating hours of half-focused waste.

Know what you're going to work on. This one is important. Before you even sit down you should already know what your first keystrokes are going to be. To help, each time you stop working, write a short todo list on a scrap of paper or a notes app (not your team's Trello or Jira board) of what you need to work on next time you sit down. It's good for these to crescendo from small to large: 1. "Finish the primary navigation breakpoints" 2. "Write a click-away handler for the dropdown" 3. "make a new modal component". It can even be a good idea to even leave yourself a breadcrumb, such as an easy to solve problem that only takes a few lines of code to complete that’s been obviously left incomplete for you (by you). This little trick can really jump start your day's work.
Close your apps. Shut down email, Slack, discord, social media and anything else that can send you a notification. Seriously. Shut 👏 Them 👏 Down 👏. Nervous someone will need you? Tell your co-workers to call you on the phone if it's really an emergency — trust me they won't call. People hate making phone calls. Those little red bubbles and pinging sounds are the death of flow state.
Music. This is controversial, but I've always had my best sessions with music. I've found it's best to put something on that is well-worn. You already know the words and can get into the rhythm instantly.
Ride the wave. Once you get into flow, ride the wave as far as it takes you, and then get off when it's over. Typically, I've found ~3-4 hours is as long as I can go before my mental state begins to crumble, but while I'm in flow I try hard to stay there even if it’s inconvenient. Occasionally the zen-like magic strikes me at 11:00pm and I make the conscious decision to ride it till it runs out, around 2:00- 3:00am. I'm not suggesting this is a good time to work, as you need to be well rested, but I am saying these sessions are so valuable (and frankly rare) that when they strike, it is worth the sacrifice to stay in them.
Instant on. The moment you sit down and the screen turns on, start working. Literally do nothing else. Don't check email one last time, or order that thing off Amazon. — You can do all that later. Start writing code...now. Your brain will push back and try to distract you — you need to win this argument. Your brain will thank you later.
Don’t reward yourself. Once in flow you'll start conquering problems left and right, but watch out! These little victories are a signal to your brain to chill out and celebrate the good times. You will suddenly find yourself randomly disengaging. — Don't fall for it. As soon as you solve one problem, instantly jump to the next, then the next. Let the progress snowball until your efficiency starts to die off.
Know how much to sleep. Don't just Google "how much sleep do I need to sleep", you're a unique human being. My wife needs a solid nine hours every single night, I need about six. Everyone is different. Listen to your body, and then give it what it needs. If you're thinking about sleep while you're trying to program — you didn't get enough.
Temperature. The temperature should be comfortable, but I've found that being slightly cold is better than being slightly hot.
Wear comfortable clothes. I remember high school teachers telling me to wear comfortable clothes when taking the SAT. They were right, although, perhaps "comfortable" isn't quite the right word. The important thing is not to be conscious of your clothes (positive or negative), you don't want to think about your clothes at all.
Hydrate & caffeinate. Drinking a glass of water ahead of time, and having coffee (if that's your thing) hot and ready is key. You don't want to have to get up for a while, so make sure your coffee is in a mug that doesn't get cold. I'm not saying that specifically coffee is needed but rather that it is important to consider and address your body's needs ahead of time so you don't get distracted. For me that “need” happens to be coffee, but for you that might be tea, fruit, or just a cup of water.

There’s more to work than flow

This article, rightfully, glorifies flow state. However, it's important to realize there is more to work than what occurs in flow. As developers, we're positioned in a market where our ability to rapidly produce high quality code is a great asset, but it's not our only one. Meetings, emails, code reviews, helping team members, writing blog posts and other important tasks are part of everyone's job and generally don't require the same level of hyper focus to accomplish. That's okay. When it comes to flow state, keep your powder dry, and your aim narrow. Don't get too down on yourself if you can't achieve flow state every day. While that's an admirable goal, our brains just won't always get there. Remember, there is plenty of other work that can be accomplished as a mere mortal too.

I hope you find these techniques helpful. If you're interested in hearing from me when you're not in flow you can follow me on Twitter @jpschroeder.

Better uploads with Vue Formulate, S3, and Lambda

Justin Schroeder — Thu, 14 Jan 2021 21:57:44 +0000

Not many developers enjoy building forms — and even the oddballs who say they do don't enjoy file uploads (or they're lying 🤷‍♂️). It's a universal experience — file uploads are a pain, and worse — after all the necessary technical work the end user experience is still typically poor.

Gather around friends, today I'd like to share another way to upload files that makes writing file uploads as easy as <FormulateInput type="file" />, provides a slick user experience, and requires no server-side code (well — AWS Lambdas are technically servers...ehh, you get the idea).

This is a long article, but the end results are worth it. Here's what we'll be covering:

The old way of doing file uploads
A better way of doing file uploads with Vue Formulate and AWS
- Setting up an AWS Account
- Creating an S3 Storage Bucket
- Configuring CORS for your S3 Bucket
- Creating an IAM role
- Creating a Lambda and accompanying API
- Publishing Lambda function code
- Configuring an API Gateway
- Testing the upload endpoint
- Adding a custom uploader function to Vue Formulate
A working example

See? It's a lot, but remember the end result is <FormulateInput type="file" /> resulting in direct uploads to AWS S3. Stick with me and we'll make it through.

Ye olde way

In the ye olde days we uploaded files by slapping one or more <input type="file"> inputs in a <form> that included the HTML attribute enctype="multipart-form-data". This did all the hard work of buttoning up the file for us and submitting it to our backend. Our backend code would then handle those files and usually place them somewhere on the filesystem. For example, here is a PHP script (from the official PHP docs) that handles a file upload:

<?php
$uploaddir = '/var/www/uploads/';
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);

if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {
    echo "File is valid, and was successfully uploaded.\n";
} else {
    echo "Possible file upload attack!\n";
}

Nice — so we can see PHP magically created some kind of temporary file with the contents of the uploaded file, and we move that temporary file to a permanent location on the filesystem (if we want to keep the file). This methodology still works today across various platforms, so why is it passé? Let’s highlight some of the ways this simple approach falls short:

There is no user feedback that the file is uploading. No progress bar, no loading animations, no disabled submit button. The user just sits there waiting for the form to submit. Have a lot of files? Your user will definitely get confused and click that submit button multiple times. Neato 👌
If there's an issue with the file upload, the user won't find out till after they waited for the entire upload to complete.
Your backend needs to be configured to handle file uploads. For PHP this requires configuring php.ini variables like upload_max_filesize, post_max_size and max_input_time.
If you're using a node server you need to be even more careful with uploads. Due to the single-threaded nature of node you can easily cause your server to run out of memory and crash.
If you're using a serverless stack your backend won't even have a filesystem to store the uploads on (thats where this article comes in handy 👍).
Your servers have a finite amount of disk space and it will eventually run out.

Some of these issues can be solved by passing the file "through" your server and then on to a cloud service like S3. For example, the PHP code above could use a stream wrapper to pass the file through to an S3 bucket instead of the local filesystem. However, this is effectively double-uploading — 1) the client uploads the file to your server 2) then your server uploads the file to S3.

An even better user experience is to upload files via fetch or XMLHttpRequest (XMLHttpRequest is still preferred since fetch doesn't support progress updates). However, rigging up these AJAX uploaders is a lot of work even when using pre-existing libraries and they come with their own backend shortcomings.

There's another way

What if our backend servers never touched the file uploads at all? What if we could upload our files directly to our cloud provider from the client's browser? What if our backend/database only stored the URL to the uploaded file?

Vue Formulate allows you to turbo-charge your file and image inputs to do just that by implementing a custom uploader function. The following describes how this can be accomplished with AWS Lambda and S3. What is Vue Formulate? Glad you asked — it's the easiest way to build forms for Vue — and I wrote an introduction article about it you might be interested in.

To provide the best user experience, Vue Formulate handles file uploads in an opinionated way. The library handles all of the UX like creating a dropzone, showing selected files, progress bars, file validation, displaying upload errors, and pushing completed uploads into the form's model. All you need to provide is an instance of Axios or a custom uploader function that performs your desired XHR request (don't worry, we're going to work through that together in this article).

By the time a user submits the form and your @submit handler is called Vue Formulate has already completed any file uploads in your form and merged the file URLs into the form data. Your backend can be sent a simple JSON payload and never needs to deal with the original files themselves. Even better, with just a little work, we can make those files upload directly to S3.

So how does this "direct uploading" work — and how do we do it in a secure way? S3 supports a feature that allows the creation of "signed URLs", which are generated URLs that include all the necessary credentials to perform 1 pre-approved function — such as putting an object into an S3 bucket 😉! However to create these signed URLs we need some code to be executed in a secured environment — this environment could be a standard backend server, but for our purposes we're going to use a simple Lambda function. This is a great use case for Lambda as it is a small, discrete operation that only needs to be run when a user adds files to our form (no need to have a server running 24/7 waiting to perform this operation).

Our custom Vue Formulate uploader function will perform a few steps:

Collect the files to be uploaded.
Request a signed upload URL from our AWS Lambda function.
Upload the file(s) to our S3 bucket using the signed upload URL.

Once we've added our custom uploader to our Vue Formulate instance, all of our file and image inputs will automatically use this mechanism. Sounds good, yeah? Ok — let's get cracking!

1. Setup an AWS Account

If you don't already have an AWS account, you'll need to set one up first. This is a standard signup process — you'll need to verify yourself and provide billing information (don't worry, AWS Lambda function call pricing and AWS S3 storage pricing are really cheap).

2. Create an S3 Storage Bucket

Use the services dropdown to navigate to S3 so that we can create a new storage bucket. You'll need to answer a series of question when creating the bucket. This includes:

Bucket name — I generally try to pick names that could be subdomains if I decide to rig up a DNS record for them in the future. For this example, I'll use uploads.vueformulate.com as my bucket name.
Region name (pick the one geographically closest to you)
Bucket settings for Block Public Access — uncheck all of these boxes since we're going to allow public downloads. In this example, we won't be creating private file uploads, but this same process works for that use case.
Bucket versioning — you can leave this disabled, it's cheaper and we'll be using random ids to ensure we don't accidentally overwrite existing files with new uploads.
Tags — These are optional and only if you want to use them. These can be helpful for tracking billing costs if you are using a lot of AWS resources.
Advanced Settings - Leave "Object Lock" disabled.

3. Configure CORS for the bucket

Next, we need to ensure that we configure CORS for the bucket to enable our direct uploading. In this case I'm going to apply a liberal Access-Control-Allow-Origin: * since I want my example to work from any domain. You can be more specific with your access control if you want to limit which domains are allowed to upload files to your S3 storage bucket.

Click on your bucket, then select "Permissions" in the tab bar. Scroll down to "Cross-origin resource sharing", click "Edit", and enter the following JSON configuration. Finally, hit "Save Changes":

[
    {
        "AllowedHeaders": [
            "Content-Type"
        ],
        "AllowedMethods": [
            "PUT"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": []
    }
]

4. Create an IAM role

Next, we'll need to create an IAM role for Lambda. Use the services menu to navigate to the IAM service (Identity Access Management). Click on roles in the sidebar and choose "Create role". Select the Lambda "use case" from the services use cases and move on to the next step.

This is where we attach "policies" (basically permissions). We'll add the AWSLambdaBasicExecutionRole which gives our new role the ability to run Lambda functions.

Next, add tags if you want them (not required), and finally, give your role a name and a description you'll recognize and create the role.

Next, we need to add the ability for this role to access the S3 bucket we created. Choose the role we just created, select "Attach policies", and then click "Create Policy" button at the top. Then follow these steps:

Select the S3 service
Select actions PutObject, and PutObjectACL
Specify the bucket ARN, and "Any" (*) object in the bucket.
Review and name the policy, then create it.

Finally, go back to the role we created, refresh the list of policies, search for our newly created policy, and add it to the role.

5. Create the Lambda and API

Use the services dropdown to search for the Lambda service. Open it, and choose "Create Function", and follow the prompts:

Select "Author from scratch"
Choose a function name, for this example I'll use "VueFormulateUploadSigner".
Change the execution role and select "Use existing Role". Choose the new role that we created in the previous step.
Leave the advanced settings unchanged and create the function.

Remember, this Lambda function is responsible for creating our signed upload URL, so we need an endpoint to trigger the lambda's execution. To do this, click the "+ add trigger" button, select "API Gateway", and follow the prompts:

Select "Create an API"
For "API type" choose "HTTP API"
For security, select "open" (You can always come back and add JWT later if it's needed for your specific application)
Leave the additional settings blank and "Add" the gateway.

6. Add the function code

We need our lambda function to create a signed putObject URL for us. In the Function code section double click on index.js. This file is the actual code that will be executed when our Lambda is run. In this case we want to use the AWS SDK for node.js to create a signed putObject URL for S3.

Here's some code that does just that. You can copy and paste it directly into the code editor — although you should read through it to understand what it is doing.

var S3 = require('aws-sdk/clients/s3');

const CORS = {
    'Access-Control-Allow-Origin': '*',
    'Access-Control-Allow-Headers': 'Content-Type'
}

/**
 * Return an error response code with a message
 */
function invalid (message, statusCode = 422) {
    return {
      isBase64Encoded: false,
      statusCode,
      body: JSON.stringify({ message }),
      headers: {
        "Content-Type": "application/json",
        ...CORS
      }
    }
}

/**
 * Generate a random slug-friendly UUID
 */
function uuid (iterations = 1) {
    let randomStr = Math.random().toString(36).substring(2, 15)
    return iterations <= 0 ? randomStr : randomStr + uuid(iterations - 1)
}

/**
 * Our primary Lambda handler.
 */
exports.handler = async (event) => {
    // Handle CORS preflight requests
    if (event.requestContext.http.method === 'OPTIONS') {
        return {
            statusCode: 200,
            headers: CORS
        }
    }
    // Lets make sure this request has a fileName
    const body = JSON.parse(event.body)

    // First, let's do some basic validation to ensure we recieved proper data
    if (!body && typeof body !== 'object' || !body.extension || !body.mime) {
        return invalid('Request must include "extension" and "mime" properties.')
    }

    /**
     * We generate a random filename to store this file at. This generally good
     * practice as it helps prevent unintended naming collisions, and helps
     * reduce the exposure of the files (slightly). If we want to keep the name
     * of the original file, store that server-side with a record of this new
     * name.
     */
    const filePath = `${uuid()}.${body.extension}`

    /**
     * These are the configuration options that we want to apply to the signed
     * 'putObject' URL we are going to generate. In this case, we want to add
     * a file with a public upload. The expiration here ensures this upload URL
     * is only valid for 5 minutes.
     */
    var params = {
        Bucket: process.env.BUCKET_NAME,
        Key: filePath,
        Expires: 300,
        ACL: 'public-read'
    };

    /**
     * Now we create a new instance of the AWS SDK for S3. Notice how there are
     * no credentials here. This is because AWS will automatically use the
     * IAM role that has been assigned to this Lambda runtime.
     * 
     * The signature that gets generated uses the permissions assigned to this
     * role, so you must ensure that the Lambda role has permissions to
     * `putObject` on the bucket you specified above. If this is not true, the
     * signature will still get produced (getSignedUrl is just computational, it
     * does not actually check permissions) but when you try to PUT to the S3
     * bucket you will run into an Access Denied error.
     */
    const client = new S3({
        signatureVersion: 'v4',
        region: 'us-east-1',
    })

    try {
        /**
         * Now we create the signed 'putObject' URL that will allow us to upload
         * files directly to our S3 bucket from the client-side.
         */
        const uploadUrl = await new Promise((resolve, reject) => {
            client.getSignedUrl('putObject', params, function (err, url) {
                return (err) ? reject(err) : resolve(url)
            });
        })

        // Finally, we return the uploadUrl in the HTTP response
        return {
            headers: {
                'Content-Type': 'application/json',
                ...CORS
            },
            statusCode: 200,
            body: JSON.stringify({ uploadUrl })
        }
    } catch (error) {
        // If there are any errors in the signature generation process, we
        // let the end user know with a 500.
        return invalid('Unable to create the signed URL.', 500)
    }
}

Once you add this code, click "Deploy". Now — the last thing we need to do in Lambda is add the BUCKET_NAME environment variable.

Scroll down from the code editor and choose "Edit" under environment variables. Enter a new key BUCKET_NAME and set the value to our S3 bucket name (I chose uploads.vueformulate.com as my name). Hit save, and your Lambda is ready to go!

7. Configure the API Gateway

We're getting close! Before we can start sending HTTP traffic to our Lambda we need to configure the API Gateway we created.

Navigate to the API gateway service and you should see a service with the same name as our Lambda with an -API suffix — let's click into that. The API Gateway service is a powerful utility that makes it easy to configure which Lambdas respond to which API requests. If you chose "Develop > Routes" you'll see that our Lambda has already attached itself to the /{lambdaName} route.

Personally, I prefer this route to be something more like /signature. We can easily change it, and while we're at it, let's restrict this endpoint to only respond to POST requests.

There's a problem though. Since we've restricted the endpoint to POST only, the browser's CORS OPTIONS preflight requests will fail.

Let's add another route for the same /signature path that also points to our Lambda (our code there will handle the CORS request). Create the route, and then click "Create and attach an integration" on the for the OPTIONS route and follow the prompts:

Select "Lambda function" for the integration type.
Select the region and function of our Lambda.
Create the integration.

When making changes to this default API, the changes are auto-deployed on the default "stage". You can think of stages like environments. Adding multiple stages here is beyond the scope of what we're doing here. For such a simple function using the default stage is perfectly fine.

If you navigate back to the main page for this API, you'll see we have an "invoke URL" for $default — this is your new APIs URL!

(You can change this to a custom domain if you wish, but this guide doesn't focus on that)

8. Test your endpoint!

Phew — that took some doing, but we should be up and running at this point. To test, copy the "invoke URL" and append /signature to the end of it. Let's try to ping our endpoint with a cURL request. Be sure to replace the values with your own endpoint values:

curl -d '{"extension": "pdf", "mime": "application/json"}' \
-H 'Content-Type: application/json' \
-X POST https://cq2cm6d0h6.execute-api.us-east-1.amazonaws.com/signature

You should get back a JSON response with a signed URL:

{"uploadUrl":"https://s3.amazonaws.com/uploads.vueformulate.com/hf8wj10h5svg3irf42gf.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIA2EL2NL4LVYXJTOK2%2F20210105%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210105T165545Z&X-Amz-Expires=300&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEFEaCXVzLWVhc3QtMiJHMEUCICwx61VITKOKB77AbzOBYFQ54hPigpS8YjXBn3opFCBHAiEAw4bNSBBAnrugIVs0kxFgFU%2Bxich0WrN%2BS96WJBqLt%2BYq1wEIGhAAGgw2OTY1NzgzMDE3MTkiDJLL6F8ULm9ygw6pIyq0Ac1moVu2PgGMBz4th89uCWW6XUsUAD%2FNcY5JUf06%2Btl2LU7j9DjxLtm5fKt0Bkc6Z96U03HmP4job3vYTKXR2wQPaW381fd5UKQLgiqz3o4ENwg8E92unTtZZ8DrP4yjntkkqUrw8Ybavyrik2eAPnp2ME%2FQe2kzl85rBWFgQdHj8bXBYPxgV1dIGyAi%2BQtp0XMMcJyJNR5Lgdh05py3WEpf0mCVS3vBe1MJP3m6kph7OMZLWDCnsNL%2FBTrgAQplCeuZMLkutxSWG8KHYUUGB5fLkJQJtK4xJab4zmxBndNXRT4tPLDPpiyyX%2B25DQbAxD48azztgdEOOim8%2BnY6rZTsY7KTd1%2FuQwryAr%2Bt9rzvL0ubkCo3PWK1UD0TBhx%2BjpE1KPyYjA4df0xlQyx0D1ee0uVRthn9FY9bDkuN8EWs2KNVxbt%2BbWYxAUJ5mqOtq1zWWa%2BXTWR20BlzWGG8NZTy0krkp9mBLM1mPIHdVNpgbgdMsnW3L0UtZXpCYT8n1QpVsMnIDuYcAK3ogOYLcIq0KOK8PWOk6whbz39W&X-Amz-Signature=362c8bc5cb11d6b5a14c52f82b58c25eae56b70bfaf22e01b25ac4ba4436b71e&X-Amz-SignedHeaders=host%3Bx-amz-acl&x-amz-acl=public-read"}

Success! Our Lambda code creates upload URLs that expire after 5 minutes — this isn't a problem since Vue Formulate will use the signed url immediately, but if you're playing around with the URL by hand it's worth keeping the expiration limit in mind.

Note: The above CURL request is an actual live lambda I manage, feel free test with it, be be aware that all files are automatically deleted after 24 hours 👍

9. The uploader function

The last step in our process is writing a custom uploader for Vue Formulate. Remember, when Vue Formulate receives a file from the end user it passes that file off to an uploader function (or axios). We want to use a custom implementation of the uploader function to fetch a signed URL and then perform an XMLHttpRequest (xhr) to that URL with our file data. The implementation details of this will vary ever so slightly depending on the specifics of your project but here's how this can be done globally via a Vue Formulate plugin:

s3-uploader-plugin.js

async function uploadToS3 (file, progress, error, options) {
  const matches = file.name.match(/\.([a-zA-Z0-9]+)$/)
  const extension = (matches) ? matches[1] : 'txt'
  progress(5)
  const response = await fetch(options.uploadUrl, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      extension,
      mime: file.type || 'application/octet-stream'
    })
  })
  if (response.ok) {
    const { uploadUrl } = await response.json()
    progress(10)
    const xhr = new XMLHttpRequest()
    xhr.open('PUT', uploadUrl)
    xhr.upload.addEventListener('progress', e => progress(Math.round(e.loaded / e.total * 90) + 10))
    xhr.setRequestHeader('Content-Type', 'application/octet-stream')
    try {
      await new Promise((resolve, reject) => {
        xhr.onload = e => (xhr.status - 200) < 100 ? resolve() : reject(new Error('Failed to upload'))
        xhr.onerror = e => reject(new Error('Failed to upload'))
        xhr.send(file)
      })
      progress(100)
      const url = new URL(uploadUrl)
      return {
        url: `${url.protocol}//${url.host}${url.pathname}`,
        name: file.name
      }
    } catch {
      // we'll suppress this since we have a catch all error
    }
  }
  // Catch all error
  error('There was an error uploading your file.')
}

export default function (instance) {
  instance.extend({
    uploader: uploadToS3
  })
}

main.js

import Vue from 'vue'
import VueFormulate from '@braid/vue-formulate'
import S3UploaderPlugin from './s3-uploader-plugin'

// Your main.js file or wherever you initialize Vue Formulate.

Vue.use(VueFormulate, {
    // Use API Gateway URL + route path 😉
    uploadUrl: 'https://6etx7kng79.execute-api.us-east-2.amazonaws.com/signature',
    plugins: [
        S3UploaderPlugin
    ]
})

A working example

You're done! With those changes in place, all file and image inputs in your Vue Formulate instance will automatically upload their contents directly to S3 from the
client's browser.

You can use as many file uploads as you'd like on any and all forms in your project with no additional configuration.

Here's an example in action:

If you’re intrigued, checkout vueformulate.com. You can follow me, Justin Schroeder, on twitter — as well as my co-maintainer Andrew Boyd.

Tailwind + Vue Formulate = ❤️

Justin Schroeder — Thu, 18 Jun 2020 18:33:47 +0000

Using Tailwind with Vue Formulate

Watching Vue Formulate begin to gain traction in the Vue ecosystem in the last few months has been a real thrill. Sadly, we've also watched citizens of the Tailwind world struggle to @apply their beloved styles to Vue Formulate’s internal elements. I'm happy to announce that with the release of 2.4, that just changed for Tailwind (and any other class-based CSS framework).

Mobile users: The demos in this article are on codesandbox which breaks on mobile. If you’re on mobile, you might want to revisit on desktop.

Missions aligned

Tailwind’s core concept of writing “HTML instead of CSS” is aimed at improving the developer experience, increasing maintainability, and making developers more efficient. Tailwind achieves this by reducing the decision making process around class names, tightly coupling styles with their usage, and abstracting away the complexity of the underlying framework.

These goals are nearly identical to how Vue Formulate approaches another one of web development’s least favorite necessities: forms. Vue Formulate’s objective is to provide the best possible developer experience for creating forms by minimizing time consuming features like accessibility, validation, and error handling.

In “Introducing Vue Formulate,” I described how there are several good pre-existing tools in the Vue ecosystem that handle various aspects of forms. Some of these handle validation, some handle form generation, some form bindings — Vue Formulate aims to handle all of these concerns. I believe they’re tightly coupled issues and call for a tightly coupled solution, not unlike Tailwind’s approach to styling.

Defaults matter

This coupling means form inputs come with markup out of the box. The out-of-the-box DOM structure is well suited for the vast majority of forms, and for those that fall outside the bell curve, Vue Formulate supports extensive scoped slots and (“slot components”). Still — defaults matter. In my own development career I've learned that, as frequently as possible, it’s wise to “prefer defaults”, only deviating when necessary (I can’t tell you how many times I’ve debugged someone's fish shell because they saw a nifty article about it).

Vue Formulate’s defaults are there for good reason too. Actually, lots of good reasons:

Value added features: Labels, help text, progress bars, and error messages require markup.
Accessibility: How often do developers remember to wire up aria-describedby for their help text?
Styling: Some elements just can’t be styled well natively and require wrappers or decorators.
Consistency: How often do developers write tests for their project’s forms? The default markup and functionality of Vue Formulate is heavily tested out of the box.

Personally, my favorite feature of Vue Formulate is that once you’ve setup your styles and customizations, the API for composing those forms is always consistent. No wrapper components, no digging through classes to apply (hm... was it .form-control, .input, or .input-element 🤪), and no need to define scoped slots every time.

So what’s the downside? Well, until now, it's been a bit tedious to add styles to the internal markup — especially if you were using a utility framework like Tailwind. Let’s take a look at how the updates in 2.4 make styling easier than ever.

Defining your classes (props!)

Every DOM element in Vue Formulate’s internal markup is named. We call these names element class keys — and they’re useful for targeting the exact element you want to manipulate with custom classes. Let’s start with the basics — a text input. Out of the box this input will have no styling at all (unless you install the default theme).

<FormulateInput />

In this case, we want to spice that element up by adding some Tailwind mojo to the <input> element itself. The class key for the <input> is input 🙀. Sensible defaults — what! Let’s slap some Tailwind classes on the input element by defining the new input-class prop.

<FormulateInput
  input-class="w-full px-3 py-2 border border-gray-400 border-box rounded leading-none focus:border-green-500 outline-none"
/>

Ok! That’s a start, but Vue Formulate wouldn’t be very useful if that’s all it was. Time to flex. Let’s make a password reset form with a dash of validation logic, and for styling we’ll use the input-class prop we defined above.

<FormulateForm v-model="values" @submit="submitted">
  <h2 class="text-2xl mb-2">Password reset</h2>
  <FormulateInput
    type="password"
    name="password"
    label="New password"
    help="Pick a new password, must have at least 1 number."
    validation="^required|min:5,length|matches:/[0-9]/"
    :validation-messages="{
      matches: 'Password must contain at least 1 number.'
    }"
    input-class="border border-gray-400 rounded px-3 py-2 leading-none focus:border-green-500 outline-none border-box w-full"
  />
  <FormulateInput
    type="password"
    name="password_confirm"
    label="Confirm password"
    help="Just re-type what you entered above"
    validation="^required|confirm"
    validation-name="Password confirmation"
    input-class="border border-gray-400 rounded px-3 py-2 leading-none focus:border-green-500 outline-none border-box w-full"
  />
  <FormulateInput type="submit"/>
</FormulateForm>

Ok, clearly it needs a little more styling. We’re dealing with a lot more DOM elements than just the text input now. Fortunately, the documentation for our element keys makes these easily identifiable.

So it seems we need to define styles for the outer, label, help, and error keys too. Let’s try this again.

<FormulateInput
  ...
  outer-class="mb-4"
  input-class="border border-gray-400 rounded px-3 py-2 leading-none focus:border-green-500 outline-none border-box w-full mb-1"
  label-class="font-medium text-sm"
  help-class="text-xs mb-1 text-gray-600"
  error-class="text-red-700 text-xs mb-1"
/>

Ok, that’s looking much better. But while it’s a relief for our eyes, the beauty is only skin deep. Those were some gnarly class props and we had to copy and paste them for both our inputs.

Defining your classes (base classes!)

So what’s a Tailwinder to do? Wrap these components in a higher order component, right!? Heck no. Please, please don’t do that. While wrapping is sometimes the right choice, Vue Formulate is clear that it’s an anti-pattern for your FormulateInput components. Why? Well lots of reasons, but just to name a few:

It makes props unpredictable. Did you remember to pass them all through? Will you update all your HOCs to support newly released features?
Form composition no longer has a unified API. Now you need to start naming, remembering, and implementing custom components.
You can no longer use schema defaults when generating forms.

So let’s avoid this Instant Technical Debt™ and instead use Vue Formulate’s global configuration system. We can define all of the above Tailwind classes when we first register Vue Formulate with Vue.

import Vue from 'vue'
import VueFormulate from 'vue-formulate'

Vue.use(VueFormulate, {
  classes: {
    outer: 'mb-4',
    input: 'border border-gray-400 rounded px-3 py-2 leading-none focus:border-green-500 outline-none border-box w-full mb-1',
    label: 'font-medium text-sm',
    help: 'text-xs mb-1 text-gray-600',
    error: 'text-red-700 text-xs mb-1'
  }
})

That really cleans up our inputs!

<FormulateInput
  type="password"
  name="password"
  label="New password"
  help="Pick a new password, must have at least 1 number."
  validation="^required|min:5,length|matches:/[0-9]/"
  :validation-messages="{
    matches: 'Password must contain at least 1 number.'
  }"
/>
<FormulateInput
  type="password"
  name="password_confirm"
  label="Confirm password"
  help="Just re-type what you entered above"
  validation="^required|confirm"
  validation-name="Password confirmation"
/>

If you viewed the working code in CodeSandbox, you might have noticed we’re still using the input-class prop on the submit button — and to be crystal clear — setting classes with props is not discouraged at all. Generally you’ll want to pre-configure default Tailwind classes for all of your inputs first and then use class props for selective overrides.

In this case, however, the desired styles for our password input is nothing like our submit button. To account for this, we can change our classes.input option to be a function instead of a string allowing us to dynamically apply classes based on contextual information.

import Vue from 'vue'
import VueFormulate from 'vue-formulate'

Vue.use(VueFormulate, {
  classes: {
    outer: 'mb-4',
    input (context) {
      switch (context.classification) {
        case 'button':
          return 'px-4 py-2 rounded bg-green-500 text-white hover:bg-green-600'
        default:
          return 'border border-gray-400 rounded px-3 py-2 leading-none focus:border-green-500 outline-none border-box w-full mb-1'
      }
    },
    label: 'font-medium text-sm',
    help: 'text-xs mb-1 text-gray-600',
    error: 'text-red-700 text-xs mb-1'
  }
})

We can use Vue Formulate’s “classifications” from the provided context object to change which classes are returned. These class functions give efficient, precise, reactive control over the classes you want to generate for any input (in any state). For more details on how to leverage them, checkout the documentation.

Our example form is now fully styled, and our inputs contain no inline classes or class prop declarations at all. Any additional FormulateInput will now also have base styles. Great success!

Oh, the places you’ll go

There’s a lot more to love about the new class system in Vue Formulate that is covered in the documentation. You can easily reset, replace, extend, and manipulate classes on any of your form inputs. You can apply classes based on the type of input, the validation state of an input, or whenever or not a value equals “Adam Wathan”. To top it off, once you’ve landed on a set of utility classes for your project, you can package them up into your own plugin for reuse on other projects or to share with the world.

Dropping the mic

One last demo for the road? Great! Let’s combine Tailwind with another Vue Formulate fan favorite: form generation. With this feature, you can store your forms in a database or CMS and generate them on the fly with a simple schema and 1 line of code. First our schema, which is just a JavaScript object:

const schema = [
  {
    component: "h3",
    class: "text-2xl mb-4",
    children: "Order pizza"
  },
  {
    type: "select",
    label: "Pizza size",
    name: "size",
    placeholder: "Select a size",
    options: {
      small: "Small",
      large: "Large",
      extra_large: "Extra Large"
    },
    validation: "required"
  },
  {
    component: "div",
    class: "flex",
    children: [
      {
        name: "cheese",
        label: "Cheese options",
        type: "checkbox",
        validation: "min:1,length",
        options: {
          mozzarella: "Mozzarella",
          feta: "Feta",
          parmesan: "Parmesan",
          extra: "Extra cheese"
        },
        "outer-class": ["w-1/2"]
      },
      {
        name: "toppings",
        label: "Toppings",
        type: "checkbox",
        validation: "min:2,length",
        options: {
          salami: "Salami",
          prosciutto: "Prosciutto",
          avocado: "Avocado",
          onion: "Onion"
        },
        "outer-class": ["w-1/2"]
      }
    ]
  },
  {
    component: "div",
    class: "flex",
    children: [
      {
        type: "select",
        name: "country_code",
        label: "Code",
        value: "1",
        "outer-class": ["w-1/4 mr-4"],
        options: {
          "1": "+1",
          "49": "+49",
          "55": "+55"
        }
      },
      {
        type: "text",
        label: "Phone number",
        name: "phone",
        inputmode: "numeric",
        pattern: "[0-9]*",
        validation: "matches:/^[0-9-]+$/",
        "outer-class": ["flex-grow"],
        "validation-messages": {
          matches: "Phone number should only include numbers and dashes."
        }
      }
    ]
  },
  {
    type: "submit",
    label: "Order pizza"
  }
];

And our single line of code:

<FormulateForm :schema="schema" />

Presto! Your form is ready.

If you’re intrigued, checkout vueformulate.com. You can follow me, Justin Schroeder, on twitter — as well as my co-maintainer Andrew Boyd.

Introducing Vue Formulate — truly delightful form authoring.

Justin Schroeder — Tue, 19 May 2020 19:38:53 +0000

Vue Formulate has been in the wild for 2 months now, and with the latest release (v2.3) the project has enough momentum to warrant a post from its creator (me, Justin Schroeder) on why it exists, what it does, and where it is going.

The problem with forms

When you’re learning to program, one of the most exciting early progressions is when you make your "Hello World" app interactive by prompting a user for their name. Take those mad I.O. skills to the web and it gets even easier! Just plop an <input> tag into your markup and you’re off the races right? Well...not so fast.

Over the past two months, I've gotten a lot of questions about Vue Formulate. Unsurprisingly one of the most frequent ones is, "What’s wrong with HTML?".

// Detect dark theme var iframe = document.getElementById('tweet-1236275673108557824-882'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1236275673108557824&theme=dark" }

There’s nothing wrong with HTML, of course, just like there was nothing wrong with JavaScript before Vue and React (I know, I know, Vanilla purists’ blood is boiling out there). HTML, React, Vue... it doesn’t matter — the reality is: creating high-quality forms requires a lot of consideration. Labels, help text, validation, inline file uploads, and accessibility are just a few of the items a developer will need to address. This almost inevitably amounts to gobs of copy/paste and boilerplate markup littered throughout your codebase.

There are other issues too. HTML validation, for example, is pretty limited. What if you want to asynchronously check if a username is already taken? What if you want to have well-styled validation errors? What if you want to offer the ability for someone to add more attendees on their ticket purchase? None of these are available to native HTML/React/Vue without considerable effort. Furthermore, maintaining a high level of quality while working on such disparate features becomes secondary to just making the form work. This is fertile ground for a library to help increase developer happiness while pushing quality and accessibility.

Why is Vue Formulate different?

Vue Formulate is far from the first library to address these concerns. Our long-time friends in the community have been fighting these battles for ages: vue-forms, VeeValidate, Vuelidate, and even some UI frameworks like Vuetify aim to help developers author better forms. These are great packages and I wouldn’t discourage you from using them if they’re appropriate for your project. However, Vue Formulate approaches the same problems with two specific objectives:

Improve the developer experience of form authoring.
Increase the quality of forms for end-users.

In order to provide a great developer experience, Vue Formulate needs to focus on being a comprehensive form authoring solution. It cannot just be a validator and doesn’t aspire to become a full UI library. Instead, these guiding principles have resulted in a highly consistent component-first API focused solely on first-class form authoring. To that end, every single input in Vue Formulate is authored with the same component <FormulateInput>, smoothing out the inconsistencies in HTML’s default elements such as <input>, <textarea>, <select> and others. In Vue Formulate you simply tell the <FormulateInput> what type of input it should be — a text input (<FormulateInput type="text">) and a select input (<FormulateInput type="select">) can even be dynamically exchanged by changing the type prop on the fly.

Why is this better you ask? It’s better because it’s easy to remember, fast to compose, and reduces mistakes. We absolutely shouldn’t discount those very real quality of life improvements... but of course that’s not all.

By ensuring all inputs conform to a single component interface we allow for more powerful enhancements like automatic labels, declarative validation, form generation, automatic accessibility attributes, and support for complex custom inputs. This allows a FormulateInput component to maintain an easy-to-use API while being endowed with super powers. Consider how similarly these two inputs are authored using Vue Formulate and yet how different their actual HTML implementation is:

<FormulateInput
  type="email"
  name="email"
  label="Enter your email address"
  help="We’ll send you an email when your ice cream is ready"
  validation="required|email"
/>
<FormulateInput
  type="checkbox"
  name="flavor"
  label="Pick your 2 favorite flavors"
  validation="min:2,length"
  :options="{
   vanilla: 'Vanilla',
   chocolate: 'Chocolate',
   strawberry: ’Strawberry',
   apple: 'Apple'
  }"
/>

Now, notice some of the things we didn’t have to deal with in that example:

<label> elements inputs were automatically generated and linked to the <input> element via auto-generated ids (specify if you want).
Help text was generated in the proper location and the input was linked to it with aria-describedby.
We added real time input validation without having to explicitly output errors.
Multiple checkboxes were rendered with their values linked together.
The labels for the checkboxes automatically adjusted their position.

By consolidating inputs into a single FormulateInput component, we drastically improve the quality of life for developers, and simultaneously create a powerful hook for adding new features and functionality to those inputs. As a bonus, when it comes time to upgrade to Vue 3’s Composition API, Vue Formulate’s component-first API means developers won’t need to refactor anything in their template code.

Neato, but where’s my form?

I’ve explained Vue Formulate’s purpose and its unique approach to inputs, but how about the form itself? Let’s consider the purpose of the native <form> element: to transmit input from a user to a server by aggregating the values of its input elements. What does that look like in Vue Formulate? Pretty much exactly what you would expect:

<template>
  <FormulateForm
    @submit="login"
  >
    <FormulateInput
      type="email"
      name="email"
      label="Email address"
      validation="required|email"
    />
    <FormulateInput
      type="password"
      name="password"
      label="Password"
      validation="required" 
    />
    <FormulateInput label="Login" type="submit" />
  </FormulateForm>
</template>

<script>
export default {
  methods: {
    login (data) {
      /* do something with data when it passes validation:
       * { email: 'zzz@zzz.com', password: 'xyz' }
       */
      alert('Logged in')
    }
  }
}
</script>

Great, so data aggregation works just like a normal form, but there’s not anything “reactive” here yet. Ahh, let’s slap a v-model onto that form — and — presto! We have a fully reactive object with all the data in our form.

<template>
  <FormulateForm
    @submit="login"
    v-model="values"
  >
    <FormulateInput
      type="email"
      name="email"
      label="Email address"
      validation="required|email"
    />
    <FormulateInput
      type="password"
      name="password"
      label="Password"
      validation="required" 
    />
    <FormulateInput label="Login" type="submit" />
    <pre>{{ values }}</pre>
  </FormulateForm>
</template>

<script>
export default {
  data () {
   return {
     values: {}
   }
  },
  methods: {
    login (data) {
      /* do something with data:
       * { email: 'zzz@zzz.com', password: 'xyz' }
       */
      alert('Logged in')
    }
  }
}
</script>

And yes, v-model means its two-way data binding. You can write values into any input in your form by changing properties on a single object. Aim small, miss small — so let’s shoot for making “it just works” the default developer experience.

Slots, custom inputs, plugins — oh my!

This article is just an introduction — not a substitute for the full documentation — but it wouldn’t be fair to leave out some of my favorite extensibility features. Form authoring tools need to be flexible — there’s an edge case for everything right? Vue Formulate’s highly opinionated component-first API may seem at odds with flexibility, but in reality that consistent API is the core behind a highly flexible architecture.

Slots are a great example of how consistency pays the bills. Central to Vue Formulate’s inputs is a comprehensive context object that dictates virtually everything about an input. The model, validation errors, label value, help text, and lots (lots!) more are members of this object. Because every input has a consistent API, every input has a consistent context object.

While the flexibility to use scoped slots is great — they can hurt the consistency and readability of our form’s code. To address this, Vue Formulate also includes the ability to override the default value of every slot. We call these “Slot Components”, and they’re fundamental to maintaining a clean consistent authoring API. Want to add that example tooltip to every label? No problem. You can replace the default value in the label slot on every input in your project without having to use scoped slots or wrap your components in your templates at all.

If you decide you’re better off creating your own custom input type, you can do that too! Custom inputs keep form authoring buttery-smooth, just pick your own input type and register it with Vue Formulate. Your custom input will get validation, labels, help text, model binding, and more out of the box. Even better, once you’ve created a custom input you can easily turn it into a plugin to share with your team members or the larger community.

Where you go is where I wanna be...

In the excellent Honeypot Vue documentary, Thorsten Lünborg summed up what I consider to be the number one reasons for Vue’s spectacular success:

The focus in Vue.js from the get-go was always that the framework is more than just the code. It’s not like, “this is the library, this is the documentation, of how it works, and now you solve the rest.”

In essence, the Vue core team was willing to go where developers were feeling pain points the most. As a result they have created a framework that isn’t just elegant — it’s delightful for real-world developers to use. Vue Formulate maintains this spirit; to meet developer’s pain points with delightful form authoring solutions. We believe we’ve now paved the road for 90% of users — but if your road is less traveled and you find yourself at an edge case — please shout it out. We're listening.

If you’re intrigued, checkout vueformulate.com. You can follow me, Justin Schroeder, on twitter — as well as my co-maintainer Andrew Boyd.

DEV Community: Justin Schroeder

Shakespeare makes you a better engineer.

Building Bod.Coach: LLM Lessons Learned The Hard Way.

Lesson 1: LLMs have a left and right brain.

Solution?

Lesson 2: LLMs are always dying

Solution?

Lesson 3: LLMs have analysis paralysis

Solution?

Lesson 4: LLMs are Stupid or Stupid Expensive

Solution?

Lesson 5: Build Your Own LLM Tooling

Conclusion

Introducing: KickStart — a form builder for developers.

Rolldown: why it matters

The landscape:

The problem:

The solution:

Thanks:

Introducing Tempo • A new date library for JavaScript (and TypeScript).

Intl.DateTimeFormat styles

Parse what you format

Timezones out of the box

Death to the builder pattern

Stop the plugins

Better docs

Why not?

Highlights

Convert a dateStyle to tokens

Using timezones

Token ranges

Get building

I’m a software engineer, what does AI mean for me?

The ticking clock

The match

The legacy of replacement

New roles and old ones?

How far is that horizon?

What will I do?

Introducing AutoAnimate — add motion to your apps with a single line of code.

Introducing FormKit: A Vue 3 form building framework

What can it do?

Single component

No more boilerplate

Validation

Form state

Model binding

Plugins

Schema

What’s next

Sustainability

So much more...

Flow State: 10 Practical Tips for Getting In The Zone

Know the basics

10 Practical Tips

There’s more to work than flow

Better uploads with Vue Formulate, S3, and Lambda

Ye olde way

There's another way

1. Setup an AWS Account

2. Create an S3 Storage Bucket

3. Configure CORS for the bucket

4. Create an IAM role

5. Create the Lambda and API

6. Add the function code

7. Configure the API Gateway

8. Test your endpoint!

9. The uploader function

s3-uploader-plugin.js

main.js

A working example

Tailwind + Vue Formulate = ❤️

Using Tailwind with Vue Formulate

Missions aligned

Defaults matter

Defining your classes (props!)

Defining your classes (base classes!)

Oh, the places you’ll go

Dropping the mic

Introducing Vue Formulate — truly delightful form authoring.

`Intl.DateTimeFormat` styles

Convert a `dateStyle` to tokens