5 ms·

> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies... > ... > b) the 300 tracking scripts every site has to try to squee

> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies... > ... > b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible Having seen the dynamics up close, I'd say it's far closer to the truth to say that the reason developers don't have time for a) is because they are having to spend all their time on things like b). I've not met a developer who doesn't want to build a better experience. I have met many developers who can't do so, for reasons outside their control. Characterising it as "if the developer cares" puts the blame in entirely the wrong place.

soulofmischief 2y ago
It's both. The majority of web developers today suck, plain and simple. They thought they could make a lot of money doing web dev and don't approach engineering as an art form or a science. They just scrape by and do not level up on their own outside of or during work. I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together. Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.
- injidup 2y ago
  > React is a nightmare ... culture of shaming developers who haven't switched to the new React paradigm-of-the-year proceeds to shame and suggests changing to the new paragdigm of the year. > For a framework meant for serious adults
  - soulofmischief 2y ago
    I have been using mithril for a decade. It isn't the new paradigm of the year. It's been API stable for a long time. And the sentence you quoted is a dig at React and the React ecosystem, not individual developers. Nice try, though!
  - RUnconcerned 2y ago
    mithril is hardly the new paradigm of the year
- bryanrasmussen 2y ago
  I'd think it has about 60% cohesive vision, but that's just a ballpark, 0 seems way to low though.
  - soulofmischief 2y ago
    Fair. I'm curious, what do you think are the best-designed and most cohesive parts of React?
    - bryanrasmussen 2y ago
      The idea of JSX is I think genius. If I were making a component rendering type library before React I would probably end up making some fake attributes on HTML elements the way Angular and a lot of other people do. It's a pretty simple idea. Pretty much everybody was doing it about the time of Backbone and Angular etc. etc. I'm sure you can think of other examples. But whoever first came up with JSX said hey, if we're already making non standard HTML why not go all the way, allow you make your own semantic tree that we "render down" to HTML. This of course allows you in fact separate out the media target - HTML, Native App, PDF, graphics from your renderable representation of that in code, and thus have different renderers for the same declarative way of structuring content. https://github.com/chentsulin/awesome-react-renderer https://github.com/chentsulin/awesome-react-renderer So to me JSX is actually a sensible step up in abstraction layer, although not all the way yet, because you still need to have lots of specific knowledge of your particular media rendering target. This is perhaps of particular interest to me as in about 2004 I was working on a media management system where the idea was you would feed in multiple markup formats, and a configuration for the media, and then use an in house declarative language to dynamically do things in each media, without having to have much understanding of how the media worked internally because our rendering pipeline took care of that - generated pdf, DHTML website (fancy menus), HTML help, and emails - with of course possibility of saving data for reuse in different media and cross media styling (use same company logos, color schemes, email addresses without having to write code for them in each media etc.) sorry about last part, old programmer wandering.
      - 2y ago
- johnisgood 2y ago
  > The majority of web developers today suck Because they are what we called script kiddies back then, copy-pasting from SO and now LLMs. I do not even know if they would classify as "junior" devs. This does not apply to ALL web developers, but many.
  - maccard 2y ago
    They still existed and wrote shitty code 20 years ago, or 30 years ago.
- branko_d 2y ago
  > Also, React is a nightmare. I think React is a “nightmare” in similar way that JavaScript is a ”nightmare” - it certainly can be, if you abuse it, and it makes it a little too easy to do so. However, you can take “just the good parts” and ignore the rest. For me, that means using React as a rendering library and managing state almost entirely outside of it.
- lexlash 2y ago
  I've introduced mithril at three different companies to audiences of non-UX engineers and it went well each time, resulting in small, static, API-driven single page applications. For my Software Engineering class, I'm able to get the basics across in a day and let students iterate without having to set up build tools for them. Huge fan. React seems to be a self-perpetuating ecosystem at this point, and I keep reading about the next framework-of-the-month being tied to a specific vendor or having an uncertain future with funding/bugs/forks. https://mithril.js.org/ https://mithril.js.org/
cbm-vic-20 2y ago
I've seen this happen many times: Dev: Hey, I added that screen you asked for- take a look and tell me what you think- any layout changes, wording, etc. PM: Looks great! Okay, the next thing is... Dev: Hold on! I need to go back and clean up some of the code I put in there to test a few ideas, and there's a loop in there that has some side effects if some if the timing is off. PM: This looks fine. Let's move on to the next thing..
- tonyedgecombe 2y ago
  Isn't this one of the main selling points of apps like Balsamiq, you can present something that looks sketch like rather than a completed page. https://balsamiq.com/product/ https://balsamiq.com/product/
  - pmontra 2y ago
    When starting from scratch: yes. When maintaining a mature application: no, because then you need to keep in sync the app and balsamiq and there is neither the time nor the will for that. And the money.
    - edoceo 2y ago
      I'm still designing on paper with crayons (not a joke)
      - worthless-trash 2y ago
        I design with pencils, but I thought crayons would give the PM something to chew on when there is technical discussion. Are your designs huge ?
        edoceo 2y ago
        One screen per paper I print with special guides. So, I've got various resolution represented. The I just take pictures of the drawings, load them into this webtool and connect them together. Like a super low budget Balsamiq
friendzis 2y ago
How can you close the ticket without "taking any time to optimize, lazy load, cache, minimize dependencies..." if that is in the AC/DoD? Why don't those developers that care put important things the AC/DoD?
- HappMacDonald 2y ago
  Maybe they're not doing Scrum?
maccard 2y ago
I’ve worked with plenty of developers who will argue that it’s fine on their development environment and their machine on the same network with test data and that it must be $OTHER_TEAM who is causing it. Arguably more of them than ones who really care. The problem is it only takes 2-3 of those people to bring the whole thing crashing down.
ikurei 2y ago
That's a good point. I didn't mean to demean React developers: I've been one for years and I can't say I optimized everything I could've. The blame for not caring enough about performance and UX is on the whole industry. That does include developers, but not just them.

soulofmischief 2y ago

It's both. The majority of web developers today suck, plain and simple. They thought they could make a lot of money doing web dev and don't approach engineering as an art form or a science. They just scrape by and do not level up on their own outside of or during work. I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together. Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.

injidup 2y ago
> React is a nightmare ... culture of shaming developers who haven't switched to the new React paradigm-of-the-year proceeds to shame and suggests changing to the new paragdigm of the year. > For a framework meant for serious adults
- soulofmischief 2y ago
  I have been using mithril for a decade. It isn't the new paradigm of the year. It's been API stable for a long time. And the sentence you quoted is a dig at React and the React ecosystem, not individual developers. Nice try, though!
- RUnconcerned 2y ago
  mithril is hardly the new paradigm of the year
bryanrasmussen 2y ago
I'd think it has about 60% cohesive vision, but that's just a ballpark, 0 seems way to low though.
- soulofmischief 2y ago
  Fair. I'm curious, what do you think are the best-designed and most cohesive parts of React?
  - bryanrasmussen 2y ago
    The idea of JSX is I think genius. If I were making a component rendering type library before React I would probably end up making some fake attributes on HTML elements the way Angular and a lot of other people do. It's a pretty simple idea. Pretty much everybody was doing it about the time of Backbone and Angular etc. etc. I'm sure you can think of other examples. But whoever first came up with JSX said hey, if we're already making non standard HTML why not go all the way, allow you make your own semantic tree that we "render down" to HTML. This of course allows you in fact separate out the media target - HTML, Native App, PDF, graphics from your renderable representation of that in code, and thus have different renderers for the same declarative way of structuring content. https://github.com/chentsulin/awesome-react-renderer https://github.com/chentsulin/awesome-react-renderer So to me JSX is actually a sensible step up in abstraction layer, although not all the way yet, because you still need to have lots of specific knowledge of your particular media rendering target. This is perhaps of particular interest to me as in about 2004 I was working on a media management system where the idea was you would feed in multiple markup formats, and a configuration for the media, and then use an in house declarative language to dynamically do things in each media, without having to have much understanding of how the media worked internally because our rendering pipeline took care of that - generated pdf, DHTML website (fancy menus), HTML help, and emails - with of course possibility of saving data for reuse in different media and cross media styling (use same company logos, color schemes, email addresses without having to write code for them in each media etc.) sorry about last part, old programmer wandering.
    - 2y ago
johnisgood 2y ago
> The majority of web developers today suck Because they are what we called script kiddies back then, copy-pasting from SO and now LLMs. I do not even know if they would classify as "junior" devs. This does not apply to ALL web developers, but many.
- maccard 2y ago
  They still existed and wrote shitty code 20 years ago, or 30 years ago.
branko_d 2y ago
> Also, React is a nightmare. I think React is a “nightmare” in similar way that JavaScript is a ”nightmare” - it certainly can be, if you abuse it, and it makes it a little too easy to do so. However, you can take “just the good parts” and ignore the rest. For me, that means using React as a rendering library and managing state almost entirely outside of it.
lexlash 2y ago
I've introduced mithril at three different companies to audiences of non-UX engineers and it went well each time, resulting in small, static, API-driven single page applications. For my Software Engineering class, I'm able to get the basics across in a day and let students iterate without having to set up build tools for them. Huge fan. React seems to be a self-perpetuating ecosystem at this point, and I keep reading about the next framework-of-the-month being tied to a specific vendor or having an uncertain future with funding/bugs/forks. https://mithril.js.org/ https://mithril.js.org/

cbm-vic-20 2y ago

I've seen this happen many times: Dev: Hey, I added that screen you asked for- take a look and tell me what you think- any layout changes, wording, etc. PM: Looks great! Okay, the next thing is... Dev: Hold on! I need to go back and clean up some of the code I put in there to test a few ideas, and there's a loop in there that has some side effects if some if the timing is off. PM: This looks fine. Let's move on to the next thing..

tonyedgecombe 2y ago
Isn't this one of the main selling points of apps like Balsamiq, you can present something that looks sketch like rather than a completed page. https://balsamiq.com/product/ https://balsamiq.com/product/
- pmontra 2y ago
  When starting from scratch: yes. When maintaining a mature application: no, because then you need to keep in sync the app and balsamiq and there is neither the time nor the will for that. And the money.
  - edoceo 2y ago
    I'm still designing on paper with crayons (not a joke)
    - worthless-trash 2y ago
      I design with pencils, but I thought crayons would give the PM something to chew on when there is technical discussion. Are your designs huge ?
      - edoceo 2y ago
        One screen per paper I print with special guides. So, I've got various resolution represented. The I just take pictures of the drawings, load them into this webtool and connect them together. Like a super low budget Balsamiq

friendzis 2y ago

How can you close the ticket without "taking any time to optimize, lazy load, cache, minimize dependencies..." if that is in the AC/DoD? Why don't those developers that care put important things the AC/DoD?

HappMacDonald 2y ago
Maybe they're not doing Scrum?

maccard 2y ago

I’ve worked with plenty of developers who will argue that it’s fine on their development environment and their machine on the same network with test data and that it must be $OTHER_TEAM who is causing it. Arguably more of them than ones who really care. The problem is it only takes 2-3 of those people to bring the whole thing crashing down.

ikurei 2y ago

That's a good point. I didn't mean to demean React developers: I've been one for years and I can't say I optimized everything I could've. The blame for not caring enough about performance and UX is on the whole industry. That does include developers, but not just them.