3 ms·

I don't think you're alone. I felt the same way about overcomplexity until I had a few runs at working on already established complex frontend codebases. What s

I don't think you're alone. I felt the same way about overcomplexity until I had a few runs at working on already established complex frontend codebases. What seemed to happen around 2008 onward is that the basic principles of the web were sort of simple, but then to do anything at a larger scale it got pretty crazy quite quickly, and so new architecture ideas came along to address that by people who were in the business of solving engineering type architecture problems. For any site of inherently simple interactivity, it's always been as easy if not easier than it ever has, but now it's also more manageable if you know you're going to need to scale a certain way. It doesn't necessarily take all that much before you can start to see the reasoning. For example, take a humble grid of products, each with their own add to wishlist button, and a profile preview button in the corner of the page that indicates how many things are on your wishlist. Pretty simple to handle, render the thumbnails with unique ids and make an XHR request that stores the data with your account. Update the wishlist total count however you would. Now suppose though that each thumbnail in the grid can open a bigger preview dialog that has more images, a bigger description, and it's own add to wishlist button. You can click that button, and it does the same thing. You close the dialog, but now your grid item needs to reflect that it's already been added to the wishlist. These things get really tiresome to keep building, something that I'm sure isn't new to you if as you say, you've been in software a while. Sorry for the book, I mostly wrote that to challenge myself to think it through, not to imply you couldn't think of how it would be necessary to componentize things. I'm not particularly fond of React more than Vue or anything, except for the fact that they both allow you to define UI as collections of functional state machines when it's necessary to do so.

kh_hk 5y ago
On the contrary, I enjoy a good discussion! I do totally get the point of using a framework like React or Vue to manage state on a complex app. I do purposefully call them apps, because websites are a more general term. Hand woven javascript UI, even if it was using an utility framework like mootools could get out of hand pretty easily. I recall things like extjs that were also popular. Following my own example, managing push state by hand was tricky. So I did buy in on the premise that an opinionated way of structuring help and more importantly state was necessary. But I have been consistently failing to learn any new frontend tool ever since. This was not terrible professionally, since I mostly do what most refer to backend or systems. But still it is a bit frustrating not being able to follow along. Maybe it would be easier if this was 'it' when I started learning as sometimes it's difficult to forget and relearn. Speaking of React / Vue codebases, I have thrice tried to contribute some changes or fix a bug on different projects and the amount of boilerplate I had to go through felt completely unnecessary and overkill. Maybe the pattern on these never 'clicked' or I was very unlucky to stumble unto bad examples. It's very easy to dismiss something one does not understand as unnecessary complex so I am still open minded about it. The feeling of disgust when I see the many levels of inference, types and juggling state around for UX that I see as pretty basic persists, though. I like the result, I abhor the execution.
- soneca 5y ago
  I would think that “feeling disgust” and ”being open minded” are mutually exclusive. So my impression from your post is that you are not being honest (to us or to yourself) about being open minded.
  - kh_hk 5y ago
    I do not see why these are exclusive: When I read the code, I can't control feeling disgusted by what I see. Specially how every base starts with an opinionated and strong "this is how it's done" style, just to devolve into copypaste and hacks because someone didn't understand state, reductors, types, dispatchers, ... but I am open minded about acknowledging that the problem might be mine, be it because of stubborness on not getting it, or being extremely unlucky on what projects I stumble upon.
timr 5y ago
> Now suppose though that each thumbnail in the grid can open a bigger preview dialog that has more images, a bigger description, and it's own add to wishlist button. You can click that button, and it does the same thing. You close the dialog, but now your grid item needs to reflect that it's already been added to the wishlist. These things get really tiresome to keep building, something that I'm sure isn't new to you if as you say, you've been in software a while. I've done this many times, using plain-old jQuery and server-side rendering, and it really isn't that hard. The "conventional" way is to (of course), render the preview(s) with classes or data attributes on the updatable elements s.t. you can quickly identify the elements that need to change (say $('.wishlist-count').text(updatedCount) for the sake of argument). For more complex things (let's say you need to be able to insert a complicated, but slightly different, object in the wishlist, for example), you can render a template into the page, dup it on wishlist addition, and populate the variable data in any number of different ways. You can even create JS objects that encapsulate this kind of logic (e.g. Wishlist.add(itemNumber)) without much additional effort. No framework required. Now, I grant you that when you need to do this for many different kinds dynamic elements that all interact in different ways, or when you need to absolutely guarantee minimal re-rendering, you might want to jump to a framework. But I still feel that most front-end people these days instinctively rule out simpler approaches that would work just fine, because they're prematurely optimizing. Or worse...because they simply don't know anything other than React.

kh_hk 5y ago

On the contrary, I enjoy a good discussion! I do totally get the point of using a framework like React or Vue to manage state on a complex app. I do purposefully call them apps, because websites are a more general term. Hand woven javascript UI, even if it was using an utility framework like mootools could get out of hand pretty easily. I recall things like extjs that were also popular. Following my own example, managing push state by hand was tricky. So I did buy in on the premise that an opinionated way of structuring help and more importantly state was necessary. But I have been consistently failing to learn any new frontend tool ever since. This was not terrible professionally, since I mostly do what most refer to backend or systems. But still it is a bit frustrating not being able to follow along. Maybe it would be easier if this was 'it' when I started learning as sometimes it's difficult to forget and relearn. Speaking of React / Vue codebases, I have thrice tried to contribute some changes or fix a bug on different projects and the amount of boilerplate I had to go through felt completely unnecessary and overkill. Maybe the pattern on these never 'clicked' or I was very unlucky to stumble unto bad examples. It's very easy to dismiss something one does not understand as unnecessary complex so I am still open minded about it. The feeling of disgust when I see the many levels of inference, types and juggling state around for UX that I see as pretty basic persists, though. I like the result, I abhor the execution.

soneca 5y ago
I would think that “feeling disgust” and ”being open minded” are mutually exclusive. So my impression from your post is that you are not being honest (to us or to yourself) about being open minded.
- kh_hk 5y ago
  I do not see why these are exclusive: When I read the code, I can't control feeling disgusted by what I see. Specially how every base starts with an opinionated and strong "this is how it's done" style, just to devolve into copypaste and hacks because someone didn't understand state, reductors, types, dispatchers, ... but I am open minded about acknowledging that the problem might be mine, be it because of stubborness on not getting it, or being extremely unlucky on what projects I stumble upon.

timr 5y ago

> Now suppose though that each thumbnail in the grid can open a bigger preview dialog that has more images, a bigger description, and it's own add to wishlist button. You can click that button, and it does the same thing. You close the dialog, but now your grid item needs to reflect that it's already been added to the wishlist. These things get really tiresome to keep building, something that I'm sure isn't new to you if as you say, you've been in software a while. I've done this many times, using plain-old jQuery and server-side rendering, and it really isn't that hard. The "conventional" way is to (of course), render the preview(s) with classes or data attributes on the updatable elements s.t. you can quickly identify the elements that need to change (say $('.wishlist-count').text(updatedCount) for the sake of argument). For more complex things (let's say you need to be able to insert a complicated, but slightly different, object in the wishlist, for example), you can render a template into the page, dup it on wishlist addition, and populate the variable data in any number of different ways. You can even create JS objects that encapsulate this kind of logic (e.g. Wishlist.add(itemNumber)) without much additional effort. No framework required. Now, I grant you that when you need to do this for many different kinds dynamic elements that all interact in different ways, or when you need to absolutely guarantee minimal re-rendering, you might want to jump to a framework. But I still feel that most front-end people these days instinctively rule out simpler approaches that would work just fine, because they're prematurely optimizing. Or worse...because they simply don't know anything other than React.