A Frontend Developer's Take On AI

AI is shaking things up in frontend development, changing the way developers build and improve web applications. AI can of course add interesting benefits to product design and development - automating mundane tasks or offering alternative design patterns. But it can also divide the community. Some believe it’s ushering in a new era of smart, responsive, and user-friendly web applications, while others are concerned about the dependence on AI, potential biases, ethical implications, overall quality and accuracy, and security vulnerabilities to boot.

As Studio’s lead frontend developer, I am cautiously optimistic about AI. I already utilize OpenAI regularly: first with VSCode and GitHub’s Copilot code completion extension, and second by leveraging ChatGPT to convert UX components from one technology to another. My experience so far has been using ChatGPT for internal UX prototypes that I build on Codepen or CodeSandbox, while I've been using Copilot for around 2 years both when it was free and now behind a subscription for both commercial and personal projects.

This won’t be another how-to get started with AI, but rather a reflection on my frontend experience leveraging AI.

VSCode & Github Copilot - Code Completion Tools

In the past, traditional code completion tools relied on developers to provide direct code-related input, such as variable names and functions, without the use of natural language descriptions. These tools were integrated into IDEs over the last 2 decades or so, but they often relied on small datasets and heuristics to offer suggestions, which were limited in scope and context.

However, tools like Emmet, which include code completion as just one feature of their toolkit, still hold value. Whether they are more useful than AI depends on your approach to extracting designs that might be in Figma, in browser, or built from static images (I feel your pain). Like mentioned above, this is code completion and not exported code generation from uploading or inputting files.

CSS, HTML & JS

My overall experience is that HTML & CSS code completion isn’t strong enough yet, but has glimpses of greatness. After a recent update to Copilot, it can now access project workspaces. This has given me a false sense of security in its understanding of a project’s overall context. I find myself more often deleting suggested code after accidentally hitting tab when a suggestion is provided. That finger that presses that tab key is awfully itchy.

CSS

I’m under the impression that it has access to variables / mixins / functions that are recurring patterns throughout the code, so it will get you 50% of the way for recurring, mostly typographical, elements. If you’re setting up your typographical elements for a design system, it won’t get this right immediately. For those small modifiers it can provide all the necessary properties but still requires backtracking to adjust the values you actually need.

Productivity may have been marginally improved given the above, but experienced developers can write those properties out just as quickly without the backtrack or need to wait for an API to catch up. It rightly assumes that you want to reuse properties from other components in your library, but this can lead to extra scruff if those properties have already been componentized specifically. This can be time-consuming when working on a new isolated component. Just be cautious on hitting that tab/enter key.

Some additional thoughts:

Useful for recurring properties like flex/grid and their related properties like align-items/grid-template-columns. However, productivity isn't significantly better than writing it yourself as it’s highly unlikely it’ll get it spot on without - again - the context of seeing the design.
Copilot won’t catch cross browser compatibility issues. While Figma-generated CSS is exactly what you want the design to look like, it's worth noting that Figma CSS may not fully work with all browsers or will work but have performance bottlenecks. Looking at you, Safari on MacOS and iOS.

HTML & JS

It seems that code completion for HTML is generally better than it is for CSS, though the effectiveness varies depending on your tech stack. When it comes to plain HTML, stick with Emmet (or your IDE’s version of it), it’s so much faster and it gets all class name methodologies, css utilities/modifiers and attributes right the first time.

It truly shines with JS/TS and JSX/TSX, largely due to the extra steps these types require. Initially, I wouldn’t use it when setting up a JSX/TSX component, using abbreviated shorthand commands that come from great extensions to generate boilerplate can be faster for the initial setup than the time it takes to input a query, receive a response from Copilot, and accept that response.

However the part that it really excels at is when you’ve happily finished writing your components HTML-like syntax, adding the accompanying functions or states/hooks is a blast. When writing the JSDoc or a comment first, it will grab the context and more often than not can be spot on with the functionality, give or take a few odd values or misspelled variables it didn’t know you had already created. Writing JSDoc or comments always tend to be an afterthought that a developer tacks on when preparing a PR for review - here it’s pushing me to write this first so I do less later. Takes me back to writing JSDoc for Google’s closure compiler without the constant failing.

It’s worth noting that if you’re not providing context in comments/JSDoc first then setting up functions, it is more often wrong as it misses the execution you want and wastes time generating responses. If you’re not 100% sure about a library for example, it can take you down a rabbit hole which may be distracting for a junior developer.

Here are some other observations I've made:

The suggestions for unordered lists can be wild in HTML and CSS. “Did you want extra list items or pseudo elements in your sandwich? No?”.

Recreating components from one tech library to another using ChatGPT

Using ChatGPT to recreate JavaScript components from one technology library to another can be a highly effective approach, particularly when dealing with animations. I like to scope around for new emerging libraries that I’ve not used before or not currently using in a tech stack and recreate those components in a sandbox or on Codepen to something I’m more familiar with. For instance, converting animations from AnimeJS to GSAP can be streamlined with the help of ChatGPT.

Below is an example of using ChatGPT to recreate a component from the Aceternity UI library (if you haven’t checked them out, highly recommend).The example converts AnimeJS and Tailwind to GSAP with plain HTML & CSS.

As you can see from the above example, while basic animations can be easily translated, the process requires providing extensive context. Simply querying the model to "convert this AnimeJS component using Tailwind to vanilla GSAP, HTML and JS" won’t yield the instant result you assume it can deliver. You need to detail the specific animations and the desired outcomes for more accurate assistance with plenty of back and forth dialog.

When it comes to complex animations, ChatGPT can get you about 50-75% of the way there, assuming you have a good understanding of the library you are comfortable using. The model will drop specifics, so you must be able to read and understand the code you’re converting. It provides a good starting point and can handle much of the boilerplate and basic setup, but fine-tuning and final adjustments will be necessary. This hands-on involvement is crucial, especially for intricate animations where the nuances of each library’s capabilities and syntax come into play. Here’s a link to my conversation with ChatGPT to get the above.

Using ChatGPT for this purpose is excellent for prototyping and expanding your own knowledge. It allows you to explore different approaches and techniques within a new library, giving you a solid foundation to build upon. However, for client work, it’s less ideal. The need to experiment with and refine contextual prompts can be time-consuming. Ensuring the model stays on the right track requires careful guidance and may result in wasted time that could be better spent on direct implementation. Therefore, while ChatGPT is a valuable tool for learning and initial development, it’s best supplemented with your expertise for polished, user-ready products.

Conclusion

GitHub Copilot and ChatGPT are intriguing tools that significantly aid learning, yet they require a serious amount of contextual input and experience to discern whether their suggestions are correct—a common theme across various practices beyond engineering. While these tools can propose useful code snippets, they may also recommend poor practices that overlook essential aspects like methodology, brevity, or readability. Experienced developers can recognize and avoid these "code smells" or bad practices, but these tools won't elevate a junior developer’s expertise.

In many cases, the guidance provided by Copilot and ChatGPT can lead novices astray, wasting valuable time and potentially causing confusion without fostering a deep understanding of the code. For senior developers, these tools can sometimes enhance development speed, but only if the prompts are crafted correctly and contextually. Crafting such prompts can itself be time-consuming and may detract from the overall efficiency.

While these tools can serve as a helpful pair programmer, particularly when a senior developer is unavailable, they have limitations. They seem to handle components under 100 lines of code well, but for more complex tasks, they often miss critical details, necessitating frequent corrections and diminishing their utility. Despite these shortcomings, these tools can still certainly be enjoyable to use. Even when they suggest flawed or suboptimal code, they sometimes introduce new ideas or approaches that enhance my technical understanding of a library or language. Through practice, I've learned when I should seek their assistance and when to proceed independently.

This is an ongoing conversation and I’d love to hear your thoughts as the tech advances. Feel free to reach me at chris@buildwithstudio.com

Written by Chris Tough, a frontend lead at Studio, this post summarizes the state of AI platforms as reviewed by their impact and usefulness for frontend developers as of July 2024. AI is changing quickly, and if you're looking for the latest insight, subscribe to Studio Bytes or contact us.

A Frontend Developer's Take On AI

VSCode & Github Copilot - Code Completion Tools

CSS, HTML & JS

CSS

HTML & JS

Recreating components from one tech library to another using ChatGPT

Conclusion

How to Build the Best App Onboarding

Implementing a Digital Reward System

The Guide to Submitting to Apple's App Store

Guide to Building an MVP Shopify App

How to Build a Shoppable Video Strategy