Benchmark: case native vs custom

Script Preparation code:

const NS = "dhx"

const BUTTON = `${NS}_button`
const BUTTON_DANGER = `${NS}_button--color_danger`
const BUTTON_SECONDARY = `${NS}_button--color_secondary`
const BUTTON_PRIMARY = `${NS}_button--color_primary`
const BUTTON_SUCCESS = `${NS}_button--color_success`
const BUTTON_SMALL = `${NS}_button--size_small`
const BUTTON_MEDIUM = `${NS}_button--size_medium`
const BUTTON_FLAT = `${NS}_button--view_flat`
const BUTTON_LINK = `${NS}_button--view_link`
const BUTTON_FULL = `${NS}_button--width_full`
const BUTTON_CIRCLE = `${NS}_button--circle`
const BUTTON_LOADING = `${NS}_button--loading`
const BUTTON_ICON = `${NS}_button--icon`

function custom(props) {
    let css = `${BUTTON} `

    switch (props.color) {
        case "danger":
            css += BUTTON_DANGER;
            break
        case "secondary":
            css += BUTTON_SECONDARY;
            break
        case "primary":
            css += BUTTON_PRIMARY;
            break
        case "success":
            css += BUTTON_SUCCESS;
            break
    }
    css += " "

    if (props.size === "small") {
        css += BUTTON_SMALL
    } else {
        css += BUTTON_MEDIUM
    }
    css += " "

    if (props.view === "flat") {
        css += BUTTON_FLAT
    } else {
        css += BUTTON_LINK
    }
    css += " "

    if (props.full) css += ` ${BUTTON_FULL}`
    if (props.circle) css += ` ${BUTTON_CIRCLE}`
    if (props.loading) css += ` ${BUTTON_LOADING}`
    if (props.icon) css += ` ${BUTTON_ICON}`

    return css;
}

function native(props) {
    const colorsCss = {
        danger: " dhx_button--color_danger",
        secondary: " dhx_button--color_secondary",
        primary: " dhx_button--color_primary",
        success: " dhx_button--color_success",
    } [props.color] || " dhx_button--color_primary"

    const sizeCss = {
        small: " dhx_button--size_small",
        medium: " dhx_button--size_medium",
    } [props.size] || " dhx_button--size_medium"

    const viewCss = {
        flat: " dhx_button--view_flat",
        link: " dhx_button--view_link",
    } [props.view] || " dhx_button--view_flat"

    const fullCss = props.full ? " dhx_button--width_full" : ""
    const circleCss = props.circle ? " dhx_button--circle" : ""
    const loadingCss = props.loading ? " dhx_button--loading" : ""
    const iconViewCss = props.icon && !props.text ? " dhx_button--icon" : ""

    return `dhx_button${colorsCss}${sizeCss}${viewCss}${fullCss}${circleCss}${loadingCss}${iconViewCss}`
}

Tests:

custom
const cls = custom({color: "danger"})
native
const cls = native({color: "danger"})

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
custom
native

Fastest: N/A

Slowest: N/A

Latest run results:

No previous run results

This benchmark does not have any results yet. Be the first one to run it!

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark and its test cases.

**Benchmark Definition**

The benchmark measures two approaches to generating CSS classes for `dhx_buttons`. The script preparation code defines two functions: `custom` and `native`. Both functions take an object with various properties (e.g., color, size, view) as input and generate a CSS class string based on these properties.

**Custom Approach**

The custom approach uses a `switch` statement to determine the CSS classes to apply. It iterates over the input object's properties, adding corresponding CSS classes to a string. If a property is not present in the object or has an invalid value, it defaults to a specific fallback value (e.g., `" dhx_button--color_primary"`).

Pros:

* Allows for more control over the generated CSS classes, making it easier to customize the appearance.
* Can be used to test specific use cases or edge cases.

Cons:

* May lead to slower performance due to the increased number of iterations and conditional checks.

**Native Approach**

The native approach uses an object-based configuration system. It iterates over an object with predefined CSS classes for each property (e.g., `colorsCss`, `sizeCss`, etc.). If a property is not present in the input object or has an invalid value, it defaults to the fallback value defined in the object.

Pros:

* Generally faster than the custom approach due to fewer iterations and conditional checks.
* Easier to maintain and extend the configuration system.

Cons:

* Less flexible than the custom approach, as changes require updating the predefined configuration object.

**Library Usage**

The benchmark uses two JavaScript libraries:

1. `dhx` (no library is explicitly mentioned): It's likely a proprietary library or a custom implementation used by `dhx_buttons`.
2. `console`: Used for logging and debugging purposes.

**Special JS Features/Syntax**

There are no special JavaScript features or syntax used in this benchmark.

**Alternatives**

Other alternatives to these approaches could include:

1. Using a CSS-in-JS solution, such as styled-components or emotion, which would allow for more declarative and flexible styling.
2. Utilizing a library like PostCSS or PurgeCSS to handle CSS class generation and optimization.
3. Implementing a custom solution using JavaScript's `template literals` feature, which would provide a balance between flexibility and performance.

Keep in mind that the choice of approach depends on the specific requirements and constraints of the project.

Related benchmarks:

case native vs custom (version: 0)

Comparing performance of: custom vs native

Created: 4 years ago by: Registered User

Jump to the latest result

custom

native

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

No previous run results

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):