71–80 of 184 posts
HelloBar from 2012 seems to still be one of the top results.
Could you elaborate on your approach to setting up a WP CRUD app? What are your go-to tools?
Use a framework like symphony or laravel and you only need to worry about business logic. The rest is taken care of by the framework.
Great question. The funny thing is, 6 years ago, if you'd ask the same question (and I'm guess that's what you're coming from) the go-to answer on HN would've been Rails / Django something. Where both will allow you to build a basic crud app in 20 minutes. Since then, everybody has gone heavily into various javascript stacks, and the norm has become to deal with 20 different packages to build (somewhat) the same thin…
> But today's requirements in terms of UX / dynamism (is that a word?) require you to end up building things differently, so even if you get up and running fast with a rails app, you'd end up having to build up a pretty hefty JS stack in the end, so you'd basically be delaying the inevitable. I'm starting to wonder to what degree this is actually true. Most people I know, all along the spectrum of 'computer literacy'…
Secondly I’d argue that if “dynamicism” matters, choosing rails or Django doesn’t hinder that ability as a lot of that is simply presentation layer concerns.
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…
You need neither JS nor CSS to build a simple CRUD app. Just use the server technology of your liking and a database. Sure, it will look ugly but so did apps 20 years ago. The landscape got complicated because now we build beautiful and elaborate things. We have apps that serve hundreds if not thousands of users simultaneously. Modern databases get hammered with requests every single second. What was the average case…
As someone who works at a large company which has TONS of crud web apps, let me just say ...
No.
We don't.
We build ugly disasters, badly, with loads of bugs and unusable interfaces.
And of course, only very rarely are 2 crud apps built using the same stack. We have everything from Oracle WebForms to Ruby on Rails, to AngularJS on NodeJS.
And may I add, the "beautiful" ones are the worst in terms of usability. Can we place take all the frameworks that don't have a very good and built-in data grid and shoot them ?
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…
Golang for the API, running on Lambda. React or Vue for the UI. FaaS isn’t a fad, new systems built on an event based architecture are simpler, more cost effective, and scalable than the traditional application server approach. And the reactive programming pattern is easy and powerful and maps extremely well to modern UI needs. I have a boilerplate Go / Lambda app here: https://github.com/nzoschke/gofaas I use it wit…
// KMS is an xray instrumented KMS client
func KMS() *kms.KMS {
c := kms.New(session.Must(session.NewSession()))
xray.AWS(c.Client)
return c
}
You forgot "YAML for configuration. Python for ... I'm not even sure what for (linting the configurations ?), but you use lots of it. TOML for golang dependencies. JSON for other pieces of configuration. There is even some XML stuff in there". Even just limiting to Go you're using something like 10 large external libraries.
When I read this, I'm like ... sigh not AGAIN.
Oh and after starting it, may I just point out, that despite all that work, it's nowhere near as good as a Laravel, Drupal or Ruby-on-rails app, in terms of functionality (speficially, using this, you'll constantly need to write extra tools for basic operations on the database that your tool doesn't support, whereas each of those frameworks have something like Drupal's "admin"). And I might add, more expensive to host than either of those options too.
In increasing level of complexity. PHP is very fast to write, but gets unmanageable relatively quickly. GWT can handle anything you could possibly want to do, but it'll be quite a while before your app starts working.
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.