It's been a while since I can develop from a clean slate and I was hoping web dev in 2021 would be much simpler than what I am used to. However, I spent this entire morning looking at modern frameworks (not going to name them to avoid turning this into a different kind of discussion) and I'm kinda disappointed. They all look complicated and require lots of configs and plumbing to get started.
Any stack/framework that you find simple and joyful to develop with?
PHP => Symfony or Laravel
Python => Django or Flask
Javascript => Node/Express
Ruby => Rails
Then there are others like elixir/Phoenix etc and then you can do your own in Go etc.
I've not used it in depth yet, but from a poke around the overall design and syntax seem very nicely thought out (much more logical/intuitive than Flask, honestly) and it's very fast.
I do recommend dipping in Laravel first, before Livewire.
With the addition of:
C# => .Net Core
Their latest web framework running on the latest long-term support version of .NET
Rooting for quarkus to become more mature though. (Recently tried based on someone's recommendation on HN).
WordPress.
Why? Incredibly easy to dev against. Powerful API built in. User model. Flexible theming. Plugins for extensibility. Multisite for more complex apps.
I've built a few web apps in house using it and am now making a couple for production use. I might one day find I need to get this made bespoke but I can't see a requirement any day soon. WP does everything I need.
WP is a full blown CMS. It’s very versatile and you can achieve a lot with just the core. Additionally the Gutenberg Editor is the definitive editor for building content-pages.
A few month ago I tried to find a CMS as feature-complete as WP. However, I wasn’t able to find any good alternatives. I also asked on another forum and summed up my favorite WP features:
- Extendable admin area
- Custom post types
- Single- and archive-pages/-routes
- Taxonomy aka categories and tags
- Dynamic meta data (especially with ACF)
- Solid page editor for content
- Action-/Filter-capabilities
- Shortcodes
- Open Source
- Very compatible upgrade philosophy
- Media Library including automatic image scaling
- User Login
- API Support with custom routes
However, you need to know, that WP is higher settled than frameworks like Laravel. Especially data-management gets tedious on bigger instances. Just have a look at the DB schema and you will see, what I mean. On our company we solved this issue by integrating Illuminate/Database btw.
The biggest business chore is usually around user management, roles, permissions—all easily expanded/modified through WP’s extremely well-documented core framework APIs. Custom REST API endpoints are a breeze to implement with or without authentication requirements. If you need external deps, you can manage them like any other modern php project with composer. Deploying is easy with docker and uploads sent off to some S3-like bucket.
One recent project I built had WordPress driving fully custom content for a set of giant LED screens in a corporate HQ lobby that allowed users to build presentations, manage a recurring and one-off scheduling, build, edit, and manage reusable content, view live video feeds of what’s currently on the screens, and request static image and video preview renders from an on-prem media server. Users authenticate via the typical WP dashboard experience, but have rich web app features presented to them for their tasks using the WordPress custom REST API endpoints and the existing WP data model behind the scenes (for the most part). Any business needs they presented were easily absorbed by WordPress through straightforward customizations. IMO, WP is an underrated contender in building CRUD-ware.
Seriously, whenever a customer asks for something relatively simple that I know can be implemented using WP, I usually do it. You already have user management and many other functions built in, and extending it is very easy. It comes very handy when all the customer wants is basically a CRUD connecting to some internal system.
I ask because not long ago what you write was true - but only if you've not seen how 'it can be' in modern stacks. WordPress is (was) great for a time that is (was) gone.
I'm saying was because I have not worked with WP in a while so I can't really judge.
The functions / classes you use could be in a plugin for portability, or just on the page or in your functions.php file for ease, whatever you like.
The nice thing about building like this for me is that the journey from nothing to something is short and so much is supported out of the box.
Seriously, is super productive this way!
Is very pragmatic. That means your whole investment in the arcane ways of JS are dust. Not hipster at all.
---
More seriously, Is of little issues here. You setup and it works, so is not something that lead to "generate content" like other setups.
I found only a significant issue (to me) (https://github.com/bigskysoftware/htmx/issues/596) but then I do something that have never done in long time with a JS library: I poke into the source and fix it myself. Far easier than expected! (ie: The code is plain!)
I quite like HTMX myself, although I consider it a tool you use to enhance websites and not something you use to build full blown web apps.
I don't get your point, Dart is also compiled to JavaScript.
But if you really want a full stack framework or don’t want to deal with fancy JavaScript frameworks, I think you’re better off sticking with Rails/Django/Express or something you’ve probably heard of.
With Golang, you actually don't need a mega framework to get started, you can use small libraries that will do the job for you without doing any magic behind the scenes. (Like, for sure you can use echo[0] but you would probably be happy with mux[1] and it's middlewares itself). And it's not uncommon in Go codebases to repeat yourself. I'd argue that's a much better paradigm than polluting your codebase with 10k indirect dependencies, the garbage that is the Node.js ecosystem.
[0]: https://echo.labstack.com/ [1]: https://github.com/gorilla/mux
You just need to build it from scratch, document it and ensure it is well tried and tested.
"mega frameworks" are there for a reason. Rails, Django, Laravel, etc have everything they have because almost any web application you build (except if it is just a minimalist micro-service) will need routing, authentication, i18n, ORM or similar, migrations, caching, e2e testing, validation, background job processing (the one that works after a deploy or restart), and a thousand more other things.
Of course you don't need it to "get started", but 1 week after getting started you'll find yourself rebuilding the wheel yourself or tying together 10k dependencies (something doable if you have enough experience and know what to pick and what to not pick, but risky).
> And it's not uncommon in Go codebases to repeat yourself.
The fact that it is not uncommon doesn't make it any better. Rewriting the universe from scratch in every single project is the worst idea ever.
I don't think that because we like a programming language which happens to have no popular web framework we need to negate all the problems of not having one, or say it is in benefit of simplicity. It is not.
I'm very sorry for my rant, but I've already faced too many disasters in work environment were people thought that "just flask" would be enough, and years later we're still fighting the fire and trying to understand why this custom ORM validation integration doesn't work.
I looked at fastapi but when I saw the benchmarks I thought I might as well just use go for the type safety, speed and ease of deployment.
Currently running on Google cloud run. I'll probably switch to AWS though because Google dns doesn't do naked domain redirection, but AWS app run seems half baked...
So much can be accomplished with server-side rendering and some jQuery sprinkled on top. (jQuery isn't even strictly necessary with modern vanilla JS, but it's very nice syntactic sugar at the least.)
90% of apps/sites will fit into a basic CRUD/REST document format, which is exactly what server-side HTML served over a RESTful interface was made for. Judicious use of jQuery fills in the front end blanks for all but the most advanced use cases.
The big benefit of this is that you're not locked in to the JS framework-of-the-week once it inevitably becomes either deprecated by its mammoth corporate sponsor who doesn't care about you, or when it's no longer the new hotness and you can't find developers who understand it anymore. jQuery has been around with a largely stable interface for a decade and a half.
The secondary benefit is that you're not including some vast framework with innumerable, inauditable dependencies, requiring special expertise from highly-paid developers, just to put an AJAX button on a webform.
I've met a few devs recently that are starting with that for simple CRUD projects even though they could easily spin something up in Rails.
Edit - to make life extra easy also set it up with Postgres and deploy to Heroku. Everything literally just works.
What would you choose?
I heard .net Blazor or Razor page is something like that, but as I checked, they don't hide html/css/js.
R Shiny is the closest I get. You don't have to use any html/css/js code to build a web app. Only R language is needed. See a simple example here: https://shiny.rstudio.com/articles/basics.html
I would love to hear about more options here.
Does anyone have an opinionated stack they like with Django to get things up and running quickly that could also set me up well for the future for a website and an app(if I want to transition the website to a stable business, etc)?
The things I'd be looking for opinions on:
- django vs DRF
- react (or next.js) vs vue vs something else for frontend
- what other tooling should I use for modern front end development
- what else is in your stack for CI/CD, rollbacks, db migrations, deployments, etc.
- do you use any other templates or themes for the frontend to make the UI look good?
- how you handle security / auth when using a front end framework with django as the backend -- are there any tricks? I've heard JWT can cause headaches
- any django packages they recommend using, or other front end packages that are popular
Backend:
- Huey for background jobs
- Whitenoise for statics handling
- Gunicorn for running the application
- Honcho for process management (also for development, for spawning js and css bundling)
- Slippers for django template components
- django-all-auth for signup/password recovery/etc.
- django-rest-framework if you need an API
- Unpoly for ajaxy SPAish feel (just the good parts of that feeling)
- Tailwind for styling
- esbuild (CLI) for bundling js
- npm for frontend dependencies
- postcss (CLI) for building/packaging css
- Dokku for hobbie or side projects
- Heroku for getting started with production apps, AppEngine if shit gets real.
- No need for Websockets, polling is good enough most of the time.
- Sqlite for side projects
- PostgresQL for serios stuff
- Maybe redisIt's not a "vs"; DRF is merely a library for Django thus requires Django. It gives you building blocks to create REST APIs and handles the boring stuff such as validation & serialization, pagination, rate-limiting, authentication, URL routing (in a RESTful manner), etc. If you need more than a few read-only API endpoints I suggest you go with DRF; it takes some time to learn the way it wants to do things but it's worth it in the end.
If all you need is to expose your models as a REST API, DRF will do that with pretty much zero code required, and in most cases that's enough. You can of course decouple your API structure from your models and write custom viewsets, serializers, etc but in this case you lose a lot of the built-in functionality of DRF and have to implement it all manually.
> react (or next.js) vs vue vs something else for frontend
Look at it from the perspective of the problem you're trying to solve as opposed to hype or frontend developers' career prospects.
Good old server-side rendered HTML (with ad-hoc JS or even jQuery where needed) can be good enough. The main advantage is that there's no barrier to entry, you grow as you go. Since you render the pages directly on the server you don't have to worry about providing API endpoints, then parsing that data back in JS, you just directly output it in the HTML.
If you do choose a single-page application approach, I suggest serving the SPA as static files from your Django app so that it is served from the same domain from the browser's point of view. This also allows you to mix and match SPA and server-side-rendered views (you can have your main app an SPA, but the login page - which is just a form and has no need for SPA features - can be server-side rendered for example).
In terms of which frontend framework to choose, I would advise against React as it's just a UI library meaning you need to (poorly) reinvent everything else such as URL routing, REST API clients, etc manually. Every React project I've been involved in had a custom, different, and differently flawed way of doing basic things like hitting a REST API even though it should be a solved problem (there's DRF on the server that can generate RESTful endpoint based on just a model, why is there no "JRF or JavaScript REST Framework" as a client-side equivalent?). I think Ember.js might be worth exploring as it's an MVC framework and should take care of the boring stuff so you can focus on business logic. It looks like it has the concept of "data adapters" so provided your API has a consistent structure it looks like you can have a data adapter that'll automatically map it all back to JS replicas of your model classes and then be able to use it as an ORM of sorts (and have the network communication, serialization, pagination, etc abstracted away by the data adapter).
> what else is in your stack for CI/CD, rollbacks, db migrations, deployments, etc.
Django now has built-in migrations which is pretty good. Deployments and stuff is highly dependent on whatever target you're deploying to. One thing I could suggest is Dokku (https://dokku.com) coupled with a bare-metal server from OVH or Hetzner. It's basically Heroku but orders of magnitude cheaper and more powerful. Depending on your uptime requirements this might be good enough for production, but if not it's at least a good option for a staging/test environment.
Use Celery with RabbitMQ for background & scheduled tasks. Do not use the Redis backend for it even if it's technically supported - it can fail catastrophically with the workers thrashing on the same task over and over again (speaking from previous experience having had to use the fire extinguisher more than once).
Use Sentry (cloud or self-hosted) for exception tracking.
> how you handle security / auth when using a front end framework with django as the backend -- are there any tricks?
Built-in Django auth is good if all you need is username/password auth. The django-registration package provides server-side-rendered views for registration/login. If you need social/federated login I suggest django-allauth which also provides its own views. For API endpoints you'll most likely need to roll your own login endpoint (with serializer) which takes a username/password, calls the auth backend(s) to check those credentials and then returns some kind of reusable token to the user (see below).
> I've heard JWT can cause headaches
JWTs (or other auth token formats) only come in play once you've already authenticated the user somehow (by them providing some secret info - most likely a username and password) and just want to give their client a way to reauthenticate without having to resubmit the same secret info again and again. You still need to actually handle that first part (see above). Once you actually authed the user and want to give them a token, then JWTs or similar come into play.
JWT's only selling point is that they can be validated statelessly without hitting a DB (they carry all the information you need along with a signature). This is mainly a benefit in microservices environments where some services might be completely stateless. In most Django projects you'd be hitting the DB to access the user model anyway (by accessing request.user for example) thus nullifying the sole benefit of JWTs. The rest of JWTs' features are just drawbacks is that it's extremely extensible meaning it's more complex than most projects need, and easy to screw up their validation or issuance, either from your side or even from the JWT library developer's side, thus I don't recommend them.
If you need to provide an API to browser-based clients, serve your frontend from the same domain as the API and use Django's built-in session authentication. On the login API endpoint, initialize the user's session (which will send a cookie back to the browser) and the browser will automatically send the session cookie for subsequent requests without your frontend ever having to do anything - all it needs to do is check for 401s and handle those by displaying the login view. As a bonus, any server-side-rendered views will also work out of the box.
For mobile apps, technically cookie-based sessions can also work, but common practice is to use some kind of bearer token. In this case, DRF has a very simple "Token" auth mechanism that just stores tokens in the DB and is good enough to get started. I suggest however extending that and making those "Device" models instead where you also store some device-specific metadata such as the push notification token, that way if you delete the auth token you implicitly delete the push token too and don't end up sending pushes to devices that are no longer authorized (seen that in production multiple times sadly). This also gives you a way to display to the user all the devices logged into their account and revoke them.
For the logins themselves something I recommend is to actually make your login page always server-side-rendered even if you use a SPA or a mobile app and render that page in a webview/iframe. This will allow you to easily change the login requirements later on (such as responding to brute-force attacks by adding a captcha, etc) without having to update the clients at all. That way you can swiftly react to new & constantly evolving security threats.
I felt the same way so I made my own full-stack "framework" just for me centered around the Svelte component library which I love:
https://github.com/Glench/full-stack-svelte-prototype/
Been using it in production and really really happy with it. Obviously kind of stinks to not have community support but so far it hasn't been a huge issue.
It basically sets up all the crap that I don't want to have to think about while keeping a tight coupling between the front-end and back-end (which is how I develop) — clear separation of code that runs on the server vs the client (with code splitting and CSS generation), rendering pages on server and hydrating client components, communicating between the server and client, re-rendering components when new data arrives. It really fits my needs well.
SvelteKit is very new and I haven't had a chance to use it yet, but my own framework was directly inspired by it. SvelteKit does a lot and looks great — fantastic developer experience, deploys to lots of types of services, SSR/SSG/client-side routing support, etc. And it seems like a great thing for Svelte to have as a default way for developers to start making Svelte components.
Personally, I'm going to wait till SvelteKit a bit more mature before I dig in, but I'm guessing I'll end up rewriting my framework on top of SvelteKit at some point.
Put in on a VM, deploy with Ansible, and call it a day.
This is my boilerplate: https://github.com/ttymck/fastapi-fullstack-boilerplate
It tries to automate a lot via the ember-data module (which also makes queries automatically, e.g. left/right joins etc) so it shines with its predefined rules, lots of former rails people seem to contribute to its ecosystem these days.
From my personal perspective I'd say that Ember tries to keep the "fatigue" effect as low as possible when comparing it with e.g. what's going on since the React Hooks "refactors" everywhere.
A single codebase is used to create applications for Android, iOS, Mac, Windows, Web, and Linux with Flutter. It lets you build user interfaces, add new features, and fix bugs without sacrificing speed.
However, hire a dedicated developer for your app development projects if you wanna build a website or an app click the link down below.
Would you mind to explain how some of these things are tackled?
But if you're looking to deliver search engines friendly websites i didn't recommend it.
Frameworks automate the boilerplate away so you can focus on the things that deliver business value. Clients ultimately don't care how their problem gets solved, but from your perspective you're better off spending 1 hour implementing the business logic rather than that + an extra 10 hours implementing a URL routing system, database access/management/migrations, etc.
Strapi has a great builtin admin panel and cms And gives you built in api to create, read , update and manage access, so its almost like a combination of wordpress + hasura kinda, and it comes in one docker image to host, you can choose between sqlite3 and postgres for the db.
Hugo for building my static web pages and page templates, after that I either render it statically with hugo (and serve it with nginx) or migrate the final file into template folder for my python app
Then for the dynamic content (SSR) , fastapi + jinja2 (for simple pages) or if i need to built a custom api (i try to handle it with strapi and only build my custom api if i need to)
When i want to build a spa , i use lemonade.js for csr, with fastapi for custom apis, and strapi takes care of the simple crud apis.
[strapi](https://strapi.io/)
[hugo](https://gohugo.io/)
[fast-api](https://fastapi.tiangolo.com/)
[lemonade-js](https://lemonadejs.net/)
If you don't mind separating them out (which lets you use different tools for your web tier and your middle tier) I'd probably use a combination of a static page driven by VueJS on the frontend and Golang on the backend for the API.
Very lightweight without much black box magic.
Miguel Grinberg’s tutorials and book are a great and quick crash course.
Recently, I tried Next.js and it changed my mind a bit. It prefers convention over configuration, requiring tremendously less configuration compared to other frontend frameworks. It is still a bit complex, but hides the fact nicely under a well-defined abstraction. I might try another project with Next.js in the near future.
Azure functions or Google Firebase for the backend.
With this approach you might not need to pay a cent depending on your usage, plus you can take advantage of the large ecosystem of React components. For a "non-serverless" approach, I would set up a VM on Linode and use docker-compose behind nginx.
Plenty of folks who "haven't used a framework, but heard X is great" are missing out on the real deal. Give it a go, you won't regret it!
Concentrate on delivering value to your target group. I'd recommend not to do SPA frontends just for the sake of it.
A terrific solution for creating most websites with some dynamic components is the Astro framework. Handles partial hydration and allows using Svelte, Vue, React for dynamic components.
The PHP language obviously still has some sharp edges and annoying design choices, but it's seen some huge improvements in the past few years imo. Simply using a framework like Laravel will also save you from some of the more infamous footguns, since there's a lot of secure/sane defaults included.
Over the last decade, people moved away from thinking of a backend+frontend combo as being the correct abstraction, and more towards thinking of a web client as just another client, akin to a mobile client, which happens to be connected to an API. Because of the very different needs of the two parts, it became much more popular to split them up (either conceptually, or with actual separate codebases being deployed separately).
So nowadays, the standard way of looking at things is to pick some kind of framework for building a backend, e.g. Django, and some kind of front-end framework, e.g. ReactJS, and develop them separately.
I'm not saying this is the only way to do things, but I believe this is correct approach a lot of the time.
I personally am looking into using it (or most probably next.js) with Cloudflare Workers / Durable Objects. Running backend code close to end users is awesome.
For a more conservative approach, if you are looking to rapidly scale up a team and/or desire a huge ecosystem of packages to use, then I'd say modern Ruby on Rails is the way to go for maximum initial velocity. However, in my experience Ruby on Rails requires a lot of experience and discipline to keep things "on the rails" as you grow your application, and that initial velocity can quickly vanish if you are not careful.
I say this as someone with a good amount of experience with both frameworks.
I looked extensively at various frameworks to see which would make me most productive in starting projects from scratch in my limited development time and this is the one I settled on.
For me, front end is the biggest time sink, so I wanted one that had the best coverage there. Full components suites debugged and working, etc. It really helps that it can target SPA, PWA, mobile (capacitor) as well as SSR.
I enjoy writing typescript so much and from the answers maybe I’ll try next.js
I know rails is pretty impressive in what it can get setup and running super quickly but I have little joy writing Ruby.
[Spring boot](https://spring.io/projects/spring-boot)
I’m also doing some projects in nodejs+Fastify+vuejs
One weird thing: I prefer not using Webpack, full spa frameworks etc if I can help it. Just add vuejs from cdn and use it to add client behavior to plain HTML output by asp.net or nodejs if I can get away with it.
For mobile app dev, Ionic Framework in the angular flavor- last I tried their Vue implementation was lacking.
Golang backend
Containers
Fargate
RDS