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...

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.

Oh, actually, I started building websites earlier than '00, maybe something like '95, but started doing it for a job in '00.

> 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.

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.

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.

> Is that not something you can learn by picking up any number of good books in the area in much less time?

I'm shocked that you believe this. Work at a moderate or higher sized tech company. The juniors, mid levels and seniors all make the same mistakes and slowly grow out of making them. If it were the case that everyone could stop making the same mistakes and choosing the wrong abstractions simply by reading a book then professional programmers would be good on day one and make none of those mistakes and college students who've read dozens of books would come in at the top of the rankings.

> 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.

This is learning to code, it's not learning to engineer. Assuming you finish your book(s) you'll start on the path of making lots and lots of mistakes until you grow into someone with more experience who stops making them.

> you grow into someone with more experience who stops making them.

or at least fewer, and sometimes more complicated mistakes.

Of course you need experience as an engineer. But knowing which Javascript libraries to pick is the easy part. I was not saying that you don't need experience, but you don't need much Javascript / Typescript experience. This can be done in a few months.

It will take a few months just to bring yourself up to speed on mouse/keyboard event bindings and how they interact in one specific browser and one operating system let alone all browsers and operating systems and mobile and that's without even thinking about rendering, templating, network operation wrappers, local storage, camera and sound APIs. The list goes on.

I've been doing this since literally IE 5.5 and I'm still learning new stuff all the time. The fact that you think you can learn all this in a few months is hilarious.

I already learnt most of what I need in one week. I was being pessimistic with 3 months.

If I need to know a particular event, I look it up in the documentation. The stuff you cite is just APIs, I can look that up too. I've used APIs before, you know. Right now I am piping data from Swift to Apple Metal and back, and write GPU code to estimate measurements from the FaceID camera in realtime.

Real programmers are coming to the Web, babe.

Furthermore, from what I see, a lot has changed in JS land. You can basically assume ES2018, with a few exceptions in the library, module systems are part of the standard now, and package managers seem to catch up with that. A lot of what you learnt what is older than 5 years about JS and accompanying APIs, you can basically forget now. Arguably, it might even be better if you had never learnt it in the first place. Because, let's face it, what was going on then was a hot mess of steaming shit.

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.

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.

> 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).

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.

I'm just explaining to you how it plays out when a business is deciding whether or not to use TS at all. Mistakes and errors are checked for by linters and unit tests automatically in the background so that's not a benefit anyone cares about. The liability of having to find coders that want to work on your TS project decreases potential candidates and makes hiring more difficult. Large organizations can deal with it cause when you have 500 engineers on staff you can find 50 that will use TS for you. For smaller orgs it's a pain.

These are concerns that will arise in some organisations, for sure. Personally, I don't have a need to work together with people who cannot be bothered to learn TypeScript. A nice type system is something you really want, and which improves code quality. No need not also to use linters and unit tests. These things do not oppose each other, they work together nicely.

Some things just have to be experienced 50 times before you learn them

> 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.

Pretty sure they aren’t flexing and it’s just you who is treating this like a competition.

They're providing context, not flexing.

> 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.

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

> 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

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.

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.

> 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.

I think that's an over generalisation, for every "world changing, do everything" trendy OSS library there's also a much simpler alternative maintained by a fellow grognard who just wants to write the bare minimum so you don't have to.

The alternative is adding my own mediocre code, with all the maintenance costs that incurs.

Ideally, I like to build on top of a batteries-included base. Failing that, I'd rather reinvent wheels than spend all my time impedance-matching with glue.

The problem with bizarre config files is that you repeatedly have to learn enough to make them work but then do not need to use that knowledge again until after you've long since forgotten and you have to start the learning process from scratch.

Exactly. Badly written libraries are just bad libraries, it doesn't mean that its a bad idea to build reusable components.

So you need a wheel, but you end up getting a whole car, and the wheels turn out to be octagons, which don't work great for your purpose (but basically work on more different terrains that different users had problems with?) ... and in half the time and one-hundredth the price you could have just made the round wheel you need.

“If you wish to make an apple pie from scratch, you must first invent the universe.”

-Carl Sagan

> but fundamentally because I enjoy writing good code.

Using Copilot speeds you up, so why not take advantage of it?

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.