IdeaWell

Project ideas from Hacker News discussions.

Replacing JavaScript with Just HTML

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

1. Appreciation for Native HTML/CSS Simplicity and Functionality

Users praise HTML elements like <details>/<summary> and <datalist> for reducing JS dependency, improving performance, and enhancing accessibility without complexity.
"start with the simplest solution like the html-only autofilters first, then add complex behavior later" (prisenco).
"The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them" (subdavis).
"most JS in these cases isn’t adding capability, it’s compensating for forgotten platform features" (Theoleff).

2. Limitations of Native Features (Styling, Browser Support, Control)

Criticism focuses on inconsistent styling, poor browser support, lack of programmatic control, and missing advanced UX like dynamic autocomplete or animations.
"every browser has its own styling and they are impossible to change enough to get the really long options to show up correctly" (zdragnar).
"Having to use the property on the element instance, rather than the actual HTML attribute, is exactly the kind of wrapper code I want to avoid" (crooked-v).
"datalist is that there's no easy way to show and allow only text... but have the actual value selected be a number" (kmoser).

3. Debate on JS Reliance vs. Platform Evolution

Opinions split on JS necessity for complex apps versus pushing HTML/CSS standards; mentions HTMX/React dominance and hiring biases.
"Complex/interactive web apps requires JavaScript, period" (overflowy).
"they still judge a developer's JS skills (especially React) than being semantically correct on HTML elements" (bodash).
"Progression enhancement is the way to go if you care about technical excellence" (augustk).

🚀 Project Ideas

Native Datalist Enhancer

Summary

  • A lightweight JavaScript polyfill that supercharges HTML <datalist> with fuzzy matching, typo tolerance, dynamic XHR loading, label/value separation, consistent cross-browser styling, and mobile-optimized UX.
  • Core value: Replaces brittle custom autocomplete components with a drop-in enhancer for native inputs, reducing bundle size while matching Google-style search suggestions.

Details

Key Value
Target Audience Web developers frustrated with datalist limitations (e.g., "typo in the field", "no way to filter... appear near the end")
Core Feature Progressive enhancement: fuzzy search via Fuse.js, auto-populate options from API, customizable dropdown styling via CSS vars
Tech Stack Vanilla JS, Fuse.js for fuzzy matching, ResizeObserver for responsive dropdowns
Difficulty Medium
Monetization Revenue-ready: Freemium (core free, pro for enterprise features like server-side search)

Notes

  • HN users lament datalist's poor UX: "no HTML way to interactively load results", "terrible UX", "can't do complex autocomplete"; this fixes it without full JS rewrite.
  • High discussion potential as a "use the platform" enhancer; practical for forms in apps/sites.

Accessible Native UI Playground

Summary

  • An interactive online editor/playground for building/testing accordions, tabs, modals, and popovers using only HTML/CSS (details/summary, popover API, etc.), with live browser support checks, a11y audits, animation previews, and code export.
  • Core value: Democratizes "use the platform" by visualizing native features, catching gotchas like Edge styling or Firefox animation gaps before production.

Details

Key Value
Target Audience Frontend devs debating native vs. JS: "every component library just pretends they don’t exist", "pure HTML/CSS tabs fail a11y"
Core Feature Drag-drop builder for details-based accordions/tabs, real-time caniuse integration, WAVE a11y scanner, one-click copy-paste code
Tech Stack Svelte/Vanilla JS frontend, Web Components for demos, caniuse API + Playwright for cross-browser screenshots
Difficulty High
Monetization Revenue-ready: Sponsored tiers (browser vendors), pro export to frameworks

Notes

  • Directly addresses "details / summary... kills me", tab a11y issues ("requires JavaScript"), animation frustrations ("tricky... interpolate-size yet to land"); quotes like "subdavis: There’s basically nothing you can’t do with them".
  • Sparks HN debates on standards; utility for prototyping progressive enhancement.

Cross-Browser Native Form Styler

Summary

  • A CSS-in-JS tool/service that generates consistent, customizable stylesheets for native form elements (datalist, select, date inputs, details) across browsers, with previewer, theme generator, and polyfill suggestions.
  • Core value: Solves "every browser has its own styling... impossible to change", enabling native controls in production without div-soup hacks.

Details

Key Value
Target Audience Devs avoiding JS heaviness: "styling... ugly", "doesn't work in Edge", "client tells you that it doesn't work"
Core Feature AI-assisted theme builder (via CSS vars), live multi-browser previews, auto-prefixer + fallbacks for animations/transitions
Tech Stack Tailwind/CSS vars generator, Puppeteer for browser renders, Vercel deployment
Difficulty Medium
Monetization Hobby

Notes

  • Targets rants like "zdragnar: doesn't work in Edge... impossible to change", "sevenseacat: default styling... ugly"; promotes "start with simplest... html-only autofilters".
  • Practical utility for rapid styling; HN loves tools bridging CSS/HTML gaps for real-world use.

Read Later