Live data from Hacker News

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

news.ycombinator.com

171–180 of 184 posts

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

#171
Development: Definitely Laravel (PHP7 + Mysql) for backend with Vue 2 + Webpack (or mix) for frontend. It's the best combo to get shit done.

Deployment: EC2 or DO both work great.

P.S. Most important thing. Do not worry about optimization before you ship your first version.

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

#172

Twenty years ago, a simple CRUD app would have been written in Visual Basic or Delphi. It would have needed one programming language, and one framework. The tool support would be good: everything would talk to everything else. Heck, you'd even have an IDE with autocomplete! Today, a typical web app requires no fewer than five different languages (JS, HTML, CSS, Python/Ruby/whatever on the server, SQL). And that's bef…

Worth checking out https://apex.oracle.com/en/ apex also, easy to build and a no cost/license option.

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

#173

Twenty years ago, a simple CRUD app would have been written in Visual Basic or Delphi. It would have needed one programming language, and one framework. The tool support would be good: everything would talk to everything else. Heck, you'd even have an IDE with autocomplete! Today, a typical web app requires no fewer than five different languages (JS, HTML, CSS, Python/Ruby/whatever on the server, SQL). And that's bef…

I think this is at a tipping point and will be solved soon (for better or worse) because network effects. Technology at each layer consolidates once the next layer is identified, which I think is functional programming everywhere and thus anticipate a consolidation is already underway.

Hmm, according to wikipedia lisp appeared 60 years ago, so it's had some chance to gain ground and functional is popular currently but everywhere, soon seems like a stretch

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

#174
post #86

Earlier quoted context omitted.

Home-grown means every other developer that ever has to touch it is going to have huge additional overhead getting started with the codebase (because your documentation is going to be nonexistent), and you're going to spend a ton of time unnecessarily reinventing the basics. These days it's never worth it to home roll in the CRUD world. There's way too much good tooling out there.

While it is true that there is additional overhead, they did say "if the application is going to be around for more than 5 years". After 5 years there is a better chance you can make changes to a pure language coded app, than try and get what ever stack was common at that time working. Basically, it could be the difference between throwing away your app and rewriting it.

I'm working on code bases that are 10 years old today, built on asp.net webforms and mvc. If you don't choose a FOTM you'll be ok, all the answers are still on SO.

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

#175

You should not write a CRUD app in 2018. Update and delete are remnants from the times where memory and disk were expensive, and update in place was a necessity. This is no longer the case. Apart from a few very specialised use cases, there is no need any more for update or delete. Record new facts and don’t destroy the older ones.

Going to laugh when anyone audits you for GDPR compliance. This is the exact sort of shit the laws are being brought in to prevent.

If a users wants data deleted they want the data DELETED, not kept for a hacker to hoover up in a few years time.

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

#176

Earlier quoted context omitted.

While it is true that there is additional overhead, they did say "if the application is going to be around for more than 5 years". After 5 years there is a better chance you can make changes to a pure language coded app, than try and get what ever stack was common at that time working. Basically, it could be the difference between throwing away your app and rewriting it.

> than try and get what ever stack was common at that time working Doesn't seem like a problem for languages with sane package management solutions, of which there are plenty. A Java app on Maven is going to work just fine in 5 years, and on the latest version of java to boot.

Maven is a build tool and can help manage dependencies. It doesn't ensure your code base is compatible with the latest version of the dependency or ensure the dependency is still supported.

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

#177

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…

Is there any way you could create (or link) a small, open source app that uses these technologies.

Something good for beginners? I realize I'm asking for a lot but I might as well ask.

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

#178
post #173

Earlier quoted context omitted.

I think this is at a tipping point and will be solved soon (for better or worse) because network effects. Technology at each layer consolidates once the next layer is identified, which I think is functional programming everywhere and thus anticipate a consolidation is already underway.

Hmm, according to wikipedia lisp appeared 60 years ago, so it's had some chance to gain ground and functional is popular currently but everywhere, soon seems like a stretch

Not sure if trolling. FP requires fast immutable data structures. Okasaki was published in 1998. Persistent data structures require amazing GC. JVM got good in 2000s. To do it in the database requires cloud scale compute and storage. AWS got good in 2010s. Datomic (functional paradigm postgres killer) got good in 2018.

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

#179

If you're using Postgres and want to get something done today, use PostgREST: https://postgrest.com/en/v4.4/ It is the fastest, leanest, and most powerful way to interface to postgres with an API. I've been using Python for 25 years an can tell you with certainty that Django is a slow, leaky, autocommit-infested, memory hogging pile of crap with a degenerate half-ORM that cannot model even the simplest aggregates. ht…

This is the exact thing everybody seems to be looking for. Create the DB, get an API out of it, polish it off with a frontend framework. Why hasn't this taken over the world by storm? What's the catch?

The coaching gap: https://www.youtube.com/watch?v=ecIWPzGEbFc

People early in their career thinking SQL is something UNIX greybeards did in ancient times, and which is not necessary anymore.

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

#180
post #172

Twenty years ago, a simple CRUD app would have been written in Visual Basic or Delphi. It would have needed one programming language, and one framework. The tool support would be good: everything would talk to everything else. Heck, you'd even have an IDE with autocomplete! Today, a typical web app requires no fewer than five different languages (JS, HTML, CSS, Python/Ruby/whatever on the server, SQL). And that's bef…

Worth checking out https://apex.oracle.com/en/ apex also, easy to build and a no cost/license option.

Being an Oracle consultant by trade I'm probably biased, but I've always enjoyed the simplicity of Apex from a developer's perspective. Simple CRUD forms can be built and published in minutes that are both functional and beautiful. The language stack is SQL/PLSQL/HTML/CSS/JS, and most all of the Javascript you'd ever need to write for field validations, etc. is built for you. I think folks tend to ignore it because it's not open source, but as a tool it's underrated. Not the most performant solution out there, granted, but suitable for most cases. If your backend database is Oracle, it should absolutely be in consideration.
Post reply on HN