4 ms·

Every time I try to do something with modern JS I'm reminded of this blog post (https://peterxjang.com/blog/modern-javascript-explained-for-dinosaurs.html https

by agufal 3y ago

Every time I try to do something with modern JS I'm reminded of this blog post (https://peterxjang.com/blog/modern-javascript-explained-for-dinosaurs.html https://peterxjang.com/blog/modern-javascript-explained-for-...) And also every time I end up giving up because it's so damn complex

firecall 3y ago
It’s bonkers. I’m sure there is some sort of collective delusion. I’m currently fixing a React app for client. I’m convinced the previous “Dev Team” had no idea how it all actually worked. It’s all so fragile they seemed to never be able to change anything with breaking something.
- graftak 3y ago
  Just imagine what those devs would make without a framework.
  - noman-land 3y ago
    No framework is going to teach someone how to design a complex application that not only does everything it's supposed to, but does it well, and lends itself well to extension and modification over time by a constantly changing array of people. That takes years of experience, an excellent engineering culture and a well designed infrastructure. You can't expect React to do that. It's just a tool. React takes a developer from zero to one very quickly, but the rest is the craft.
xerxesaa 3y ago
I agree it can be very confusing to set all of this up from scratch, but if you're using something like Vue CLI, all of these dependencies and configs are generated for you.
- hstaab 3y ago
  IMO this only kicks the can down the road. I like to understand my build system from the beginning; these project-init scripts change so frequently.
  - ttfkam 3y ago
    Only if you upgrade. ;-) If you stay on the same version of the init script, you're still marginally better than rolling your own. On the other hand, if you learn it once and then allow updates to occur, you'll still understand the process in the abstract. You'll just have to let go of the notion of knowing all details of your stacks from top to bottom. This is why we have teams and specializations. Computing long ago exceeded typical human capacity for complete knowledge. Now we learn as much as we can including the wisdom of who to trust when the solution is bigger than we can individually muster. We trust compilers and browsers and libraries and frameworks all the time. When they break, hopefully the broken area is in our wheelhouse or at least well-documented. But the issue of complexity isn't going away if we want to continue making forward progress. My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for. Change happens. "Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
    - moritzwarhier 3y ago
      I agree with everything you wrote. Also, things seem to be converging towards simplicity in a positive way, comparing e.g. Vite to Webpack. But without any disagreement: the churn is real. Not upgrading is only an option if you 1) are sure you don't run vulnerable code on a server (e.g. through SSR) - if any code is public-facing, ignoring most "npm audit" reports ceases to be an option. 2) don't need new packages to change your build setup that are significantly newer than your previous setup. To repeat, I don't disagree and I prefer the spirit of your comment to my critique. Almost all of the time it is a good idea to settle on versions and evaluate when upgrading is worth it. Update costs can also vary a lot depending on the project. In other words, preserving behavior while fixing dependency conflicts, breaking changes etc after updating major versions. If one avoids to do clever stuff with the bundler and if the project requirements are simple, it can be easy upgrade or even swap tools (e.g. Webpack for Vite). This rings very true for me, bravo: > My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for. > Change happens. > "Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
ttfkam 3y ago
Except just needing HTML, CSS, and JS was never true. Back in 1995, JS and CSS didn't exist. But Perl did, which is what most cgi-bin scripts were written in. Then you had to learn mod_perl after you figured out Apache's crazy non-regular config file format. (Are you markup or not?! Pick a lane!). Build scripts? LOL! Learn FTP sucka, and copy those files manually. Wait… now I'm on a Windows server? What in the hell is ISAPI? Now you want to send an email from that contact form on your site? Better learn how to set up sendmail servers. (WTF is m4? I need a macro language to generate the config file for my email server?!) document.write("Hello World!"); Fast forward to 2004. Firefox (or was it Phoenix?) is hoping to slowly wrench dominance away from IE, but for now frontend devs gotta know ActiveX (insecure), Java applets (slow as molasses), and Macromedia Flash (you've got a DSL connection, right?). Don't forget JS has competition in VBScript. And oh, those .htc behavior files. All the old <font color=red> and table-based layouts are passé, and folks are demanding they be rewritten in that cool CSS now that Netscape 4 usage is officially dead. Still gotta fit those PDFs in sometimes though. HTML is looking drab compared to that XML hotness. Better get on board with XHTML! Scratch that! All the XML flavors: XSLT, XSL:FO, SOAP, XML Schema (or RelaxNG for the cool kids), XPath, SAX, X-Force! (Okay, maybe not that last one.) Firefox is getting better so much faster than IE, so don't forget to polyfill all the things. Jump to 2010. We've got more browser engines than we know what to do with and they all render differently. Maybe not a lot in this one case, but different enough. Bring on the JSON! The rise of JS libraries brings us the choices of Prototype (the OG, but already obsolete), YUI, Jquery, and a new entry every month at least. Tree shaking? CI/CD? What crazy talk are you spouting now? I'm just barely handling minification and manual image optimization. ----- Thank [deity] things today aren't as complex as they were back then! To quote BSG: "This has all happened before. And it will happen again."

by agufal 3y ago

firecall 3y ago

It’s bonkers. I’m sure there is some sort of collective delusion. I’m currently fixing a React app for client. I’m convinced the previous “Dev Team” had no idea how it all actually worked. It’s all so fragile they seemed to never be able to change anything with breaking something.

graftak 3y ago
Just imagine what those devs would make without a framework.
- noman-land 3y ago
  No framework is going to teach someone how to design a complex application that not only does everything it's supposed to, but does it well, and lends itself well to extension and modification over time by a constantly changing array of people. That takes years of experience, an excellent engineering culture and a well designed infrastructure. You can't expect React to do that. It's just a tool. React takes a developer from zero to one very quickly, but the rest is the craft.

xerxesaa 3y ago

I agree it can be very confusing to set all of this up from scratch, but if you're using something like Vue CLI, all of these dependencies and configs are generated for you.

hstaab 3y ago
IMO this only kicks the can down the road. I like to understand my build system from the beginning; these project-init scripts change so frequently.
- ttfkam 3y ago
  Only if you upgrade. ;-) If you stay on the same version of the init script, you're still marginally better than rolling your own. On the other hand, if you learn it once and then allow updates to occur, you'll still understand the process in the abstract. You'll just have to let go of the notion of knowing all details of your stacks from top to bottom. This is why we have teams and specializations. Computing long ago exceeded typical human capacity for complete knowledge. Now we learn as much as we can including the wisdom of who to trust when the solution is bigger than we can individually muster. We trust compilers and browsers and libraries and frameworks all the time. When they break, hopefully the broken area is in our wheelhouse or at least well-documented. But the issue of complexity isn't going away if we want to continue making forward progress. My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for. Change happens. "Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
  - moritzwarhier 3y ago
    I agree with everything you wrote. Also, things seem to be converging towards simplicity in a positive way, comparing e.g. Vite to Webpack. But without any disagreement: the churn is real. Not upgrading is only an option if you 1) are sure you don't run vulnerable code on a server (e.g. through SSR) - if any code is public-facing, ignoring most "npm audit" reports ceases to be an option. 2) don't need new packages to change your build setup that are significantly newer than your previous setup. To repeat, I don't disagree and I prefer the spirit of your comment to my critique. Almost all of the time it is a good idea to settle on versions and evaluate when upgrading is worth it. Update costs can also vary a lot depending on the project. In other words, preserving behavior while fixing dependency conflicts, breaking changes etc after updating major versions. If one avoids to do clever stuff with the bundler and if the project requirements are simple, it can be easy upgrade or even swap tools (e.g. Webpack for Vite). This rings very true for me, bravo: > My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for. > Change happens. > "Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"

ttfkam 3y ago

Except just needing HTML, CSS, and JS was never true. Back in 1995, JS and CSS didn't exist. But Perl did, which is what most cgi-bin scripts were written in. Then you had to learn mod_perl after you figured out Apache's crazy non-regular config file format. (Are you markup or not?! Pick a lane!). Build scripts? LOL! Learn FTP sucka, and copy those files manually. Wait… now I'm on a Windows server? What in the hell is ISAPI? Now you want to send an email from that contact form on your site? Better learn how to set up sendmail servers. (WTF is m4? I need a macro language to generate the config file for my email server?!) document.write("Hello World!"); Fast forward to 2004. Firefox (or was it Phoenix?) is hoping to slowly wrench dominance away from IE, but for now frontend devs gotta know ActiveX (insecure), Java applets (slow as molasses), and Macromedia Flash (you've got a DSL connection, right?). Don't forget JS has competition in VBScript. And oh, those .htc behavior files. All the old <font color=red> and table-based layouts are passé, and folks are demanding they be rewritten in that cool CSS now that Netscape 4 usage is officially dead. Still gotta fit those PDFs in sometimes though. HTML is looking drab compared to that XML hotness. Better get on board with XHTML! Scratch that! All the XML flavors: XSLT, XSL:FO, SOAP, XML Schema (or RelaxNG for the cool kids), XPath, SAX, X-Force! (Okay, maybe not that last one.) Firefox is getting better so much faster than IE, so don't forget to polyfill all the things. Jump to 2010. We've got more browser engines than we know what to do with and they all render differently. Maybe not a lot in this one case, but different enough. Bring on the JSON! The rise of JS libraries brings us the choices of Prototype (the OG, but already obsolete), YUI, Jquery, and a new entry every month at least. Tree shaking? CI/CD? What crazy talk are you spouting now? I'm just barely handling minification and manual image optimization. ----- Thank [deity] things today aren't as complex as they were back then! To quote BSG: "This has all happened before. And it will happen again."