Hacker News new | past | comments | ask | show | jobs | submit login

I sometimes find myself hacking together a quick console-based or vanilla JS prototype for an idea and then just stop there because messing with different cloud providers, containers, react, webpack and etc is just soul draining. I remember when I was 14 I'd throw up a quick PHP script for my project, upload it to my host and get it up and running in just a few minutes. A month ago I spent week trying to get Cognito working with a Serverless API and by the time I figured it out I was mentally done with the project. I cannot ever seem to get over this hump. I love working on side projects but getting things up and running properly is just a huge drag these days.



Maybe just go back to PHP :D

I mean, I am enjoying the custom webpack setup that I built for my work project... but just because I can do that stuff doesn't mean I should.

Nothing wrong with tossing a php script on some shared hosting.


The secret to building side projects fast:

* Django https://www.djangoproject.com/ * Unpoly https://unpoly.com/ * Parcel https://parceljs.org/ * Heroku https://www.heroku.com/ * Tailwindcss https://tailwindcss.com/


Do you use Unpoly on production or just on toy projects?


Me and my team manage many services and web apps at work. We only used it in production on just one of them and it works very well. The most difficult part is convincing a bunch of pure frontend guys without much backend experience to use it.

Other than that, I use it in several of my own side projects.


Awesome. I can imagine it being a struggle to get front-end devs on board, but I'm glad to hear it's working well.

Thanks for answering.


Confession: it took me like two damn hours the other day just to figure out how to get TS code that included Node modules packaged for the browser. There was a lot of advice that was wrong or outdated or otherwise didn’t work. I’ve written JS since before jQuery was a thing and have done some damn good work in React and React Native, but hadn’t dealt with bundlers and such manually. Phew boy, it is a mess.


Yes my frustration is the entire frontend in x framework now requires nodejs by default. I develop with Javascript (nodejs), Erlang(Elixir) and Ruby(Ror and Jekyll). The one pain point is managing the nodejs dependencies in these projects.


It is very hard to control your dependencies when you use a framework or a transpiler in JS. They bring in tons of other packages which have their own dependencies and so on.

This has also opened a new dangerous attack vector where hackers take over a small forgotten component used by many nodejs packages and inject malicious code into projects without anyone noticing.


can you give some tips? I'm starting out with this too, and would love to hear how you ended up doing it.


Hahaha, I've already forgotten :-(

It ended up being some arcane combination of config for... webpack, I think? Which is really weird because it seems to me "bundle all this in one file for web" is one of the countable-on-one's-fingers most-common use cases for a JS bundler, so should probably be available with a command line switch and no config file at all.

If I've found the right file (I was just trying to slap something together to try out a couple node modules in the browser... so much for that being quick & easy) then I ended up on an es5 target for TS, with "amd" module output. I've also got about a 12 SLOC webpack config file that specifies a single output "bundle.js".

The worst thing about troubleshooting shit like this is it's rarely clear what's broken. Is some part of the build choking on a bad ES-version + module combo (but just producing a broken build rather than, you know, fucking telling me that)? Is it a bundler config problem? Is Node at the wrong version(!)? So the troubleshooting process rapidly becomes combinatoric, which is an awful experience. You google some of these problems and see that everyone else is clearly going through the exact same "try one combination, see what happens, try the next" brute-force approach as you are. Meanwhile, again, the common use cases for these tools seem easily enumerable and quite tractable, so why they're driven indirectly by smashing together a bunch of implementation details until they work, rather than by explicitly stating which of a small number of common desired outcomes one wants and letting the build tools figure out how to make that happen in all but the most unusual cases, is baffling to me.


yeah I think I'm in the same boat, just not nearly as far as you. Thanks for the tips, I will give webpack a try (I was trying to use Parcel, but havent looked into browser-side yet)


AWS is not a great place for small projects that you want to set up quickly. There are a lot of options with a much more lightweight setup experience: zeit/vercel, netlify, digitalocean, firebase.


Heroku does well from 10 years ago


Digitalocean


> A month ago I spent week trying to get Cognito working with a Serverless API

Do you actually need Cognito and a Serverless API?

It's a drag because you put yourself requirement that make no sense with your project. The goal of theses tools are to make you go quicker, if they doesn't, it should be your first warning that they aren't for you right now.


I'd be lying if I said this wasn't the case for myself :) All the new stuff also drains me and I'm a lot more motivated to hack up stuff in PHP and jquery for these side projects. I think you shouldn't let "the modern way to do things" stop you from hacking up prototypes in whatever way you want.

I'll say though, after having done a few side projects with modern SaaS/stack -- e.g. Netlify, Heroku, nodejs -- it does start to look like to me that it's a time trade-off. When I embrace the JAM stack with static site gen (with Svelte/Sapper) and an API layer (nodejs on Heroku), what I'm doing is trade the time to get started (more time/effort) with less maintenance and deploy effort later. But if you have the passion to hack up something right this moment and can't deal with that drag to kick off the project, and you don't know if it's a product that'll work out and get traction anyway, by all means hack it up in PHP and jquery.


I think that time trade-off really comes down to your current skill set. Learning less new stuff is just faster for small projects.


The funny thing is, I love to setup a backend and AWS environment and then get stuck on building an UI (dreading anything js related). I guess that why we should find others to collaborate with :)


I feel this. When I was younger, I would focus more on just getting something working, and now I feel more the need to do things "the right way" since I know better. I think I need to get back to just getting things working.


Recently I was able to finish a working prototype for a tiny side project and I skipped a few things that I would have considered "the right way", like even a good code structure, it went well and you know what, at the end, my code was a bit better structured, it was closer to the "right way" than I thought, it works well and each time I works on it, it get a bit closer to the "right way".

It made me realize that the "right way" is also a question of circumstance. The "right way" exist for one thing, avoiding some kinds of issues, but a side project is often quite simple, and most of theses issues won't happen, you most likely won't gains anything doing theses, so is it really the "right way" then?

It was hard to write that badly at first, hell my server side code is still mostly a single file, but most of my code took only a few hours to write, it's so easy right now to just erase a part of it and make it better. The frontend is using React, and at first it was a single big component, again the wrong way, but that component did something and it was working. Once I got some duplication in it, well I moved some stuff to another component. I could have done that earlier, I knew I would have duplication there, but I would have lost time making another component if I had abandoned the project (and I would most likely have if I had done everything "the right way").

So yeah, I'll keep doing it that way for now, doing it the bad way until I actually need the right way.


I feel you. And even if you get everything to run well on a VPS or Netlify, opening it up to a big user base, limiting liability and generating income is another huge battle. I’m working on a side project I want to transform into an entire self-sustaining business at the moment. When I first had the idea, I got a prototype of the key parts up and running in less than a month. Now it’s been like a year and I spent my days optimizing webpack chunk sizes, trying different pwa cache busting techniques, reading Stripe-integration docs, studying international VAT schemes, legal requirements, ... The step from zero to product is way smaller than the step from product to law-abiding, income-generating service-providing business.

Edit: For those of you looking for a way to get simple prototypes working without having to use opinionated frameworks like Laravel or going down the JS rabbit hole, try Flask (in combination with SQLAlchemy and Marshmellow if you also need a simple ORM). Full flexibility, can be learned in minutes and you have the whole freedom of Python to do what you want.


Nice to hear I'm not alone, I am starting a similar journey myself. Any tips on minimizing the legal exposure?

As for the VAT, I am leaning towards paddle instead of stripe, because they take care of everything tax related (for a bit bigger piece of pie of course). Any thoughts on this?

Good luck!


I’m EU-based and my business is going to be B2C SaaS so these tips might not help you a lot. To minimize legal exposure the safest bet is to form a limited liability company wether that be a Spanish SL, a Dutch BV ir a German GmbH. Usually these also have a smaller counterpart which doesn’t require as much capital but still provides you with limited liability. If you need an US based corporation Stripe Atlas might also be of interest to you or if you need an EU-based one Estonia offers something called an eResidency and lets you create an EU business from abroad. Apart from that having an account take care of your taxes or at least proof-read your yearly filings seems like another step to limit you personal responsibility, even if a bit expensive.

As for VAT, I’m focusing on the EU market at the moment. EU law is that all SaaS B2C sales have to pay VAT in the country where the client resides, luckily there’s a process called mini one stop shop which allows you to file your VAT taxes in one EU country (while still indicating the country of every sale) which will then take care of the redistribution of the VAT taxes (a similar procedure exists for non-EU businesses who have EU customers, searching for EU VAT on e-Services should help you get started). With Stripe that means creating a taxId for every country and matching that with the country of residence my users have to provide on checkout when I create their session in the backend. Sadly I haven’t found any good applications that then take care of everything so it’s probably going to have to be a mix of csv importing everything into accounting software and handing everything to an account. It’s a bit frustrating tbh because it looks like accounting will be the single biggest expense in the initial phase of the business. So if anybody knows of a good solution for EU-wide SaaS B2C sales with Stripe I would be happy if they shared them. Even Quaderno and the like are not really feasible if you’re product costs less than 5$/month since they base their pricing on the number of sales.


Thank you for a detailed answer! Yes, I'm based in EU, but the customers could be from USA, AUS, India,... I am hoping to address all (well, most) of the markets from the start.

Btw, it might make sense to contact Quaderno (/others) and describe your pain point, they might be able to offer some solution.


Was in the same boat (regarding the Javascript ecosystem) until I discovered NextJS. It's pretty opinionated, but lets me get fully functional React sites up and running in with sensible defaults in minutes. Not exactly as clean as PHP, but for quick projects, it's removes a substantial amount of overhead.


This is why I still love Ruby on Rails. I can rapidly build something robust and throw it up on Heroku with no issues. I recently built a little thing for myself and had it built and hosted within a few hours.

Rails 5 with webpacker and turbolinks strikes the perfect balance between classic and modern web dev imo.


100% this. So much environment complexity these days before you get to Hello World. Command line, install this and that, mess with configuration files and on and on.

Like you, the last quick prototype I did was all html and js uploaded to a shared hosting (https://arcadejack.com). I would like to get back to building simple apps, but the barriers are higher than 20 yrs ago. For my current side project I'm using PHP and hired a developer online to help me with initial boilerplates.


I'm pretty good at JavaScript ecosystem, like Webpack and all other staff.

But for me, to setup some full-sized project is still pretty daunting, and boilerplates and scaffolds are pretty messy and brittle.

When I'm setting up side projects, I would still use Basic Node.js + Parcel + Heroku as a starting point. It would only take minutes at most.


100% give Heroku a chance. It’s free to play with and takes care of 90% of that non-app-dev rubbish.


Build with the Boring Stack! ™


I think the trick is to make it non-scalable and once you run into scaling issues you are profitable enough to hire someone to do it for you :)


This. I'm curious why We should use techs that could scale massively but has some limitation like Firebase DBs .


One can scale quite a bit by just getting bigger servers.


A Node basic backend project is pretty simple. I don’t come across any complexities really. The most would be the web server in production. However that is unfair as I am familiar with Apache and Nginx because of PHP.

Something like React is almost plug and play at this point. It builds into a static site that can be uploaded any more.

Even a non basic PHP app is more effort


Just go back to using PHP (or sth similar like Rails or Django).

Serverless, everything-in-javascript, jamstack etc. are fads that are currently overhyped. (There are of course use-cases where they make sense. But for most project having a normal backend is clearly superior and much simpler.)


I have a server at home that I use for exactly that: Small prototypes/scripts I hack together and want somewhere hosted.

That, or I use heroku/a private k8s cluster on digitalocean when it's a tad more serious, that I just throw the docker container on and have it over with.


I’m running into some of the same issues working with cloud native applications. The tooling and observability just isn’t there yet. I think the future is bright for the tech but it’s just very early. Fighting the AWS console is the worst.


I picked up reactjs as the framework, and firebase services for the backend. Life becomes much easier. I tried Vercel & Render, both are good alternatives.


I'm quite fond of CapRover personally, but yeah there is a brain drain from all of the shit needed to get something on the internet securely.


This is why I keep telling people that their recommendations that EVERYTHING should be on serverless or k8s or whatever, is appropriate.


If you want to nonetheless do it serverless, you should look into either AWS Amplify or Firebase


Check out AWS Amplify, it strips away a lot of the complexity and time consuming config work.


what about netlify drop? you can get a website up and running in seconds ;)




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: