Hacker Newsnew | past | comments | ask | show | jobs | submit | jq_2023's commentslogin

what about the value of abstraction to readability and maintainability? Do you really want to be stuck with debugging/upgrading and generally working with such low level vanilla js code when elegant abstractions are so much more efficient ?


Abstraction for its own sake, especially with js frameworks, doesn't make anything more readable or maintainable. React apps are some of the most spaghetti style software I've ever seen, and it takes like 10 steps to find the code actually implementing business logic.


Some of that is the coding standards rather than the framework. I think Dan Abramov did a hang-up job on React, but his naming conventions and file structure are deranged.

Unfortunately there isn't any one preferred alternative convention. But if you ignore his and roll your own it will almost certainly be better. Not great for reading other people's code but you can make your own files pretty clear.


What "naming conventions and file structures" are you referring to? I don't think Dan ever really popularized anything like that for _React_.

If you're thinking of _Redux_, are you referring to the early conventions of "folder-by-type" file structures? ie `actions/todos.js`, `reducers/todos.js`, `constants/todos.js`? If so, there's perfectly understandable reasons why we ended up there:

- as programmers we try to "keep code of different kinds in different files", so you'd separate action creator definitions from reducer logic

- but we want to have consistency and avoid accidental typos, especially in untyped plain JS, so you'd extract the string constants like `const ADD_TODO = "ADD_TODO"` into their own file for reuse in both places

To be clear that was never a requirement for using Redux, although the docs did show that pattern. We eventually concluded that the "folder-by-feature" approach was better:

- https://redux.js.org/style-guide/#structure-files-as-feature...

and in fact the original "Redux Ducks" approach for single-file logic was created by the community just a couple months after Redux was created:

- https://github.com/erikras/ducks-modular-redux

which is what we later turned into "Redux slices", a single file with a `createSlice` call that has your reducer logic and generates the action creators for you:

- https://redux.js.org/tutorials/essentials/part-2-app-structu...


Do they do this notably worse than say a Spring boot API or a Vue frontend? I don't think this is a React thing. Those spaghetti projects would be so with or without React.


I've been leaning more on web components as an abstraction here, once an LLM can take care of their boilerplate they're a pretty nice way to modularize frontend code.


To be fair, React is a very leaky abstraction, I wouldn't define it "elegant". It does work at simplifying things for certain usecases though


the point around MCPs is spot on


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: