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 vanilla JS with some jQuery sprinkled in. When (if) the team/product grows, figure out which frontend framework fits best.
Database: PostgreSQL. Well-maintained, reliable, and great documentation.
In-memory cache: Redis.
Infrastructure: AWS. EC2 for hosting, S3 for file uploads and static file storage, CloudFront for content delivery.
Web server: nginx. Let's Encrypt for SSL cert generation.
App server: gunicorn. It works.
There are probably a few other things I'm missing but these are the big ones! All of my clients from years back (a few who now have 20+ people on their engineering teams) are still using this entire stack, so it scales both technically and as the number of team members grow. Happy to answer any questions!
I don't think that quote justifies your love of jQuery. The keywords are "some" and "sprinkled in". In my experience jQuery always trends towards a huge mess the more it is used.
Sure, it could be used but it really shouldn't.
Interacting with the DOM in a procedural way, and storing state on the DOM is always going to be harder to manage than using a reactive pattern when you trend towards more complexity.
`document.querySelectorAll` is amazing. It's a unification of the css syntax and javascript. No more filtering it your self, and your standard javascript stuff still works. It's wonderful.
All of this except Django, overkill for many small and mid sized projects. I use a lightweight Bottle/uwsgi api to get json into _underscore templates. Up and running in ten mins :)
I have a CloudFormation template that sets it all up for me in about 5 minutes (gets a little tiresome to do the same thing over and over again). Booting an EC2 instance and installing the necessary packages takes the bulk of that time. I spend about 30 seconds setting the project name and domain name, make some coffee, and by the time I'm done everything is up and running. The template sets up the GitHub repository, provisions the entire stack, and sets up auto-deployment, amongst a lot of other things.
Shameless plug: I'm currently looking for beta testers to use this provisioning tool, so if you're interested in trying it out for your stack, send me a note (email in profile).
Another commenter mentioned that EC2 was relatively expensive. Technically, that's true, but the sheer power of being able to automate everything in the infrastructure is pretty awesome.
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 mostly consume the content and only occasionally input some data. When I tried to create complex input forms with a lot of complicated, relational data that users would be able to input and modify, it felt so much harder than exposing the data models in the admin panel — it really felt that this wasn't the use case this framework was designed for.
Did I get the right impression, or may be I just didn't learn to use Django correctly?
> Generating admin sites for your staff or clients to add, change, and delete content is tedious work that doesn’t require much creativity. For that reason, Django entirely automates creation of admin interfaces for models.
> Django was written in a newsroom environment, with a very clear separation between “content publishers” and the “public” site. Site managers use the system to add news stories, events, sports scores, etc., and that content is displayed on the public site. Django solves the problem of creating a unified interface for site administrators to edit content.
> The admin isn’t intended to be used by site visitors. It’s for site managers.
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.
> When I tried to create complex input forms with a lot of complicated, relational data that users would be able to input and modify, it felt so much harder than exposing the data models in the admin panel
Hmm, really interesting. I can't say I've ever run into this, and maybe it's just that Django is so good at the admin stuff, it makes everything else look hard in comparison.
Most forms I have start off as subclasses as ModelForm. If I need to combine two forms on one page, I just give the form a prefix and populate them both within the same <form> tag. I'm not sure if this is the sort of more "complicated" use case you were thinking of, but y4mi's suggestion of breaking forms into sections with wizards is another great way to go about it.
i'm not an experienced django dev but i asked the same question some time ago. The answer i got back then was essentially 'one form per object, if you want to create two interdependent objects, just chain the forms into a "wizard"'
it kinda makes sense, considering how easy it is to create form views
Looks like exactly what I would suggest, although I’d argue EC2 might be slightly overkill. You’d get more for your money with Linode/DigitalOcean/OVH or even Hetzner’s new cloud offering. Will help save some pennies early on.
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.
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.
What parts of jquery do you use today? I ask because my impression is that it's simply not needed anymore with the better DOM interface methods like querySelector
A lot of it has been simplified thanks to API improvements, but simple element manipulation, event handling, etc. is just a little bit easier with it than without. The special ":hidden" selector is just one example I grabbed from opening a recent JS file (e.g., `$(selector).is(":hidden")`).
I picked all of these things for my startup 6 months ago except I'm using Vuetify with Vue. just like it doesn't make sense to rebuild everything that Django provides it doesn't make sense to rebuild all the UI components Vuetify provides.
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 before you even start on the frameworks:
- Something to make JS bearable (eg React)
- Something to make CSS bearable (eg Bootstrap)
- Possibly another JS framework (eg Redux)
- A framework to make web serving bearable (eg Flask)
- Something to make database access easier (eg SQLAlchemy)
- Did I mention Webpack, Docker, AWS, CI/CD...?
Now, I'm sure we're going to have a big lively thread, debating which technology we should choose for each of these slots (and whether the answer has changed since last week). But the ecosystem which requires so many components, for a simple CRUD app, is utterly insane.
We designed Anvil (https://anvil.works) to be the complete opposite of this. It's a development environment that lets you build and deploy full-stack web apps, from your browser, with nothing but Python. There's a visual designer, client code, server code, and a built-in database. Unsurprisingly, when we did the head-to-head tests, a typical CRUD app is about seven times faster to build with Anvil than with traditional tools. Looking at the list above, are you surprised?
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 scenario for a CRUD app 20 years ago? Some godforsaken company that had a couple hundred employees at best and no more than 10 at time were accessing the data. And lets not forget the endless hours we used to spend trying to get reports printed properly. With web apps whatever you see on the screen you get on the paper.
> The landscape got complicated because now we build beautiful and elaborate things
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 ?
As someone who builds SaaS sites the shit I build now are miles more elegant and functional than the apps I used to build back in the Visual Basic days, or even earlier when I was writing software for DOS. We may bitch and moan all we like but the fact is that the average web app of today is way more usable than the average windows app some twenty years ago.
I won't argue that the situation with web development is ludicrous, we have a bazillion of js frameworks that last no more than two to three years until the next shinny thing pops-up not to mention changes in pretty much every aspect of the stack, from devops to server-side languages and whatnot.
As a testament, take a look at the available dashboard templates in the major template sites. Some of them are so beautiful they make me droll. We never had so gorgeous interfaces in recent history.
Well, perhaps it's that I used Delphi back in the days, but I have a different experience. Delphi apps the equivalent of tiny webapps were orders of magnitude simpler.
I do really enjoy making apps with the modern web stack, but when I look at how many moving pieces are required to make something simple, I do start to wonder if it's all a bit pants-on-head crazy.
It's probably because those tools are not made to "make something simple".
If you have a simple need, just go for simple solutions: a Django/symfony/whatever without JS on frontend (I suppose that's not even the simplest, but wil get you a long long way)
I'd really like to use a tool like Anvil, but my experience with one-click magic solution tools is that it oftens greatly limits the customization options or doing something outside what it's built for.
Well, all I can say is that this is a known design trap that we have strained every sinew to avoid.
Anvil provides a toolbox of help you can take or leave, all driven by a real industrial-strength programming language (Python). And if all else fails, you can always drop down to the HTML and Javascript, and/or a REST API.
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.
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.
Yep, it's a hosted service - you can publish your app with one click! Self-hosting requires an on-site Anvil installation. This is because many of the things we do to make things easy (eg returning live database rows from server to client in a function call, then manipulating them directly there) require server-side report.
We think it's worth it - for example, it saves you building a new REST API each time you blow your nose - but the trade-off is that we can't just provide a "download as Flask app" button.
If you want to run server code on your own machine, though, check out the Uplink. It's a library you 'pip install', connect to your app, and then you can drive your code from the web. Here's an example driving a Raspberry Pi: https://anvil.works/blog/uplink
While Anvil sounds interesting, one thing that pops to mind before buying into such a technology is "what are the limitations?" Could I build a multi-tenant app? Can I integrate JS components, like a sophisticated datagrid? Will I be able to query the DB with SQL as I wish? Does it use AJAX behind the scenes to speed up the responses? etc.
> Will I be able to query the DB with SQL as I wish?
Our built-in DB is shared, so you can't run SQL against it on a standard plan. Dedicated-plan customers can do that. Or just spin up another database and access it with the standard Python tools - example: https://anvil.works/blog/dashboard
> Does it use AJAX behind the scenes to speed up the responses?
- Clojure and clojurescript give nearly identical experiences on the front and back end, with the ability to actually share some code between the two.
- Clojure is dynamic and spec gives some really awesome validation and generative test capabilities
- There is a lot of fuss around javascript frameworks and dealing with html / css build tools and their arbitrary syntax. Clojure front end frameworks provide tools that make templating html look just like regular data structures in clojure, styles too. With stylefy you can also keep all styles inline while supporting media queries. It really is a low cognitive load setup once you get going. I love it.
- re-frame is basically redux but easier and with less boilerplate. I use it for small and large projects.
- Pure immutable functions are such a game changer. Even poorly written projects with tons of features can be reasoned about and broken down for long term maintenance if the language supports immutability and pure functions. Re-frame really plays to this strength for managing state and I can't say enough good things about it. Been working with it for 2+ years and I can't imagine switching for anything else I've seen out there.
Server side rendered templates with Rails or Flask using Postgres + Redis + background worker of choice.
I'm starting to build some apps with Phoenix now, but it's not because I feel the above 2 are poor choices. I just like learning new things, especially when I see big wins of potentially using it. It's another tool in my tool belt, not an all-in replacement of the previous thing.
100% agree - unless you're doing anything especially novel, or know you're getting 10's of millions of connections from day 1, with the ecosystem around it, I wouldn't hesitate choosing Rails + Postgres + Redis + Sidekiq.
99% agree. I just don't feel like using Sidekiq or Celery anymore for short lived jobs when I can do it without any additional infrastructure using Elixir and Phoenix (same for websockets.) However anything else is easier with those older languages including deployment, especially for Rails (capistrano or mina.)
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.
For the API server, unfortunately we don't have better magic frameworks yet. Here I have listed pros and cons of couple of frameworks, and mentioned wishlist for an ideal API REST JSON server
Is there any resource that you suggest to get good at learning sql? I am a django developer and have relied on the orm up until now. I know the basics of SQL and databases but I still won't feel too comfortable doing without ORM. Thanks
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 thing. And the first hour will easily be spent researching different dependencies, trying to get them all to work how you'd want etc.
It's easy to see this as a horrible backwards progression, but the reality might be a bit nuanced.
The easiest way to get a basic crud app up and running these days is probably still some sort of rails/django stack. 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.
So the answer really depends on what level of "good enough" you're going for.
> 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', complain about the slowness and brokenness of many sites and web apps. On the other hand I've never heard anyone complain about a lack of 'dynamism'.
To be clear, some degree of interactivity is often useful. But I can't help but feel that it's quite often not at all necessary to move things like routing, validation, and (almost) complete page changes to the client side, at least not as long as it increases complexity to such a degree.
I came to say something similar, it’s easy in tech to see something could be “better” but from the outside most people just want something that works and is easy to use (pretty is bonus).
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.
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 easy to pick up.
I personally love using Drupal 8 (which is built with Symfony), it has an excellent database abstraction layer, you can easily swap MySQL out for Postgres for example. There's a lot of functionality built in, and very developer minded (compared to WP) with many extra 3rd party addons. It also has a proven track record with deployments from small SMB to large enterprise users. It can also easily be extended with any Symfony packages.
For front end, I swear by Ember.js it is a framework which makes a lot of important decisions for you. You don't loose time setting up your tooling, deployments, state management, ... A great community, many excellent add-ons. A proven track record (LinkedIn, Twitch, Apple Music, ...)
And on top of that, it has been around for 6 years, and is still actively developed with regular releases, with a excellent deprecation support so you can easily upgrade to new versions.
"_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.
Back end: Java 9 JVM, Spring Boot web service, Kotlin, plain SQL via JdbcTemplate working with Kotlin data classes, Liquibase for DDL and migrations, Spring caching with redis if need be, Postgres, deployment via docker to AWS Fargate
Front end: Angular... but I’d like to try Vue. Nginx and docker to Fargate
This. Might not be hip and trendy, but we've been using this stack (just with React on the frontend) and it's probably the best that I've ever worked with.
Anyone who knows Java/Kotlin will have experience with Spring Boot so it's easy to find good people. The whole platform is as mature as it gets at this point and the docs/questions cover pretty much everything.
It's really easy to get started when working on smaller projects, but you can also easily scale and integrate loads of other technologies if/when you need to. You might not need a complex caching layer, monitoring, metrics etc when you're starting out, but you know you can add it in if needed.
I tried Vue a few months back and I could not be happier. The single-file components (html/css/js) make development a breeze. I now need to make changes in relatively complex components I created 2 months ago, and my learning curve is small. Most things in Vue are expressed as expected and just work.
I cannot wait for full ES6 support in vue - it will get massively better by then.
I'm really in love with just having v-if available. Ternary operators in React are ugly and the alternative of hoisting control flow makes things much more complicated to read through.
I hadn’t seen this before. It’s really cool. It’s quite validating to see a lot of things I’ve handrolled implemented into a framework like this, for example the environment corner ribbon. I’d use it for sure for a new project.
As a developer working with Rails (and previously Django), I'd love to try Phoenix/Elixir now. I'd probably find lots of great reasons why it's the best choice. And I won't be wrong.
As an entrepreneur however, I would opt for Wordpress unless there's a clear, strong reason not to. I know it's a bit heretic here on HN, and I dislike PHP and working with Wordpress isn't fun at all. But they take the concept of "Batteries included" to the next level. It's like "Nuclear power included".
You want a simple and powerful admin backend? got it. Caching? check. Image optimization? Yup. Logins? of course. Payment/Shopping Cart/Even subscriptions - just get woocommerce. 5 minutes later you're charging credit cards or paypal. Not to mention how easy it is to create content pages, landing pages, blog posts... You know, the stuff that actually convinces people to even consider your shiny new app.
I often meet people who want to use <insert tech here> for their generic MVP or website, and seem quite eager to spend thousands on programmers replicating what you can easily find on WordPress. But even though I tell them they should buy a WordPress template closest to the result they want, and hire a programmer if they need to customize it (saving thousands of dollars and a while load of grief), quite a few simply don't believe it's possible and still spend the money.
couldn't agree more. This was from the perspective of a developer-entrepreneur. If I was talking to non-technical entrepreneur the arguments in favour of Wordpress are probably stronger. So much easier to find developers and agencies who are familiar with it. Without spending a fortune. It's easier to pass from one agency to another even. Not to mention easier to sell your business later on... To quote Patrick McKenzie[0]:
"Practically speaking, this means that the market wants your website to be on WordPress and your technology stack to be something very, very mainstream, like Rails or PHP. That ensures that, when they want to hire someone to work with it, that person will exist in quantity and be inexpensive. The market highly dislikes software which is written in something more esoteric (the new Javascript hotness, Golang, Erlang, etc) because that adds substantial risk and cost to operating the business."
What you're describing is a pretty specific use case for an 'app' though. I don't disagree that Wordpress is often the best solution, but it's not exactly the thing I'd choose if my 'app' isn't primarily content/shop/some basic formy stuff.
I build lots of CRUD apps very fast with JHipster, which is designed to handle the initial bootstrapping of traditional CRUD apps very well, while also allowing you to choose your tech stack (in some ways). Because it's giving you a nice boilerplate, you can customize it as you go.
The stack ist mostly Java with Spring and AngularJS on the frontend.
Honestly, I would probably build it out on WordPress with a slick theme from somewhere, and the app built out as a plugin using jQuery or Backbone on the frontend. See if works and people give me money.
If I get money, refactor frontend to use react/redux.
On the back, if PHP/WordPress weren't a good fit, I'd rewrite in another language and have WordPress proxy the requests and cache the responses smartly (POST/DELETE/etc would invalidate the cache for GET) or something.
I don't understand why you'd want to start out with a complex stack. It locks you into a set of solutions when you don't even know the whole problem set yet. See what people give you money for and figure it out from there.
Out of all the responses here, you'd be first to market/go-live long before the others. Like you said, see what sticks, what people want, what they'll pay, and then decide what to build and how. I have no shame in using Wordpress + mySQL + a some quick jQuery.
Most of the times a good old non-SPA with NodeJS / Express / Some ORM with vanilla JS / Handlebars and SASS will do the job without having a huge technical debt.
If on the other hand the requirements are to have a more complicated SPA, I would go with React / Redux and a NodeJS / Express / ORM for the API. Hosting the front-end on an S3 and the backend on a Digital Ocean Droplet.
Funny, I was writing something to manage orders for a side business that looks promising and I started building it with Node+Express. It took some hours (3-4) but then I realized I haven't deployed a Node application to production and I'm not even sure how to keep the process alive forever, how updates would work, etc.
I re-wrote it last night in the LAMP stack in about 30 minutes. So I would write a CRUD app in PHP in 2018, I would suggest you do too tbh; PHP7 is a joy to work with. For backend framework I'm using https://www.slimframework.com/
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.
Half the source files read like J2EE stuff. An example:
// KMS is an xray instrumented KMS client
func KMS() *kms.KMS {
c := kms.New(session.Must(session.NewSession()))
xray.AWS(c.Client)
return c
}
> Golang for the API, running on Lambda. React or Vue for the UI.
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.
It may be more verbose but it's simpler than Rail's ERB in YAML that requires a the Ruby VM plus application config to interpret.
Yes external libraries. 80% of those are for testing (as is the Python stuff). In Go land you should effectively ignore the vendor folder, I check it in for developer convenience and system stability.
Compare to Rails which has a massive dependency graph. And one that has to follow your app around for every build and deploy.
I will absolutely grant that for SQL CRUD apps, you still can't beat the Rails tooling. Migrations, rake tasks, ActiveRecord, Scaffolding and the Ruby REPL to poke at your models and data are very useful.
But decoupled tooling is getting really good.
The https://github.com/marmelab/admin-on-rest project is better than Django Admin. The basic CRUD stuff is just as easy, then it's infinitely more configurable with a bit of custom React programming. And it's not coupled to any language, framework or database.
Finally cost is effectively zero for all of these options to start. AWS and Heroku offer a generous free tier. Developer time is the real cost to watch.
But in terms of raw resource consumption, static Go binaries talking to DynamoDB plus a static React page are obviously less "expensive" than Ruby VMs talking to a dedicated Postgres server and rendering HTML pages.
I completely agree with this. Whatever's most familiar for you, but hopefully, it should be familiar for other people too. Try to write it in a way that you can switch out parts if you really needed to. For example, I'm still a Rails programmer but I've been structuring my apps differently from traditional Rails (oftentimes just doing the API backend).
However, that's only because I still have the luxury of time. If I had a gun to my head and a finite number of hours to code an app, then I'd go with vanilla Rails. If I was given a few weeks to study a new framework, I'd go with Elixir/Phoenix, but only because I spent a few days trying it around and while I'm not particularly fluent with it yet, I like its design and speed a lot more than Rails.
I think this is why we perfect our craft. We have to be able to code fast or code pretty, depending on the circumstances.
For those of you saying WordPress...could you elaborate a bit more? I'm willing to shelve my pride in favor of speed, but it seems like there are very few guides to building a web app in WP.
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?
There’s a couple ways to do it, depending on how much you do/don’t want it to look like WordPress. In both scenarios you have to mentally translate what you want to do into WP architecture (e.g. you want a new model? In WP that’s a custom post type, etc.).
The “easier” way is to create custom post types for each model you want, and use Advanced Custom Fields (plugin) for the data fields. Users log into the WP backend and can CRUD the custom post types. With ACF, pretty amazing things are possible (inter-model relationships, uploads, etc, and all done with amazing UIs for each type of field).
The “harder” way (if you are trying to make your app appear less like WP) is to get a plug-in that hijacks the user login process and admin, then customize the front-end to display the CRUD fields/controls (again using custom post types and ACF) when users are logged in, so your users never see the WP admin.
Both ways (and more, now that WP also has a new-ish full-featured rest API) are possible, however the standard WP caveats apply: the more plugin-spaghettini you introduce, the more unexpected issues you will face. I’ve been meaning to write up a guide, need to do that one of these days...
On client side that toolset provides an almost seamless API that gets you authorization, authentication, offline/mobile first, and data sync among all connected devices. And it's a very fast app because it runs almost entirely on the client side and transfers very little data between the client and server.
There's not a lot to do on the server side with this setup. PouchDB/CouchDB work together to handle the CRUD routines for both the client and server side and to sync data automatically and/or on-demand when the client is online.
You can also setup a 2nd CouchDB on a remote server to replicate your data to for automated backups. And it's fairly easy to configure a cluster of CouchDB servers with load balancing.
Productivity is what we're really looking for in a framework. To achieve that you want a very low learning curve and a very rich feature set. You want to leverage what you already know, as opposed to "learning a new way" to do things.
I've also worked with quite a few startups and usually recommend the following:
- Python / Node.js for the backend
- React.js (with Redux) / Angular for the front-end
- MySQL / Postgresql as the db
- Host on a digitalocean or linode VM
- ReactNative (if using React.js) for mobile apps, prefer to write native apps otherwise.
All of the above are proven technologies with Node.js giving an edge when it comes to real-time applications.
The hardest part I've found is in having a consistent design, marketing and branding strategy. Usually the inhouse designers are swamped and it gets really tricky for frontend developers to make the beautiful looking widgets that were designed in Adobe InDesign or whatever...
It works pretty well and is fairly straightforward to use. It can be really frustrating if you have more advanced requirements for your editable tables, but it works great and is documented pretty well for its intended use cases.
- Any of the Sinatra-derived frameworks (flask, express, etc. Language isn't a major factor as the API is small).
- Neo4j graph db instead of a relational db. Simple crud stuff is easy, and you can encode most business logic (if there is a need for anything beyond basic crud) as simple graph operations, avoiding the need for a bunch of other boilerplate that is found in frameworks that leverage ORMs.
It always depends on the use-cases. JS frameworks are good for interactive content, but if the content is write once read many times, they might not be the best solution. So I wont even mention any of them.
From server oriented stacks I would suggest and personally use for many years:
Open-source:
OpenXava - because it will generate the whole CRUD app automatically based on the database relations, and this will be sufficient for generic use-cases (it is based on Java Server Pages, Hibernate)
or
Tapestry - if I need something which is very component oriented, flexible and capable of extreme customization of the rendering process.
or Commercial:
Oracle APEX (Application Express) - it is extremely easy to create CRUD apps and general table/grid/master-detail type UI. Even if you are not a programmer you will be able to create a nice app. There are free options and there are cheaper options for smaller websites. If you get a hosted version it's easeir, if you host it yourself you would need a Oracle DBA knowledge to install it.
If the application is going to be around longer than 5 years, roll your own MVC or ROA pattern in Java. Write your own DAO and database calls (stay away from ORMs). Keep 3rd party library use down to a minimum, limiting your vulnerability exposure and rewrites due to upgrades.
As a developer who has worked on code bases that were home rolled, and built with popular frameworks (spring, rails). The worst code bases I've ever worked on were home rolled. Obviously that's only my experience, but I have a hard time agreeing with this advice.
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.
> 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.
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.
I had to build an in house CRUD app that serviced millions of records and multiple users. It's a pain. The same technologies that existed years ago still work best today. I'm always open to rebuilding it and connecting the database to something _new_ but everything is cumbersome. I'd really like to move away from certain CRMs system but there is a lot to consider and it's always been a long battle. That's why older more mature systems have solutions ready to go.
Waiting for the day where something is smart enough to look at a SQL db and understand it then build out a quick web app that integrates with it.
Django Admin. Or even Drupal, for all its brokenness, bloat, slowness and security problems, you can build fairly decent data entry and retrieval apps with it without writing a single line of code.
Don't look too far, Django is still the most flexible and stable solution (If you're familiar with Python) for CRUD unless you need a single page application (SPA).
This is probably more hopeful/an ambitious end goal than anything sane people would really do today, but I would try to write a functional reactive isomorphic Rust app.
I'd use Rails today. But I can see the value in Django or Express or ASP.Net or Spring Boot.
Criteria I'd think about:
What is going to be easy for my organization to support (both operationally and with future code changes).
What do I know/want to learn? If the CRUD app is complicated, then I want a tech I know well. If the CRUD app is simple, then I may want to experiment with a different technology (again, within the organizational support guardrails).
Whatever you're experienced with. I know it's nice to write a backend in js and easy to learn Python, but if all you ever did is writing C#, then there's nothing wrong with using it. You only know jQuery? Don't worry, you're probably being paid for the result and not for using React. (This is obviously not true if you want to learn new technologies)
Regarding front-end, CxJS is a JavaScript framework specifically designed for large CRUD apps. It offers powerful data-binding, form widgets + validation, advanced grid (data-tables) and much more. CxJS is free for small teams and startups.
Developer of Solvent (codesolvent.com)...We are still finding the right angle for the product but it has been my goto platform for web development for the past 3 yrs.
Combines custom middle-ware+appserver+IDE to give you a one-stop web app solution. You then use whatever else you want on the front-end or backend (jvm libraries).
I would use rails for the API and react on the front end. Rails 5.1 makes it super easy to do this and Rails 5.2 which is coming out soon (5.2.rc1 I'd already available) also adds some neat features. Database I usually pick is postgres.
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.
Whichever one you're familiar with - that requirement doesn't provide any meaningful information to decide among the many choices. It's like asking "which path should I take to cross the street".
Came here to say this. Go is such a nice language to develop with and once you understand the ELM architecture, VueJS with ElementUI makes throwing a webapp together a breeze.
This is a big question and hard to answer IMHO without more context and constraint. I'll take a stab at laying out some thoughts on the matter.
So many apps can fit into the CRUD tent. I mean, Jira and Confluence are basically CRUD apps, right? But so is an ad-hoc internal company app. I'll focus more on apps that are meant to be externally facing as I typically work on larger efforts, and then mostly on backend services and infrastructure automation.
I would personally stay away from Python. Not only do I prefer typed languages, but I also appreciate languages with fantastic tooling and language services, mature concurrency primitives, and an active/energetic community. I find Python seriously lacking in those regards, and falling further behind other language choices every year. I personally have no issues with writing prototype/production ready code in less dynamic languages at the same speed; faster usually is my sense for anything more than a few dozen lines.
If elixir had focused more on a type system and better language services/tooling(like the F# team) I'd probably be more interested in Phoenix. Ignoring the erlang VM, I find F# much more compelling as a language and am hoping one of the new crop of frameworks will shape into a viable Phoenix alternative. That being said, I could still see myself pushing Phoenix depending on the experience and leanings of the rest of the team.
In no particular order:
TypeScript+React+ASP.NET:
I really like C#; it's not for everyone, but coupled with the CLR it has completely acceptable performance, concurrency primitives, and language services(intellisense, refactor support, etc). Entity framework and linq are a super compelling combo; using this ORM will ruin most other ORMs for many people. Dotnet core has resulted in a lot of extra activity in the OSS community, and the dot.net ecosystem is full of very well engineered, comprehensive projects.
F#+React+ASP.NET:
For some extra spice try F# full-stack. There are some great backend frameworks shaping up, and Fable makes F# possible for the client. Great language and great concurrency support. F# is my crush language. Fable's creator has been doing excellent work including making it possible to consume TypeScript type definitions; going so far as to reach out to the F# team to include features necessary to support the flexibility of TS. Ability to execute on this would really depend on the starting team as well as current/future hiring practices.
TypeScript+React+Node.js(TypeScript):
This is one of my favorite "easy-ish-to-sell" stacks. Nodejs has come a long ways, and offers a sufficient concurrency experience with async/await. Node-Chakra-Core has some clutch time-travel debugging abilities.. Javascript programmers at least keeping up with ES6 shouldn't have TOO much trouble adjusting to TS, and as a bonus they can be more effective working full-stack on the backend. This should provide for a very large potentially hiring pool. There are some super compelling TypeScript-first projects cropping up as well like MobX, NestJS, TypeORM, etc. My sense is that TypeScript is attracting more of the "engineery" types to the JS/Node ecosystem. If C# is any indication, this is a welcome addition IMHO.
Dart:
Dart appears on the surface to be a more first class TypeScript. It looks super compelling, has some great tooling(including a sweet looking profiler), has a great looking VM for server side execution, and a small but very passionate and motivated community.. A few highly visible companies adopted it and swear by it. This is probably the most experimental stack I would consider and can't really explain it... I'm dart-curious. I feel they should ditch the custom eclipse based IDE and focus on the language server protocol and plugins for the popular IDEs with the 2.0 initiative.
TypeScript+React+Golang:
Sure, why not? I think I'd need a good reason for going golang... Like some serious server-side performance requirements and/or lots of backend services. In the context of a "CRUD" app, I'd be more likely to swap services written in other languages out with golang as the performance requirements became clear.
Mini-rant:
React is pretty great but I wouldn't mind a TypeScript-first implementation to it's interfaces. DefinitelyTyped group has done an excellent job but keeping everything typed can be a bit gnarly and gross.
I'm a huge proponent of MobX over redux until you know you need redux. I haven't personally missed redux since extricated myself from it, however I can imagine circumstances where I'd "see the light" and want it. Take the redux creators advice; you probably don't need it.
As a Tcl fan, I was just clowning around; but as a matter of curiosity, there do happen to be a number of possibly-credible Tcl web frameworks. I haven’t done any homework on any of them. https://wiki.tcl.tk/40649
At my company, we still use the same thing to create high performance web sites. HTML, CSS, JavaScript, SQL and our favorite programming language which I won't go into. We don't even consider anything else because we've been there and done that (whatever one needs) years ago. The only time we give any thought to any framework or library is when the client requires it for some existing interface and we can't get around it. But we will make an effort to scrape off such things wherever possible cause that's our job: high performance at low cost.
What Dart library/framework do you use for the backend? The recent DartConf has only 5 mins of talk of Dart server end. The emphasis seems to switch to use Dart for front end clients.
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.
This is not true generally anyway (in most mainstream systems it is much simpler to update or delete when appropriate), but please consider e.g. the GDPR where the ability to delete personal data is mandatory, and the "keep everything forever" mindset is precisely what that legislation is designed to remedy.
Disclaimer: I'm about to promote my own company, Surround Technologies[1]
Reading through all of the comments so far, I'm seeing solutions that give you a CRUD web app... and nothing else. If that's all you really need, then that's fine. For the past seven years I've been working with large companies who need Enterprise-class CRUD apps, with Enterprise-class requirements that go far beyond what you get out of the box with most of the cobble-it-together-yourself solutions being mentioned here.
Surround Accelerator is a CRUD Application Generator and Framework. To use it, you first develop an optional plugin that customizes the generator, then you run the generator and point it at your database. It loads the schema, does a bunch of analysis, and asks you a bunch of questions. Your plugin is used to govern the analysis and provide standard answers to the questions, so that you can customize the result consistently. Finally, a set of C# web services and applications are created. We're currently producing both a WPF desktop application and a fully-responsive ASP.Net MVC SPAs. Both GUIs are highly customizable; our framework is very flexible and all of the code you need to change to customize the application is part of the generation rather than locked up in the framework.
Generation isn't a one-time thing though; if your schema changes we've got tools that you can use to re-generate just the parts you've changed, or to add generation for the parts that are new. Typically, the way we've structured our code to allow for customization, it's easy to merge your customizations back into the generated code.
If any of this interests you, please visit our website. We've got a number of videos showing the process, a bunch of demos, and many case studies and testimonials from actual customers.
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 vanilla JS with some jQuery sprinkled in. When (if) the team/product grows, figure out which frontend framework fits best.
Database: PostgreSQL. Well-maintained, reliable, and great documentation.
In-memory cache: Redis.
Infrastructure: AWS. EC2 for hosting, S3 for file uploads and static file storage, CloudFront for content delivery.
Web server: nginx. Let's Encrypt for SSL cert generation.
App server: gunicorn. It works.
There are probably a few other things I'm missing but these are the big ones! All of my clients from years back (a few who now have 20+ people on their engineering teams) are still using this entire stack, so it scales both technically and as the number of team members grow. Happy to answer any questions!