5 ms·

I would strongly encourage you not to dive into learning React or AWS. Both are very good to learn about if your goal is to become an employee at a tech company

I would strongly encourage you not to dive into learning React or AWS. Both are very good to learn about if your goal is to become an employee at a tech company, but not so much for a solo founder. React itself is fine and relatively straight-forward, but its ecosystem is massive and there are many competing options for several accompanying libraries. AWS includes a powerful array of services, but it's considerably more time-consuming to learn than other hosting options such as Render.com. I'd say your best bet is to just use an MVC-ish back-end framework and sprinkles of JavaScript. Once you've done well enough to hire a few engineers, then maybe start thinking about React, AWS, more complex devops, etc. At the beginning, the most important thing is speed.

ramraj07 6y ago
Disagree on AWS. It's not that hard, and if you're gonna spend any amount of time figuring some vendor locked cloud system (which they all are), AWS is the best bet. And you obviously need to be careful with using every service that company throws at you, but barring that they provide the most solid reliable suite of services you can hope for so you spend more time on logic and business after some initial time investment.
- thinkingkong 6y ago
  No AWS _is_ hard. It's hard. They're all hard. They require tons and tons of knowledge before understanding what to look at, how to use it, when to use it, etc. Everyone who thinks these systems are simple completely take for granted the years and years of knowledge they've acquired. Even in the form of shared vocabulary, AWS is insane. IAM is a whole other nightmare of complexity that is insanely powerful, but I wouldn't dare point anyone in that direction if they were just starting out.
  - porknubbins 6y ago
    I’ve found AWS services individually to be straightforward but the UI is full of unintuitive menus so you always end up having to google “how to x on AWS”. Also understanding how to make the services interact takes a fairly high level of networking knowledge.
- yowlingcat 6y ago
  I dunno about that. AWS is useful at a certain point, but I must say, if I want to spin up a prototype that I need to get into production ASAP with no pre-existing infra, the first tool I reach for is Heroku. It's hard to beat how clean the UX is. Why? It's opinionated. I get an instance of an RDBMS and my service. It's really easy to install Heroku apps. It doesn't make me learn unrelated abstractions to do that, or fill my life with pointless noise and bullshit. I will always appreciate AWS for how I can rely on it in production, but it definitely require a lot more verbosity and configuration than it needs to. I wish we would remember the product design lessons DHH taught us. Convention is preferable to configuration when possible for a reason. It reduces unnecessary complexity. It makes it easier for your brain to work with.
  - AlchemistCamp 6y ago
    The option I suggested, Render, is essentially the new Heroku. It's focused on dev experience, run by ex-Stripe people who worked on their infra and it's much less expensive than Heroku has been post-acquisition. If you want something managed that requires minimal time worrying about infra, they're a great choice. For something that truly requires low costs per user, I wouldn't use them but they make a ton of sense for many projects. And to be fair, AWS also has some serious limitations in terms of price scalability compared to a VPS like Digital Ocean or Linode: https://questinglog.com/costs-are-part-of-scalability/#just-egress-bandwidth-costs-can-be-considerable https://questinglog.com/costs-are-part-of-scalability/#just-...
    - yowlingcat 6y ago
      I think you are comparing apples and oranges. Heroku is great not just because of its DX, but 1) because it's a subsidiary of Salesforce and I know it won't disappear tomorrow and 2) it has a thriving app ecosystem. It's a real stretch to compare a recent $2.25M seed funded upstart with it and borderline malpractice to suggest running your production workloads on it. With AWS although you have to pay the premium on egress, you don't pay that until you leave their sandbox; what's more, you can add links into your VPC that sidestep it. If you're just running open source software or a kubes cluster on commodity boxes and you're fine owning all of your operational burden, sure. Use whatever you like. But if you want reliability and good DX, your options get narrower. Personally, I think that AWS Code Suite and VS/Azure spaces (and GitHub spaces by proxy) are going to be the real challengers in this space. There is a real UX problem to solve but it doesn't mean I want to necessarily use a different platform.
whoknew1122 6y ago
Strong disagree on not learning AWS (or another cloud provider). I was partial to AWS even before I worked for them, but chances are you're going to run your startup in the cloud. For that, you should know at least the basics of the cloud you're going to use. I'm not saying learn CloudFormation, CodeDeploy, or any of the hardcore DevOps stuff you'll be interested in once you start to scale. But you need to know how security works (i.e. IAM), how to build networking infrastructure (i.e. VPC), how to deploy servers and databases (i.e. EC2 and RDS/DynamoDB). And, of course, how to do things cost-effectively. If you don't take the time to learn the cloud, you're going to be stuck when it's time to push your project into production. So you're going to need to: 1.) Hire a cloud architect. This isn't cheap nor is it a good solution. If you ever part ways with your cloud architect, you're going to be starting step one all over again. Except now you have to learn how the cloud works and how your environment was architected. And that's assuming your architect doesn't maliciously make a mess of things on the way out (which happens -- A LOT). 2.) Open a support ticket for every little issue you run across. This can easily become a blocker with deployment. Not to mention you're likely going to have a developer support plan. Which means you get email-only support and the replying support engineer may not even be in your timezone. So not only do you have to deal with the inefficiency of back-and-forth email conversations, you may have to deal with the time lag based on the engineer who works on your case.
- coffeefirst 6y ago
  Alternatively, if I were starting a business tomorrow, I'd start out with Heroku or a normal VPS (Linode) depending on the budget and requirements, and only switch to AWS when it made economic sense to invest in that setup.
  - whoknew1122 6y ago
    This is a fair way to go about it. Really, my point is that you're likely to use the cloud. And if you're running a small/solo shop, you really need to learn the basics of that cloud vendor before rolling out on the cloud platform. I see too many people roll things out on AWS without any knowledge of the platform whatsoever.
- 6y ago
mraza007 6y ago
Do you suggest investing time in frameworks like Django or Rails
mr-ron 6y ago
> At the beginning, the most important thing is speed. Specifically, speed of development

ramraj07 6y ago

Disagree on AWS. It's not that hard, and if you're gonna spend any amount of time figuring some vendor locked cloud system (which they all are), AWS is the best bet. And you obviously need to be careful with using every service that company throws at you, but barring that they provide the most solid reliable suite of services you can hope for so you spend more time on logic and business after some initial time investment.

thinkingkong 6y ago
No AWS _is_ hard. It's hard. They're all hard. They require tons and tons of knowledge before understanding what to look at, how to use it, when to use it, etc. Everyone who thinks these systems are simple completely take for granted the years and years of knowledge they've acquired. Even in the form of shared vocabulary, AWS is insane. IAM is a whole other nightmare of complexity that is insanely powerful, but I wouldn't dare point anyone in that direction if they were just starting out.
- porknubbins 6y ago
  I’ve found AWS services individually to be straightforward but the UI is full of unintuitive menus so you always end up having to google “how to x on AWS”. Also understanding how to make the services interact takes a fairly high level of networking knowledge.
yowlingcat 6y ago
I dunno about that. AWS is useful at a certain point, but I must say, if I want to spin up a prototype that I need to get into production ASAP with no pre-existing infra, the first tool I reach for is Heroku. It's hard to beat how clean the UX is. Why? It's opinionated. I get an instance of an RDBMS and my service. It's really easy to install Heroku apps. It doesn't make me learn unrelated abstractions to do that, or fill my life with pointless noise and bullshit. I will always appreciate AWS for how I can rely on it in production, but it definitely require a lot more verbosity and configuration than it needs to. I wish we would remember the product design lessons DHH taught us. Convention is preferable to configuration when possible for a reason. It reduces unnecessary complexity. It makes it easier for your brain to work with.
- AlchemistCamp 6y ago
  The option I suggested, Render, is essentially the new Heroku. It's focused on dev experience, run by ex-Stripe people who worked on their infra and it's much less expensive than Heroku has been post-acquisition. If you want something managed that requires minimal time worrying about infra, they're a great choice. For something that truly requires low costs per user, I wouldn't use them but they make a ton of sense for many projects. And to be fair, AWS also has some serious limitations in terms of price scalability compared to a VPS like Digital Ocean or Linode: https://questinglog.com/costs-are-part-of-scalability/#just-egress-bandwidth-costs-can-be-considerable https://questinglog.com/costs-are-part-of-scalability/#just-...
  - yowlingcat 6y ago
    I think you are comparing apples and oranges. Heroku is great not just because of its DX, but 1) because it's a subsidiary of Salesforce and I know it won't disappear tomorrow and 2) it has a thriving app ecosystem. It's a real stretch to compare a recent $2.25M seed funded upstart with it and borderline malpractice to suggest running your production workloads on it. With AWS although you have to pay the premium on egress, you don't pay that until you leave their sandbox; what's more, you can add links into your VPC that sidestep it. If you're just running open source software or a kubes cluster on commodity boxes and you're fine owning all of your operational burden, sure. Use whatever you like. But if you want reliability and good DX, your options get narrower. Personally, I think that AWS Code Suite and VS/Azure spaces (and GitHub spaces by proxy) are going to be the real challengers in this space. There is a real UX problem to solve but it doesn't mean I want to necessarily use a different platform.

whoknew1122 6y ago

Strong disagree on not learning AWS (or another cloud provider). I was partial to AWS even before I worked for them, but chances are you're going to run your startup in the cloud. For that, you should know at least the basics of the cloud you're going to use. I'm not saying learn CloudFormation, CodeDeploy, or any of the hardcore DevOps stuff you'll be interested in once you start to scale. But you need to know how security works (i.e. IAM), how to build networking infrastructure (i.e. VPC), how to deploy servers and databases (i.e. EC2 and RDS/DynamoDB). And, of course, how to do things cost-effectively. If you don't take the time to learn the cloud, you're going to be stuck when it's time to push your project into production. So you're going to need to: 1.) Hire a cloud architect. This isn't cheap nor is it a good solution. If you ever part ways with your cloud architect, you're going to be starting step one all over again. Except now you have to learn how the cloud works and how your environment was architected. And that's assuming your architect doesn't maliciously make a mess of things on the way out (which happens -- A LOT). 2.) Open a support ticket for every little issue you run across. This can easily become a blocker with deployment. Not to mention you're likely going to have a developer support plan. Which means you get email-only support and the replying support engineer may not even be in your timezone. So not only do you have to deal with the inefficiency of back-and-forth email conversations, you may have to deal with the time lag based on the engineer who works on your case.

coffeefirst 6y ago
Alternatively, if I were starting a business tomorrow, I'd start out with Heroku or a normal VPS (Linode) depending on the budget and requirements, and only switch to AWS when it made economic sense to invest in that setup.
- whoknew1122 6y ago
  This is a fair way to go about it. Really, my point is that you're likely to use the cloud. And if you're running a small/solo shop, you really need to learn the basics of that cloud vendor before rolling out on the cloud platform. I see too many people roll things out on AWS without any knowledge of the platform whatsoever.
6y ago

mraza007 6y ago

Do you suggest investing time in frameworks like Django or Rails

mr-ron 6y ago

> At the beginning, the most important thing is speed. Specifically, speed of development