DEV Community: Ganesh Deshmukh

AI Can Write Frontend Code — What Should Developers Still Know?

Ganesh Deshmukh — Mon, 21 Sep 2026 06:21:03 +0000

A few years ago, writing frontend code meant spending a lot of time typing HTML, CSS, and JavaScript yourself.

Today, AI can generate a complete component in seconds.

You can ask:

"Create a responsive navbar in React with a mobile menu."

And you may get working code almost immediately.

So this raises an important question:

If AI can write frontend code, what does a frontend developer need to know?

I don't think the answer is "nothing."

In fact, I think understanding the fundamentals is becoming even more important.

AI Can Write Code. But Code Is Not the Whole Job.

A frontend developer's job isn't simply:

Requirement
    ↓
Write code

Real projects look more like:

Business requirement
        ↓
Understand UX
        ↓
Choose architecture
        ↓
Build UI
        ↓
Connect APIs
        ↓
Handle edge cases
        ↓
Accessibility
        ↓
Performance
        ↓
Testing
        ↓
Debugging
        ↓
Deployment

AI can help with many of these steps.

But someone still needs to understand what should actually be built.

1. HTML Still Matters

AI can generate HTML very quickly.

But can you tell whether this is appropriate?

<div onclick="submitForm()">Submit</div>

It may visually look like a button.

But semantically, a real button is usually better:

<button type="submit">
  Submit
</button>

Understanding semantic HTML helps with:

Accessibility
Keyboard navigation
SEO
Browser behavior
Maintainability

You don't want to blindly accept generated markup.

You need to know what good HTML looks like.

2. CSS Knowledge Is Still Important

AI can generate CSS.

But real projects rarely say:

"Just make it look nice."

You may get requirements like:

Match the Figma design
Support mobile, tablet, and desktop
Handle long text
Support different content lengths
Maintain consistent spacing
Work across browsers
Avoid layout shifts

You need to understand things like:

Flexbox
Grid
Positioning
Specificity
Cascade
Responsive design
Container queries
Media queries
Typography
Animations

Otherwise, you may end up accepting CSS that works for one screenshot but breaks everywhere else.

3. JavaScript Fundamentals Matter Even More

AI can generate:

const handleClick = () => {
  // ...
};

But what happens when the code contains:

useEffect(() => {
  fetchData();
}, []);

Do you understand:

Why the dependency array is empty?
When the effect runs?
What happens during re-render?
What happens if the request fails?
What happens if the component unmounts?
Can the request create a race condition?

You don't need to write every line manually.

But you should be able to read and reason about the code.

4. You Still Need to Understand the Browser

This is one of the biggest areas developers shouldn't ignore.

You should understand:

HTML
 ↓
DOM
 ↓
CSSOM
 ↓
Render
 ↓
Layout
 ↓
Paint
 ↓
Composite

You should also understand:

HTTP
Cookies
Local storage
CORS
Browser caching
Network requests
Events
DOM
Rendering
Web APIs

Why?

Because when something breaks, you need to know where to look.

For example:

"The API works in Postman but doesn't work in the browser."

AI might suggest ten possible solutions.

A developer who understands CORS can immediately investigate the browser's security policy and network response.

5. Accessibility Cannot Be an Afterthought

AI can generate a beautiful UI.

But accessibility requires more than visual output.

You should know:

Semantic HTML
Keyboard navigation
Focus management
ARIA
Color contrast
Form labels
Screen-reader behavior
Accessible error messages

For example:

<input type="text" placeholder="Email">

may look fine.

But a properly labelled form control is generally preferable:

<label for="email">
  Email
</label>

<input
  id="email"
  type="email"
  name="email"
/>

AI can help generate accessible code.

But developers still need to verify it.

6. Performance Still Needs Human Thinking

AI can generate code that works.

That doesn't mean the code is efficient.

For example, a page might have:

10 large images
15 JavaScript libraries
Multiple API requests
Heavy animations
Large fonts
Unused CSS

Everything may technically work.

But the user experience may be poor.

Frontend developers still need to understand:

LCP
CLS
INP
Image optimization
Lazy loading
Code splitting
Caching
Bundle size
Critical rendering path

The goal isn't:

"Make the code work."

The goal is:

"Make the website work well for real users."

7. Architecture Is More Than Generating Components

Imagine you ask AI:

"Create a React product page."

It might generate:

ProductPage.jsx

But a real application may need:

src/
├── components/
├── pages/
├── hooks/
├── services/
├── api/
├── utils/
├── features/
├── stores/
└── types/

Where should the API logic live?

Should this data be global state?

Should it be server state?

Should you use React Query?

Should the component fetch the data directly?

Should the page be server-rendered?

These aren't simply coding questions.

They're architecture decisions.

8. Debugging Is Still a Developer Skill

This may become even more important in an AI-assisted workflow.

Suppose AI gives you code that looks correct.

But the application throws:

Cannot read properties of undefined

What do you do?

You need to understand:

Stack trace
↓
Error location
↓
Data flow
↓
State
↓
Network request
↓
Actual root cause

AI can help investigate the problem.

But you still need enough knowledge to verify its suggestions.

Otherwise, you can end up fixing one error and creating another.

9. Security Still Matters

AI-generated code can contain mistakes.

Frontend developers should understand common issues such as:

XSS
CSRF
Unsafe HTML rendering
Exposing secrets
Insecure authentication handling
Sensitive data in local storage
Dependency vulnerabilities

For example:

element.innerHTML = userInput;

should immediately make you think about whether untrusted input is being inserted into the DOM.

AI can write the code.

You are still responsible for understanding what the code does.

10. Testing Becomes More Important

If AI allows developers to produce code faster, we also need reliable ways to verify that code.

Testing can include:

Unit tests
Integration tests
Component tests
End-to-end tests
Accessibility testing
Visual testing
Performance testing

For a button, you don't only want to know:

"Does it look correct?"

You may also want to check:

Can I reach it using the keyboard?
Does it work after multiple clicks?
Does it show the correct loading state?
Does it handle API failure?
Does it work on mobile?

11. Understanding the Requirement Is a Major Skill

This is something AI cannot magically solve for you.

A client might say:

"I want a faster checkout."

What does that actually mean?

Maybe they mean:

Fewer form fields
Faster API response
Better mobile UX
Fewer checkout steps
Better error messages
Faster page loading

Before writing code, someone needs to understand the actual problem.

Good developers don't immediately start coding.

They ask questions.

12. AI Changes How We Code

I don't think AI means developers should stop learning syntax.

But the workflow can change.

Instead of:

Think
 ↓
Search Google
 ↓
Read documentation
 ↓
Write code
 ↓
Debug

It can become:

Understand problem
 ↓
Ask AI for an approach
 ↓
Review the generated code
 ↓
Test it
 ↓
Modify it
 ↓
Debug
 ↓
Verify

The developer becomes more of a reviewer, problem solver, and system designer.

13. What Should a Frontend Developer Learn?

If you're starting or growing as a frontend developer, I would still focus on these fundamentals:

HTML

Semantic HTML
Forms
Accessibility
SEO basics

CSS

Box model
Flexbox
Grid
Responsive design
Animations
Modern CSS

JavaScript

Variables
Functions
Scope
Closures
Promises
Async/await
DOM
Events
Modules
Error handling

Browser

HTTP
Cookies
Storage
Caching
CORS
Rendering
DevTools
Network debugging

React or another framework

Components
Props
State
Hooks
Rendering
Performance
Data fetching
Component architecture

Engineering

Git
Testing
Accessibility
Performance
Security
Code review
Deployment

And now add one more skill:

AI-assisted development

14. The New Skill: Knowing What to Ask AI

There is also a new skill developers are developing: giving AI useful context.

Instead of:

"Create a React component."

You can provide:

Create a reusable React product card.

Requirements:
- React
- TypeScript
- Accessible HTML
- Mobile responsive
- No unnecessary dependencies
- Product data comes from props
- Handle missing image
- Handle long product names
- Use semantic HTML

The better the problem definition, the more useful the output becomes.

But even then, the developer needs to review the result.

15. Don't Become Dependent on AI

One simple test I like is:

If the AI disappeared tomorrow, could I debug my application?

You don't need to memorize every API.

You don't need to write everything from scratch.

But you should understand enough to:

Read code
Debug code
Review code
Explain code
Change code
Identify bad approaches
Make architectural decisions

That's a much stronger position than simply being able to generate code.

Final Thought

AI is changing frontend development.

There's no reason to ignore it.

Use it.

Let it help you:

Generate boilerplate
Explore solutions
Explain unfamiliar code
Create tests
Find bugs
Refactor code
Learn new APIs
Speed up repetitive work

But don't outsource your understanding.

A developer who can write 500 lines of code manually isn't necessarily more valuable than someone who can generate those 500 lines in seconds.

The important skill is knowing:

What should be built, why it should be built that way, whether the generated code is correct, and how it will behave in the real world.

AI can help write the code.

Developers still need to understand the web.

Do We Really Need React for Every Website?

Ganesh Deshmukh — Mon, 21 Sep 2026 06:13:30 +0000

If you're a frontend developer today, it's easy to feel like every new website should be built with React.

Need a landing page? React.

Need a portfolio? React.

Need a company website? React.

Need a simple blog? React.

But there is one question we don't always ask:

Do we actually need React for every website?

The short answer is no.

React is a powerful tool, but like any tool, it makes more sense when it solves a problem you actually have.

What Problem Does React Solve?

React is useful when the UI becomes interactive and complex.

For example, imagine an application with:

Product filters
Shopping cart
User authentication
Notifications
Modals
Tabs
Search
Real-time updates
Complex forms
Shared application state

Managing all of this with manual DOM manipulation can become difficult.

React gives us a component-based approach.

function ProductCard({ product }) {
  return (
    <article>
      <h2>{product.name}</h2>
      <p>{product.price}</p>
      <button>Add to Cart</button>
    </article>
  );
}

The UI is broken into reusable components.

That becomes valuable as the application grows.

But What If My Website Is Simple?

Let's say you're building a website for a small business.

It has:

Home
About
Services
Projects
Contact

Maybe there are a few animations, a contact form, and a mobile menu.

Do you need React?

Probably not.

You could build it with:

HTML
CSS
JavaScript

And potentially use a server-rendered CMS or backend if required.

The browser already knows how to render HTML.

You don't need a JavaScript framework just to display a heading and an image.

The Cost of Adding React

React itself isn't necessarily a problem.

The question is what additional complexity you're introducing.

A React project may involve:

React
↓
Package manager
↓
Build tool
↓
Dependencies
↓
Components
↓
State management
↓
Routing
↓
Data fetching
↓
Deployment configuration

For a large application, this complexity can be justified.

For a five-page static website, it might be unnecessary.

This doesn't mean React is bad.

It means architecture should match the problem.

Example 1: Portfolio Website

Imagine a developer portfolio:

Home
About
Skills
Projects
Contact

Most of the content doesn't change frequently.

You could build it with plain HTML, CSS, and JavaScript.

Benefits:

Simple architecture
Very little JavaScript
Easy to deploy
Easy to maintain
Fast initial rendering

Could React build it?

Absolutely.

But being able to use React doesn't automatically mean you should.

Example 2: E-commerce Website

Now consider a large e-commerce application.

You might have:

Product Listing
      ↓
Filters
      ↓
Product Details
      ↓
Cart
      ↓
Checkout
      ↓
User Account

The UI has lots of state.

For example:

Selected filters
Cart items
Quantity
User authentication
Loading states
Errors
Product data
Search results

Here, a component-based architecture can be very useful.

React can help organize this complexity.

Example 3: Dashboard

Consider an admin dashboard.

Dashboard
├── Sidebar
├── Header
├── Statistics
├── Charts
├── Tables
├── Filters
└── Notifications

The user may:

Filter data
Sort tables
Open modals
Change settings
Update records
Navigate between sections
Fetch data from APIs

This is a very different problem from a static marketing website.

React can be a natural fit here.

What About a Landing Page?

This is where things become interesting.

A landing page might contain:

Hero section
Animations
Testimonials
Pricing
FAQ
Lead form
Scroll interactions

You don't need React just because the page has animations.

CSS can handle many animations.

JavaScript can handle interactions.

Libraries such as GSAP can handle more advanced animations.

So the question shouldn't be:

"Is the website interactive?"

Almost every modern website is interactive.

The better question is:

"How complex is the interaction and UI state?"

React vs Plain JavaScript

Here's a simple way to think about it.

Requirement	Plain JS	React
Static pages	✅	Usually unnecessary
Simple interactions	✅	Often unnecessary
Small landing page	✅	Optional
Simple portfolio	✅	Optional
Large dashboard	Possible	Useful
Complex forms	Possible	Useful
Large SPA	Difficult to organize	Useful
Complex shared state	Possible	Useful
Highly interactive application	Possible	Often useful

The important word here is possible.

Almost anything can be built with vanilla JavaScript.

The question is how maintainable the solution will be.

But There Is Another Side

React can also be useful even for smaller websites if your team already has:

A React design system
Reusable components
Existing React infrastructure
Shared frontend libraries
Developers experienced with React
A larger application planned for the future

For example, if a marketing website is only the first part of a larger product, choosing React may reduce the cost of switching architectures later.

So context matters.

Don't Confuse React With Modern Web Development

One thing I noticed while learning frontend development is that developers sometimes associate:

React = Modern
Vanilla JS = Old

That's not correct.

Modern web development also includes:

Semantic HTML
Modern CSS
Responsive design
Accessibility
Performance optimization
Web APIs
Progressive enhancement
Good UX
SEO

You can build an extremely modern website without React.

You can also build a poorly designed website with React.

The framework doesn't automatically determine the quality of the website.

What About SEO?

SEO is another reason this discussion becomes more complicated.

A simple content-heavy website doesn't automatically need React.

HTML itself is excellent for content.

For applications that need JavaScript rendering, frameworks and rendering strategies such as SSR or SSG can help.

But it's important to understand that:

React itself is not an SEO strategy.

You still need to think about:

Semantic HTML
Metadata
Structured content
Page performance
Crawlability
Accessibility
URLs
Internal linking

Performance Matters Too

Adding React doesn't automatically make a website slow.

But adding unnecessary JavaScript can create unnecessary work for the browser.

For a simple page, imagine sending:

HTML
CSS
JavaScript
React
Dependencies
Application code

when the browser could have rendered most of the page directly from HTML and CSS.

That's worth thinking about.

At the same time, for a complex application, React can provide an organized architecture that makes the overall product easier to develop and maintain.

Again:

It depends on the problem.

The Better Question

Instead of asking:

"Should I use React?"

I think we should ask:

1. How interactive is the application?

2. How much UI state do I need?

3. How large will the application become?

4. Does the team already have a React ecosystem?

5. How important are initial performance and JavaScript size?

6. Does the project need a component system?

7. Will the application communicate heavily with APIs?

8. How frequently will the UI change?

These questions give you a better starting point than simply choosing a popular framework.

My Simple Rule

I like to think about it this way:

Simple website
    ↓
Start simple
    ↓
HTML + CSS + JavaScript

For a more complex application:

Complex UI
    ↓
Many components
    ↓
Lots of state
    ↓
Frequent UI updates
    ↓
Consider React or another framework

The framework should solve a problem.

Don't create a problem just to justify using the framework.

Final Thought

React is not the enemy of simple websites.

And vanilla JavaScript isn't the enemy of modern development.

Both have their place.

The real skill isn't knowing how to use React.

The real skill is knowing when you don't need it.

Before starting your next project, don't ask:

"What framework is trending?"

Ask:

"What is the simplest architecture that can solve this problem well?"

Sometimes the answer will be React.

Sometimes it won't.

And that's perfectly fine.

From PHP + jQuery to React: How Web Development Changed

Ganesh Deshmukh — Mon, 21 Sep 2026 06:07:18 +0000

If you started web development with React, you might wonder:

What did developers use before React?

Before React became popular, a lot of websites were built using PHP, HTML, CSS, JavaScript, jQuery, and MySQL.

I’ve worked with both traditional and modern approaches, and one thing became clear to me:

Modern frontend development didn't replace the old web overnight. It evolved from problems developers were already trying to solve.

Let's look at that journey.

1. The PHP + MySQL Era

A common architecture looked like this:

Browser
   ↓
PHP Server
   ↓
MySQL Database
   ↓
PHP generates HTML
   ↓
Browser

For example, a product page might have PHP code like:

<?php
$product = getProduct($_GET['id']);
?>

<h1><?php echo $product['name']; ?></h1>
<p><?php echo $product['price']; ?></p>

The PHP code ran on the server.

The browser received the final HTML:

<h1>iPhone</h1>
<p>$999</p>

The browser didn't know that PHP generated it.

This approach was simple and worked very well for many types of websites.

2. But What Happened When the User Clicked Something?

Imagine a user opens:

/products

and clicks a product.

The browser requests:

/products/123

The server then:

Receives the request
Gets the product ID
Queries the database
Generates HTML
Sends the response
Browser loads the new page

Something like:

Click
  ↓
HTTP Request
  ↓
PHP
  ↓
Database
  ↓
HTML
  ↓
Browser

For a normal website, this was perfectly fine.

But as websites became more interactive, developers wanted a better experience.

3. JavaScript Started Taking More Responsibility

JavaScript allowed developers to change the page without asking the server to generate an entirely new page.

For example:

document.querySelector("#button")
  .addEventListener("click", function () {
    document.querySelector("#message").textContent = "Hello!";
  });

Now the browser could update the UI itself.

This sounds normal today, but it was an important shift.

The browser wasn't just displaying HTML anymore.

It was becoming responsible for part of the application.

4. Then jQuery Became Popular

Writing browser-compatible JavaScript wasn't always pleasant.

jQuery made common tasks easier.

Instead of writing:

document.querySelector("#button")
  .addEventListener("click", function () {
    document.querySelector("#message").textContent = "Hello!";
  });

developers could write:

$("#button").click(function () {
    $("#message").text("Hello!");
});

jQuery was heavily used for:

DOM manipulation
Events
AJAX requests
Animations
Form handling
Cross-browser compatibility

A typical project could look like:

HTML
CSS
jQuery
PHP
MySQL

And honestly, many of these websites worked very well.

5. AJAX Changed the User Experience

One of the biggest changes was AJAX.

Instead of:

User action
   ↓
Full page reload

developers could do:

User action
   ↓
JavaScript
   ↓
AJAX request
   ↓
Server
   ↓
Response
   ↓
Update part of the page

For example:

$.ajax({
    url: "/products",
    success: function(data) {
        $("#products").html(data);
    }
});

Now only part of the page could change.

This made websites feel much more interactive.

6. But There Was a Problem

As applications became larger, frontend JavaScript became harder to maintain.

Imagine having:

Header
Menu
Modal
Shopping Cart
Filters
Product List
Notifications
User Profile
Forms
Tabs

And each component is changing the DOM using different JavaScript functions.

You might end up with code like:

$("#cart").html(...);

$("#menu").show();

$("#modal").hide();

$("#products").html(...);

$("#notification").text(...);

It can work.

But as the application grows, keeping track of what changed, when it changed, and why it changed becomes difficult.

This was one of the problems modern frontend frameworks tried to address.

7. Enter React

React introduced a different way of thinking about UI.

Instead of manually telling the browser:

"Change this element."

You describe what the UI should look like based on the current state.

For example:

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      {count}
    </button>
  );
}

When the state changes, React takes care of updating the UI.

The developer mainly thinks about:

State
  ↓
UI

rather than manually managing every DOM operation.

8. Components Changed How We Build UI

Traditional development often started from pages.

React encouraged developers to think in components.

For example:

App
├── Header
├── Navigation
├── ProductList
│   ├── ProductCard
│   ├── ProductCard
│   └── ProductCard
├── Cart
└── Footer

A reusable component might look like:

function ProductCard({ product }) {
  return (
    <article>
      <h2>{product.name}</h2>
      <p>{product.price}</p>
    </article>
  );
}

Now the same component can be reused with different data.

This became particularly useful as applications became larger.

9. From Pages to Applications

The biggest change wasn't simply:

jQuery → React

The bigger change was how we thought about web applications.

Traditional approach

Browser
   ↓
Server
   ↓
HTML
   ↓
Browser

Modern application approach

React Application
       ↓
      API
       ↓
Backend
       ↓
Database

The frontend and backend could now be developed more independently.

The backend could provide JSON:

{
  "name": "iPhone",
  "price": 999
}

And the frontend could decide how to display it.

10. What Happened to PHP?

PHP didn't disappear.

In fact, PHP is still widely used.

The difference is that there are now many different ways to build a web application.

For example:

PHP + MySQL

can still be a great choice for a traditional website.

Or you might have:

React
   ↓
REST API
   ↓
PHP / Node.js / .NET / Java
   ↓
Database

The frontend doesn't necessarily care what language the backend uses.

It communicates through the API.

11. What Happened to jQuery?

jQuery also didn't suddenly become useless.

There are still many existing websites and applications that use it.

But modern JavaScript now provides many features that previously made libraries like jQuery very useful.

For example:

document.querySelector()

can handle DOM selection.

And:

fetch("/api/products")

can make HTTP requests.

Modern browser APIs, better JavaScript support, and frontend frameworks reduced the need for jQuery in many new projects.

12. The Evolution in One Picture

You can roughly think about the evolution like this:

Traditional Web
      ↓
HTML + CSS + PHP
      ↓
JavaScript
      ↓
jQuery
      ↓
AJAX
      ↓
More Interactive Applications
      ↓
Frontend Frameworks
      ↓
React / Vue / Angular
      ↓
API-based Applications
      ↓
Modern Full-Stack Applications

Of course, real-world web development didn't follow one single straight line.

Different technologies evolved at the same time.

But this gives us a useful picture of the direction.

13. Does Modern Always Mean Better?

Not necessarily.

This is something developers sometimes forget.

If you need a simple marketing website with a few pages, using a large frontend application architecture may add unnecessary complexity.

A simple server-rendered website can still be a good solution.

On the other hand, if you're building a complex application with lots of interactive UI and shared state, a component-based frontend architecture can make development easier to organize.

The right technology depends on the problem.

14. What I Learned From This Evolution

For me, the most interesting part isn't that React replaced jQuery.

It's that the responsibility gradually moved toward the browser.

We went from:

Server generates most of the page

to:

Browser handles more of the application

And now we're seeing another shift with technologies such as server components, server-side rendering, static generation, edge computing, and full-stack frameworks.

So web development isn't finished evolving.

It's still changing.

Final Thought

If you're learning React today, don't only learn React.

Try to understand what problem React was created to solve.

Learn:

How HTTP requests work
How server-side rendering works
How PHP applications worked
How the DOM works
How AJAX works
How APIs work
How JavaScript interacts with the browser
Why component-based architecture became useful

Once you understand the journey, many modern frontend concepts become easier to understand.

The best way to understand the modern web is sometimes to look at the old web first.