Live data from Hacker News

Ask HN: What stack would you use to build a CRUD web app in 2018?

news.ycombinator.com

181–184 of 184 posts

Re: Ask HN: What stack would you use to build a CRUD web app in 2018?

#182
post #69

Start with what you know, don't spend months figuring out a certain database tech for example when MySQL/mariaDB is just as good for 99% of the use cases. I know there's a lot of bias out there against PHP. But I would still use it over the alternatives, there's a large community. With excellent frameworks who do the heavy lifting for you. (Symfony, Laravel). Great support and tooling, a large recruiting base and eas…

"_Start with what you know_" - amin to that. I also found this is the most important consideration for this decision. I've made the mistake of applying the "_if it fails, at least I used and learnt a new system_" logic, but every time I did that, I still preferred my old stack. So I ended up taking 2x as much time to build, to re-use nothing of the learning (on the development front). I'm now a big believer in the "_build fast, fail fast_" mantra.

My favorite stack: nginx, PostgreSQL/MySQL, PHP 7.1/7.2, Laravel, BackpackForLaravel for admin panels, jQuery/Vue.js

That being said, I'm the creator of BackpackForLaravel. So my productivity is off-the-charts with it, and I'm probably biased towards PHP. I think PHP is underrated, especially in the US & Silicon Valley. It's "cool" to hate on PHP for its past mistakes, and I agreed on many of them, but nowadays, with Laravel... - it's a joy to work in it (I now like it better than Ruby) - you get _so much_ done, so fast - I've been able to easily scale it for millions of users (I've built a social network, a video-on-demand app, an e-learning app - for clients, not myself) - PHP/Laravel developers are easy to find, all across the world, when you need it - there's a plethora of good agencies that use it, if you ever want to outsource the entire development team

IMHO, Laravel is here to stay. And with BackpackForLaravel for admin apnels, I hope it'll soon be on par with Django.

Re: Ask HN: What stack would you use to build a CRUD web app in 2018?

#183

I work with startups, so I make this decision every 2-3 weeks or so. Language: Python. Python is easy to learn for those that don't know it, and all-around liked. It's not hard to find engineers with existing experience if you need to grow. Framework: Django. Django does everything you might want in a framework. It scales with larger teams, and the admin is still one of its killer features. Frontend: SCSS/SASS, and v…

I always had a question I wanted to ask an experienced Django dev. After trying this framework for a couple of hobby projects (I'm a client game developer primarily and never worked on "serious" web project), I kinda got the impression that it's architecture is created for two main user roles: admins who create most of the content and have marvelous admin forms in front of them to input all the data, and users, who m…

It sounds like the "out-of-the-box" expectations created by the admin app are the problem. I mean, hey, Django makes exposing data models in the admin interface trivial! You can certainly create more complicated forms for relational data, but in those cases you can't rely on Django's default functionality to do as much for you. I've written or worked on more than a few serious apps including those with more complex user facing data and Django's worked beautifully. Happy to answer any specific questions you might have.

Re: Ask HN: What stack would you use to build a CRUD web app in 2018?

#184

Earlier quoted context omitted.

In-memory cache: Redis. Do you typically run Redis on the same host as your web server? Treating it as "in-memory" can have interesting side effects as you centralize it and introduce network delays.

> Do you typically run Redis on the same host as your web server? Yes, at least initially. > Treating it as "in-memory" can have interesting side effects as you centralize it and introduce network delays. I'd love to hear more about this!

Sorry, totally missed this because there is no notification system here...

Let's say you have a large, tight loop in which Redis is used. If it's local, great, no problem. Now when it's centralized, you introduced a network delay you hadn't planned for. This "gotcha" comes up when you mess around with cache locality and didn't account for the delay changes in all areas of code.

Post reply on HN