4 ms·

PHP was my first language back when I was a teenager in highschool - it all started because I wanted to get some data from users and store it (I just knew basic

PHP was my first language back when I was a teenager in highschool - it all started because I wanted to get some data from users and store it (I just knew basic HTML and CSS back then), when a friend mentioned he used a PHP snippet to send an email from a website. That sounded like magic to me so I bought a book on PHP and my mind was blown by the possibilities. Several websites and years later I had a pretty good understanding of backend/frontend concerns, web security, SQL and databases... although I didn't really bother setting up a local environment so I just tested new stuff "in prod" by dropping the new files directly via FPT! After University I then started working as a software developer doing full stack work (mostly Java & Python backends) and Angular, then React for frontend. In many ways I prefer TypeScript + React in the frontend with a Java/Nodejs + TS GraphQl backend, but I remember the speed with which you could get a website up and running, self contained, with no CI/build/deploy issues and it was the best thing ever to learn really I'm almost curious to see what it'd be like to build a website super professionally now with PHP, but I'm pretty sure it'd feel very similar to typed python or Java

brentroose 4y ago
Hey, I'm the author of the post. A while ago I made a video where I built a small but serious hobby project in PHP with Laravel. It was a five hour recording, but I condensed it into a commentated 20-minutes timelapse: https://www.youtube.com/watch?v=mmtVkDh9RGw https://www.youtube.com/watch?v=mmtVkDh9RGw If you don't have the time to watch it, you can also check out the open source code of that project: https://github.com/brendt/aggregate.stitcher.io https://github.com/brendt/aggregate.stitcher.io I still work on it, and I'd say i's a pretty accurate representation of a standard Laravel application.
- samuell 4y ago
  Which leads me to start to think if there is a way to make timelapse videos that filter out some of the too quick movements, like windows and dialogs opening ... to make you mostly see how the code grows. App idea perhaps? :)
  - brentroose 4y ago
    You could probably use GIT commit history as a data source?
smarkov 4y ago
> with no CI/build/deploy issues I miss those days. I think the amount of front end building we do for the web nowadays is absurd. We transpile everything - JS, CSS HTML, and then we bundle them in odd ways to circumvent all kinds of issues. The way we make webpages is so disconnected from the technologies that browsers offer us. Makes you wonder when people are going to realize that we're way past serving static pages and don't need the next big front end tool, we just need a better way to run actual applications in the browser.
- oblio 4y ago
  > we just need a better way to run actual applications in the browser. That's not going to happen. It's been tried, and it's almost always proprietary. So it isn't really adopted. WASM might be "it", but in that case, you're still compiling/building stuff :-)
- nawgz 4y ago
  > The way we make webpages is so disconnected from the technologies that browsers offer us. Can you say more about this? I don't really see how "actual applications" differ from a React app in a meaningful way; React apps almost always leverage the capabilities of of course HTML/CSS/JS, history, AJAX/HTTP, cookies, and so on. As the JS distributions evolve, the build systems do too in terms of output. Maybe I misunderstand something, but in general the idea that just writing vanillaJS or some analogue would be sufficient to deliver the quality of apps enabled by frameworks (and talented devs) seems a bit naive to me.
  - smarkov 4y ago
    > Can you say more about this? I don't really see how "actual applications" differ from a React app in a meaningful way; React is everything the web (in its initial conception) was never meant to be. HTML was meant to be used for static documents. CSS (single file, linked to by all documents) was meant to add styling to all those documents. JS was meant to add simple interactivity to documents. Navigating between documents reloads everything and no state is kept (other than user sessions of course). We broke every single one of those concepts and the way they were meant to be used. Now, our HTML consists of a single index.html with a div#app and primarily content in the <head>. Elements are entirely generated by JS. Most of the time you just load a single big JS file that contains everything and navigating just replaces elements, state-wise you're still on the same document. We want all kinds of fancy CSS features that won't be implemented for another 25 years so instead we use transpilers. That is, if we don't include our CSS in the JS. Did I say JS? I meant JSX, because we don't even write HTML directly anymore. The point is, we don't use any of the 3 the way they were meant to be used. We've built layers on top of layers of abstraction to be able to add a level of interactivity that was never meant to exist on the web. Instead of coming up with a new way of building actual applications that meet all our needs, we keep (poorly) patching old technology to get it to play nicely with our modern needs. It's a constant fight and a gigantic waste of everyone's time. We can do better.
nicolaslem 4y ago
> although I didn't really bother setting up a local environment so I just tested new stuff "in prod" by dropping the new files directly via FPT! That was serverless before serverless was even a thing. However it came with its fair share of problems. One being that to be usable on a wide range of hosting providers, applications had to be written for the least common denominator.
zztop44 4y ago
Haha we had the exact same experience. My mind was blown by PHP as a teen and I even made decent money in high school making websites - all without ever setting up a local environment. I didn’t keep doing dev work and had a different career but changed back to development a few years ago (also mostly TS). I’ve also been curious for a while about what it’d feel like to start a new project in Lavarel instead of Next.js or Sveltekit like usual.

brentroose 4y ago

Hey, I'm the author of the post. A while ago I made a video where I built a small but serious hobby project in PHP with Laravel. It was a five hour recording, but I condensed it into a commentated 20-minutes timelapse: https://www.youtube.com/watch?v=mmtVkDh9RGw https://www.youtube.com/watch?v=mmtVkDh9RGw If you don't have the time to watch it, you can also check out the open source code of that project: https://github.com/brendt/aggregate.stitcher.io https://github.com/brendt/aggregate.stitcher.io I still work on it, and I'd say i's a pretty accurate representation of a standard Laravel application.

samuell 4y ago
Which leads me to start to think if there is a way to make timelapse videos that filter out some of the too quick movements, like windows and dialogs opening ... to make you mostly see how the code grows. App idea perhaps? :)
- brentroose 4y ago
  You could probably use GIT commit history as a data source?

smarkov 4y ago

> with no CI/build/deploy issues I miss those days. I think the amount of front end building we do for the web nowadays is absurd. We transpile everything - JS, CSS HTML, and then we bundle them in odd ways to circumvent all kinds of issues. The way we make webpages is so disconnected from the technologies that browsers offer us. Makes you wonder when people are going to realize that we're way past serving static pages and don't need the next big front end tool, we just need a better way to run actual applications in the browser.

oblio 4y ago
> we just need a better way to run actual applications in the browser. That's not going to happen. It's been tried, and it's almost always proprietary. So it isn't really adopted. WASM might be "it", but in that case, you're still compiling/building stuff :-)
nawgz 4y ago
> The way we make webpages is so disconnected from the technologies that browsers offer us. Can you say more about this? I don't really see how "actual applications" differ from a React app in a meaningful way; React apps almost always leverage the capabilities of of course HTML/CSS/JS, history, AJAX/HTTP, cookies, and so on. As the JS distributions evolve, the build systems do too in terms of output. Maybe I misunderstand something, but in general the idea that just writing vanillaJS or some analogue would be sufficient to deliver the quality of apps enabled by frameworks (and talented devs) seems a bit naive to me.
- smarkov 4y ago
  > Can you say more about this? I don't really see how "actual applications" differ from a React app in a meaningful way; React is everything the web (in its initial conception) was never meant to be. HTML was meant to be used for static documents. CSS (single file, linked to by all documents) was meant to add styling to all those documents. JS was meant to add simple interactivity to documents. Navigating between documents reloads everything and no state is kept (other than user sessions of course). We broke every single one of those concepts and the way they were meant to be used. Now, our HTML consists of a single index.html with a div#app and primarily content in the <head>. Elements are entirely generated by JS. Most of the time you just load a single big JS file that contains everything and navigating just replaces elements, state-wise you're still on the same document. We want all kinds of fancy CSS features that won't be implemented for another 25 years so instead we use transpilers. That is, if we don't include our CSS in the JS. Did I say JS? I meant JSX, because we don't even write HTML directly anymore. The point is, we don't use any of the 3 the way they were meant to be used. We've built layers on top of layers of abstraction to be able to add a level of interactivity that was never meant to exist on the web. Instead of coming up with a new way of building actual applications that meet all our needs, we keep (poorly) patching old technology to get it to play nicely with our modern needs. It's a constant fight and a gigantic waste of everyone's time. We can do better.

nicolaslem 4y ago

> although I didn't really bother setting up a local environment so I just tested new stuff "in prod" by dropping the new files directly via FPT! That was serverless before serverless was even a thing. However it came with its fair share of problems. One being that to be usable on a wide range of hosting providers, applications had to be written for the least common denominator.

zztop44 4y ago

Haha we had the exact same experience. My mind was blown by PHP as a teen and I even made decent money in high school making websites - all without ever setting up a local environment. I didn’t keep doing dev work and had a different career but changed back to development a few years ago (also mostly TS). I’ve also been curious for a while about what it’d feel like to start a new project in Lavarel instead of Next.js or Sveltekit like usual.