20 ms·

MariaDB/MySQL + PHP + HTML/CSS and some vainilla JavaScript if necessary. What else is needed? I deploy in production using FTP. My version control is ZIP files

MariaDB/MySQL + PHP + HTML/CSS and some vainilla JavaScript if necessary. What else is needed? I deploy in production using FTP. My version control is ZIP files in some old hard drive. Of course, this won't work if you're working in a team or are developing a huge web app, but for 99% of use cases, this just works. The only thing I focus on is valid markup, accessibility, performance, good error handling, and getting a 100% in Lighthouse. At least I'm doing better than my bank's "modern" home banking app in Angular that breaks half of the time and can't even handle multiple tabs :)

netol 4y ago
I think working in a team is quite common, isn't it? Especially if you are starting, how are you supposed to find customers if you are alone and lack experience? And even when you have the experience, I think most companies would prefer to hire a company rather than a single developer. But unless the client wants to manage the content, I agree that MySQL + PHP + HTML/CSS/JS works great for simple websites. I would add git and lint tools too. If the client wants to manage the content, then using a CMS such as Drupal or WordPress may be required.
KronisLV 4y ago
> MariaDB/MySQL + PHP + HTML/CSS and some vanilla JavaScript if necessary. What else is needed? This is a surprisingly usable stack, I'm tempted to agree. Personally, I'm on the fence about using server side rendering (which PHP is pretty good at) versus just writing RESTful APIs, because browsers now have fetch API built in which makes consuming them easy (no need for jQuery or necessarily even something like Axios). Of course, I might still go for a reasonably feature complete framework like Laravel (which handles certain things that you're very likely to get wrong, like auth/encryption or working with mail queues and such), or Slim (which is a nice option for smaller setups, essentially a micro framework; like Lumen used to be). > I deploy in production using FTP. This isn't ideal from a performance or reproducibility perspective, but can be workable. A caveat here could be file permissions, depending who is uploading what and how, as well as copying over files that should perhaps be transient (e.g. vendor directory, when you should be using Composer or something like that instead). Personally I'd go for containers since writing a Dockerfile and shipping/running a container image (even with just Docker or Docker Compose, or Docker Swarm) isn't all that hard. If nothing else, it works wonderfully for getting as many databases up and running as you need, running different versions with different ports in parallel, managing resource limits, configuration and so on. > My version control is ZIP files in some old hard drive. This is a very counter cultural stance, that may or may not border on insanity in the eyes of those who want to exaggerate for the sake of an eye catching sentence. Others might joke about file names like code_2022_11_17_release_final(1).tar.gz.backup2 which this workflow might lead to. Personally, I think that this is just a bad idea, even when working alone. It's good to be able to see what was changed when and have different changesets that you can easily compare, navigate or merge into whatever solution you decide on. Also, it's very nice to be able to revert granular changes, if that's ever necessary. Try implementing a feature, realize that after changing 34 files you want redo certain parts and need to revert changes in 14 of them, do that with just a few clicks or keystrokes in Git (or other VCS) solution of your choice. Version control is just a good idea in most software development cases, period. That said, opinions on how to use it and which system to use rightfully differ, as does what to version, whether to use something like Git LFS, whether you need a web UI of some sort or should you work with patches and so on.
- netol 4y ago
  > Personally, I'm on the fence about using server side rendering (which PHP is pretty good at) versus just writing RESTful APIs, because browsers now have fetch API built in which makes consuming them easy (no need for jQuery or necessarily even something like Axios). That depends on the target website (or web app), but as a web visitor, I usually dislike having the stuff rendered client-side, it always feels slower. Also, for content-based websites, I like when JS is optional.
- kitd 4y ago
  Personally, I'm on the fence about using server side rendering (which PHP is pretty good at) versus just writing RESTful APIs, because browsers now have fetch API built in which makes consuming them easy (no need for jQuery or necessarily even something like Axios). You can do a kind of halfway house with Htmx. Have your backend generate HTML fragments, and Htmx in the browser will inject them into the page without having to do full-page reloads or complex vDom manipulation. https://htmx.org/ https://htmx.org/
onion2k 4y ago
I don't know how this has happened, but at some point in the future I must invent a time machine, go back to 2005, and submit a post to HN that arrives today. That's exciting.
- Trufa 4y ago
  I must be going crazy, the amount of posts I’ve been seeing recommending PHP on HN lately is making me doubt my sanity. I am no latest tech only hipster kid, but making a fast no bloat website this day with modern JS stack is pretty darn easy. For me it’s hard to evaluate cause I’ve been doing it for years but I’ve recently thought it to a couple of people with no coding experience and they got it. Seriously, people are terribly close minded about the JS ecosystem and the fame is well deserved maybe but seriously if you have some minimum guidance of what to stick to it’s one of the best and easiest stacks around.
  - onion2k 4y ago
    I love to dunk on PHP as much as the next dev, but if you're recommending JS instead then you're not really thinking about it enough. Pretty much all the issues with PHP apply equally to JS. The cool kids dunk on both of them.
  - netol 4y ago
    > I am no latest tech only hipster kid, but making a fast no bloat website this day with modern JS stack is pretty darn easy. Are you talking about static websites, or API-driven? Can you put an example?
  - conductr 4y ago
    I've observing on HN what seems to be a trend back to self hosting and that essentially is going to lead to the simplicity of the good ole LAMP stack. I see what seems like a lot of fatigue with all the frameworks, dependencies, containers, etc. It was like those things had initial excitement but then longer term were more of a burden/risk/hindrance.
- NorwegianDude 4y ago
mypastself 4y ago
You’ll get no complaints about the stack from me, but I do have to push back against your approach to version control a little bit. Even if you’re the sole dev, having easy access to change history, checking out specific versions, or even branching and merging your experimental changes, are all a godsend. And a git repo is much easier to manage than having to contend with all your “query-fix-final(1).zip”s.
NorwegianDude 4y ago
Using something like Git is highly recommended even if you're solo, just because it is so useful to have a log over changes. It doesn't really have any downside and can even easily replace FTP as the deployment method. Using FTP can be a bad idea as the replacement of files might not be atomic and can result in an invalid state.
- radiator 4y ago
  If you are solo, you would not use Git, which was designed for hundreds of collaborators working on a project. Instead, a simpler version control system (something like Git?) would suit you better.
  - _t2kx 4y ago
    No, I definitely still use Git on solo projects, there’s no reason not to do so.
    - conductr 4y ago
      If you know it, use it. But it's not worth learning if you don't already know it. Or, it's at least fairly low on the priority list.
      - pinusc 4y ago
        Strongly disagree. Learning complex girl workflows is unnecessary unless you're in a team. However, learning the absolute basics is really easy and has benefits over "storing previous versions in a zip file". By absolute basics I mean add, commit, reset. If you add basic branching (checkout and merge) you already get a very powerful tool to experiment with your code without worrying about fucking it up. Then you can learn the rest when you have a use for it—log, diff, even rebase. But here's the thing: without VCS, if you ever do need anything slightly more sophisticated... you're on your own. Yesterday I was helping a friend debug some code from an intro CS class, and I was so stressed out about changing something whithout being able to revert it, because he obviously wasn't using git. Granted, I really wish there was a mainstream git alternative, ideally simpler, without the more complex features catering to large teams. At least there's a lot of graphical interfaces on top of git, which make it really intuitive to use and can bring the great VCS benefits without the investment of learning git. Maybe simple interfaces to complex tools is a good middle ground.
threatofrain 4y ago
If you use something like Astro or anything focusing on minimal JS style SSR/SSG then that’s basically the PHP experience but without an extra language, and given that OP asks for simple web apps, getting 100% lighthouse is too easy. With basic CRUD apps you can easily get 0.2s TTI.

netol 4y ago

I think working in a team is quite common, isn't it? Especially if you are starting, how are you supposed to find customers if you are alone and lack experience? And even when you have the experience, I think most companies would prefer to hire a company rather than a single developer. But unless the client wants to manage the content, I agree that MySQL + PHP + HTML/CSS/JS works great for simple websites. I would add git and lint tools too. If the client wants to manage the content, then using a CMS such as Drupal or WordPress may be required.

KronisLV 4y ago

> MariaDB/MySQL + PHP + HTML/CSS and some vanilla JavaScript if necessary. What else is needed? This is a surprisingly usable stack, I'm tempted to agree. Personally, I'm on the fence about using server side rendering (which PHP is pretty good at) versus just writing RESTful APIs, because browsers now have fetch API built in which makes consuming them easy (no need for jQuery or necessarily even something like Axios). Of course, I might still go for a reasonably feature complete framework like Laravel (which handles certain things that you're very likely to get wrong, like auth/encryption or working with mail queues and such), or Slim (which is a nice option for smaller setups, essentially a micro framework; like Lumen used to be). > I deploy in production using FTP. This isn't ideal from a performance or reproducibility perspective, but can be workable. A caveat here could be file permissions, depending who is uploading what and how, as well as copying over files that should perhaps be transient (e.g. vendor directory, when you should be using Composer or something like that instead). Personally I'd go for containers since writing a Dockerfile and shipping/running a container image (even with just Docker or Docker Compose, or Docker Swarm) isn't all that hard. If nothing else, it works wonderfully for getting as many databases up and running as you need, running different versions with different ports in parallel, managing resource limits, configuration and so on. > My version control is ZIP files in some old hard drive. This is a very counter cultural stance, that may or may not border on insanity in the eyes of those who want to exaggerate for the sake of an eye catching sentence. Others might joke about file names like code_2022_11_17_release_final(1).tar.gz.backup2 which this workflow might lead to. Personally, I think that this is just a bad idea, even when working alone. It's good to be able to see what was changed when and have different changesets that you can easily compare, navigate or merge into whatever solution you decide on. Also, it's very nice to be able to revert granular changes, if that's ever necessary. Try implementing a feature, realize that after changing 34 files you want redo certain parts and need to revert changes in 14 of them, do that with just a few clicks or keystrokes in Git (or other VCS) solution of your choice. Version control is just a good idea in most software development cases, period. That said, opinions on how to use it and which system to use rightfully differ, as does what to version, whether to use something like Git LFS, whether you need a web UI of some sort or should you work with patches and so on.

netol 4y ago
> Personally, I'm on the fence about using server side rendering (which PHP is pretty good at) versus just writing RESTful APIs, because browsers now have fetch API built in which makes consuming them easy (no need for jQuery or necessarily even something like Axios). That depends on the target website (or web app), but as a web visitor, I usually dislike having the stuff rendered client-side, it always feels slower. Also, for content-based websites, I like when JS is optional.
kitd 4y ago
Personally, I'm on the fence about using server side rendering (which PHP is pretty good at) versus just writing RESTful APIs, because browsers now have fetch API built in which makes consuming them easy (no need for jQuery or necessarily even something like Axios). You can do a kind of halfway house with Htmx. Have your backend generate HTML fragments, and Htmx in the browser will inject them into the page without having to do full-page reloads or complex vDom manipulation. https://htmx.org/ https://htmx.org/

onion2k 4y ago

I don't know how this has happened, but at some point in the future I must invent a time machine, go back to 2005, and submit a post to HN that arrives today. That's exciting.

Trufa 4y ago
I must be going crazy, the amount of posts I’ve been seeing recommending PHP on HN lately is making me doubt my sanity. I am no latest tech only hipster kid, but making a fast no bloat website this day with modern JS stack is pretty darn easy. For me it’s hard to evaluate cause I’ve been doing it for years but I’ve recently thought it to a couple of people with no coding experience and they got it. Seriously, people are terribly close minded about the JS ecosystem and the fame is well deserved maybe but seriously if you have some minimum guidance of what to stick to it’s one of the best and easiest stacks around.
- onion2k 4y ago
  I love to dunk on PHP as much as the next dev, but if you're recommending JS instead then you're not really thinking about it enough. Pretty much all the issues with PHP apply equally to JS. The cool kids dunk on both of them.
- netol 4y ago
  > I am no latest tech only hipster kid, but making a fast no bloat website this day with modern JS stack is pretty darn easy. Are you talking about static websites, or API-driven? Can you put an example?
- conductr 4y ago
  I've observing on HN what seems to be a trend back to self hosting and that essentially is going to lead to the simplicity of the good ole LAMP stack. I see what seems like a lot of fatigue with all the frameworks, dependencies, containers, etc. It was like those things had initial excitement but then longer term were more of a burden/risk/hindrance.
NorwegianDude 4y ago

mypastself 4y ago

You’ll get no complaints about the stack from me, but I do have to push back against your approach to version control a little bit. Even if you’re the sole dev, having easy access to change history, checking out specific versions, or even branching and merging your experimental changes, are all a godsend. And a git repo is much easier to manage than having to contend with all your “query-fix-final(1).zip”s.

NorwegianDude 4y ago

Using something like Git is highly recommended even if you're solo, just because it is so useful to have a log over changes. It doesn't really have any downside and can even easily replace FTP as the deployment method. Using FTP can be a bad idea as the replacement of files might not be atomic and can result in an invalid state.

radiator 4y ago
If you are solo, you would not use Git, which was designed for hundreds of collaborators working on a project. Instead, a simpler version control system (something like Git?) would suit you better.
- _t2kx 4y ago
  No, I definitely still use Git on solo projects, there’s no reason not to do so.
  - conductr 4y ago
    If you know it, use it. But it's not worth learning if you don't already know it. Or, it's at least fairly low on the priority list.
    - pinusc 4y ago
      Strongly disagree. Learning complex girl workflows is unnecessary unless you're in a team. However, learning the absolute basics is really easy and has benefits over "storing previous versions in a zip file". By absolute basics I mean add, commit, reset. If you add basic branching (checkout and merge) you already get a very powerful tool to experiment with your code without worrying about fucking it up. Then you can learn the rest when you have a use for it—log, diff, even rebase. But here's the thing: without VCS, if you ever do need anything slightly more sophisticated... you're on your own. Yesterday I was helping a friend debug some code from an intro CS class, and I was so stressed out about changing something whithout being able to revert it, because he obviously wasn't using git. Granted, I really wish there was a mainstream git alternative, ideally simpler, without the more complex features catering to large teams. At least there's a lot of graphical interfaces on top of git, which make it really intuitive to use and can bring the great VCS benefits without the investment of learning git. Maybe simple interfaces to complex tools is a good middle ground.

threatofrain 4y ago

If you use something like Astro or anything focusing on minimal JS style SSR/SSG then that’s basically the PHP experience but without an extra language, and given that OP asks for simple web apps, getting 100% lighthouse is too easy. With basic CRUD apps you can easily get 0.2s TTI.