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!
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 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?
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.
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
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.
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.
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.
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.
- 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.
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.
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 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.
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.
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.
[+] [-] theli0nheart|8 years ago|reply
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!
[+] [-] zengid|8 years ago|reply
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!
[+] [-] brandfountain|8 years ago|reply
[+] [-] golergka|8 years ago|reply
Did I get the right impression, or may be I just didn't learn to use Django correctly?
[+] [-] ioddly|8 years ago|reply
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.
[+] [-] graystevens|8 years ago|reply
[+] [-] dmarlow|8 years ago|reply
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.
[+] [-] bojanstef|8 years ago|reply
Something good for beginners? I realize I'm asking for a lot but I might as well ask.
[+] [-] Waterluvian|8 years ago|reply
[+] [-] mlevental|8 years ago|reply
[+] [-] meredydd|8 years ago|reply
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:
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?
[+] [-] elorant|8 years ago|reply
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.
[+] [-] rpeden|8 years ago|reply
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.
[+] [-] muzani|8 years ago|reply
[+] [-] dustingetz|8 years ago|reply
[+] [-] thorin|8 years ago|reply
[+] [-] jgoodhcg|8 years ago|reply
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.
[+] [-] WalterGR|8 years ago|reply
[+] [-] nickjj|8 years ago|reply
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.
[+] [-] wastedhours|8 years ago|reply
[+] [-] pmontra|8 years ago|reply
[+] [-] michelpp|8 years ago|reply
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.
[+] [-] copperx|8 years ago|reply
Why hasn't this taken over the world by storm? What's the catch?
[+] [-] rrjanbiah|8 years ago|reply
https://github.com/RestyaPlatform/board/issues/1250
[+] [-] tejinderss|8 years ago|reply
[+] [-] alt_f4|8 years ago|reply
[+] [-] arnorhs|8 years ago|reply
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.
[+] [-] mercer|8 years ago|reply
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.
[+] [-] farnsworthy|8 years ago|reply
[+] [-] sudders|8 years ago|reply
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.
[+] [-] tabacitu|8 years ago|reply
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.
[+] [-] songshu|8 years ago|reply
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
[+] [-] mulrian|8 years ago|reply
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.
[+] [-] sharpercoder|8 years ago|reply
I cannot wait for full ES6 support in vue - it will get massively better by then.
[+] [-] RandomCSGeek|8 years ago|reply
[+] [-] gingerlime|8 years ago|reply
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.
[+] [-] red0point|8 years ago|reply
The stack ist mostly Java with Spring and AngularJS on the frontend.
http://www.jhipster.tech/
[+] [-] withinboredom|8 years ago|reply
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.
[+] [-] drinchev|8 years ago|reply
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.
[+] [-] arenaninja|8 years ago|reply
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/
[+] [-] shmooth|8 years ago|reply
and, symfony is the worst garbage in the history of the planet. worst mistake ever.
[+] [-] nzoschke|8 years ago|reply
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:
https://github.com/marmelab/admin-on-rest
[+] [-] perlgeek|8 years ago|reply
[+] [-] iambateman|8 years ago|reply
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?
[+] [-] astockwell|8 years ago|reply
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...
[+] [-] daigoba66|8 years ago|reply
[+] [-] Clobbersmith|8 years ago|reply
[+] [-] oblib|8 years ago|reply
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.
[+] [-] unknown|8 years ago|reply
[deleted]