> Those ramps are going to die and get replaced by new ones. It's part of technological progress.
That completely misses the point. This makes sense as technology changes, however, HTML and CSS are not dramatically different now than they were 20 years ago. Despite that lack of significant difference the approach and entry points have radically changed and continue to change. This is problematic for a number of reasons addressed in the article.
The article touched on only one of the two biggest problems. The article did a great job talking about the churn every couple of years and the associated disconnect between a former group and a later group of developers. That disconnect is incredibly understated and important.
The article fails to talk about performance. Many sites today are not more performant than sites more than a decade ago even though hardware and JavaScript are orders of magnitude faster. If everything is 10s or 100s of times faster and yet the end products remain the same what got lost? The technology got lost behind layers of abstractions. These abstractions, in almost every case, don't exist to supplement (enhance) the technology. They exist to supplement the developer.
My personal single page app pushes nearly 1.5mb of JavaScript doing really heavy computing to the user and yet the site is still fully loaded in about 1.6s. The techniques I use scares the shit out of younger developers, because they are old and primitive (and yet stupid fast). I can remember the last big dot com I worked at struggled to get back down to 16s homepage load from 24s even though there is very little code doing anything the user would care for on site load.
> there is something deeper and more worrying than a company having to throw away a couple of years of work and rebuild because they can’t support a poorly chosen framework.
In my experience every framework or technology stack becomes poorly chosen on a long enough timeline by the incoming developers. Consider other solutions before thinking about abstraction, abstract only as an exception to policy, and then document the measured costs.
Consider the current most popular web abstraction: React. There are now numerous abstractions for React. It is only a matter of time before those abstractions over abstractions have their own abstractions until somebody wants to reinvent the framework again. People now spend more time and energy learning the abstractions than I spent learning the base technologies, but then difference is that my comfort with the base technologies allows me to spit out a solution in less time, that is smaller, and performs faster to the shock and disgust of framework advocates. That makes perfect sense realizing that the abstractions are there to supplement the technology but to supplement the developer.
That completely misses the point. This makes sense as technology changes, however, HTML and CSS are not dramatically different now than they were 20 years ago. Despite that lack of significant difference the approach and entry points have radically changed and continue to change. This is problematic for a number of reasons addressed in the article.
The article touched on only one of the two biggest problems. The article did a great job talking about the churn every couple of years and the associated disconnect between a former group and a later group of developers. That disconnect is incredibly understated and important.
The article fails to talk about performance. Many sites today are not more performant than sites more than a decade ago even though hardware and JavaScript are orders of magnitude faster. If everything is 10s or 100s of times faster and yet the end products remain the same what got lost? The technology got lost behind layers of abstractions. These abstractions, in almost every case, don't exist to supplement (enhance) the technology. They exist to supplement the developer.
My personal single page app pushes nearly 1.5mb of JavaScript doing really heavy computing to the user and yet the site is still fully loaded in about 1.6s. The techniques I use scares the shit out of younger developers, because they are old and primitive (and yet stupid fast). I can remember the last big dot com I worked at struggled to get back down to 16s homepage load from 24s even though there is very little code doing anything the user would care for on site load.
> there is something deeper and more worrying than a company having to throw away a couple of years of work and rebuild because they can’t support a poorly chosen framework.
In my experience every framework or technology stack becomes poorly chosen on a long enough timeline by the incoming developers. Consider other solutions before thinking about abstraction, abstract only as an exception to policy, and then document the measured costs.
Consider the current most popular web abstraction: React. There are now numerous abstractions for React. It is only a matter of time before those abstractions over abstractions have their own abstractions until somebody wants to reinvent the framework again. People now spend more time and energy learning the abstractions than I spent learning the base technologies, but then difference is that my comfort with the base technologies allows me to spit out a solution in less time, that is smaller, and performs faster to the shock and disgust of framework advocates. That makes perfect sense realizing that the abstractions are there to supplement the technology but to supplement the developer.