How functional programming shaped and twisted front end development

Original Article ↗ Hacker News Discussion ↗

Article’s Thesis and Role of FP

  • Many commenters feel the piece misattributes frontend complexity to “functional purism.”
  • React is seen more as a pragmatic abstraction that won by merit, not an FP ideology; it even had class components.
  • Several implementation details criticized in the article (synthetic events, custom dialogs, custom selects) are argued to be driven by browser incompatibilities or immature platform features, not FP dogma.
  • Some see the article as a long setup to promote HTMX, with selective use of examples and incomplete treatment of client-vs-server tradeoffs.

FP Style in JavaScript (map/filter/reduce vs loops)

  • Strong split between people who prefer chained array methods (map/filter/some/every/reduce) and those who find them overused and less readable than plain loops.
  • Pro-FP side: chains emphasize intent, improve modularity and composability, and align with REPL-driven iteration; loops become unwieldy as logic grows.
  • Skeptical side: in practice devs often write convoluted chains, abuse reduce, mutate accumulators, and gain none of the theoretical benefits; those cases should be rewritten, not defended as FP.
  • Agreement that JS is not a great FP language (global mutable facilities, weak typing) and that “FP,” “declarative,” and “immutable” are often conflated.

Components, State, and Data Flow

  • A central thread: the DOM/component tree and the data-flow graph are distinct structures that React forces together via props, context, and global state.
  • Critics argue this destroys modularity: deep trees lead to prop drilling, components become tied to unrelated state, and reuse across contexts is hard.
  • Others respond that this is mostly an architectural choice: flatter hierarchies, richer “layout”/template components, and concentrating logic near the top can avoid deep drilling without exotic state tools.
  • Alternative models mentioned: frameworks that model state as an explicit graph (separate from DOM), Aurelia’s “whole page as one component,” and classic jQuery+HTML plus bindings. Redux is praised by some for decoupling UI events from a global data graph.

CSS, Design Systems, and Org Problems

  • Multiple comments say teams routinely fail at scalable CSS; CSS-in-JS, Tailwind, and similar arise mainly as organizational patches, not pure technical wins.
  • Others argue plain SCSS + CSS Modules is sufficient if teams actually value and enforce CSS discipline.
  • There’s broad agreement that many frontend devs are weak at CSS, interviews under-weight it, and that design systems and Figma often don’t translate cleanly into coherent, maintainable styles.

Alternatives, Platforms, and “Wicked Problems”

  • Some see frontend and ORMs as “wicked problems” where underlying mismatches (HTML as document vs app UI; objects vs tables) ensure imperfect solutions.
  • Discussion touches Web Components (seen as insufficient), the slow pace and politics of web standards, and WASM as a possible future escape hatch from DOM-centric app UIs.
  • HTMX/hypermedia approaches get interest but also criticism for downplaying limitations of server-rendered interaction in rich, stateful UIs.