Hacker News Reader

Comment by slibhb | Hacker News Reader

You're arguing about configuration vs convention. You can prefer batteries-included frameworks (convention). Other people can prefer a barebones approach (configuration). Either way, it's full stack if you can write code that runs on the server and code that runs on the client.

View on HN

Either way, it's full stack if you can write code that runs on the server and code that runs on the client.

I wouldn't call it full stack without a database.

Clearly, we're not gonna reach any conclusion in this debate of what it means. So what's more fun than stop arguing over definitions? Polls, of course! Here is one: https://news.ycombinator.com/item?id=29811603

Once completed, we have our answer :)

While I all generally think of a database being a part of full-stack, I'm not so sure that it makes sense to be a prerequisite. A database is just a tool for storing data. If all you need is in-memory data, flat file, or even no long-term data at all, I see no reason the requirement of long-lasting data to be a requirement for full-stack.

That being said, the more I keep thinking about it, the less useful the term full-stack even feels. Why is front-end + back-end + database (+ other?) the full-stack? Why not also require third-party integrations? What about the hardware? Should the definition of full-stack expand as the options do, or should it stay static at whatever it's original usage was?

"Why not also require third-party integrations" - it almost has to include that anyway, but.. the skill set required to understand and work with third-party integrations is almost certainly going to be a subset of 'front-end' or 'back-end' anyway. Mastery of client side and mastery of server side are distinct enough that those sort of 'what abouts' you raised seem to fall under the broad 'front/back' domains already, no?

There's enough virtualization that 'hardware' itself is a somewhat elastic term. However, I've had to deal with 4 different devs in the last few months, all trying to get set up with one of two projects. Both are docker-based. But... "well, I'm on windows... I'm on WSL... I'm on Mac, but M1... I'm on Mac, but Mojave, and this doesn't work..., oh, I can't have 2 things running on the same port?" Unless every single person is on the exact same hardware/OS combinations, having some understanding of 'hardware and OS diffs' and how they may impact you may still be necessary.

Convention is what you have in rails. Configuration is what you have in Django. What you have when you need to take 1k decisions per second and tie things together to kind of reproduce something usable as a whole is something totally different.

Reply on news.ycombinator.com