6 ms·

I have a feeling that this is the next religious war in dev. I read this article and shudder in horror at, well, all of it. I like static sites (that wouldn't

I have a feeling that this is the next religious war in dev. I read this article and shudder in horror at, well, all of it. I like static sites (that wouldn't take minutes to build if they were written in a decent language). Adding lots and lots of JS dependencies and frameworks gives me the screaming ab-dabs - it's just adding complexity and dependency. I like writing code, not plumbing together bits of other people's code with bizarre config files. I object to CodePilot for all sorts of reasons, but fundamentally because I enjoy writing good code. But I know experienced devs who have exactly the reverse opinions. Like OP, they see all this as going in the right direction and making their lives easier.

0x0nyandesu 5y ago
I feel the same way as the author but I work with php. Recently it's all been TDD, statically typed, and JavaScript gets web packed into one or two files so instead of juggling 15 script tags I only have one or two and a style tag for css. With CI this all happens in the background on every commit. What you pay for when you hire a dev like me with 17 years of experience in the field is the ability to know which libraries are the best to use and which techniques are worth using in the process.
- auggierose 5y ago
  Is that not something you can learn by picking up any number of good books in the area in much less time? I am just getting into TypeScript programming, and I am really having fun. I learnt about the details of how Javascript works, and it is quite cool to have a static layer over a dynamic one. For learning JavaScript, I like "The Good Parts" and the "You don't know JS" series. It took me a while to learn how to create a datatype that can defend its invariants not only statically, but also at runtime, but that seems quite feasible as well, especially with decorators. It is interesting though that nobody seems to be particularly interested in doing that, there is not much direct information about this available.
  - 0x0nyandesu 5y ago
    Not really. You can't replicate experience. Everything you just wrote about with data types, invariants, and decorators is just flavor which you only have control over in your own personal code however as soon as you interact with web browser APIs, nodejs, and 3rd party libraries all that goes out the window and you end up conforming to other people's patterns. In my honest opinion Typescript is a fad. You're still just coding JavaScript with an alternative syntax. Since you're borrowing dependencies from JS you need to know both and context switching between the two slows you down. From a CS perspective I get why TS syntax is better but from a functional perspective it's harder to find engineers that actually want to work with it because every TS project I've ever seen is really a mix of TS and JS.
    - auggierose 5y ago
      Web browser API's usually do keep their invariants. I wouldn't use libraries which don't. Libraries which do not support TypeScript will vanish. See, all your experience (in a limited field) is telling you the wrong thing. And it is quite obvious to me that you need to know BOTH TypeScript and Javascript, of course, you cannot just learn TypeScript, because it is just a thin layer on top of Javascript without many runtime guarantees otherwise.
      - westoncb 5y ago
        > See, all your experience (in a limited field) is telling you the wrong thing. You seem to be conflating objective wrong/right with your own personal stance. Do you have an objective argument in favor of your assertion about the longevity of non-TS libs? > And it is quite obvious to me that you need to know BOTH TypeScript and Javascript That's a reasonable strategy on the assumption that TypeScript will be used, but the very fact of its being so is actually an argument in favor of the point made by gp which has been left unaddressed (RE context-switching).
        auggierose 5y ago
        Obviously, there is no objective wrong/right here, as only the future can tell. My subjective experience tells me, it will be that way. There is no need to context-switch. Just accept Javascript as part of TypeScript, because it really is. The argument is clear: TypeScript drastically reduces the amount of errors you will be making when coding, and the amount of time you need to think about stuff that is really trivial. The rule of thumb on how to do this is also simple: Keep your types simple, use them to make your life easier, not more complicated. If you cannot model something simply using types, don't try to do so, just use the dynamic typing escape hatch that Javascript provides.
- marcus_holmes 5y ago
  > a dev like me with 17 years of experience in the field That's not the flex I think you think it is ;) I've been coding for over 40 years now, professionally for over 25. The attitude you have is one I very much associate with younger devs with limited experience.
  - spiderice 5y ago
    Pretty sure they aren’t flexing and it’s just you who is treating this like a competition.
  - DiggyJohnson 5y ago
    They're providing context, not flexing.
jetsetgo 5y ago
zeepzeep 5y ago
> I like writing code, not plumbing together bits of other people's code with bizarre config files I don't like reinventing the wheel every time I build something
- ehnto 5y ago
  There's a balance to be struck between your opposing opinions I imagine. I would just suggest solving the core business problems of your software in your own code, so that you have full control over them, can learn about your product from the building process, and can provide value through specializing your codebase.
- shaan7 5y ago
  Exactly. Badly written libraries are just bad libraries, it doesn't mean that its a bad idea to build reusable components.
- alpaca128 5y ago
  Meanwhile I do like reinventing the wheel. Or, more accurately, designing a wheel that fits my needs well. Sure, I also use libraries for things that are just tedious, hard to get right or just some standard feature that's always used the same way. But you can overdo it. Debugging my own code is annoying but doable. Debugging other people's code is a lot more tedious. Troubleshooting a mess of 1000 transitive dependencies because one package had version 10.0.6 instead of 10.0.5 and that caused an avalanche of breakage makes me reconsider my life choices.
- marcus_holmes 5y ago
  > I don't like reinventing the wheel every time I build something This is the crux of the difference, I think. I see open-source libraries as (mostly) mediocre code, usually massively bloated with features I don't need. Using them is like using an 18-wheeler to nip to the shops. I have found in my experience that it saves time in the long run to just write the minimal amount of code I need for the job, rather than dealing with the added complexity and dependency of adding a 3rd-party library.
  - 5y ago
Mezzie 5y ago
Same. I started making websites in 93, and to me, websites are about communication and sharing. They exist to facilitate communication. The current system of crazy dependencies and frameworks just doesn't do this; it values speed and ease over every other aspect of communicating. Imagine if TV developed in a way where they sat and tested how much they could speed up the show and be understood and made that the standard so shows could be 'watched' more quickly: That experience would SUCK. Or cars that can go from 0 to 100 in .5 seconds but have no seat belts, no horns, no airbags, no turn signals...
- GordonS 5y ago
  I started in '00, and I still favour server-side rendered websites, with a smattering of JavaScript where needed. I've worked with Angular and React, and they have their place, but IMO 95% of websites just don't need them.
  - GordonS 5y ago
    Oh, actually, I started building websites earlier than '00, maybe something like '95, but started doing it for a job in '00.
the_only_law 5y ago
> Imagine if TV developed in a way where they sat and tested how much they could speed up the show and be understood and made that the standard so shows could be 'watched' more quickly: That experience would SUCK. Honestly, a lot of times, I’m left wondering if this isn’t the case.
- marcosdumay 5y ago
  Well, the trend seems to be completely on the other way, on making the experience as slow as possible.
_fat_santa 5y ago
> I object to CodePilot for all sorts of reasons I've been testing copilot for about a month now, one thing I realized very quickly is it's not as useful as you might think it is. Copilot is great for writing repetitive code, so if you just wrote a function to select an item, copilot will correctly guess what the deselect function implementation should be. Outside of that though I find that it gets in the way far more often that it helps, by far the most annoying part is that it interferes with intellisense sometimes, picking values from an enum in Typescript is now a PIA if you have Copilot enabled.
polyterative 5y ago
> but fundamentally because I enjoy writing good code. Using Copilot speeds you up, so why not take advantage of it?
- almaember 5y ago
  Because it's a massive footgun, no, footcannon. It also most likely violates the GPL. It's copy-pasting from stackoverflow except a little faster.

0x0nyandesu 5y ago

I feel the same way as the author but I work with php. Recently it's all been TDD, statically typed, and JavaScript gets web packed into one or two files so instead of juggling 15 script tags I only have one or two and a style tag for css. With CI this all happens in the background on every commit. What you pay for when you hire a dev like me with 17 years of experience in the field is the ability to know which libraries are the best to use and which techniques are worth using in the process.

auggierose 5y ago
Is that not something you can learn by picking up any number of good books in the area in much less time? I am just getting into TypeScript programming, and I am really having fun. I learnt about the details of how Javascript works, and it is quite cool to have a static layer over a dynamic one. For learning JavaScript, I like "The Good Parts" and the "You don't know JS" series. It took me a while to learn how to create a datatype that can defend its invariants not only statically, but also at runtime, but that seems quite feasible as well, especially with decorators. It is interesting though that nobody seems to be particularly interested in doing that, there is not much direct information about this available.
- 0x0nyandesu 5y ago
  Not really. You can't replicate experience. Everything you just wrote about with data types, invariants, and decorators is just flavor which you only have control over in your own personal code however as soon as you interact with web browser APIs, nodejs, and 3rd party libraries all that goes out the window and you end up conforming to other people's patterns. In my honest opinion Typescript is a fad. You're still just coding JavaScript with an alternative syntax. Since you're borrowing dependencies from JS you need to know both and context switching between the two slows you down. From a CS perspective I get why TS syntax is better but from a functional perspective it's harder to find engineers that actually want to work with it because every TS project I've ever seen is really a mix of TS and JS.
  - auggierose 5y ago
    Web browser API's usually do keep their invariants. I wouldn't use libraries which don't. Libraries which do not support TypeScript will vanish. See, all your experience (in a limited field) is telling you the wrong thing. And it is quite obvious to me that you need to know BOTH TypeScript and Javascript, of course, you cannot just learn TypeScript, because it is just a thin layer on top of Javascript without many runtime guarantees otherwise.
    - westoncb 5y ago
      > See, all your experience (in a limited field) is telling you the wrong thing. You seem to be conflating objective wrong/right with your own personal stance. Do you have an objective argument in favor of your assertion about the longevity of non-TS libs? > And it is quite obvious to me that you need to know BOTH TypeScript and Javascript That's a reasonable strategy on the assumption that TypeScript will be used, but the very fact of its being so is actually an argument in favor of the point made by gp which has been left unaddressed (RE context-switching).
      - auggierose 5y ago
        Obviously, there is no objective wrong/right here, as only the future can tell. My subjective experience tells me, it will be that way. There is no need to context-switch. Just accept Javascript as part of TypeScript, because it really is. The argument is clear: TypeScript drastically reduces the amount of errors you will be making when coding, and the amount of time you need to think about stuff that is really trivial. The rule of thumb on how to do this is also simple: Keep your types simple, use them to make your life easier, not more complicated. If you cannot model something simply using types, don't try to do so, just use the dynamic typing escape hatch that Javascript provides.
marcus_holmes 5y ago
> a dev like me with 17 years of experience in the field That's not the flex I think you think it is ;) I've been coding for over 40 years now, professionally for over 25. The attitude you have is one I very much associate with younger devs with limited experience.
- spiderice 5y ago
  Pretty sure they aren’t flexing and it’s just you who is treating this like a competition.
- DiggyJohnson 5y ago
  They're providing context, not flexing.

jetsetgo 5y ago

zeepzeep 5y ago

> I like writing code, not plumbing together bits of other people's code with bizarre config files I don't like reinventing the wheel every time I build something

ehnto 5y ago
There's a balance to be struck between your opposing opinions I imagine. I would just suggest solving the core business problems of your software in your own code, so that you have full control over them, can learn about your product from the building process, and can provide value through specializing your codebase.
shaan7 5y ago
Exactly. Badly written libraries are just bad libraries, it doesn't mean that its a bad idea to build reusable components.
alpaca128 5y ago
Meanwhile I do like reinventing the wheel. Or, more accurately, designing a wheel that fits my needs well. Sure, I also use libraries for things that are just tedious, hard to get right or just some standard feature that's always used the same way. But you can overdo it. Debugging my own code is annoying but doable. Debugging other people's code is a lot more tedious. Troubleshooting a mess of 1000 transitive dependencies because one package had version 10.0.6 instead of 10.0.5 and that caused an avalanche of breakage makes me reconsider my life choices.
marcus_holmes 5y ago
> I don't like reinventing the wheel every time I build something This is the crux of the difference, I think. I see open-source libraries as (mostly) mediocre code, usually massively bloated with features I don't need. Using them is like using an 18-wheeler to nip to the shops. I have found in my experience that it saves time in the long run to just write the minimal amount of code I need for the job, rather than dealing with the added complexity and dependency of adding a 3rd-party library.
- 5y ago

Mezzie 5y ago

Same. I started making websites in 93, and to me, websites are about communication and sharing. They exist to facilitate communication. The current system of crazy dependencies and frameworks just doesn't do this; it values speed and ease over every other aspect of communicating. Imagine if TV developed in a way where they sat and tested how much they could speed up the show and be understood and made that the standard so shows could be 'watched' more quickly: That experience would SUCK. Or cars that can go from 0 to 100 in .5 seconds but have no seat belts, no horns, no airbags, no turn signals...

GordonS 5y ago
I started in '00, and I still favour server-side rendered websites, with a smattering of JavaScript where needed. I've worked with Angular and React, and they have their place, but IMO 95% of websites just don't need them.
- GordonS 5y ago
  Oh, actually, I started building websites earlier than '00, maybe something like '95, but started doing it for a job in '00.

the_only_law 5y ago

> Imagine if TV developed in a way where they sat and tested how much they could speed up the show and be understood and made that the standard so shows could be 'watched' more quickly: That experience would SUCK. Honestly, a lot of times, I’m left wondering if this isn’t the case.

marcosdumay 5y ago
Well, the trend seems to be completely on the other way, on making the experience as slow as possible.

_fat_santa 5y ago

> I object to CodePilot for all sorts of reasons I've been testing copilot for about a month now, one thing I realized very quickly is it's not as useful as you might think it is. Copilot is great for writing repetitive code, so if you just wrote a function to select an item, copilot will correctly guess what the deselect function implementation should be. Outside of that though I find that it gets in the way far more often that it helps, by far the most annoying part is that it interferes with intellisense sometimes, picking values from an enum in Typescript is now a PIA if you have Copilot enabled.

polyterative 5y ago

> but fundamentally because I enjoy writing good code. Using Copilot speeds you up, so why not take advantage of it?

almaember 5y ago
Because it's a massive footgun, no, footcannon. It also most likely violates the GPL. It's copy-pasting from stackoverflow except a little faster.