3 ms·

Javascript indeed sucks, but Typescript whips To call Javascript "poorly designed" when having a discussion about PHP is… a bit jarring… Both PHP 7/8 and Types

Javascript indeed sucks, but Typescript whips To call Javascript "poorly designed" when having a discussion about PHP is… a bit jarring… Both PHP 7/8 and Typescript are huge improvements over their forbearers, but it seems indisputable to me that fundamental Javascript is at least a better-designed language than fundamental PHP (circa v3), and contemporary Typescript is better-designed than modern PHP. (creds: I've been writing PHP and Javascript since around 1997)

kypro 4y ago
Okay, so let's talk about TypeScript. Let's say I want to create a simple app. Nothing complex, it just needs to connect to a database to support some some basic user auth and CRUD stuff. TypeScript is probably my strongest language, and everyone says it's great so I'll use it for my backend. Cool. So first thing we need to do is create a user API for signups. I'm going to need a framework for the API stuff. Express is good, let's go with that... Okay, now we need to talk to the database. Let's install mysql2, seems popular and well maintained, should be okay.. Do I need a @types package? Nope. Great. Now I need to create some environment config for connecting to MySQL. Going to need another library for that, I guess. dotenv is popular, should be safe enough... Hm, actually I probably want to set up some logging too just in case there are SQL/DB errors. Going to need a library that. Looks like log4js would probably work. Is it well maintained / safe? Eh. Should be fine, just need to build this thing... Right, finally connecting to the DB. How do I do DB migrations? Is there a library for that? Hm, let's check Google... Okay, typeorm seems like it might work. Seems quite popular. Let's try that. Okay, our tables have been defined and we're connecting to the DB. Great! Now we can finally create the signup code. Hm, actually, going need to validate email addresses. Do I write an email validator? No, don't be silly, this is the JS ecosystem! There's probably a library for that. validator seems popular, I'll go with that. It's probably safe... Okay, signup done. That wasn't so hard was it? Just need to connect to the SMTP server to send the email verification email now... Erm, wait... How do I do that in TypeScript exactly? Guess I'll need a library for that. I won't go on but this is the developer experience of just trying to do something extremely simple in TypeScript. But it gets worse because in two weeks when you come back to the project you'll find several of your libraries have been deprecated so you'll need to spend a few hours refactoring and the docs for the 50 libraries you needed are distributed across 22 websites (2 of which are 404ing) and 28 Github readmes. In comparison all of this would probably take me about 15 minutes max in Laravel and I wouldn't need to install any 3rd party packages. And if I'm honest I could probably do this in Spring Boot faster too without having to worry about installing malicious, poorly maintained packages along the way. Like, I swear I must be missing something here because while I acknowledge TypeScript itself is great, the JS ecosystem it's built on is awful. So yeah, sure, TS is better designed that modern PHP, but why anyone developer would choose to use TS for their backend isn't clear to me. Unless you absolutely need TS for writing isomorphic code or something then why bother with the headache?
- aastronaut 4y ago
  You're question seems more on the side of "Why use a micro framework when you can use a mature full-fledged one?". I feel a lot if new ideas in the web development space are first available as "micro" packages, so that's just what you use when you want to stay on the edge. I feel there is still so much momentum in the JS/TS community. Would you genuinely pick PHP for anything else besides Laravel? I would also question you're mentioned frequency to update packages tbh. Just pin a stable version with a lock file, track the required node engine and use an OCI image to provide just enough reproducibility. I never had to do anything more than cd-ing into a directory and run npm ci after coming back to a project for a few years now.
  - deleted 4y ago
    [deleted]
  - kypro 4y ago
    > I feel a lot if new ideas in the web development space are first available as "micro" packages, so that's just what you use when you want to stay on the edge I'm not talking about staying on the edge though, I'm talking about connecting to databases and logging - stuff that would be considered basic when working with other languages. You're right though... If there existed a fully-fledged framework for the backend (with dev tools) which had been around for a few years and fairly stable, I'd consider it. Frontend JS frameworks like Next.js are pretty great. They still feel a bit immature and prone to large changes, but they're on the right track and get a lot of things right. Also, yes, I would probably still use PHP even without Laravel. I have PHP projects which are over a decade old which use a very minimalist framework I created for simple projects. It still works fine and I haven't changed the framework in over a decade. You're right that you can just pick some stable packages, but what happens when you're running Node 12 and you want to upgrade to 14 or 16? Do you upgrade and risk breaking packages or just continue running an out-dated unsupported version of Node? I've had this specific issue several times now. I think some people here think I'm saying Node is unusably bad, but I'm not. I'm just saying I don't get why people / projects who would have used PHP a few years back are now moving to Node when Node is still so immature and PHP has improved so much. I guess I'm not sure why my view of PHP has improved so much, while the industry as a whole seems to be dismissing it for the JS ecosystem which in my opinion has a lot of problems.

kypro 4y ago

Okay, so let's talk about TypeScript. Let's say I want to create a simple app. Nothing complex, it just needs to connect to a database to support some some basic user auth and CRUD stuff. TypeScript is probably my strongest language, and everyone says it's great so I'll use it for my backend. Cool. So first thing we need to do is create a user API for signups. I'm going to need a framework for the API stuff. Express is good, let's go with that... Okay, now we need to talk to the database. Let's install mysql2, seems popular and well maintained, should be okay.. Do I need a @types package? Nope. Great. Now I need to create some environment config for connecting to MySQL. Going to need another library for that, I guess. dotenv is popular, should be safe enough... Hm, actually I probably want to set up some logging too just in case there are SQL/DB errors. Going to need a library that. Looks like log4js would probably work. Is it well maintained / safe? Eh. Should be fine, just need to build this thing... Right, finally connecting to the DB. How do I do DB migrations? Is there a library for that? Hm, let's check Google... Okay, typeorm seems like it might work. Seems quite popular. Let's try that. Okay, our tables have been defined and we're connecting to the DB. Great! Now we can finally create the signup code. Hm, actually, going need to validate email addresses. Do I write an email validator? No, don't be silly, this is the JS ecosystem! There's probably a library for that. validator seems popular, I'll go with that. It's probably safe... Okay, signup done. That wasn't so hard was it? Just need to connect to the SMTP server to send the email verification email now... Erm, wait... How do I do that in TypeScript exactly? Guess I'll need a library for that. I won't go on but this is the developer experience of just trying to do something extremely simple in TypeScript. But it gets worse because in two weeks when you come back to the project you'll find several of your libraries have been deprecated so you'll need to spend a few hours refactoring and the docs for the 50 libraries you needed are distributed across 22 websites (2 of which are 404ing) and 28 Github readmes. In comparison all of this would probably take me about 15 minutes max in Laravel and I wouldn't need to install any 3rd party packages. And if I'm honest I could probably do this in Spring Boot faster too without having to worry about installing malicious, poorly maintained packages along the way. Like, I swear I must be missing something here because while I acknowledge TypeScript itself is great, the JS ecosystem it's built on is awful. So yeah, sure, TS is better designed that modern PHP, but why anyone developer would choose to use TS for their backend isn't clear to me. Unless you absolutely need TS for writing isomorphic code or something then why bother with the headache?

aastronaut 4y ago
You're question seems more on the side of "Why use a micro framework when you can use a mature full-fledged one?". I feel a lot if new ideas in the web development space are first available as "micro" packages, so that's just what you use when you want to stay on the edge. I feel there is still so much momentum in the JS/TS community. Would you genuinely pick PHP for anything else besides Laravel? I would also question you're mentioned frequency to update packages tbh. Just pin a stable version with a lock file, track the required node engine and use an OCI image to provide just enough reproducibility. I never had to do anything more than cd-ing into a directory and run npm ci after coming back to a project for a few years now.
- deleted 4y ago
  [deleted]
- kypro 4y ago
  > I feel a lot if new ideas in the web development space are first available as "micro" packages, so that's just what you use when you want to stay on the edge I'm not talking about staying on the edge though, I'm talking about connecting to databases and logging - stuff that would be considered basic when working with other languages. You're right though... If there existed a fully-fledged framework for the backend (with dev tools) which had been around for a few years and fairly stable, I'd consider it. Frontend JS frameworks like Next.js are pretty great. They still feel a bit immature and prone to large changes, but they're on the right track and get a lot of things right. Also, yes, I would probably still use PHP even without Laravel. I have PHP projects which are over a decade old which use a very minimalist framework I created for simple projects. It still works fine and I haven't changed the framework in over a decade. You're right that you can just pick some stable packages, but what happens when you're running Node 12 and you want to upgrade to 14 or 16? Do you upgrade and risk breaking packages or just continue running an out-dated unsupported version of Node? I've had this specific issue several times now. I think some people here think I'm saying Node is unusably bad, but I'm not. I'm just saying I don't get why people / projects who would have used PHP a few years back are now moving to Node when Node is still so immature and PHP has improved so much. I guess I'm not sure why my view of PHP has improved so much, while the industry as a whole seems to be dismissing it for the JS ecosystem which in my opinion has a lot of problems.