If you will start your project today (medium to large application) which web framework technology would you pick:
- Asp.Net Core
- Node + Angular
- Node + React
- Django or Flask
- Rails
- Laravel or Zend
- Play Framework
- Other
My usecase is mostly side-projects that I want to take to the market. So I stick to Django.
Why?
* I am already familiar with it's advantages and quirks. So I can get running faster. The knowledge that I have accumulated in my previous projects will be handy to get going. Time to market is important for both validating the product and avoiding a burnout.
* There is a well defined way to do most common stuff. So you need not experiment and reinvent the most basic stuff. All those get out of the way and I can concentrate on the meat of the problem.
* Many libraries like auth, rest framework are battle tested and most likely tested for security vulnerabilities. if you are taking something to market, it is in everybody's best interest to ensure security is taken care of by the pros. Django is solid in that aspect.
* Though python may not be the most performant language (I have been bit by that a lot in data processing) it is still fast enough for websites with normal loads (which is 99.999% of today's websites).
* If I do have a performance bottleneck, there are lessons from pioneers on how to optimize it.
For me, django fits all these needs. For you it might be Rails, Node, Play or Phoenix. I used to want to learn Phoenix and Play.
But I realized it is a no-win situation when you mix a brand new tech with brand new product.
Now I reach out to new tech only if it fixes a sore need that my existing toolkit cannot handle.
For example, I am looking into webpack and purifycss, because django does not have the necessary functionality to trim the fat in bloated CSS, while Node stack excels.
If I work on a interaction heavy front-end, I might reach for vue or react, and that too only if I really need it.
Else, I am quite happy with django/vanilla-javascript/sass/bootstrap(for prototyping)
Either you are building something for learning, or you are building something to ship it, and it's better not to mix the two. If you are building something to learn new technology, then use whatever that excites you to make something that you won't feel guilty throwing away.
If you are building something to ship, then you should preferably use nothing that you haven't already used before. You'll still improve as a developer, because you will get better at technology that you have already invested in.
I don't understand why people still write javascript except legacy codebase maintenance although I respect everyone's freedom. Especially, sorry, React/Redux why? Yet, people are obsessed managing state on client (browser), that's the bad days of whatever framework including Elm. 90' Game developers would wonder too since they often prevent corrupt states from bad people was trying hard to mess (cheat) game states, thus source of truth and constraints must only live on server. States on front-end must be just something only for sake of displaying.
Game developers protect state to prevent cheating. For example, allowing a player to update his location could allow teleporting or spawning tons of bullets\projectiles
If a web developer creates an IM webapp, why should they care if you modify your local copy of the message data? It only affects your session and the next time you get a copy of the message it will be the original. All other users are still seeing the original
"Global" state should live on server. Only local state lives on client. I'm not sure how you are against react, angular, etc, since they only manage "local" state.
I know any framework or any single line of code on client is all about "local" state. But when people lost focus they _potentially_ couple business logics, local truth and constraints with "Global" state from servers, and trust wrong source of truth. And that might end up with next corrupted, e.g. POST, requests.
I am trying to avoid blaming React/Redux specifically because it's going to end up with a blog post. Tree nodes communication, composition and state.
Imagine you have a 5-height tree, each node is an object that can receive properties from its parent (hell yeah, lightly inheritance smell), that's not that bad until all objects' methods (components' callbacks) execution orders come together (hell yeah, lightly recursion smell in _imperative ways_ while a normal recursion can be done in declarative way of thinking). Next turn, Redux. Connect a store to any level of tree you want, ahh that sounds handy but I have no ideas who setState, when and where. Saga|Thunk hmm this is slightly better since it is a separate middleware but wait, it's not completely isolated, anything _available_ for you there; Dispatch, Store, setState etc. Finally, all these built on top javascript ahhhh I personally suck at orchestrating these things.
Everyone is posting layers upon layers of components and frameworks. It just seems so bloated, so hostile towards the developer.
From my experience, the more independent projects you include, the harder an application will be to maintain, let alone configure and build. Am I just old and cranky? Or is there reasonable justification to do this?
If you're unfamiliar with a framework -- whether it's Django, Rails, Express, Angular, or React -- much of the structure it imposes on your code feels tedious, over-architected, bloated, or just plain silly.
Once you've built a couple applications from scratch without using a framework, you begin to realize just how boring and error-prone things can get when you do them by hand. I want to get to the good stuff, the meat of my application, as quickly as possible. Knowing a framework inside-out lets me do just that.
Maybe the next time you're forced into using a framework, start looking at how it's put together under the hood. It's educational and a lot of fun. And you realize just how much accumulated knowledge these frameworks contain :)
I'm with ya on this. Although I mostly work on back-end, it seems like a lot of the front-end frameworks have many layered requirements to just use them. Things like compilers, build tools, etc. just to use the framework.
If you are starting a project, like others said, it is probably small so start with the minimal you need to get something working. And start with what you are most familiar with. Developers like to evaluate things and analyze to the Nth degree because it can be fun to bike shed. In reality the technology for the most part doesn't matter, especially for web stuff.
No, but you may be a bit too optimistic. By the time you hand craft your CSS and Javascript to support all the browsers and features you need, you will have created yet another framework: deedubaya.js
> Or is there reasonable justification to do this?
The browser was meant to display documents. We keep trying to make into an runtime environment.
I used to use Pyramid for everything unless I needed forms and UI then Django is a no brainer choice. But I stopped wanting to setup SQLAlchemy and writing bootstrap codes for managing test states etc. I still love Pyramid because of its flexibility, but perhaps I need to invest time in the plugins to see if there's anything quality to support SQLAlchemy integration much like Django's ORM out of the box, and whether there's quality test integration out of the box much like django test command. Flask I have a love & hate relationship too. I feel like the community is too lose. I used to write Flask apps but back then half of the recommended libraries/projects would not have updates for months. I can't trust code that isn't widely adopted and widely used, because I don't want to be the only one filing bugs. At least Pyramid has built-in Authentication modules that you can use, but Flask I'd have to rely on the community project which to be really honest, I am not sure if I want to trust it in the long run. So these days, I fall back to Django first, Pryamid second, then Flask finally (especially convenient for quick projects).
I don't really do any front-end development because I totally not good at it, so I gave up ~3 years now. But I would look at EmberJS and React.
* What I would not use is any language that is not statically typed. The compiler can catch an entire class of errors and there are great tools for automated refactors. For me this narrows down my choice of languages to C#, TypeScript (Node), and if really necessary Java. But today I would probably use Kotlin instead of Java if possible.
* Technology is a means to and end for me - to get stuff done and to remain marketable. So I would probably choose the front end framework that is the most marketable. Which seems to still be Angular. Two advantages - when it's time to switch jobs I have more choices and when I'm looking for contractors to come on to projects that I'm over, Angular coders are a dime a dozen.
That being said, I'm really finding the combination of Bootstrap + JQuery + Handlebars to be refreshing for non-SPA websites.
* Databases. If I'm spending other people's money, I prefer SQL Server/Entity Framework as an MS person. When NoSql is the right choice, SQL Server has pretty good support for JSON. It really is the best of both worlds.
If I'm spending my own money or don't have a budget, I would probably choose either MySQL (relational) or MongoDB (NoSql)
* I know this wasn't part of the question, but for hosting, AWS all of the way and I would use as many of their services as possible except for DynamoDB. It just feels a little odd.
* And to go even more down the rabbit hole. I would hate coding without my JetBrains subscription. Right now, I just have Resharper. But if I were doing this as a side project I would have the subscription that included everything.
In my 7 years of using this framework I have come across nothing that comes even close to in terms of LOC, ease of pickup and quality of the end product.
Why? It works. It's not gonna have crazy changes. It's simple. There are a million relevant resources to help learn how to do x, or help you if you get stuck. It's easy to hire skilled people that know this stuff back to front.
btw - you don't start a medium to large project. You start a small one, build incrementally, and see what happens. If you have success, then you can spend money building in whatever you like.
Depends on the project, but most likely just Node + express + TypeScript on the backend (so no "framework" in the traditional sense).
On the frontend, React + MobX + TypeScript.
This of course means it would be a single-page application.
Benefit of using TypeScript on both client and server is that you get to automatically share the schema of the data they're exchanging (and maybe some more code as well, like validation). For free. And when you change the structure of something - and you will - you get immediately alerted to any issues on both sides (e.g. this property is now required, and you omitted it in this function!). This is huge because maintenance is often more difficult than writing the initial version - and I don't even mean the initial released version.
Also you get to potentially reuse some of the code in the future for a React Native based mobile app.
I'm also eyeing GraphQL and Apollo a bit, but I don't have enough experience with them to use them in a "real" project just yet.
I would do pretty much exactly what OP suggests. I might just go for React+Redux instead of MobX, but that's not too important.
What I'd like to hear is arguments as to why I might want to consider other options. Why Elixir, compared to the above solution? Why Phoenix, or for that matter Django? Or for the front-end-ish side: why MobX instead of what seems to be a more industry-standard Redux? Why Node.js and Express instead of the alternatives (Django, Rails, but also Hapi and Sails)?
> Benefit of using TypeScript on both client and server is that you get to automatically share the schema of the data they're exchanging (and maybe some more code as well, like validation). For free.
How do you do this? Do you have a separate NPM package that just contains your schema/validation code? Or do you keep your backend and frontend code in the same repository?
Same repository, 3 different directories (client, server, shared). This also makes it easy to have shared docs, dockerfiles, and other things needed for the complete setup on any machine.
But you can also just do this with a git submodule for example, or any other method that will physically get you the shared files there.
I've always wanted to try breaking projects down into separate NPM packages, but I usually end up using git submodules. Path of least resistance and all.
Mojolicious (Perl), Spring Boot (Java / Kotlin) or plain Go. Depending on productivity, performance and hardware constrains.
If it's the typical CRUD site I'd use Django (Python) if I worried about finding developers, otherwise sticking to good old Catalyst (Perl) or perhaps giving Phoenix (Elixir) a try.
To be as concise as I can, I would say that Spring Boot is a framework which minimizes the amount of "code" you have to write at the cost of everything else.
And this means that it's hard to understand what is going on under the covers, hard to debug (partly due to metaprogramming bananza), slow to start, uses too much CPU, uses huge amounts of stack, has all bells and whistles turned on by default etc etc.
It gives you all errors at runtime. Encourages you to make your app too configurable (hard to test all configs). Reimplements a bunch of tools and libs badly (like one-jar). Its also intrusive like all frameworks. Requiring a custom test runner is not a feature, Spring! For these type of reasons you cannot easily integrate it with other frameworks.
> "all bells and whistles turned on by default etc"
Arguably a little unfair? Spring boot makes it pretty trivial to just pick and choose the components you need for a project, especially with the https://start.spring.io/ tool.
> Requiring a custom test runner is not a feature, Spring!
I'm guessing this is a reference to using Spring's test runner to support Spring's dependency injection mechanism? No one forces you to use this so it's a stretch to say its 'required', but for certain tests it will save time over manually mocking etc, and often only applies to integration tests anyway. You can absolutely unit test without it.
> "It gives you all errors at runtime."
I'm sure it does, if you have errors.
> "Encourages you to make your app too configurable"
Spring boot apps are only as configurable as you make them, much like any other application. At least Spring tries to provide a standardized methodology/pattern for externalizing configuration parameters. I fail to see the 'encouragement'.
> you cannot easily integrate it with other frameworks.
It's java at the end of the day - there's a ludicrous number of third party frameworks it will play nicely with.
> slow to start, uses too much CPU
Sure JVM applications rarely have 'instant' startup for various reasons, but is a handful of seconds really a problem? 'Uses too much CPU' - I don't really think this is fair either - Spring Boot applications can deliver very efficient solutions.
Not going to argue it's the perfect choice for every project, but no framework is.
Isn't spring boot "thread-per-request"? Some people care about that kind of performance-related stuff.
Also, I think "It gives you all errors at runtime.", should have been "It doesn't give you the errors other frameworks are able to give you at compile time." -and I kind of agree, if memory serves "Spring" is sort of synonymous with "reflection", which isn't exactly performant either.
EDIT: Wow, just read my comment and realized it comes across like I really hate Spring.
I don't, I think it's nice. It's great for web apps that have human users; for services that are consumed by other services, I would probably go for something else.
By default, Spring Boot uses an integrated Tomcat in standalone mode. That Tomcat is configured to use a worker threadpool with a default size of 200. In addition to that you can make Controller methods "asynchronous" (as in free the worker thread as soon as possible) by simply wrapping the methods content in a Callable<T>, which amounts to wrapping it in a lambda method. Calling methods asynchronously is trivial as well, you just need to annotate them with @Async and wrap your result in an AsyncResult<T>.
If you follow the reactive/async/callback/functional cargo cult you can use the brand-new, already usable Spring 5.x spring-webflux. As they describe it: "fully reactive and non-blocking. It is suitable for event-loop style processing with a small number of threads"
If you stick to the script its ok. But the script sucks right?
I prefer dropwizard + libs, always end up googling how to do X with spring boot, where X is a bit off the beaten path
How's Go with web applications that render HTML content? I've had a lot of fun building microservices with JSON REST APIs in Go lately, but I have not done anything that emits HTML. I'm afraid that as soon as you generate HTML, stuff gets messy and you need to include bajillion modules with all this CSS/JS crap.
If what you're trying to achieve is to pump out some
HTML, Go has built-in safe HTML templating. The template syntax isn't glamorous (in fact it can be very unpleasant at times), but with it you can catch type errors at parse time, and the ability to bind custom functions on your templates comes in handy.
Usefully, too, any type that implements the Stringer interface can be dropped into a template and will come out of it as a string without any additional fussing. If your app implements a number of custom types, it's actually possible to get Go templates to look relatively sane.
Phoenix (Elixir) for the backend because I started with Elixir this year and really enjoy it. If the app was simple enough and I was feeling up for a challenge than maybe just Erlang directly with Cowboy (so no real framework).
For the front end: Elm or maybe Ember.js. I started learning Elm this year too and like it but I possibly would go Ember because it seems interesting and since I have a membership to Daily Drip I have free tutorials on Ember (as well as Elm and Elixir)
Django if front end is complex (lots of forms, complicated templating, need to have a free admin interface for out of the box).
Or if the front end is simple, I'd just write it in Go using core net/http library.
To make it more maintainable, I'd probably split the application into two components, so backend could be API written in Go and front end a Django app.
Not because they are so great but because everything else is even worse.
After significant React experience I can no longer tolerate send-html-template-sprinkle-javascript stacks.
The downside is that the amount of boilerplate is unbearable. There's significant friction in the tooling because of transpiling, sourcemaps, multiple layers of sourcemaps, file watching, having to produce multiple different bundles for server side rendering, client-side bundle and so on, testing with transpiling is a pain, test coverage with transpiling is at times borderline impossible, proper isomorphic data-loading is difficult and the list goes on. Still prefer it to the other stuff.
Even if they are extremely familiar with the tooling it's still a huge problem.
People get seduced by unrealistic examples online and think "oh easy just drop this little config thing here and done".
The problem is the little things pile up on top of each other before you know for a production app you are deep into plugins and transpilers and configs to your knees and you have to make them all play with each other.
Just some examples of difficulties of this architecture,
- You must have an API for doing anything because the client-side needs the API, but on the server you also have to use the same code for server side rendering. It gets more fun because you have to deal with authentication as well on both sides. So you will have to "proxy" the cookies from the client on the server side to the API to load initial data for server side rendering. This is full of gotchas and largely undocumented it will take you at least multiple days to get right.
- Data loading for client-side navigation is tricky. At what point do you fire ajax calls to load data for the destination? Sometimes multiple calls are needed. With react router you'll need a custom "Link" component with data loading functions that produce promises then you can do Promise.all on them and transition when ready. For a good experience you have to incorporate timeouts. In my case I immediately start loading target data upon link click for navigation, wait up to 100ms ("navigation wait tolerance") and if things are not done by then I navigate to the target in a loading state and the page re-renders when data is loaded or error happens and error is displayed. Again, full of gotchas.
- Need an admin panel? well you better not have any potentially sensitive text on your admin pages because guess what that ASCII text is going right into your javascript bundle. This is a minefield if you don't want to be leaking your admin UI and capabilities. At this point you will need to have a separate admin bundle that is not given to normal users. Good luck with that. You can't just "add" it on top of the normal bundle (too hard to explain, try it and you'll find out). So it needs to be a complete application bundle that is built for admins. But well if you want the admins to go through the normal login page like all the other users ... gotta switch somewhere in there.
- Testing? Forget about all the usual CLI tools like mocha/jasmine/ava/jest/etc... they will all blow up one way or another when facing a sufficiently complex application with webpack/jsx/transpiling/etc. So you have to have another "test" bundle that imports all the tests, you have to transpile and build that bundle then execute it with a test runner. At this point all the usual tools for test coverage become nearly unusable.
- Server side rendering: since your client-side stuff like React components are also needed on the server now you need to be building a server side rendering bundle and then you have to constantly keep running the output of that build so your server-side-rendering during development works correctly.
These problems will interact with each other in complex ways you can't just solve them separately one by one. Each one you try to fix will create other compromises or problems in another area.
In summary, it's an absolute cluster fuck and I challenge anyone who think it's easy to do a non-trivial project complete with user signup/login/logout/admin panel/authentication/authorization/roles/server side rendering/tests and come back.
And with all of this bullshit I still prefer this to the old(er) way of jQuery event handlers and so on.
At some point I got so fed up with the problems I described earlier I tried to go back to the old stuff but I couldn't tolerate it anymore so I came back and accepted the new nonsense.
Mind you it has improved a lot since the last year as well. Especially with the newer versions of React Router.
Sounds like you might like Clojurescript + Reagent which is based on React but with much simpler tooling (Leiningen). You can also run Clojurescript on Node now with Macchiato (https://macchiato-framework.github.io). If you need something CPU-heavy you can hook it up to a backend API written in Clojure. Turtles all the way down :)
This seems like a lot of independent concepts to grok + configure to create a webapp. Especially when a viable alternative might be PHP +Postgres + jQuery. I guess I'm just old and cranky anymore :)
Believe me I used to do lots of PHP+Postgres+jQuery but after experiencing React I just feel like shooting myself after writing some CSS selectors and binding event handlers.
It feels like trying to start a fire with a stick when you have a lighter in your pocket.
But as I said the boilerplate and friction is still unbearable.
I think there is just one sane choice: I'd use the one that I know best, and the one that has huge number of users (which means it's more battle tested).
React: once you get the framework down, it's a lot easier to build a native mobile app with React Native. There's no Angular Native.
Angular: powerful and abundant. A little different, but flexible. Answers on SO for every little thing that will come up to ask. Not sure if newer frameworks will have that same luxury.
Rails: a lot of convention. But once you get it down, you'll be able to build complex apps in little time. Also a lot of community support and search engine presence.
If it helps, I've open-sourced all code around Standard Notes. It's mostly a Rails/Angular stack.
I agree with what you've written, but just wanted to note that Nativescript provides a React Native equivalent for Angular 2/4+.
I still prefer React Native overall as more people are using it and the ecosystem is bigger, but using Nativescript with Angular was surprisingly pleasant when I first tried it out a few weeks ago.
If I was to start a project today it would be Elixir using cowboy and plug. I like to keep things simple. If I thought the project was more on the medium size I would probably use Asp.Net Core. For the frontend I like to stay vanilla and use bare bone so html/sass/typescript with maybe jquery if needs be. Postgres for my database needs.
Why? Speed and flexibility of development (although tbh this is just about what you're used to), using the same language on both ends, and I really like js.
Not really, you could make that argument about any set of technologies working in tandem. Traditionally a framework is an entire set of technologies, only really designed to work together (e.g. Laravel, Rails, Backbone, CakePHP, etc.).
Express is a routing library for handling HTTP requests, it's not opinionated about anything else. It does one thing, and it does it fairly well.
React is a library for building UI components. It's not particularly opinionated on how you manage your data, or anything else really. It just renders things, and helps you do this efficiently.
Redux is a library for managing state changes in an application. It doesn't tell you how to render these changes, it just manages state.
These are not frameworks, they're focussed libraries.
Backend: Django as soon as you want an admin interface for your models. It just saves so much time, and nobody enjoys writing those dumb CRUD routes. If you don't need an admin interface and want to stay in Python, I'd recommend Flask. Else I'm also enjoying Node.js.
Backend: Django (Python 3.5+). Yes flask might be lighter etc, but at the end of the day, when you need to do things quick, batteries included approach goes a long way. Also, it will be easier to find developers who can hit the ground running. Most of the time, I would use it for an API layer coupled with Django Rest Framework.
Database: PostgreSQL 9.6. That's easy. You get the best of all worlds here. RDBMS with indexable JSON document store. Stable, fast. There is no other choice for me.
Front end: Depends. React/Redux works for me 80% of the time. I prefer to use Semantic-UI (the React port is excellent) for the presentation. The other 20% are simple admin only apps where plain old html would do just fine. I now try to avoid all-in frameworks which tie you in like a Catholic marriage.
Async: Celery + RabbitMQ. It works, and works very very well as a background task/job runner.
Source control and Project Management: Git and Github.
Specialised system apps - Go(lang). For fast specialised servers, websockets, etc.
Deployment/Provisioning: Ansible.
Bonus points: Personal Development: Learn a new language every year. Do a little project in it.
If you're starting up a new project, choosing the "best" framework vs the one you're most familiar with is going to make everything that much more difficult. You're going to learn something before you can build something? And build something more slowly because you're trying to learn something?
My untrendy answer:
Frontend: Backbone/Bootstrap
Backend: Node
DB: Postgres or Mongo
If you don't know those things, then this isn't the right answer for you, but whenever I start up a new little project in my spare time and utilize Backbone, it's like a breath of fresh air, compared to most of the current popular frameworks and what we have to use at work.
I really like Elixir. Learning to write & test concurrent code has certainly been adventure! It's probably been a good warmup for testing microservices.
I've created a list of every technology (language, framework, DB, etc) posted as of 0913 May 22: (This list may contain some overlap, since I don't recognize like 75% of these names)
After years working in an Angular 1.x stack, I took a long, hard look at Angular 4 and decided to make the switch to Vue.js (with firebase on the back end). I'm happier and more productive with this combination than I have been with any web development setup in literally decades.
Vue does everything Angular did for me without nearly as much cognitive overhead. Working in Angular just felt like an endless stream of hidden gotchas and idiosyncratic jargon; for the year or so it took me to really start to feel like I had a handle on the framework it seemed like the answer to "How do I do foo in Angular?" was always "Don't do foo; do bar, baz and bat instead, but make sure you don't quux, that'd be really bad". And even after I'd more or less gotten used to the Angular Way To Do Things it always felt like I was fighting against the framework instead of depending on it.
Vue just works. The component structure is really developer-friendly, it's much easier to incorporate non-Vue code when you need to, and it all just pretty much DWIM without you having to think about what's going on in the guts of the framework. It took maybe two weeks of practice before I felt totally comfortable with the system. Clientside performance is a zillion times better than Angular; you don't have to pick through an entire freaking ecosystem of secondary frameworks just to get started like you do in React; vue-cli gives you sensible scaffolding and you don't have to spend much time fiddling around with webpack and build configuration. Yeah. Good stuff.
Firebase I'm a tiny bit less unreservedly enthusiastic about -- don't get me wrong, it's super convenient, and it's nice not having to spend much attention on the network layer of my apps, but there are times I wish it were a little bit less magic than it is: I can't always tell whether I'm using it efficiently or not. And the tree data structure isn't appropriate for every project; I kinda wish there were an equivalent with the same websocket live data updates but backed by a boring old RDBMS instead of a JSON store. Plus, you know, vendor lock-in is always a concern. For a mostly-front-end guy who just wants to be able to store and retrieve data without thinking too much about it, it's fine; I'm not ready to evangelize for it quite as much as I am Vue though.
Clojure + Ring + Compojure on the server, ClojureScript + Reagent on the client. Because I don't know any better, and want to be punished the moment I have to hire anybody.
Another server-side option is Macchiato (https://macchiato-framework.github.io), ie. Clojurescript on Node.js. The whole Clojure/script stack really deserves wider adoption given that it arguably enhances React while reducing the insane amount of JS tooling.
PostgRest with Mithril.js or Elm on the front end. Keep it simple. Or WebSharper with SQL Server for a more integrated feel with static typing all the way from the database all the way down to the front end. Studies have shown static typing to be extremely important for removing bugs and programmer productivity, and from what I've seen WebSharper would give the best experience for that.
I've only used Mithril.js in those technologies though.
Django for the backend with a postgres database. Just use django - I am using it for around 7 years: never regretted it, always happy with my choice. This is important to me and has not happened with other things I've used (like spring mvc, jsf, angular.js, android dev etc).
I generally try to avoid complex front end stuff, in most cases a little jquery and a datepicker are enough. If I need something more client heavy then I'll always try the least complex solution - if jquery isn't enough then knockout.js would suffice most of the time.
On extreme cases (UI heavy SPAs) I'd use react+redux with a django rest framework backend. But only if it is absolutely required. I have measured that using pure django (and friends like django filters, django tables etc) is like 5 times productive and 10 times more DRay than if you add client side/ajax stuff to the mix (along with the required bloat like client side tooling/weback, apis, auth, routing, client side models and forms etc).
It's nice to see all the love for django here. I've been developing with django for many years now and I feel like more and more developers are finally picking it up for various projects. It's remained very popular for quite some time now. I especially love the django developers, as they really seem to put out high quality releases that make updating to the latest version fairly painless.
I would also opt for django, postures and react+redux on the front for any complex hi needs. With django rest framework powering an API, building complex ui's becomes less painful. I've yet to find something quite as powerful as DRF.
Recently started a large commercial project 4 months ago and I'm seriously glad I went with django.
It feels like the constraints/expectations we face building in 2017 are different from those of 2004 (when Rails was created) or 2005 (when Django was created). Both of these predate the iphone (launched in 2007) and the dominance of mobile, as well as stuff like Websockets (2011), 12 factor, immutable infrastructure, distributed systems...
It feels extremely unlikely that that if we decided to design a framework with these things in mind we would end up with something that looks like Rails or Django (or some other RESTish/MVC thing), and yet somehow these are the things we overwhelmingly use and recommend.
Definitely pick Python and Django or Flask for your server side.
Python is a super easy language to work with and if you combine with heroku for hosting it's a no brainer.
Now if you want to develop something more front end heavy maybe Flask to quickly layout your API endpoints.
I would suggest learning react redux if you want to get into JavaScript as you come out the other side with a better understanding of functional programming and a pathway into modern Webdev in terms of componentisation and progressive web apps.
The tool chain for React has been simplified to regular human levels of patience now through create-react-app
Flask if project isn't complicated or not expected to grow much or I don't care about model admin. (and maybe even Flask if project is expected to grow... Flask really is a pleasure to work with).
I prefer Flask of the three because I don't like a lot of built in extras, but prefer a larger plugin ecosystem than Bottle has. But Django isn't a bad choice either and maybe a better choice for organization.
A web user interface is just a user interface to the actual program, which I always construct as a commandline (cli) program. It should also be easy (or at least doable) to build a mobile and/or desktop user interface for the same backend cli program. All of that should naturally be able to run as docker microservices. In other words, web "frameworks" are just a pile of retarded crap that is totally incapable of doing any of the aforementioned.
For the backend, Kotlin on Intellij. It's crazy awesome and you can use it now for android clients as well.
The Javascript transpiler is probably not ready yet (in beta) so I would use a Bootstrap and/or Material Design library with lots of components and tie it together with javascript.
Database Postgres. You can go hard relational if that's appropriate or use the Json support like a better Mongo.
I am making a website based on this and the experience is amazing. I literally started learning a week back, pivoted from firebase (after 7000% fiasco), and have been kicking myself, why I wasn't aware of this before.
For the server-side, definitely Tornado + SQLAlchemy + PostgreSQL. This is the core, with a likely addition of things like Celery depending on how large the system gets.
The client side would depend on the complexity of the user interaction, but the Web part would probably involve React.
For larger apps I'd use Grails (think Rails on Spring Boot) with Postgres. Depending on the app I'd either use the built-in Hibernate offspring or the awesome jOOQ library to access the database. No freaking idea about the frontend, so much choice..
Serverless Framework + Phenomic (React static site). No servers to worry about, no OS maintenance, out-of-the-box scalability (using AWS API Gateway / Lambda / S3). All development in JavaScript, so no need to context-switch for client/server.
Yes, latest technologies.
I started this thread because almost all web frameworks had a big improvement year and they're somehow converging in a lot of features and concepts.
FAM stack; firebase + angular + material design. Get anything up and running in hours. With cloud functions you can set up server side code with minimal effort.
The choices presented make my head hurt... A simple stack is a happy life. Spend time on the business problem and choose the most boring technology available.
If i make web app and want my application to be "portable" i will go with PHP and Laravel framework.
Depending on your application. If you want to offer to users an installable copy, PHP is the most easy way to do it if you care about "portability" on existing user machines.
However if you make SAAS and not care about "portability", then you are free choose other languages and frameworks
I'd love to be able to recommend ASP.NET Core, but there have just been too many changes and U-turns. I have spent too many hours shaving the yaks of changing project formats, features missing from the old ASP.NET stack, warring dependencies, and half-finished implementations of related projects like Entity Framework Core.
I _do_ believe they'll get there, but it's been painful maintaining apps built with these technologies over the past couple of years.
Which issues did you run into with EF Core? I've been dipping my toes in the water and was on the fence about investing time in their offering after seeing their long-ish roadmap or just switching to Dapper.
My knowledge of the state of the art in *Core is likely out of date, partly because I have stopped trying to keep up. But last I checked, lazy loading wasn't supported, it lacked a find-by-pk method, seemingly with the knock-on effect that it didn't have any sort of identity map or anything resembling real object-graph management. I have live apps running on it, it's mostly fine, but the overriding sense I have of this stuff since the great open sourcing is of barely contained chaos. Starting from scratch today, the feeling might be different, I don't know.
I come from a javascript world so changes are the default for me. Kidding aside, I haven't really felt any pain except some small issues but I started using it in RC already.
Why?
* I am already familiar with it's advantages and quirks. So I can get running faster. The knowledge that I have accumulated in my previous projects will be handy to get going. Time to market is important for both validating the product and avoiding a burnout.
* There is a well defined way to do most common stuff. So you need not experiment and reinvent the most basic stuff. All those get out of the way and I can concentrate on the meat of the problem.
* Many libraries like auth, rest framework are battle tested and most likely tested for security vulnerabilities. if you are taking something to market, it is in everybody's best interest to ensure security is taken care of by the pros. Django is solid in that aspect.
* Though python may not be the most performant language (I have been bit by that a lot in data processing) it is still fast enough for websites with normal loads (which is 99.999% of today's websites).
* If I do have a performance bottleneck, there are lessons from pioneers on how to optimize it.
For me, django fits all these needs. For you it might be Rails, Node, Play or Phoenix. I used to want to learn Phoenix and Play.
But I realized it is a no-win situation when you mix a brand new tech with brand new product.
Now I reach out to new tech only if it fixes a sore need that my existing toolkit cannot handle.
For example, I am looking into webpack and purifycss, because django does not have the necessary functionality to trim the fat in bloated CSS, while Node stack excels.
If I work on a interaction heavy front-end, I might reach for vue or react, and that too only if I really need it.
Else, I am quite happy with django/vanilla-javascript/sass/bootstrap(for prototyping)