3 ms·

There is a complicating factor for a Web developer's personal Web site: resumé-driven-development (RDD). For those professionals who try to use personal side p

by neilv 2y ago

There is a complicating factor for a Web developer's personal Web site: resumé-driven-development (RDD). For those professionals who try to use personal side projects for RDD, so that they don't have to sabotage as many employers' projects as they would otherwise. Which leads me to this morning, for example... For an indie Web site I'm about to launch -- and for which I'm using a popular modern Web framework, mainly for RDD reasons -- I could no longer update my Web site. Because an NPM package had a Critical security problem, and trying to get the update got NPM stuck with some interdependency conflict that couldn't be resolved automatically. (Which, ironically, prevented pushing the security update to the production site.) The site could be 5 simple handwritten HTML files, one with a sprinkling of JS inline in it, plus 2 small Perl CGI scripts. And it would work perfectly for 25 years and counting. Instead, it's 129 NPM packages, frequently needing security updates, and a large tree of cryptic source files (template fragments, TS configurations, handlers), just for the NodeJS part of the site alone. But doing it the ridiculously complex way is something that professionals can't afford not to do. (For example, having Perl on your resumé would be the kiss of death for employability. The people who didn't throw away your resume for ageism reasons, would still think you must be an idiot for not doing RDD.)

wruza 2y ago
The site could be 5 simple handwritten HTML files, one with a sprinkling of JS inline in it, plus 2 small Perl CGI scripts. And it would work perfectly for 25 years and counting. Or it could be something in between, because it’s convenient to do so. In my case, I couldn’t care less of resumes and offers, but still I want something more ergonomic than spitting out htmls from templates in js/python. So my sites are a mix of typescript, mithril, express and a few utility libs. Idk and don’t care how many packages it is, as long as my main imports are mature and don’t give birth to a new feature-vulnerability every few minutes. You never mentioned your stack, but it’s a safe guess that it’s react and its ecosystem of always-improving-never-done bullshit. My completely unsolicited advice here is to avoid believing in false dichotomies. 1) There’s a big space between raw html and the worst possible mud. 2) This situation with react “world” is specific to react and isn’t indicative of anything outside of itself.
- apitman 2y ago
  Nice stack, but are you really using it to make complicated enough sites that TypeScript is much benefit? Drop that build step baby.
  - wruza 2y ago
    I run with `tsx [-w] src/main.ts` and `vite [build]`, so it's not that much of a step. But in general, yes, ts is much benefit. I use shared typings for cross-end calls/returns, mithril supports full component typing which is useful, the whole devtime becomes more lively. I'd agree at webpack 4 "zero" "conf" times, but rejecting ts now returns nothing.
userbinator 2y ago
But doing it the ridiculously complex way is something that professionals can't afford not to do. I think the tide is turning, as people are starting to realise the fragility of complexity.
account42 2y ago
> But doing it the ridiculously complex way is something that professionals can't afford not to do. Have you tried? Also, you don't need to put everything you have ever done on your resume if you don't think it will help.
pjmlp 2y ago
As someone that works across Web and distributed systems, my boring PHP site reading its content out XML and JSON files, hasn't been an hindrance changing jobs, thankfully.

by neilv 2y ago

wruza 2y ago

The site could be 5 simple handwritten HTML files, one with a sprinkling of JS inline in it, plus 2 small Perl CGI scripts. And it would work perfectly for 25 years and counting. Or it could be something in between, because it’s convenient to do so. In my case, I couldn’t care less of resumes and offers, but still I want something more ergonomic than spitting out htmls from templates in js/python. So my sites are a mix of typescript, mithril, express and a few utility libs. Idk and don’t care how many packages it is, as long as my main imports are mature and don’t give birth to a new feature-vulnerability every few minutes. You never mentioned your stack, but it’s a safe guess that it’s react and its ecosystem of always-improving-never-done bullshit. My completely unsolicited advice here is to avoid believing in false dichotomies. 1) There’s a big space between raw html and the worst possible mud. 2) This situation with react “world” is specific to react and isn’t indicative of anything outside of itself.

apitman 2y ago
Nice stack, but are you really using it to make complicated enough sites that TypeScript is much benefit? Drop that build step baby.
- wruza 2y ago
  I run with `tsx [-w] src/main.ts` and `vite [build]`, so it's not that much of a step. But in general, yes, ts is much benefit. I use shared typings for cross-end calls/returns, mithril supports full component typing which is useful, the whole devtime becomes more lively. I'd agree at webpack 4 "zero" "conf" times, but rejecting ts now returns nothing.

userbinator 2y ago

But doing it the ridiculously complex way is something that professionals can't afford not to do. I think the tide is turning, as people are starting to realise the fragility of complexity.

account42 2y ago

> But doing it the ridiculously complex way is something that professionals can't afford not to do. Have you tried? Also, you don't need to put everything you have ever done on your resume if you don't think it will help.

pjmlp 2y ago

As someone that works across Web and distributed systems, my boring PHP site reading its content out XML and JSON files, hasn't been an hindrance changing jobs, thankfully.