5 ms·

Not OP, but front end JavaScript frameworks are the first thing that comes to mind as an inefficient antipattern that was forced into the dev mindshare by (effe

Not OP, but front end JavaScript frameworks are the first thing that comes to mind as an inefficient antipattern that was forced into the dev mindshare by (effective) mega-cap marketing and jr devs who didn’t know any better.

vbezhenar 4y ago
You may call me junior, although I have over 10 years of programming at different things. But IMO React is hands down best thing happened with frontend. It's beautiful tech. Sometimes I write javascript without frameworks, but I'm doing it just for fun, because I have strange love for tiny code, when entire "webapp" fits in few kilobytes. That's something like demo scene from the old days. I'll never do that for any commercial project. Right now my position is something like tech lead, at least I do technical decisions in our company. And there's no way I'll allow to write anything complex without React. And sites are bad not because of React. Sites are bad because of other things. If anything, React helps making sites less bad. Second best thing is TypeScript. I don't like tooling, though, but I think it gets better.
ericwooley 4y ago
The entire concept of fronted frameworks is an anti pattern? This might be the oldest, grumpiest man on the front lawn yelling at childreniest take we on web dev, that I’ve ever heard
- fezfight 4y ago
  You have to at least admit that there's an awful lot of stuff done these days to render what used to be done with html.
  - TheCoelacanth 4y ago
    It's not what used to be done with HTML. It's what used to be done with desktop GUI toolkits. Web apps were never this complex before the creation of frontend web frameworks.
    - fezfight 4y ago
      Yes, that's the point I'm trying to make. At the end of the incredibly complex and long modern road, you end up looking at text, images, etc, in a browser.
      - shadowgovt 4y ago
        At the end of an incredibly complex and long modern road, I end up looking at text and images in any application, but I wouldn't wish upon the developers of, say, IntelliJ that they render the user interface by making their own JNI calls directly to "draw a rectangle" APIs...
        fezfight 4y ago
        I agree that would be ridiculous, but I'm talking about people using some huge front end library, react, k8s, etc, to make a form. With a logo. Obviously do whatever you want, but it's a lot.
        shadowgovt 4y ago
        A form with a logo... that looks consistent across most browsers, scales automatically between mobile and desktop user-agents, and already has all its sticky a11y metadata sorted properly, if they've picked a good framework. The gap between modern expectations and the bare-bones AJAX page is pretty wide these days. It would definitely be better if there were a way to side-load those libraries as a standardized strata underneath the main browser content to save resources. So if someone uses React to do their form, yes it seems costly but the cost only needs to be paid once, and then the relevant framework is cached more statically than the transient web cache (and with an alternative to domain-based cache, such as checksums or signed binaries, to determine if two domains are using the same framework and save the download cost for all sites you visit using that framework). ... but only better if the tricky engineering questions around caching were sorted. There's plenty of risk that you'd end up with gigabytes of cached frameworks, because the current solution means I don't have to care if one site is using React 12 and another is using React 12.1.
- chrischattin 4y ago
  Yep. Duplicating the data model on the client and server is just one example of the insanity. I could go on, but that’s for another day.
progrus 4y ago
I’ve been programming ~15 years, and from my perspective, those frameworks helped us move on from a world riddled with XSS, “better than fail whale”-level reliability expectations, and software ossification (Gmail, Facebook, etc). Today, the frameworks bite me in the ass about once a week, but I think it’s worth it to get safe React with strict TypeScript, and plenty besides. Caveat: All infrastructure requires a lot of maintenance, though! YAGNI still applies, and hopefully you have (or are on) a team dedicated to supporting the tools that you do need.
- chrischattin 4y ago
  ??? XSS has long been a solved problem. Security is definitely not an argument for using front end JS frameworks as they add attack vectors and complication to the stack.
  - progrus 4y ago
    Is your solution something like “always remember to sanitize user-generated content”?
  - dc-programmer 4y ago
    It’s definitely not a solved problem. Most developers absolutely would not escape their outputs if left to their own devices
  - shadowgovt 4y ago
    Assuming your entrypoints are typed, TypeScript makes it much harder to accidentally mishandle data of the wrong type and frameworks make it much harder to inadvertently change state at a distance in a way that was unintended. These are the two most common ways that undesired behaviors are introduced to JavaScript UIs.

vbezhenar 4y ago

You may call me junior, although I have over 10 years of programming at different things. But IMO React is hands down best thing happened with frontend. It's beautiful tech. Sometimes I write javascript without frameworks, but I'm doing it just for fun, because I have strange love for tiny code, when entire "webapp" fits in few kilobytes. That's something like demo scene from the old days. I'll never do that for any commercial project. Right now my position is something like tech lead, at least I do technical decisions in our company. And there's no way I'll allow to write anything complex without React. And sites are bad not because of React. Sites are bad because of other things. If anything, React helps making sites less bad. Second best thing is TypeScript. I don't like tooling, though, but I think it gets better.

ericwooley 4y ago

The entire concept of fronted frameworks is an anti pattern? This might be the oldest, grumpiest man on the front lawn yelling at childreniest take we on web dev, that I’ve ever heard

fezfight 4y ago
You have to at least admit that there's an awful lot of stuff done these days to render what used to be done with html.
- TheCoelacanth 4y ago
  It's not what used to be done with HTML. It's what used to be done with desktop GUI toolkits. Web apps were never this complex before the creation of frontend web frameworks.
  - fezfight 4y ago
    Yes, that's the point I'm trying to make. At the end of the incredibly complex and long modern road, you end up looking at text, images, etc, in a browser.
    - shadowgovt 4y ago
      At the end of an incredibly complex and long modern road, I end up looking at text and images in any application, but I wouldn't wish upon the developers of, say, IntelliJ that they render the user interface by making their own JNI calls directly to "draw a rectangle" APIs...
      - fezfight 4y ago
        I agree that would be ridiculous, but I'm talking about people using some huge front end library, react, k8s, etc, to make a form. With a logo. Obviously do whatever you want, but it's a lot.
        shadowgovt 4y ago
        A form with a logo... that looks consistent across most browsers, scales automatically between mobile and desktop user-agents, and already has all its sticky a11y metadata sorted properly, if they've picked a good framework. The gap between modern expectations and the bare-bones AJAX page is pretty wide these days. It would definitely be better if there were a way to side-load those libraries as a standardized strata underneath the main browser content to save resources. So if someone uses React to do their form, yes it seems costly but the cost only needs to be paid once, and then the relevant framework is cached more statically than the transient web cache (and with an alternative to domain-based cache, such as checksums or signed binaries, to determine if two domains are using the same framework and save the download cost for all sites you visit using that framework). ... but only better if the tricky engineering questions around caching were sorted. There's plenty of risk that you'd end up with gigabytes of cached frameworks, because the current solution means I don't have to care if one site is using React 12 and another is using React 12.1.
chrischattin 4y ago
Yep. Duplicating the data model on the client and server is just one example of the insanity. I could go on, but that’s for another day.

progrus 4y ago

I’ve been programming ~15 years, and from my perspective, those frameworks helped us move on from a world riddled with XSS, “better than fail whale”-level reliability expectations, and software ossification (Gmail, Facebook, etc). Today, the frameworks bite me in the ass about once a week, but I think it’s worth it to get safe React with strict TypeScript, and plenty besides. Caveat: All infrastructure requires a lot of maintenance, though! YAGNI still applies, and hopefully you have (or are on) a team dedicated to supporting the tools that you do need.

chrischattin 4y ago
??? XSS has long been a solved problem. Security is definitely not an argument for using front end JS frameworks as they add attack vectors and complication to the stack.
- progrus 4y ago
  Is your solution something like “always remember to sanitize user-generated content”?
- dc-programmer 4y ago
  It’s definitely not a solved problem. Most developers absolutely would not escape their outputs if left to their own devices
- shadowgovt 4y ago
  Assuming your entrypoints are typed, TypeScript makes it much harder to accidentally mishandle data of the wrong type and frameworks make it much harder to inadvertently change state at a distance in a way that was unintended. These are the two most common ways that undesired behaviors are introduced to JavaScript UIs.