DEV Community: OE Haruki

React vs Vue: A Comparative Guide to Basic Syntax

OE Haruki — Tue, 11 Feb 2025 10:42:58 +0000

1. Introduction

React and Vue.js are both highly popular libraries in frontend development. This article compares their basic syntax to help you understand their differences and choose the right tool for your project.

2. Component Creation

Definition and Characteristics

Vue.js

Components are written in a file format consisting of <template>, <script>, and <style> sections. This clear separation of concerns improves code organization and development efficiency. Vue.js components can exchange data through parent-child relationships.

React

Components are defined as functions or classes using JSX for UI description. JSX is a syntax that combines JavaScript and HTML, making UI construction more straightforward. React components exchange data through props.

Code Samples

Vue.js

<template>
  <div>Hello, Vue!</div>
</template>
<script>
export default {
  name: "MyComponent"
}
</script>
<style scoped>
/* Styles go here */
</style>

React

function MyComponent() {
  return <div>Hello, React!</div>;
}

3. State Management

Definition and Characteristics

Vue.js

Uses the data property to manage reactive data. The data property manages component state, and when it changes, the UI automatically updates. Vue.js's reactive system detects data changes and automatically updates the UI.

React

Uses the state object, and in function components, utilizes the useState hook. The useState hook simplifies state management and updates. React's state management requires explicit state updates but makes state management more transparent.

Code Samples

Vue.js

<script>
export default {
  data() {
    return { count: 0 };
  }
}
</script>

React

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

4. Lifecycle Methods

Definition and Characteristics

Vue.js

Uses lifecycle methods like beforeCreate, created, beforeMount, mounted, beforeUpdate, updated, beforeDestroy, and destroyed. These methods execute at different stages of a component's lifecycle to handle initialization, cleanup, and updates.

React

Class components use methods like componentDidMount, componentDidUpdate, and componentWillUnmount. Function components use the useEffect hook. The useEffect hook manages side effects and executes based on component lifecycle.

Code Samples

Vue.js

<script>
export default {
  beforeCreate() {
    console.log("Vue component beforeCreate");
  },
  created() {
    console.log("Vue component created");
  },
  mounted() {
    console.log("Vue component mounted");
  }
}
</script>

React

import { useEffect, useState } from 'react';

function MyComponent() {
  useEffect(() => {
    console.log("React component mounted");
    return () => {
      console.log("React component will unmount");
    };
  }, []);

  return <div>Component Content</div>;
}

5. Event Handling

Definition and Characteristics

Vue.js

Uses directives like @click and @input. These directives make it easy to add event listeners. Vue.js directives simplify event handling.

React

Event listeners are written in camelCase and passed directly to JSX. Event listeners are specified as JSX attributes, integrating UI construction with event handling.

Code Samples

Vue.js

<button @click="handleClick">Click Me</button>

React

<button onClick={handleClick}>Click Me</button>

6. Conditional Rendering

Definition and Characteristics

Vue.js

Uses v-if and v-else directives. These directives control UI rendering based on conditions. Vue.js's conditional rendering makes UI control easier.

React

Conditions are written directly in JSX. Conditions are evaluated as JSX expressions, allowing more flexible UI rendering control.

Code Samples

Vue.js

<div v-if="isLoggedIn">Welcome!</div>
<div v-else>Please log in.</div>

React

{isLoggedIn ? <div>Welcome!</div> : <div>Please log in.</div>}

7. List Rendering

Definition and Characteristics

Vue.js

Uses the v-for directive. The directive renders UI for each array element. Vue.js's list rendering makes it easy to render UI for array elements.

React

Uses the map method. The map method renders UI for each array element. React's list rendering is a powerful tool for rendering UI from array elements.

Code Samples

Vue.js

<li v-for="item in items" :key="item.id">{{ item.name }}</li>

React

items.map(item => <li key={item.id}>{item.name}</li>);

8. Form Binding

Definition and Characteristics

Vue.js

Uses v-model for easy two-way binding. User input is automatically reflected in the data. Vue.js's form binding makes user interface development easier by automatically reflecting form input in data.

React

Explicitly manages values through onChange events. User input is explicitly reflected in the data. React's form binding allows finer control by explicitly reflecting form input in data.

Code Samples

Vue.js

<input v-model="name" />

React

<input value={name} onChange={e => setName(e.target.value)} />

9. Conclusion

React and Vue.js each have their own unique characteristics. Use this comparison as a reference to choose the framework that best suits your project needs.

Git Commands for Breaking Down Large Code Changes into Smaller PRs

OE Haruki — Tue, 11 Feb 2025 10:40:34 +0000

Even if you've already committed many changes to a single branch, it's possible to break them down into smaller, more manageable PRs.
This article explains the detailed process.

1. Check Current Status

First, review what commits exist in your current branch.

git log --oneline

If all changes are in the latest commit, proceed to the next step.

2. Reset Latest Commit

Reset the latest commit to move changes back to the staging area. Using the --soft option preserves the working directory changes.

git reset --soft [target branch for eventual merge]

Note

--soft: Undoes the commit and returns changes to the index.

3. Stage Changes in Smaller Units

Use git add -p to stage changes in smaller chunks.

git add -p

Prompt commands:

Command	Action
`y`	Stage this change
`n`	Skip this change
`q`	Skip all remaining changes
`s`	Split current change into smaller chunks

4. Create Small Commits

Commit the staged changes.
Repeat this process to break down large changes into smaller commits.

git commit -m "feat: add feature xxx"

5. Update Remote Repository

If the branch has already been pushed to the remote repository, you'll need to overwrite the history.
Use the --force-with-lease option to safely overwrite.

git push --force-with-lease origin feature/large-update

Note

--force-with-lease: Checks remote state and forces push only if no one else has made changes.

6. Create PR

After reflecting the split branch to the remote repository, create a PR.

7. Repeat Process on New Branch

After completing the first PR, create a new branch and repeat the same process.
Here's the workflow:

a. Create New Branch

Switch to a new branch from the current state.

git checkout -b feature/next-small-pr

b. Stage Remaining Changes

Use git add -p again to stage and split the remaining changes.

git add -p

c. Commit and Push

Commit in appropriate units and push to remote as a new branch.
Since we haven't reset this branch, a normal git push is fine.

git commit -m "Refactor module Y"
git push origin feature/next-small-pr

d. Create Next PR

Create a PR from the new branch and request review.
Repeat this process as needed to organize the large code change into several smaller PRs.

Summary Table of Overall Flow

Step	Example Command	Description
Check Current Status	`git log --oneline`	Review current commit history
Reset	`git reset --soft [target branch]`	Undo all commits on branch and return changes to staging area
Stage Changes in Parts	`git add -p`	Interactively select and split changes
Commit	`git commit -m "..."`	Commit selected changes
Update Remote	`git push --force-with-lease origin feature/large-update`	Overwrite history and update remote
Create New Branch	`git checkout -b feature/next-small-pr`	Start work on new branch for next changes

Important Notes

Be Careful with Force Push

While --force-with-lease reduces the risk of overwriting others' changes, always ensure you're working with the latest state.
Don't Split Too Small

It's important to split into meaningful units. Use "one logical unit" as your guideline.

With these steps, you can safely and efficiently split large changes into smaller PRs, even after committing many changes to a single branch!
Give it a try!

A Guide to Alt Attributes for Frontend Developers

OE Haruki — Tue, 11 Feb 2025 10:37:26 +0000

Introduction

The alt attribute is a crucial HTML attribute that provides textual descriptions of images, translating visual content into verbal form.
In the context of web accessibility, it plays a vital role particularly in the following scenarios:

When users with visual impairments use screen readers
When images fail to load due to network issues
When users have disabled image display

In WCAG 2.2, proper use of alt attributes is specified under Success Criterion 1.1.1 "Non-text Content" (Level A).
This criterion requires that all non-text content, except for decorative elements, must have text alternatives that serve the equivalent purpose.

https://www.w3.org/WAI/WCAG22/Understanding/non-text-content

Basic Specifications of Alt Attributes

According to the HTML Living Standard, the alt attribute is required for img elements.

https://html.spec.whatwg.org/multipage/images.html#alt

The basic syntax is as follows:

<img src="path/to/image.jpg" alt="Description of the image">

There are primarily two patterns for using alt attributes:

Providing Alternative Text
When an image conveys information, set appropriate alternative text describing its content.
Using Empty Alt Attributes
For decorative images, set an empty value like alt="".
This causes screen readers to ignore the image's presence.

Key Points for Effective Alt Text

Keep Descriptions Concise and Accurate

Alternative text should focus on the essential information the image aims to convey.
For product images, for example, it's important to concisely describe the product name and key features.

❌ Poor example:

<img src="coffee.jpg" alt="A black ceramic mug with a handle placed on a white background, with steam rising from it">

✅ Good example:

<img src="coffee.jpg" alt="Hot coffee in a black mug">

Context-Aware Descriptions

The appropriate alternative text for the same image may vary depending on its location and purpose.

<!-- When used in navigation -->
<img src="home.svg" alt="Home">

<!-- When indicating current location -->
<img src="home.svg" alt="Current page: Home">

Consider Appropriate Length

While there's no strict character limit for alt attributes, overly long descriptions can impact usability when read by screen readers.
WebAIM and MDN Web Docs emphasize the importance of being "concise" in alt attributes.
https://webaim.org/techniques/alttext/
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#usage_notes

For complex diagrams or charts, consider using aria-describedby to provide detailed descriptions when necessary.
(More on aria-describedby later.)

Other Important Considerations

When writing alt attributes, keep these points in mind:

Avoid redundant prefixes like "image:" or "photo:"
Don't use file names as alt text
Use empty alt attributes (alt="") for decorative images
For images functioning as links or buttons, describe the action that occurs when clicked

Practical Examples by Use Case

Decorative Images

For images used purely for decoration (dividers, background images, decorative icons), set an empty alt attribute.

<img src="decoration.png" alt="">

This prevents screen readers from announcing unnecessary information by ignoring the image's presence.

Images as Navigation Elements

For images functioning as buttons or links, clearly describe what happens upon interaction.

<img src="menu.svg" alt="Open menu">
<img src="twitter.svg" alt="Share on Twitter">

Infographics and Charts

For data visualizations, concisely explain the main information or trends.
Consider using aria-describedby to provide detailed data when necessary.

<img src="graph.png" alt="Sales increased 20% in 2023 compared to previous year" aria-describedby="graph-details">
<div id="graph-details" hidden>
    Q1: $1M
    Q2: $1.5M
    Q3: $2M
    Q4: $2.5M
</div>

Product Images and Logos

For e-commerce product images, include the product name and important visual characteristics concisely.

For company or brand logos, typically use the brand name as alternative text.
However, when functioning as a link, additional context might be needed.

<!-- Product image example -->
<img src="product.jpg" alt="Leather handbag - Brown with gold hardware">

<!-- Logo image example -->
<a href="/">
    <img src="logo.png" alt="Company Name - Return to homepage">
</a>

Alternative Approaches

When alt attributes alone aren't sufficient, consider these alternatives:

aria-label / aria-labelledby

Attributes that provide direct labels for elements.

<button aria-label="Open menu">
    <img src="menu.svg" alt="">
</button>

figure and figcaption Elements

Semantically group images with their descriptions.

<figure>
    <img src="graph.png" alt="Quarterly sales graph for 2023">
    <figcaption>
        Sales grew steadily from Q1, achieving 150% year-over-year growth in Q4.
    </figcaption>
</figure>

Validation and Testing

Screen Reader Testing

Check the following points with major screen readers:

Alternative text is read properly
Decorative images are appropriately skipped
Reading order is logical

Automated Check Tools

Use these tools to detect basic issues:

axe DevTools
WAVE
Lighthouse

Summary

Key points for proper alt attribute implementation:

Basic Principles
- Provide appropriate alternative text based on image purpose and context
- Use empty alt attributes for decorative images
- Keep descriptions concise and accurate
Implementation Best Practices
- Avoid redundant descriptions
- Utilize appropriate alternatives when needed
Quality Control
- Regular testing with screen readers
- Use automated checking tools
- Code review verification

Understanding the 4 Principles of WCAG (Perceivable, Operable, Understandable, Robust)

OE Haruki — Tue, 11 Feb 2025 10:30:18 +0000

WCAG (Web Content Accessibility Guidelines) is an international standard for ensuring web accessibility.

Before diving deep into WCAG's principles, it's helpful to understand its overall structure.
For a comprehensive overview of WCAG's structure, please refer to this article:

Understanding WCAG: Structure, Principles, Guidelines, Success Criteria, and Supporting Documents

OE Haruki ・ Feb 11

#a11y #ui #html #css

Now, let's explore the four principles (Perceivable, Operable, Understandable, and Robust) that form the foundation of WCAG.

Perceivable

Information and user interface components must be presentable to users in ways they can perceive.¹

The concept is straightforward.
This principle requires that web content and interfaces must be perceivable to users.

This means content shouldn't be in a state where it's "neither visible, nor audible, nor tactilely perceivable."

While we won't delve into the specific guidelines under this principle, here are some key requirements:

Enable screen reader users to understand information through audio
Provide captions for video content so deaf users can understand it
Ensure form requirements are indicated by both color and text for color-blind users

If content can't be perceived visually, make it perceivable through audio.
If it can't be perceived through audio, make it perceivable visually.
If it can't be perceived through color vision, make it perceivable through other visual means.

Providing information through only one sensory channel makes it "imperceivable" to those with impairments in that specific sense.
Therefore, offering information through multiple sensory channels significantly expands the range of "perceivability."

However, implementing accessibility involves complex challenges.
For example, even if visual information is made available through audio, it remains "imperceivable" to deafblind users who have both visual and hearing impairments.

This doesn't mean such accommodations are meaningless.
Many deafblind users access the web using refreshable braille displays.
For instance, adding alt attributes to images not only conveys information audibly through screen readers but also enables tactile information transmission through braille displays.

To accommodate diverse disabilities, it's crucial to combine multiple sensory information delivery methods.
Each accommodation may benefit users with different disabilities.
Improving accessibility is achieved through such multi-layered approaches.

https://www.w3.org/WAI/WCAG22/Understanding/perceivable

Operable

User interface components and navigation must be operable.¹

This principle requires that user interfaces and navigation must be operable.

While many people use a mouse to browse websites, mouse usage primarily assumes a visual interface.
However, some visually impaired users find mouse operation difficult and rely solely on keyboard navigation.
The "Operable" principle demands that websites be designed to accommodate various input methods to meet diverse needs.

Beyond keyboards, we must consider users who rely on various input devices such as touchscreens, voice recognition software, and braille displays.

This principle isn't just for people with disabilities; it also applies to temporary situations where specific devices are unavailable (e.g., when a touchpad malfunctions).
In such cases, ensuring keyboard-only operation becomes crucial.

Furthermore, the Operable principle emphasizes preventing seizures and allowing sufficient time to understand and operate content.
Rapid light flashes may trigger seizures in users with conditions like epilepsy.
Since information processing speeds vary among users, adequate time must be provided.
(For example, implementing speed control features for slideshows.)

https://www.w3.org/WAI/WCAG22/Understanding/operable

Understandable

Information and the operation of user interface must be understandable.¹

This principle requires that web content and interfaces be clear and usable for users with various abilities and experiences.

Let's consider the hamburger menu button as an example.
This button typically consists of three horizontal lines and expands a menu when clicked.

https://en.wikipedia.org/wiki/Hamburger_button

While many readers of this article, such as engineers and designers familiar with web interfaces, might predict that "clicking will expand a menu," this isn't universally intuitive.

The following users might find it difficult to understand the meaning and function of this interface:

Elderly people
Those unfamiliar with web technology
People with cognitive or learning disabilities

To avoid such situations, approaches like using alternative, more predictable user interface operations are necessary.

Design user interface operations to be predictable
Provide clear and understandable labels for buttons and links
Maintain consistent design and navigation throughout the site
Clearly identify errors and provide correction methods when they occur in input forms

These measures help various users understand and properly operate web content.

https://www.w3.org/WAI/WCAG22/Understanding/understandable

Robust

Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.¹

This principle requires that content be reliably interpretable by various user agents and assistive technologies.

As we transition from PCs to smartphones, new devices may emerge in the future.
Input devices continue to evolve, and more convenient alternatives to current keyboards and mice may be developed.

Browser market share may also shift. While Google Chrome currently dominates, emerging browsers might gain prominence in the future.

Technology and user agents continue to evolve. Therefore, content itself needs to be "accessible" to accommodate these changes.
Here, "accessible" means "being reliably interpretable by evolving technologies and user agents."
It's important to ensure consistent behavior and content across different browsers and devices.

To ensure "robustness," consider the following approaches:

Writing structured HTML
Conducting multi-browser and cross-platform testing
Improving dynamic content accessibility through proper WAI-ARIA implementation

https://www.w3.org/WAI/WCAG22/Understanding/robust

Summary

The four WCAG principles (Perceivable, Operable, Understandable, and Robust) are fundamental guidelines for web accessibility.
These principles form the highest-level concepts in WCAG and serve as the foundation for ensuring web content accessibility.

A deep understanding of these principles enables a more conceptual understanding of the guidelines and success criteria based on them.
While WCAG receives major updates periodically, these principles remain more stable compared to individual success criteria.
These principles function as core concepts of web accessibility regardless of technological or situational changes.
Therefore, they can serve as long-term guidelines for teams and organizations.

"Web Content Accessibility Guidelines (WCAG) 2.2", W3C, December 12, 2024, https://www.w3.org/TR/WCAG22/ (accessed 2024-12-27) ↩

Understanding WCAG: Structure, Principles, Guidelines, and Success Criteria

OE Haruki — Tue, 11 Feb 2025 10:13:12 +0000

WCAG (Web Content Accessibility Guidelines) is an essential guideline when discussing web accessibility.

While it might seem overwhelming at first, all the content is actually consolidated into a single page.

If you find accessibility challenging, don't worry. While this single page is content-rich, its beauty lies in the fact that you can easily check accessibility basics without constantly referring to multiple pages.

As of December 28, 2024, WCAG 2.2 is the latest version. You can access it here:

https://www.w3.org/TR/WCAG22/

This article explains WCAG's overview and structure, detailing the roles of its Principles, Guidelines, Success Criteria, and Supporting Documents.

WCAG Overview and Purpose

WCAG (Web Content Accessibility Guidelines) is an international accessibility standard developed by WAI (Web Accessibility Initiative), a branch of W3C (World Wide Web Consortium), the international standards organization for the internet.

The primary goal of these guidelines is to ensure equal access and usability of web content for all people, regardless of their disabilities, limitations, or usage environment.

WCAG specifically aims to:

Address diverse disabilities including visual (blindness, low vision), auditory (deaf, hard of hearing), motor, speech, cognitive/learning disabilities, and photosensitive seizures
Consider broader user groups including elderly people and those with temporary disabilities
Ensure accessibility for people using the web in various environments and situations
Improve overall usability

WCAG is an international standard created through global collaboration, designed to be applicable across current and future web technologies. It serves as a comprehensive guide for creating "universally usable" web content.

WCAG's Hierarchical Structure and How to Read It

WCAG is organized in a three-tier hierarchical structure.
Understanding this structure makes WCAG easier to comprehend.

Hierarchical Structure

Level	Description
Principles	Top-level concepts
Guidelines	Concrete objectives under principles
Success Criteria	Detailed requirements under guidelines

Each top-level "Principle" contains multiple "Guidelines," and each Guideline includes multiple "Success Criteria."

Example

Principle 1
- Guideline 1.1
- Success Criterion 1.1.1
- Guideline 1.2
- Success Criterion 1.2.1
- Guideline 1.3
- Success Criterion 1.3.1
- Success Criterion 1.3.2
Principle 2
- Guideline 2.1
- Success Criterion 2.1.1
  - ...etc.

How to Read the Table of Contents

WCAG document numbers follow the format "Principle.Guideline.Success Criterion".

For example, looking at this WCAG document:
https://www.w3.org/TR/WCAG22/#audio-description-or-media-alternative-prerecorded

The reference number 1.2.3 indicates:

Under the 1st principle (Perceivable)
Under the 2nd guideline (Time-based Media)
The 3rd success criterion (Audio Description or Media Alternative (Prerecorded))

Understanding this structure helps locate items efficiently within the WCAG documentation.

Principles

WCAG is built on four core principles.

Principle	Description
Perceivable	Information and UI components must be presentable to users in ways they can perceive.
Operable	User interface components and navigation must be operable.
Understandable	Information and operation must be understandable.
Robust	Content must be robust enough to work with current and future technologies.

These principles are sometimes referred to as the POUR principles.

If you would like to learn more about the principles, please also read the following article.

Understanding the 4 Principles of WCAG (Perceivable, Operable, Understandable, Robust)

OE Haruki ・ Feb 11

#a11y #wcag

Guidelines

Under each principle, guidelines define goals for improving accessibility. WCAG 2.2 contains 13 guidelines.

Guidelines provide context and purpose for understanding specific success criteria.
While principles represent abstract concepts, guidelines provide general directions for achieving these principles.
(The specific implementation details are covered in the success criteria.)

For example, under the "Perceivable" principle, these guidelines are provided:

Text Alternatives: Provide text alternatives for non-text content.
Time-based Media: Provide alternatives for time-based media.
Adaptable: Create content that can be presented in different ways without losing structure.
Distinguishable: Make it easier for users to see and hear content.

Success Criteria

While guidelines provide context and purpose, success criteria are specific, testable requirements.
They serve as the basis for determining WCAG conformance.

Three Conformance Levels

Success criteria are categorized into three conformance levels,
indicating different degrees of web content accessibility.

Level A

Meets minimum standards
Must satisfy all Level A success criteria
Meets basic requirements but may still present barriers for some users

Level AA

Target level for most organizations and government agencies
Must satisfy all Level A and AA success criteria
Makes content accessible to most users
Widely adopted as legal requirements and industry standards

Level AAA

Represents the highest standard
Must satisfy all Level A, AA, and AAA success criteria
Very challenging to achieve and may not be possible in all situations
Not recommended as a general policy for entire sites

Implementation Example

Success criteria provide practical standards for web development.
Here's an example:

Success Criterion 1.1.1 Non-text Content
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.¹

To meet this criterion, implement something like:

<img src="logo.png" alt="W3C" />

This implementation satisfies the success criterion by providing alt text (text alternative) for the image (non-text content).

Supporting Documents

Supporting documents exist below success criteria to provide detailed explanations and implementation guidance.

https://www.w3.org/WAI/WCAG22/Understanding/

For example, the following page explains the intent, benefits, examples, and techniques for "Success Criterion 1.1.1 Non-text Content":

https://www.w3.org/WAI/WCAG22/Understanding/non-text-content

Difference Between Supporting Documents and Success Criteria

Success criteria define "requirements to be met" for ensuring accessibility.
These are normative parts used to evaluate WCAG compliance.
Supporting documents provide "supplementary information" to help understand and implement the criteria.
These are non-normative materials used as references.

Success Criteria

Normative
Provides WCAG conformance criteria
Mandatory requirements

Supporting Documents

Non-normative
Supports understanding and implementation
Explanations, examples, reference information (including failures)

WCAG Versions and Evolution

WCAG has evolved with technological advances while maintaining its core purpose of "making web content accessible to all."

WCAG 2.1 and 2.2 are backward compatible with previous versions.
Conforming to WCAG 2.2 automatically means conformance to WCAG 2.1 and 2.0.

Version	Year	Key Features
1.0	1999	Initial version. HTML/CSS focused with 14 guidelines.
2.0	2008	Technology-agnostic approach with 4 principles, 12 guidelines, 61 success criteria.
2.1	2018	Added 17 success criteria focusing on mobile devices, low vision, and cognitive disabilities.
2.2	2023	Added 9 success criteria including authentication methods and focus indicators.
3.0	Draft	Considering changes to evaluation metrics and conformance levels.

"Web Content Accessibility Guidelines (WCAG) 2.2", W3C, October 5, 2023, https://www.w3.org/TR/WCAG22/#non-text-content (accessed 2024-12-27) ↩