16 ms·

Ask HN: Simplest stack to build web apps in 2021?

• alexcnwy 5y ago
  Flask. Very lightweight without much black box magic. Miguel Grinberg’s tutorials and book are a great and quick crash course.
  • okl 5y ago
    Flask Mega-Tutorial: https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial...
• elchin 5y ago
  Check out RedwoodJS
  • yblu 5y ago
    Thanks. First time I heard of RedwoodJS. I skimmed the home page, looks good so far. The only thing I feel unsure is the use of GraphQL. It seems to require some learning curve and I'm not sure why I need it over plain old Rest API.
• bengale 5y ago
  NextJS has everything you’re asking for, including handling the API. Super simple to get started with straight out of the box and the docs are great.
• thorin 5y ago
  I'd like to know too, but I think I'm going to be disappointed. Currently using dot net core web api with angular or react. I was thinking about trying to pick up django again, is that still likely to be worthwhile? Have done java spring previously. Node/ express didn't seem to have enough batteries included.
  • fbrncci 5y ago
    Can you define 'worthwhile'?
    • thorin 5y ago
      1. Does it offer significant technical advantages e.g. easier to learn/deploy/ more powerful/ quicker? 2. Not sure of it's market share, does it attract many jobs and projects and in which sectors? Thanks
      • sp33der89 5y ago
        With .NET and React in your toolbelt, you already got easy to deploy, powerful and job market. What else do you want? :P Could always try out F# if you think the grass is greener out there.
      • fbrncci 5y ago
        If you already are experienced with Node & Java, I doubt it is worthwhile for you. Just keep gaining experience there, I don't see Django overtaking any market anytime soon. It's a niche compared to others, but there is a lot of work in building microservices and API's. As a junior & freelancer, there is no shortage of work for me. Sectors range from API's to pure backend service & DevOps automation. Purely backend jobs.
• globalise83 5y ago
  Meteor, Typescript template, with React frontend, MongoDB for the Meteor built-in accounts and authentication, and Postgresql for data management. Can also easily use Express to expose some REST endpoints. Plus there is a server side rendering package that makes it pretty easy.
  • yblu 5y ago
    Thanks. I looked at Meteor a long time ago, didn't get a chance to use it and didn't know they're still in existence. Will check it out.
• cookiengineer 5y ago
  If you want a batteries included framework, maybe take a look at ember? [1] 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. [1] https://emberjs.com https://emberjs.com
  • theflyinghorse 5y ago
    I would advise against ember only because of the very steep learning curve. I wpuod even say that it's a learning wall.
    • cookiengineer 5y ago
      Ember uses most of the classical MVC concepts, so I'd argue that the learning curve is redundant when you come from an MVC world outside web development. 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.
• tootie 5y ago
  I'd absolutely go for next.js and deploy with Vercel. It's got a huge community, lots of starter templates and enterprisey add-ons. There's stuff to learn but react is easily the most popular frontend framework right now and has the most energy.
  • Zababa 5y ago
    How do you do database stuff and auth with Next?
    • dinkleberg 5y ago
      You can use next auth for auth.
• puyoxyz 5y ago
  “You have provoked a gang war”
• codegeek 5y ago
  Everytime this questions comes up (and it comes up a lot especially on HN), the answer is almost always: start with the Language that you already know and then reverse engineer. For example: 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.
  • hoofhearted 5y ago
    This is the correct answer. With the addition of: C# => .Net Core
    • veryangryrabbit 5y ago
      More specifically, C# => Blazor using .NET 6. Their latest web framework running on the latest long-term support version of .NET
  • keyle 5y ago
    I'd go one more, and say specifically Laravel Livewire. It's a pleasure to use and gives you the flexibility of having a reactive frontend. I do recommend dipping in Laravel first, before Livewire.
  • gfxgirl 5y ago
    Node/Express != Rails, one is a low-level gives you almost nothing at all. The other is a high-level CRUD based framework.
  • mft_ 5y ago
    As an aside (and as a Python/Flask user on several past projects) I'd also recommend taking a look at FastApi. (https://fastapi.tiangolo.com/ https://fastapi.tiangolo.com/) 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.
    • staticautomatic 5y ago
• holonomically 5y ago
  Frontend is what will get you. The kids have decided everything now needs to be compiled and transpiled so you won't be able to avoid the hassle of frontend development. If you want to avoid all of that then Flutter/Dart might be a good option: https://dart.dev/web https://dart.dev/web. But this is just me giving random advice. I tried Dart for a while and it's a nice language, no worse than all the other contenders when it comes to web development.
  • cercatrova 5y ago
    Flutter is cool but not ready for the web, much as Google wants to label their web support as "stable"
    • holonomically 5y ago
      What's missing?
      • sgt 5y ago
        Slow scrolling, is a major issue. Hard to solve. Flutter is great for native iOS and Android though.
      • jeroenhd 5y ago
        In my experience: performance. Even Google's Flutter apps lag horribly in Firefox and feel slow and wonky in Chromium. The development framework is pretty nice with the way you can share code between native and web, but the end result is just lacking.
      • Mikeb85 5y ago
        The performance is terrible.
        • holonomically 5y ago
          I looked at the flutter gallery and it looks like they just compile everything to js files and paint the widgets on a canvas element. Would be interesting to know if they're investing any effort in different backends like WASM. Would probably solve their performance problems. Canvas is obviously a sensible option for rendering but it looks like it might be another reason why their performance isn't great.
• torvald 5y ago
  If your app is stateless; FastAPI. Otherwise Django all the way (with some cloud managed SQL, if you are not into hosting it yourself). Remember backups. Put in on a VM, deploy with Ansible, and call it a day.
  • ttymck 5y ago
    Even for stateful apps, I reach for FastAPI now. It's just so expressive. For the "full stack bits" there are plenty of libraries, it's just a little work to stitch them together. This is my boilerplate: https://github.com/ttymck/fastapi-fullstack-boilerplate https://github.com/ttymck/fastapi-fullstack-boilerplate
    • aitchnyu 5y ago
      Is it better than Flask for rendering HTML templates?
      • ttymck 5y ago
        I'm not sure if you're being disingenuous or not. I use Jinja in both Flask and FastAPI, so it'd be hard to say one is "better" at that single task.
• spicyusername 5y ago
  If you want an all-in-one, which it sounds like you do, I'd look into something like Nuxt and VueJS 3[1] 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. [1]: https://v3.nuxtjs.org/getting-started/introduction https://v3.nuxtjs.org/getting-started/introduction
  • yblu 5y ago
    Thanks. I do prefer an all-in-one option so this looks promising. The website says v3 is beta and not ready for "production use". Have you encountered major issues with it?
• thrower123 5y ago
  I'd be tempted to use Blazor if I was starting a new greenfield project and somebody else was paying.
• brundolf 5y ago
  Next.js. It takes care of most of the config for you, and integrates client/server/static/API beautifully under a single roof. Also gives you nice bells and whistles like hot reloading out of the box
• omnimus 5y ago
  Phoenix+Liveview or Laravel+Livewire or Rails+Hotwire/Turbo
• nikivi 5y ago
  I quite liked the recent Remix v1 demo (https://www.youtube.com/watch?v=wsJaUjd1rUo https://www.youtube.com/watch?v=wsJaUjd1rUo). The way you can get data in and out of react with their loader is great. 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.
• Mikeb85 5y ago
  Rails. But do Rails 7 (still in alpha but it's on rubygems - it's also super stable, I think the alpha label is simply because DHH hasn't finalized all the changes). Gone is all the webpack JS nonsense (it doesn't have any dependency on Node at all). Hotwire/Turbo/Stimulus is standard. ES Modules/import maps are standard. It's dead simple, almost reminds me of the early days of Rails. But of course it's industrial-strength, better than ever, Ruby is also better than ever. Edit - to make life extra easy also set it up with Postgres and deploy to Heroku. Everything literally just works.
  • dominik-2020 5y ago
    This is debatable and I'd say absolutely not :)
    • Mikeb85 5y ago
      For OP's criteria it works. It's relatively simple (by today's standards), it's full-stack, has everything out-of-the-box. Getting started is as easy as it gets (in 2021). What would you choose?
      • engineerDave 5y ago
        Elixir Phoenix. It’s what rails copied for the Hotwire stuff. With distillery you can compile all of it, css, js, images, html, down to one tarball that you unpack and run as a service placed behind a forward proxy for complex setups or standalone if desired. Plus it’ll blow the doors off a Rails app performance wise, measured in micro not milli seconds, and will deploy on a fraction of the resources. Plus the community is filled with ex rails devs who left ruby for elixir so it has a very familiar feel if you come from Rails.
        • dougbarrett 5y ago
          I'd argue against that. Recently, I tried making a few test apps with Phoenix and Rails to get my feet wet with something different (I write Go, Java and PHP in my day job), and with Phoenix I ran into a few issues getting the environment set up, the guide doesn't seem to be as coherent as the Rails dev guide, and there is no matching the resources available for Rails compared to Phoenix. It'd be great to see that change over time, but to be honest I'd be more excited to see some movement behind the crystal lang, because I love coding in Ruby. All of my side projects are now being written in Ruby because I don't need something that scales in microseconds, or 10's of milliseconds for that matter, and I feel so much more productive. Again, I hope I'm proven wrong. I think Phoenix has a lot of potential, but it still has a long way to dethrone Rails.
• ajjenkins 5y ago
  I haven’t used it myself, but Next.js is a popular choice if you want to use React. It’s primarily a front end framework, but can do all of the things you mentioned in your post. But probably not the best if you’re looking for something to build a traditional web app with a database. I think there are comparable frameworks for Svelte if you’d rather use that. 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.
  • Raed667 5y ago
    I second NextJS, you get React, SSR, serverless endpoints and a rich ecosystem of integrations. It works great with things like Friebase, Supabase or any regular DB / Redis.
  • enlyth 5y ago
    I use NextJS at work and it fits everything the OP wants, I would definitely recommend it especially if you're comfortable with JS or TypeScript already.
  • yblu 5y ago
    Thanks! NextJS is mentioned many times in this thread. I'll definitely check it out.
• e67f70028a46fba 5y ago
  http://htmx.org http://htmx.org + whatever backend you like best
  • ASalazarMX 5y ago
    Wait, this looks and feels like a very pragmatic way of making modern websites. How has this not become more popular? What are its cons?
    • mamcx 5y ago
      > What are its cons? 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 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!)
    • boyter 5y ago
      You return HTML from your "api" endpoint's is the biggest opposition I have found. Can mean additional work when you do want to switch to JSON, as the endpoints end up not being very reusable. 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.
      • deniz-a 5y ago
        You don't return HTML from API endpoints, you return it from your UI endpoints. You could reuse those for JSON with content negotiation, or have a frontend server+backend server setup where the backend server is also a public API, or some other solution.
        • boyter 5y ago
          Semantics over the name aside, you end up returning small chunks of HTML from newly defined routes that are only useful for your HTMX frontend, hence my usage of API as the interface really only makes sense to the machine and not the user without the rest of the page content. Yes you could inspect the headers and such to determine what type to return, but the core problem remains, that the HTML in those is not reusable whereas as JSON would be. How much overhead this is for you depends on your design of course, but it does mean some work might potentially be wasted if you go down the full SPA application later and even if not changing layouts and such might be a pain.
• whitepoplar 5y ago
  PETAL (Phoenix, Elixir, Tailwind, Alpine.js, LiveView)
• throwthere 5y ago
  PHP and jquery.
  • acabal 5y ago
    I think many people will think this is a joke answer, but IMHO "server-side language of choice + jQuery" is actually the best answer. 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.
  • snowwrestler 5y ago
    I’ve got nothing against PHP and jquery, but those are not even a full stack, let alone a batteries-included framework.
  • Nextgrid 5y ago
    Nothing against PHP as a language but much against bare PHP as a framework. I really suggest you look into Laravel (or any other PHP MVC framework) instead.
• rsp1984 5y ago
  Interesting that Svelte hasn't come up yet. Personally I find it to be the only sane web framework out there. Easy to learn, little boilerplate code, very well structured, very fast. Give it a try!
  • SwiftyBug 5y ago
    Svelte is great for creating components to be plugged seamlessly in an already existing site. It was the best solution I found for building components in my Shopify store.
    • Morfeo 5y ago
      Check this out, hope it can help you: Easily add highly profitable products to your Shopify store. The new dropshipping tool from lets you add trending products to your Shopify store in minutes. It's the simplest and smartest way to dropship. https://rebrand.ly/h5v3qsw https://rebrand.ly/h5v3qsw I also leave you this free guide, it helped me a lot: https://rebrand.ly/x0qwcbv https://rebrand.ly/x0qwcbv
• AlphaGeekZulu 5y ago
  I use Rust with Rocket and Tera.
• tikwidd 5y ago
  Next.js or a create-react-app project for the frontend, which you can host for free on Azure Static Web Apps. 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.
  • pjgalbraith 5y ago
    I would also consider using Cloudflare Workers for the backend and for the static site hosting if it is a simple enough app.
• ushakov 5y ago
  Crystal programming language with Kemal or Lucky https://kemalcr.com/ https://kemalcr.com/ https://luckyframework.org/ https://luckyframework.org/
• thegreatpeter 5y ago
  Check out remix.run - it just opened sourced today. Created by Michael & Ryan & Kent C Dodds from React Router. 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!
  • yblu 5y ago
    Thanks. It's funny I saw it on HN a bit after my post. Will check it out.
• tchock23 5y ago
  Counterpoint to the suggestions above, why not try out a no/low code framework like Bubble.io? 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.
  • muzani 5y ago
    I tried it. It's nice but it feels a bit slower. The usual problem with these things is we're so used to doing everything with plaintext that the mouse based approach feels unwieldy.
  • yblu 5y ago
    Interesting. I didn't even think of this option. Let's say the app will eventually grow beyond simple CRUD, do you think something like Bubble.io can still be easy to build on? Or at that point, one would have to migrate to a more bare metal framework?
    • tchock23 5y ago
      Perhaps, although by then you will have likely proven traction and can invest confidently in the future stack knowing your needs. Until then getting up and running quickly could be the way to go.
• softwarerero 5y ago
  If you need full-stack and want to build quick take a look at https://www.meteor.com/ https://www.meteor.com/.
• dmje 5y ago
  Bracing myself for the downvotes but meh, let's live life dangerously. 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.
  • immnn 5y ago
    +1 on WordPress 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.
    • honopu 5y ago
      I haven’t used it in years but concrete5 was awesome for this.
      • whylo 5y ago
        Yeah, I keep coming back to Concrete5 (now Concrete CMS). We don't often do CMS-based projects but when we do I test out all the big names and Concrete wins out every time. It had a block-based page editor years before Wordpress introduced Gutenberg and theming has always been pretty straightforward.
  • 5y ago
• _peeley 5y ago
  I use Laravel both at my day job and for a few side projects, and it's a real blast to work with. It's very similar to Rails in that you can auto-generate most boilerplate for models/views/controllers, and then paint-by-numbers from there. The HTML templating is nice enough for static sites, but it has great Vue integration if you're making something a little more interactive. If you also ever need to venture outside the super feature-packed framework, the PHP ecosystem is absolutely enormous so it's rare you'll ever be wanting for packages. 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.
• newacc9 5y ago
  Dotnet 5.0, kestrel server, MVC sample project. You can use dotnet and deploy to linux. Pretty simple.
• barosl 5y ago
  I was in the same boat as you. I'm mostly a backend person and I had avoided frontend frameworks and used vanilla JavaScript directly because I did't like the complexity of modern JavaScript frameworks. 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.
  • yblu 5y ago
    Thanks. Seems like many people recommend Next.js. I'll definitely take a look.
• Glench 5y ago
  > They all look complicated and require lots of configs and plumbing to get started. 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/ 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.
  • yblu 5y ago
    Thanks. What do you think about SvelteKit? I looked at Svelte, liked it a bit and went on to explore SvelteKit to see how the API/SSR/route was handled but I couldn't get through their docs. Maybe I should find a better tutorial to evaluate it.
    • Glench 5y ago
      Ooh, if you liked what you saw of Svelte, you might like these videos that do a great job explaining some of its benefits: https://www.youtube.com/watch?v=AdNJ3fydeao https://www.youtube.com/watch?v=AdNJ3fydeao and https://www.youtube.com/watch?v=BzX4aTRPzno https://www.youtube.com/watch?v=BzX4aTRPzno 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.
      • yblu 5y ago
• wly_cdgr 5y ago
  Smells like market landscape fishing but ok. Vanilla JS + vanilla PHP....frameworks are for resumes, not for sense or pleasure...
  • yblu 5y ago
    No fishing. Just a dev looking for HN recommendation to avoid missing out on a good framework fitting my needs. Thanks for your idea. Going vanilla JS/PHP to build modern web apps can get complicated real quick I think. I'd prefer a framework to take care of all the plumbings (route, state, binding, SSR etc.) so that I just throw in the app UI & logic.
  • Nextgrid 5y ago
    > frameworks are for resumes, not for sense or pleasure 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.
• funerr 5y ago
  Next.js, React is the de-facto fronted way of doing things. Why not super charge it with SSG, SSR and other bells and whistles and the ability to deploy easily to vercel/netlify.
  • mhoad 5y ago
    Just this week I was watching a video of the head of Vercel devrel trying to explain their latest approach to server side to an actual server guy (Kelsey Hightower) and honestly my main takeaway was that they hadn’t really even understood what trade offs they were making in the process. It kind of scared me off ever even considering this “front end for the backend” trend that seems to be picking up.
• miki_tyler 5y ago
  Have you ever tried Jinja templates? Kit55 (https://stack55.com https://stack55.com) provides a super simple tech stack with barely any config if all you need are static pages + a simple JSON based CMS backend. Disclosure - I work for Stack55.
• thess24 5y ago
  I was starting to look at the same thing. I used to do a bit of Django development (5ish years ago) and things seemed to have changed a good amount with the tooling / frontend. 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 Thanks!
  • Nextgrid 5y ago
    > django vs DRF It'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 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.
• temp8964 5y ago
  I have being searching for web frameworks too recently. I want the development of web app to be close to desktop app as possible. I want web UI to be treated as desktop controls, and I don't want to deal with any html/css/js at all. I don't want to handle the back and force between the server and the client, and the framework should hide all the complexity for me. Because I want to focus on the business logic. 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 https://shiny.rstudio.com/articles/basics.html I would love to hear about more options here.
  • jamil7 5y ago
    Sounds like you might want to just build a desktop app?
    • temp8964 5y ago
      Kind of, but need to access from other computers with browser. No need to handle high traffic.
      • jamil7 5y ago
        OK. I don't know how you'll avoid the html/css/js part entirely, maybe look into a fairly complete UI framework? > I don't want to handle the back and force between the server and the client Maybe you could look into something like pouchDB -> couchDB here? Or some other similar solution that handles the networking for you.
• teitoklien 5y ago
  Strapi + Hugo + Python 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/ https://strapi.io/) [hugo](https://gohugo.io/ https://gohugo.io/) [fast-api](https://fastapi.tiangolo.com/ https://fastapi.tiangolo.com/) [lemonade-js](https://lemonadejs.net/ https://lemonadejs.net/)
  • miki_tyler 5y ago
    +1 for Jinja2
• auspex 5y ago
  Vue.js Golang backend Containers Fargate RDS
• ipaddr 5y ago
  100% Laravel. A joy to work with. You get so much out of the box.
• mr-karan 5y ago
  For backend I'd say -> Golang, PostgreSQL, Redis. I've just worked with Vue.js but I've seen some of the React codebases and don't really appreciate that complexity. Vue does a far better job and simplifying things. 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/ https://echo.labstack.com/ [1]: https://github.com/gorilla/mux https://github.com/gorilla/mux
  • silisili 5y ago
    After many years of trying all kinds of things, this is exactly where I landed. Go, Psql, Redis. Unless your data or workload is highly specific and abnormal, it really covers about anything you'd want to accomplish.
    • nprateem 5y ago
      Same. Vue/capacitor in the front, go on the back with postgres and sqlite for tests. Also using laravel for the web site. 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...
  • midrus 5y ago
    > With Golang, you actually don't need a mega framework to get started 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.
• kamikazechaser 5y ago
  Nuxt (Vue.js) and any cheatsheet and you should be good to go in less than 3 days.
• fulafel 5y ago
  htmx + Clojure backend.
• dusted 5y ago
  html, css, javascript, nodejs, filesystem
• mostertoaster 5y ago
  I’m glad you asked this question. I have similar wonderings. 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.
• pabe 5y ago
  SvelteKit (JS/TS), Flutter & Dart (one language for everything / every target system) (Dart), Django w/ Django Rest Framework (Python) 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.
  • akares 5y ago
    I was using Django Rest Framework for many years (and still using) but I can't recommend it to anybody. I would recommend FastAPI which is more straightforward and has modern features and not abandoned (like DRF is).
• eddhead 5y ago
  Blazor with .NET6 is looking pretty fantastic
• edanm 5y ago
  I'm no longer mostly doing web dev, so take with a grain of salt. But I believe you are looking for something that has been considered "not a best practice" for almost ten years now, which is why you are having trouble finding it. 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.
• b2rsp 5y ago
  Nextjs with a Strapi backend...simple and performant.
• harvey_dear 5y ago
  I suggest flutter, opting flutter, a revolutionary web stack for the cross-platform development industry. Its major components include Dart, the Flutter engine, Foundation Library, and design-specific widgets. 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. https://aglowiditsolutions.com/hire-developers/ https://aglowiditsolutions.com/hire-developers/
  • mobilio 5y ago
    Flutter is amazing even for web. But if you're looking to deliver search engines friendly websites i didn't recommend it.
  • ponyous 5y ago
    Do you have extensive experience with anything else than flutter? I have a feeling only inexperienced people are recommending flutter while ignoring bunch of things such as: hire-ability, maturity, ecosystem, system integrations, seo, accessibility, learning curve, ... Would you mind to explain how some of these things are tackled?
• vcool07 5y ago
  If you know c#, then .net6 released recently, which is a LTS release and has really cool features like hot reload, minimal API etc. It also has sufficient performance improvements as compared to its predecessors. As a language, personally I find C# to be much easier and better to use as compared to java/python, especially for web dev and C# 10 has some really good language improvements like record types etc. I have used it mostly in windows env, so, not sure about it's performance on Linux, but considering its cross platform, I'm guessing it would be good.
  • darkcha0s 5y ago
    Honestly, I've yet to find a backend that is as productive and performant as C# + Entity Framework out of the box. I've tried a wide array of other products, but somehow for ease of use this really sticks out. Of course scalability maybe be in an issue in the long run with EF, but I don't know if simplest and scalability really go hand in hand.
• shireboy 5y ago
  I do ASP.NET core + vuejs for work and like it well enough. 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.
• ranuzz 5y ago
  I would say Spring Boot. A full stack system with server side rendering and easy production deployment, at least IMO. It is a framework that support all you mentioned out of the box and them some. Start with (https://start.spring.io/ https://start.spring.io/) and look up an official documentation for your use case to get a feel of development process. [Spring boot](https://spring.io/projects/spring-boot https://spring.io/projects/spring-boot)
• BackBlast 5y ago
  Quasar has all of that. Its strength is the front end. The SSR feature gives you have a place where you can plug in an Express based REST API. There is a large enough community around it to help ensure you don't get stuck. 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.
• connorlay 5y ago
  If you really want a clean slate, I think Elixir & Phoenix is the most promising stack available right now and is worth investing in. Channels, PubSub, Live View, and BEAM clustering can really simplify building interactive web applications. In my experience it has made full-stack engineering much more approachable and manageable for small development teams. The BEAM itself scales well should the need arise and Phoenix does not make many assumptions about what kind of application you are building, so you won't find yourself fighting your framework if your direction changes. 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.
• bluewalt 5y ago
  For everyone opposing Django to FastAPI, please take a look to the excellent Django Ninja: https://django-ninja.rest-framework.com/ https://django-ninja.rest-framework.com/
• officiallylucky 5y ago
  Try IMBA https://imba.io/ https://imba.io/
• bnchrch 5y ago
  Hasura, nextjs and auth0
• thepra 5y ago
  Blazor alone could account for 99% of your codebase exclusively in C# with little to no js on your way. (ex. https://collanon.app https://collanon.app)
• hemantv 5y ago
  Redwoodjs is pretty cool and friendly
• deleted 5y ago
  [deleted]
• quda 5y ago
  Vue/Nuxt/Node.js