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!
If I could I'd buy you a beer and cheers you for relieving my JS anxiety a bit. I love jQuery, and I'm tired of feeling ashamed of it, damnit!
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.
Did I get the right impression, or may be I just didn't learn to use Django correctly?
it kinda makes sense, considering how easy it is to create form views
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.
> 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.
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.
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!
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.
I do prefer React for when a frontend framework is appropriate, but I also think that's not always the case.
I think there's a lot to be said for familiarity. Rails instead of Django? Sure, if you and the folks you're working with know it better.
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.
Something good for beginners? I realize I'm asking for a lot but I might as well ask.
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...?
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?
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.
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.
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 ?
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.
Of course as always YMMV.
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
Yep! We have customers who have.
> Can I integrate JS components, like a sophisticated datagrid?
Yep! Reference docs: https://anvil.works/doc#js_interop
> 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?
The client/server RPC runs on websockets. More info: https://anvil.works/doc#runtime_details
Happy to answer more questions - check out our forums: https://anvil.works/forum
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.
https://github.com/Day8/re-frame http://www.luminusweb.net/
edit: Should probably say why...
- 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.
https://github.com/Jarzka/stylefy
edit-2: More whys...
- 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.
The back end is way more mature than front end SPA stuff so I'll just list some things I'm really glad to have in that space
- re-frame : like redux but better
- re-learn : lets you create tutorials for application with no changes to dom
- cljsjs/filesaverjs : cross browser file download dialog
- cljs-react-material-ui : material ui react library port
- camel-snake-kebab :useful for changing casing
- com.rpl/specter : easy way to deal with large nested data structures
- stylefy : inline styles with support for media queries and animations (all with clojure data structures!)
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.
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.
https://www.youtube.com/watch?v=GxL9MnWlCwo
Learn SQL and do it right.
Why hasn't this taken over the world by storm? What's the catch?
People early in their career thinking SQL is something UNIX greybeards did in ancient times, and which is not necessary anymore.
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.
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.
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.
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.
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
I cannot wait for full ES6 support in vue - it will get massively better by then.
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.
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.
"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."
[0] https://training.kalzumeus.com/newsletters/archive/selling_s...
The stack ist mostly Java with Spring and AngularJS on the frontend.
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.
I like WordPress for a CMS (wouldn't recommend anything else for a small to midsize CMS solution) but wouldn't think of it for a crud app.
That said, haven't researched it much lately, so wondering what I am missing.
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.
And we use Angular on the front end.
And I'd recommend GraphQL, takes a lot of worry about API design and wiring off your shoulders.
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/
and, symfony is the worst garbage in the history of the planet. worst mistake ever.
I've never used the full-fledged Symfony framework but I have used individual components from time to time. Surely it can't be worse than Zend 1?
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 with this excellent admin interface framework for CRUD tools:
// 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.
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.
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.
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?
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...
https://stackoverflow.com/questions/10132685/json-api-to-sho...
Server side: Apache Web Server CouchDB Perl or Python
Client side: Pouchdb jQuery Bootstrap Moustache/Handlebars
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.
For me, this "stack" provided that.
For JS, Vue.js probably. Though I'm still using Backbone + Marionette.
- 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...
For the compute back-end I'd use Serverless Lambda or Google Functions, nodejs.
For the database I' d use Firestore or datastore
For the communication between client and back, I'd use GraphQL.
https://editor.datatables.net/
I have a license for the Editor and have to say it works very well. They have an online Generator that makes it easy to get started very quickly.
Design frontend in web or mobile with poison of your choice
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.
- 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.
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.
I am working on https://github.com/daptin/daptin
These days it's never worth it to home roll in the CRUD world. There's way too much good tooling out there.
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.
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.
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.
Although recently I'm mostly using Node/Express for almost everything, and I'm really happy with them.
For a simple CRUD app the stack is irrelevant. You'll want to get to market as quickly as you can and that will be with the stuff you already know.
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).
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).
Deployment: EC2 or DO both work great.
P.S. Most important thing. Do not worry about optimization before you ship your first version.
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.
Interesting enough, it probably means the market is still growing.
Frontend: ReactJS
Backend: NodeJS
Database: Postgres
Hosting: AWS
CI/CD: Gitlab
Simple for me. Easy to deploy changes quickly. Fast iteration.
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.
frontend : VueJS
If a users wants data deleted they want the data DELETED, not kept for a hacker to hoover up in a few years time.
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.