5 ms·

Since we are on Hacker News (which was Startup News back in the day): I think for starting a startup, a simple LAMP+Framework setup is still the best approach.

by TekMol 4y ago

Since we are on Hacker News (which was Startup News back in the day): I think for starting a startup, a simple LAMP+Framework setup is still the best approach. For example Debian+Apache+MySql+Python+Django. Although I would use SQLite these days instead of MySql.

chirau 4y ago
Oh, the P in LAMP is now Python? Haha, i have always known it to be PHP
- jmyeet 4y ago
  You’re correct. It was always PHP.
- TekMol 4y ago
  I have the feeling the meaning turned from "PHP" to "PHP or some other interpreted language like Python, Perl, Ruby or JavaScript" over time. That's why I said "for example".
- ipaddr 4y ago
  It was originally Perl or PHP Python fits well.
- kbutler 4y ago
  LAMP with PHP/Perl/Python has been common for a long time - at least since 2006 https://www.computerworld.com/article/2553939/lamp.html https://www.computerworld.com/article/2553939/lamp.html
- morelisp 4y ago
  Linux/Anginx/M4/Postgres, baby.
maccard 4y ago
I disagree. For a startup it should be whatever you know and are familiar with, and preferably something managed. For $20/month you can run a mysql database, plus a DO app platform app which is a docker container with whatever stack you want. A single tutorial will give you a CI CD pipeline with reproducible artifacts and something that will scale until it's worth actually paying attention to it.
- TekMol 4y ago
  DO app platform is rather new. It will probably be in flux for the forseeable future. And then you have to dabble with changes. With barebones LAMP you can be a happy camper.
  - maccard 4y ago
    Its 2 and a half years old. I've had a side project (just a crude app) deployed with this and GitHub actions for a year, and in that time I've not once had to change anything on the DO side. I can set up a CI pipeline that deploys to a DO app service in under 5 minutes and not have to touch it again for a long time. If DO decides to pull the rug on supporting containers then I'll use some other similar platform, and in the unlikely scenario that all of those providerd disappear, ill spin up a VPS on whatever provider you run your custom lamp stack on, install docker and move on. Until that day comes, I won't worry about the underlying platform and I'll continue to deploy using a zero friction pipeline that I set up when I waited for my coffee to brew one morning last January
- digdugdirk 4y ago
  Could you expand/explain this a bit more for the less technically inclined in the audience?
  - deleted 4y ago
    [deleted]
  - maccard 4y ago
    What part do you mean?
- artificialLimbs 4y ago
  >> A single tutorial will give you a CI CD pipeline with reproducible artifacts Have any good links for this?
  - maccard 4y ago
chriswarbo 4y ago
Agreed. I would recommend learning many concepts, e.g. in the database section, what's the difference between a document/time-series/column/graph/etc. database. A broad knowledge of such things makes us better at choosing the right tool for the job, rather than (poorly) re-inventing stuff that already exists. However, I wouldn't bother choosing any actual implementation, for a few reasons: - It takes time that could otherwise be spent learning something else - If you're inheriting a legacy project, that choice has already been made for you - If you need to choose one for some green-field project, the landscape/tradeoffs may have changed since you originally learned this stuff (e.g. your preferred tool may have been discontinued, or some alternative has solved a bunch of its problems, etc.) When it comes to actually building stuff, start small and simple (e.g. LAMP, (Fast)CGI, etc.); whilst keeping those concepts in mind to avoid limiting future options (don't over-abstract, since YAGNI; but likewise don't paint yourself into a corner)
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
akavi 4y ago
I’d amend that to “whichever of python or typescript you’re most comfortable in”, but otherwise agree
reducesuffering 4y ago
Not as of a couple years ago. Frontend is too primitive to move as quickly as Next.js. There’s a reason 2/3 of significant new web projects coming out, I view-source and it’s Next.
- elforce002 4y ago
  Guilty as charged, hehe. Where I work it was decided that we rewrite all our platforms. We decided going with Next.js and We couldn't be happier. We don't care about lit, qwik, solid, or any other framework for that matter. I mean, we know they are there but there are much to cover and the team is already comfortable using Next. API routes are good too for business logic pertaining the app itself. For our backend, we stayed with TS, Node.js, and the good ol' Express.js.

by TekMol 4y ago

chirau 4y ago

Oh, the P in LAMP is now Python? Haha, i have always known it to be PHP

jmyeet 4y ago
You’re correct. It was always PHP.
TekMol 4y ago
I have the feeling the meaning turned from "PHP" to "PHP or some other interpreted language like Python, Perl, Ruby or JavaScript" over time. That's why I said "for example".
ipaddr 4y ago
It was originally Perl or PHP Python fits well.
kbutler 4y ago
LAMP with PHP/Perl/Python has been common for a long time - at least since 2006 https://www.computerworld.com/article/2553939/lamp.html https://www.computerworld.com/article/2553939/lamp.html
morelisp 4y ago
Linux/Anginx/M4/Postgres, baby.

maccard 4y ago

I disagree. For a startup it should be whatever you know and are familiar with, and preferably something managed. For $20/month you can run a mysql database, plus a DO app platform app which is a docker container with whatever stack you want. A single tutorial will give you a CI CD pipeline with reproducible artifacts and something that will scale until it's worth actually paying attention to it.

TekMol 4y ago
DO app platform is rather new. It will probably be in flux for the forseeable future. And then you have to dabble with changes. With barebones LAMP you can be a happy camper.
- maccard 4y ago
  Its 2 and a half years old. I've had a side project (just a crude app) deployed with this and GitHub actions for a year, and in that time I've not once had to change anything on the DO side. I can set up a CI pipeline that deploys to a DO app service in under 5 minutes and not have to touch it again for a long time. If DO decides to pull the rug on supporting containers then I'll use some other similar platform, and in the unlikely scenario that all of those providerd disappear, ill spin up a VPS on whatever provider you run your custom lamp stack on, install docker and move on. Until that day comes, I won't worry about the underlying platform and I'll continue to deploy using a zero friction pipeline that I set up when I waited for my coffee to brew one morning last January
digdugdirk 4y ago
Could you expand/explain this a bit more for the less technically inclined in the audience?
- deleted 4y ago
  [deleted]
- maccard 4y ago
  What part do you mean?
artificialLimbs 4y ago
>> A single tutorial will give you a CI CD pipeline with reproducible artifacts Have any good links for this?
- maccard 4y ago

chriswarbo 4y ago

Agreed. I would recommend learning many concepts, e.g. in the database section, what's the difference between a document/time-series/column/graph/etc. database. A broad knowledge of such things makes us better at choosing the right tool for the job, rather than (poorly) re-inventing stuff that already exists. However, I wouldn't bother choosing any actual implementation, for a few reasons: - It takes time that could otherwise be spent learning something else - If you're inheriting a legacy project, that choice has already been made for you - If you need to choose one for some green-field project, the landscape/tradeoffs may have changed since you originally learned this stuff (e.g. your preferred tool may have been discontinued, or some alternative has solved a bunch of its problems, etc.) When it comes to actually building stuff, start small and simple (e.g. LAMP, (Fast)CGI, etc.); whilst keeping those concepts in mind to avoid limiting future options (don't over-abstract, since YAGNI; but likewise don't paint yourself into a corner)

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]

akavi 4y ago

I’d amend that to “whichever of python or typescript you’re most comfortable in”, but otherwise agree

reducesuffering 4y ago

Not as of a couple years ago. Frontend is too primitive to move as quickly as Next.js. There’s a reason 2/3 of significant new web projects coming out, I view-source and it’s Next.

elforce002 4y ago
Guilty as charged, hehe. Where I work it was decided that we rewrite all our platforms. We decided going with Next.js and We couldn't be happier. We don't care about lit, qwik, solid, or any other framework for that matter. I mean, we know they are there but there are much to cover and the team is already comfortable using Next. API routes are good too for business logic pertaining the app itself. For our backend, we stayed with TS, Node.js, and the good ol' Express.js.