Ask HN: Why did Front end development explode in complexity?

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • redux-essentials-example-app

    Example app for the Redux Essentials tutorial

    Hi, I'm a Redux maintainer.

    I'll definitely agree that Redux _has_ been overused.

    But it's also worth understanding _why_ Redux was created in the first place and why it got so popular.

    As a brief recap: the first major wave of JS MVC frameworks had major flaws. Angular's dirty checking didn't scale and was impossible to debug. Backbone's event-based system led to events ricocheting around the app with no way to trace what would happen when a given value changed. Additionally, manual DOM manipulation made it hard to manage ongoing changes to the UI over time.

    This led to Facebook designing React to let devs write encapsulated components with predictable output and behavior, but React didn't have a solution for larger global state. Facebook later announced a "Flux Architecture" concept that tried to make larger app state updates predictable through centralization.

    The React community ran with this idea and produced dozens of Flux-inspired libraries. Redux took the ideas from several of those Flux libraries, and applied Functional Programming principles, with the goal of making it easier to understand when, where, why, and how your state is being updated and changing over time.

    The community then adopted Redux because A) it was the best of all the Flux implementations, B) it _did_ address the issues people were running into around state management, C) it was designed to work well with React, and D) it also incidentally helped work around limitations in React's original Context API. (I've talked about the original intent and purpose extensively in my blog posts and conference talks [0] [1].)

    After that, yes, Redux _did_ get shoved into many applications that didn't need it, in the same way that React has been used for many sites that didn't necessarily require that setup.

    So, we've always recommended that people actually take the time to evaluate the specific problems they need to solve in their app, and make an informed decision on whether Redux is an appropriate solution for those problems [2].

    Beyond that, we've specifically designed and built our official Redux Toolkit package [3] [4] to eliminate the old "boilerplate" concerns. "Modern Redux" with Redux Toolkit and React-Redux hooks is _much_ easier to learn and use than the original Redux patterns, and we get highly positive feedback on a daily basis from folks who enjoy using RTK. We also built an "RTK Query" data fetching and caching API [5], as data fetching is the most common thing that apps need to do today.

    [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

    [1] https://blog.isquaredsoftware.com/series/presentations

    [2] https://redux.js.org/tutorials/essentials/part-1-overview-co...

    [3] https://redux.js.org/introduction/why-rtk-is-redux-today

    [4] https://blog.isquaredsoftware.com/2022/06/presentations-mode...

    [5] https://redux-toolkit.js.org/rtk-query/overview

  • joystick

    A full-stack JavaScript framework for building stable, easy-to-maintain apps and websites.

    > Is that complexity necessary or artificially inflated?

    100% inflated and ego-based. How do I know? After years of struggling to understand the increasingly complex front-end space, I decided to build my own full-stack framework [1] to check my own opinions weren't left-field.

    Here's the harsh truth: it doesn't need to be as complex as it's made out to be. Not even close. I can speculate as to why (ego, job security, etc) but ultimately the punchline is that all of the APIs and a lot of the code under the hood are pointless Rube Goldberg machines.

    People don't want to hear that because they're invested emotionally in a lot of these tools, but from direct experience doing multi-year research and building of a framework, it's all a scam.

    [1] https://github.com/cheatcode/joystick

  • SurveyJS

    Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  • react-hook-form

    📋 React Hooks for form state management and validation (Web + React Native)

    There are probably 15k npm libraries that solve that very thing. I think this is part of what people struggle with and complain about WRT web dev. There are so many choices for libs and frameworks it can be hard to know which one to pick and which dragons you'll find along each path.

    FWIW if you're using hooks and React, React Hook Form is good: https://github.com/react-hook-form/react-hook-form

  • svelte-mpa

    Svelte MPA, Multipage Svelte

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts