4 ms·

This sounds really interesting, don't get me wrong, but it also shows just how insanely novel and complicated modern frontend dev is. Let's break down the term

by ljm 6y ago

This sounds really interesting, don't get me wrong, but it also shows just how insanely novel and complicated modern frontend dev is. Let's break down the terminology: - hooks - useEffect - useHistory - useSelector - dispatch - action - useDispatch - ducks - Actions - Epics (Observables) - Sagas (generators) - Reducers Most of those terminologies don't come from a general programming paradigm, but are the domain language of specific libraries. And I've seen more, with some places establishing patterns like Compound/Molecule/Atom and such. There's no consistent, underlying principle with them, though. If you're invested in Sagas then you're stuck with a bizarre threading model implemented with generator functions and it's pretty much all-or-nothing. If you're invested in Redux then there's no breaking out of that either, you're always going to be contending with shared global state.

michaelpb 6y ago
Not to mention terms that do come from a general programming paradigm, but have a very narrow practical / framework-specific use within frontend dev that makes it even harder for beginners (e.g. "thunk" might be a general term, but I bet most people googling it are just trying to get some Redux tutorial to work, and will end up going down dozens of rabbit holes trying to understand the general concept) I really hate to think how many collective hours have been wasted on new coders who learn JavaScript as their first language --- especially when starting with React and Redux, as it's often taught --- and end up spending most of their time spinning their wheels on these domain-specific complexities, when they haven't even gotten to "while loops" yet. This may even be harder for beginners than understanding, say, one of the classic CS sorting algorithms. New coders don't realize though that whatever degree this stuff is harder, it's a sign of bad tooling or documentation, not that it's somehow intrinsically a harder problem in math / CS, since if you're new you don't know what to expect
- ljm 6y ago
  React's hooks (and some JSX style things in general) are quite pernicious there because they essentially break JS: you can't use them inside an `if` or a `for` or a `while`, or even within another function. You're no longer writing Javascript, you're writing a restricted subset to avoid undefined behaviour. That alone is a concern, because any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself.
  - brundolf 6y ago
    In some ways JS is an excellent first language- beyond its broad applicability, it has an extremely "average of all the others" set of features and primary syntaxes. An experienced JS programmer will be conceptually comfortable with Python and Ruby, syntactically comfortable with Java and C, etc. But in terms of the industry-standard practices/ecosystem, it is a terrible first language if you want to gain a generalized understanding. What you describe here is extremely true; I've seen it in practice: > any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself I've talked with otherwise very capable JS devs who have built impressive things with multiple frameworks, but don't have a good handle on fundamental concepts like the difference between the two kinds of function syntax (they may have only ever used one), how Promises behave outside of a narrow subset of situations, what NodeJS actually is (despite having used it), or even the difference between passing by reference vs value. Many of these frameworks create such a narrow lens into the language itself, add what are effectively (sometimes literally) their own DSLs on top, sprinkle in some magical behavior, and when all is said and done you hardly end up using JS at all. Obviously there's a benefit from doing things this way or it wouldn't have happened. But I can't help but think the technologies that work well for industry are having a detrimental effect on a generation of new programmers.
    - searchableguy 6y ago
      > even the difference between passing by reference vs value You can only pass by value in JS so maybe that's why. It is a bit confusing because of how objects work that it feels like you are passing by reference. You are passing reference as the value.
      - brundolf 6y ago
        When it comes to primitives you can only pass by value, but with objects and arrays you can only pass by reference. And this applies to comparisons too: when comparing objects or arrays you are comparing by reference, not deeply by their inner values. If you want to compare them deeply you have to take some additional steps to make that possible, and all of the different strategies for doing so have different trade-offs. I once talked to someone with >5 years front-end experience, including some team-lead experience, who thought the difference between == and === was that === compares objects deeply. That is very, dangerously wrong. The only way I can imagine he got by for so long with that misconception is that he'd always used ImmutableJS.
- hombre_fatal 6y ago
  Meh, beginners are going to spin their wheels when they get to the point where they're trying to build anything, especially using a web/mobile/desktop client framework, because that's 99% of what software development is. Don't feel to bad for them, that's our entire craft. `while(true)` and sorting algorithms are not.
  - michaelpb 6y ago
    To clarify, I guess what I'm saying is it's often mistaken that this complexity is somehow intrinsic or unavoidable to the craft, when in fact it's completely avoidable. Bad (but popular) tooling isn't new --- I remember learning PHP4 was like an encyclopedia of gotchas and defensive programming --- but I feel that even a disaster like PHP4 was a lot more approachable for new coders than the state of the art now, and that the skills learned overcoming these things were more portable outside of the framework / language. All of this definitely makes my job more secure, but, I dunno, still feels like a real shame.
- littlecranky67 6y ago
  The mistake those beginner make is listening to some evagelists that will tell them they need everything, from React, TypeScript to Redux, routers, thunks/sagas etc. As a beginner, you should start with plain JS/TS. When you dealt with the hell of manipulating DOM elements all over the place and untraceable UI updates after hours of debugging, you should move on to some UI library. Only then will you understand and see what problem it solves. Then you should go with React, but not hooks or redux. Use plain old classes. When you felt the pain of distributed mutable state all over place, you will be open to hooks or redux etc. Still, do not add a library for thunks. Only after you realize how much boiler plate code you write to deal with async stuff, you will see a value in the added abstraction. A beginner should start simple, and really feel the pain. Only then will there be an "a-ha!" moment where you can judge if a library/framework actually helps you and provides value. The biggest issue in FE world is people proclaiming some given conglomerate of a library/framework soup as the silver bullet to all problems.
ZephyrBlu 6y ago
I think this is an unfair characterization. Once you understand hooks in general, any specific hook should be quite straightforward so they can collapse into one. Hooks are quite novel, but I don't find them to be overly complicated unless you're dealing with an already complex situation. Dispatch, actions and reducers can be collapsed into one since they rely on each other. I think this paradigm is not too dissimilar to message passing with something like RabbitMQ. Reducers are a common concept. Ducks and Actions, Epics and Sagas are just a convention. It's not required to use React or Redux. If you try to learn everything at once, of course you're going to get overwhelmed. But the same is true for almost any area of Software Engineering.
- nwienert 6y ago
  I think it’s totally fair. I discourage redux and all related patterns for this very reason. Well that, and I think local state is actually a good thing (and moving state out into separate files a bad thing). To me the proxy object (or proxy class) is really the best abstraction - much like valtio. Or a compiler like svelte. There’s no reason for ducks, epics, sagas, etc etc. We have a programming language already, we should use it.
  - ZephyrBlu 6y ago
    It sounds like you're agreeing with me. You don't need everything up front, so listing everything is a bit disingenuous. It's the same explaining a fully kitted out backend (Routing, caching, authentication, etc) and then going "see, it's so complicated!". Well duh, it's a big and complex system. I think the issue with valtio is that there's no central store. As far as I can see, you'll end up having these proxies scattered around your codebase or you'll end up re-creating Redux and centralizing them. Also, I have ironically never heard of valtio.
    - nwienert 6y ago
      Agreeing how? By using valtio you avoid needing to know most of that list, by using redux you.. don't. Also, you can easily wrap valtio with: const createStore = (name, store) => { if (window.stores[name]) throw 'store already exists' window.stores = { ...window.stores [name]: valtio(store) } } And boom, you can see every store just like redux.
BadInformatics 6y ago
> Most of those terminologies don't come from a general programming paradigm, but are the domain language of specific libraries. Not really? Most of these concepts can be linked back directly to earlier from CS theory and/or other languages. For example, Redux taking inspiration from FRP and functional lenses, or (most pertinent for this thread) hooks being a facsimile of algebraic effects in JS. As much as I like these concepts in general, I feel some go too far against the grain of what is idiomatic in the language and incur unnecessary friction/spooky action at a distance because of it. For example, here [1] are some well thought-out critiques of hooks and why people struggle with them from experienced JS framework authors. [1] https://news.ycombinator.com/item?id=22903967 https://news.ycombinator.com/item?id=22903967
avodonosov 6y ago
Novel - not, in my opinion. How to do GUI is known from 1970-ties. Today's single page apolication frameworks slowly re-discover the wheel. It is funny to observe.
- littlecranky67 6y ago
  The very important difference is that we do distributed systems now (admitted, X originally was also distributed, but only the drawing/events parts, not on the data level). A SPA is a distributed system, with all its drawbacks & pitfalls. If you ever did VB development in the 90s, you will know how easy it was to get a basic app running with those fancy Drag'n'Drop RAD tools. But there was no networking, everything worked offline. But then came the web and the networks, and now everything has to be a distributed system.
  - abraxas 6y ago
    There absolutely was a remote part to most VB6 apps. Usually they fetched data from some MS flavour of a RDBMS. Of course they were desktop apps and had to be installed individually but this “webify everything” mania seems to have smothered all dev productivity and experience on its altar.
    - littlecranky67 6y ago
      Yes, and I remember precisely how many apps just encoded the DB credentials inside of the code - with no access/rights abstraction whatsoever. So basically godmode. Thats why we use service layers in Apps today (REST, SOAP etc.) instead of granting a user's process godmode access to the DB.
      - avodonosov 6y ago
        Why godmode? If your DB user is restricted to specific tables and columns, he is controlled. If you eventually get access to the data, does not matter how many layers are in-between (REST, SOAP). You still got the data, so that's a "god mode" in the same sense.
qudat 6y ago
5 of those items are the same thing (hooks). Dispatch is how you emit an event (pub in pub/sub). Action is the event being emitted. Ducks is a code organization paradigm (colocation, organize by feature instead of layer). Reducers are what they sound like: a reduce function. Sagas and observables are how to perform side-effects in your application. There is nothing new here. You could argue that hooks are the weird ones but they are heavily inspired by algebraic effects.
_the_inflator 6y ago
You are talking about React here, not Frontend in general. Angular has different concepts. Steep at the beginning, but in my point of view easier in the long term with a stable API. I agree. Frontend is tough, but so is development. ;)
j-krieger 6y ago
So what. I've been a backend dev before I turned to front-end and web stuff. React has like a dozen top level functions and approaches. No backend project I have ever seen was this simple to program. How much more simple does it have to get before people stop complaining?
- littlecranky67 6y ago
  No-Code is what they look for :)
  - nsonha 6y ago
    Didn't they have dreamweaver and flash but thrown them away regardless.
littlecranky67 6y ago
This is nothing Frontend or JS specific. I've been around in BE (c#) long enough, and the "new shit" adds also terminologies that have nothing todo with C#/.NET itself and were basically "unknown" to any C# developer (or Java for that sake) 10 years ago: - Dependency Injection/IoC - Containers, Resolvers, Scopes - Microservices (Circuit Breaker anyone?) - DDD + CQRS (i could fill a whole page with terms coined by those) - Mediator Pattern etc. If you buy into a certain techstack, it will always bring associated patterns that have nothing to do with the original language/idiom.

by ljm 6y ago

michaelpb 6y ago

Not to mention terms that do come from a general programming paradigm, but have a very narrow practical / framework-specific use within frontend dev that makes it even harder for beginners (e.g. "thunk" might be a general term, but I bet most people googling it are just trying to get some Redux tutorial to work, and will end up going down dozens of rabbit holes trying to understand the general concept) I really hate to think how many collective hours have been wasted on new coders who learn JavaScript as their first language --- especially when starting with React and Redux, as it's often taught --- and end up spending most of their time spinning their wheels on these domain-specific complexities, when they haven't even gotten to "while loops" yet. This may even be harder for beginners than understanding, say, one of the classic CS sorting algorithms. New coders don't realize though that whatever degree this stuff is harder, it's a sign of bad tooling or documentation, not that it's somehow intrinsically a harder problem in math / CS, since if you're new you don't know what to expect

ljm 6y ago
React's hooks (and some JSX style things in general) are quite pernicious there because they essentially break JS: you can't use them inside an `if` or a `for` or a `while`, or even within another function. You're no longer writing Javascript, you're writing a restricted subset to avoid undefined behaviour. That alone is a concern, because any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself.
- brundolf 6y ago
  In some ways JS is an excellent first language- beyond its broad applicability, it has an extremely "average of all the others" set of features and primary syntaxes. An experienced JS programmer will be conceptually comfortable with Python and Ruby, syntactically comfortable with Java and C, etc. But in terms of the industry-standard practices/ecosystem, it is a terrible first language if you want to gain a generalized understanding. What you describe here is extremely true; I've seen it in practice: > any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself I've talked with otherwise very capable JS devs who have built impressive things with multiple frameworks, but don't have a good handle on fundamental concepts like the difference between the two kinds of function syntax (they may have only ever used one), how Promises behave outside of a narrow subset of situations, what NodeJS actually is (despite having used it), or even the difference between passing by reference vs value. Many of these frameworks create such a narrow lens into the language itself, add what are effectively (sometimes literally) their own DSLs on top, sprinkle in some magical behavior, and when all is said and done you hardly end up using JS at all. Obviously there's a benefit from doing things this way or it wouldn't have happened. But I can't help but think the technologies that work well for industry are having a detrimental effect on a generation of new programmers.
  - searchableguy 6y ago
    > even the difference between passing by reference vs value You can only pass by value in JS so maybe that's why. It is a bit confusing because of how objects work that it feels like you are passing by reference. You are passing reference as the value.
    - brundolf 6y ago
      When it comes to primitives you can only pass by value, but with objects and arrays you can only pass by reference. And this applies to comparisons too: when comparing objects or arrays you are comparing by reference, not deeply by their inner values. If you want to compare them deeply you have to take some additional steps to make that possible, and all of the different strategies for doing so have different trade-offs. I once talked to someone with >5 years front-end experience, including some team-lead experience, who thought the difference between == and === was that === compares objects deeply. That is very, dangerously wrong. The only way I can imagine he got by for so long with that misconception is that he'd always used ImmutableJS.
hombre_fatal 6y ago
Meh, beginners are going to spin their wheels when they get to the point where they're trying to build anything, especially using a web/mobile/desktop client framework, because that's 99% of what software development is. Don't feel to bad for them, that's our entire craft. `while(true)` and sorting algorithms are not.
- michaelpb 6y ago
  To clarify, I guess what I'm saying is it's often mistaken that this complexity is somehow intrinsic or unavoidable to the craft, when in fact it's completely avoidable. Bad (but popular) tooling isn't new --- I remember learning PHP4 was like an encyclopedia of gotchas and defensive programming --- but I feel that even a disaster like PHP4 was a lot more approachable for new coders than the state of the art now, and that the skills learned overcoming these things were more portable outside of the framework / language. All of this definitely makes my job more secure, but, I dunno, still feels like a real shame.
littlecranky67 6y ago
The mistake those beginner make is listening to some evagelists that will tell them they need everything, from React, TypeScript to Redux, routers, thunks/sagas etc. As a beginner, you should start with plain JS/TS. When you dealt with the hell of manipulating DOM elements all over the place and untraceable UI updates after hours of debugging, you should move on to some UI library. Only then will you understand and see what problem it solves. Then you should go with React, but not hooks or redux. Use plain old classes. When you felt the pain of distributed mutable state all over place, you will be open to hooks or redux etc. Still, do not add a library for thunks. Only after you realize how much boiler plate code you write to deal with async stuff, you will see a value in the added abstraction. A beginner should start simple, and really feel the pain. Only then will there be an "a-ha!" moment where you can judge if a library/framework actually helps you and provides value. The biggest issue in FE world is people proclaiming some given conglomerate of a library/framework soup as the silver bullet to all problems.

ZephyrBlu 6y ago

I think this is an unfair characterization. Once you understand hooks in general, any specific hook should be quite straightforward so they can collapse into one. Hooks are quite novel, but I don't find them to be overly complicated unless you're dealing with an already complex situation. Dispatch, actions and reducers can be collapsed into one since they rely on each other. I think this paradigm is not too dissimilar to message passing with something like RabbitMQ. Reducers are a common concept. Ducks and Actions, Epics and Sagas are just a convention. It's not required to use React or Redux. If you try to learn everything at once, of course you're going to get overwhelmed. But the same is true for almost any area of Software Engineering.

nwienert 6y ago
I think it’s totally fair. I discourage redux and all related patterns for this very reason. Well that, and I think local state is actually a good thing (and moving state out into separate files a bad thing). To me the proxy object (or proxy class) is really the best abstraction - much like valtio. Or a compiler like svelte. There’s no reason for ducks, epics, sagas, etc etc. We have a programming language already, we should use it.
- ZephyrBlu 6y ago
  It sounds like you're agreeing with me. You don't need everything up front, so listing everything is a bit disingenuous. It's the same explaining a fully kitted out backend (Routing, caching, authentication, etc) and then going "see, it's so complicated!". Well duh, it's a big and complex system. I think the issue with valtio is that there's no central store. As far as I can see, you'll end up having these proxies scattered around your codebase or you'll end up re-creating Redux and centralizing them. Also, I have ironically never heard of valtio.
  - nwienert 6y ago
    Agreeing how? By using valtio you avoid needing to know most of that list, by using redux you.. don't. Also, you can easily wrap valtio with: const createStore = (name, store) => { if (window.stores[name]) throw 'store already exists' window.stores = { ...window.stores [name]: valtio(store) } } And boom, you can see every store just like redux.

BadInformatics 6y ago

> Most of those terminologies don't come from a general programming paradigm, but are the domain language of specific libraries. Not really? Most of these concepts can be linked back directly to earlier from CS theory and/or other languages. For example, Redux taking inspiration from FRP and functional lenses, or (most pertinent for this thread) hooks being a facsimile of algebraic effects in JS. As much as I like these concepts in general, I feel some go too far against the grain of what is idiomatic in the language and incur unnecessary friction/spooky action at a distance because of it. For example, here [1] are some well thought-out critiques of hooks and why people struggle with them from experienced JS framework authors. [1] https://news.ycombinator.com/item?id=22903967 https://news.ycombinator.com/item?id=22903967

avodonosov 6y ago

Novel - not, in my opinion. How to do GUI is known from 1970-ties. Today's single page apolication frameworks slowly re-discover the wheel. It is funny to observe.

littlecranky67 6y ago
The very important difference is that we do distributed systems now (admitted, X originally was also distributed, but only the drawing/events parts, not on the data level). A SPA is a distributed system, with all its drawbacks & pitfalls. If you ever did VB development in the 90s, you will know how easy it was to get a basic app running with those fancy Drag'n'Drop RAD tools. But there was no networking, everything worked offline. But then came the web and the networks, and now everything has to be a distributed system.
- abraxas 6y ago
  There absolutely was a remote part to most VB6 apps. Usually they fetched data from some MS flavour of a RDBMS. Of course they were desktop apps and had to be installed individually but this “webify everything” mania seems to have smothered all dev productivity and experience on its altar.
  - littlecranky67 6y ago
    Yes, and I remember precisely how many apps just encoded the DB credentials inside of the code - with no access/rights abstraction whatsoever. So basically godmode. Thats why we use service layers in Apps today (REST, SOAP etc.) instead of granting a user's process godmode access to the DB.
    - avodonosov 6y ago
      Why godmode? If your DB user is restricted to specific tables and columns, he is controlled. If you eventually get access to the data, does not matter how many layers are in-between (REST, SOAP). You still got the data, so that's a "god mode" in the same sense.

qudat 6y ago

5 of those items are the same thing (hooks). Dispatch is how you emit an event (pub in pub/sub). Action is the event being emitted. Ducks is a code organization paradigm (colocation, organize by feature instead of layer). Reducers are what they sound like: a reduce function. Sagas and observables are how to perform side-effects in your application. There is nothing new here. You could argue that hooks are the weird ones but they are heavily inspired by algebraic effects.

_the_inflator 6y ago

You are talking about React here, not Frontend in general. Angular has different concepts. Steep at the beginning, but in my point of view easier in the long term with a stable API. I agree. Frontend is tough, but so is development. ;)

j-krieger 6y ago

So what. I've been a backend dev before I turned to front-end and web stuff. React has like a dozen top level functions and approaches. No backend project I have ever seen was this simple to program. How much more simple does it have to get before people stop complaining?

littlecranky67 6y ago
No-Code is what they look for :)
- nsonha 6y ago
  Didn't they have dreamweaver and flash but thrown them away regardless.

littlecranky67 6y ago

This is nothing Frontend or JS specific. I've been around in BE (c#) long enough, and the "new shit" adds also terminologies that have nothing todo with C#/.NET itself and were basically "unknown" to any C# developer (or Java for that sake) 10 years ago: - Dependency Injection/IoC - Containers, Resolvers, Scopes - Microservices (Circuit Breaker anyone?) - DDD + CQRS (i could fill a whole page with terms coined by those) - Mediator Pattern etc. If you buy into a certain techstack, it will always bring associated patterns that have nothing to do with the original language/idiom.