8 ms·

> You should actually learn the web stack and look at how things work in 2023 instead of reading other people's rants or secondhand opinions to form your own op

> You should actually learn the web stack and look at how things work in 2023 instead of reading other people's rants or secondhand opinions to form your own opinions. I didn't base my response on anybody else's words. I've been around the web since the good old days where jQuery was the norm and everything had a phpBB forum. It's coming from my own experience and observations. > Will this new thing achieve at least 80% of development speed? You're so concerned with development speed, yet you're rewriting the same thing in a new framework every 2 years.

refulgentis 3y ago
OPs right, and it's sort of immature to pretend its all broken and say wildly false things like "you're rewriting the same thing in a new framework every 2 years." Who is? That sounds like a management problem, not a...I don't even know, language problem? Package manager problem?
- ori_b 3y ago
  Stack maturity problem?
ttfkam 3y ago
I've been around the web since document.write() and <font color=red> were cutting edge. You're wrong. There is no way, shape, or form where 2008 web technology is comparable to today. (IE6!!!) Not in styling. Not in consistency. Not in performance. Not in accessibility. Not in security. And certainly not in management of complex sites. A cursory look at caniuse.com should disabuse you of any notion of stagnation or lack of capability. Folks rewrite "every two years" because it gets better so quickly. Svelte/Solid/Qwik are clearly steps forward from React. Were you advocating for sticking with older stuff simply because you don't like change? Or did you think C, Unix, et al technologies were born fully formed as they exist today with no evolutionary steps (and missteps) in between?
- nirvdrum 3y ago
  I think the charitable interpretation is there are a whole class of web sites/applications (news sites, e-commerce, etc.) that haven't appreciably changed in the last 15 years. Yeah, there's been some incremental improvement, but the core experience is the same. However, the versions today are generally resource hogs. It's not rare for me to leave a browser tab open and find it grows to > 2GB RAM. I had one hit 28 GB and it would have kept going if I hadn't killed it. One thing I miss on the M1 is the fan kicking on so I know when a browser tab has run away. I think the OP has a point. We've been building a massively complex ecosystem on a very shaky foundation. The web has indeed advanced, but most of the time it feels like duct taping something onto this monster of a creation. Between backwards compatibility and competing browser vendor concerns, it's hard to push meaningful change through. So many security (especially supply chain) and dependency issues in JS would go away if there were a reasonable standard library. But, there isn't, so we're doomed a large graph of inter-related dependencies that break regularly. The constant churn in frameworks is mostly related to novel ways to work around limitations in the web platform and bridging behavioral differences across browsers. It's more than just churn in frameworks though. It's depressing how many person-years have been spent on build systems and bundlers or CJS vs ES6. Participating in the open source ecosystem means needing to be familiar with all of it, so it's not enough to pick one and run with it. Prior to flexbox, people struggled to center content with CSS; it was bad for layout. There's a ton of old CSS out there, much of it accomplishing the same thing in different ways, often with vendor-specific options. You still run into this if you have to style HTML email. Given the difficulty in mapping CSS back to its usages, it's incredibly challenging to refactor. It requires familiarity with the entire product and a lot of guess work to intent since comments don't exist. Moreover, there have been massive changes in "best practices". React and Tailwind violate the previous principles of unobstructive JS and semantic naming that were the prevailing practices not too long ago. My cynical take is a lot of that is driven by consultants looking to stand out as thought leaders. Regardless, it adds to the complexity of what you need to know if you do have to work with older (often other people's) code. I'm fairly confident that if we had today's use cases in mind when designing the foundational web technologies we'd have a very different platform to work with. It almost certainly would be more efficient, less error-prone, and likely more secure. It'd be nice if we could take a step back and revisit things. A clean break would be painful, but could work. Developers are already building web apps that only work on Chrome, so much as it pains me to say, having to get all the vendors on board isn't entirely necessary.
BSEdlMMldESB 3y ago
> good old days where jQuery ... do you remember IE6? that's before jQuery, the time of ActiveX and java applets you're right that it got better by the time of jQuery... when I started on this (highschool time for me), we was writting HTML by hand. PHP 3 was used in production; PHP 4 was brand spanking new. CGI was a thing, imagine that! C code used to dynamically make HTML stuff, exposed on the web! (through C? gateway interface)
- slater 3y ago
  *Common gateway interface
TheCoreh 3y ago
> You're so concerned with development speed, yet you're rewriting the same thing in a new framework every 2 years. I think that meme gets thrown around a lot, and it used to be true, but the framework churn of JS has largely stopped at this point. A lot of us (me included) have been just using the same stack for several years now. Sure, React has evolved since 2015/2016 (e.g. the move to function components and hooks) but the old code still runs, with minimal to no changes. Patterns and best practices have largely been established. You can entirely avoid the bleeding edge stuff and still be productive.
- nirvdrum 3y ago
  Elsewhere in this thread there are comments about needing to continue pace to move beyond React. I don't think we've seen the end of the churn. I agree that React is a pretty stable base these days and you can just work with that, but it's gotten long in the tooth in places so new frameworks are still sprouting up.
- revelio 3y ago
  Old code continuing to run isn't what people mean by churn though. jquery still runs. The underlying browser APIs are stable. But you can't say React has stable patterns and best practices when the classes->hooks thing has happened so recently.

refulgentis 3y ago

OPs right, and it's sort of immature to pretend its all broken and say wildly false things like "you're rewriting the same thing in a new framework every 2 years." Who is? That sounds like a management problem, not a...I don't even know, language problem? Package manager problem?

ori_b 3y ago
Stack maturity problem?

ttfkam 3y ago

I've been around the web since document.write() and <font color=red> were cutting edge. You're wrong. There is no way, shape, or form where 2008 web technology is comparable to today. (IE6!!!) Not in styling. Not in consistency. Not in performance. Not in accessibility. Not in security. And certainly not in management of complex sites. A cursory look at caniuse.com should disabuse you of any notion of stagnation or lack of capability. Folks rewrite "every two years" because it gets better so quickly. Svelte/Solid/Qwik are clearly steps forward from React. Were you advocating for sticking with older stuff simply because you don't like change? Or did you think C, Unix, et al technologies were born fully formed as they exist today with no evolutionary steps (and missteps) in between?

nirvdrum 3y ago
I think the charitable interpretation is there are a whole class of web sites/applications (news sites, e-commerce, etc.) that haven't appreciably changed in the last 15 years. Yeah, there's been some incremental improvement, but the core experience is the same. However, the versions today are generally resource hogs. It's not rare for me to leave a browser tab open and find it grows to > 2GB RAM. I had one hit 28 GB and it would have kept going if I hadn't killed it. One thing I miss on the M1 is the fan kicking on so I know when a browser tab has run away. I think the OP has a point. We've been building a massively complex ecosystem on a very shaky foundation. The web has indeed advanced, but most of the time it feels like duct taping something onto this monster of a creation. Between backwards compatibility and competing browser vendor concerns, it's hard to push meaningful change through. So many security (especially supply chain) and dependency issues in JS would go away if there were a reasonable standard library. But, there isn't, so we're doomed a large graph of inter-related dependencies that break regularly. The constant churn in frameworks is mostly related to novel ways to work around limitations in the web platform and bridging behavioral differences across browsers. It's more than just churn in frameworks though. It's depressing how many person-years have been spent on build systems and bundlers or CJS vs ES6. Participating in the open source ecosystem means needing to be familiar with all of it, so it's not enough to pick one and run with it. Prior to flexbox, people struggled to center content with CSS; it was bad for layout. There's a ton of old CSS out there, much of it accomplishing the same thing in different ways, often with vendor-specific options. You still run into this if you have to style HTML email. Given the difficulty in mapping CSS back to its usages, it's incredibly challenging to refactor. It requires familiarity with the entire product and a lot of guess work to intent since comments don't exist. Moreover, there have been massive changes in "best practices". React and Tailwind violate the previous principles of unobstructive JS and semantic naming that were the prevailing practices not too long ago. My cynical take is a lot of that is driven by consultants looking to stand out as thought leaders. Regardless, it adds to the complexity of what you need to know if you do have to work with older (often other people's) code. I'm fairly confident that if we had today's use cases in mind when designing the foundational web technologies we'd have a very different platform to work with. It almost certainly would be more efficient, less error-prone, and likely more secure. It'd be nice if we could take a step back and revisit things. A clean break would be painful, but could work. Developers are already building web apps that only work on Chrome, so much as it pains me to say, having to get all the vendors on board isn't entirely necessary.

BSEdlMMldESB 3y ago

> good old days where jQuery ... do you remember IE6? that's before jQuery, the time of ActiveX and java applets you're right that it got better by the time of jQuery... when I started on this (highschool time for me), we was writting HTML by hand. PHP 3 was used in production; PHP 4 was brand spanking new. CGI was a thing, imagine that! C code used to dynamically make HTML stuff, exposed on the web! (through C? gateway interface)

slater 3y ago
*Common gateway interface

TheCoreh 3y ago

> You're so concerned with development speed, yet you're rewriting the same thing in a new framework every 2 years. I think that meme gets thrown around a lot, and it used to be true, but the framework churn of JS has largely stopped at this point. A lot of us (me included) have been just using the same stack for several years now. Sure, React has evolved since 2015/2016 (e.g. the move to function components and hooks) but the old code still runs, with minimal to no changes. Patterns and best practices have largely been established. You can entirely avoid the bleeding edge stuff and still be productive.

nirvdrum 3y ago
Elsewhere in this thread there are comments about needing to continue pace to move beyond React. I don't think we've seen the end of the churn. I agree that React is a pretty stable base these days and you can just work with that, but it's gotten long in the tooth in places so new frameworks are still sprouting up.
revelio 3y ago
Old code continuing to run isn't what people mean by churn though. jquery still runs. The underlying browser APIs are stable. But you can't say React has stable patterns and best practices when the classes->hooks thing has happened so recently.