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.
Backend: Rails|Phoenix
Database: PostgreSQL
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
I think we meant the same thing.
Bad code is bad; in any language or framework.
Don't blame the knife (in this case React/Redux or w/e), blame the person wielding it.
Agreed, this is a good example.
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.
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?
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.
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.
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 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.
* 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.
Technology is a means to and end for me - to get stuff done and to remain marketable.
I have never seen a job listing that wants someone who can do a web backend with F#.
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.
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.
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)?
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?
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.
On the other hand, the client and the server obviously each have their own package.json, with their own dependencies, etc.
Break your applications into separate Node modules and publish them to a private NPM.
Now that I type it out, it sounds like more trouble than it's worth.
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.
What exactly do you hate? (I feel weird liking Spring quite a bit, and would like to get in on the hatin' ...)
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.
And that is just from the top of my head.
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.
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"
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.
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.
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)
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.
This is often a deal-breaker for smaller projects where the whole team is not used to all the tooling.
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.
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 :)
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.
In my case it would be Django + PostgreSQL.
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 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.
Technologies? node.js + express; postgres; react + redux
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.
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.
Frontend: Vue.js or React.
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
Backend: Go (standard library mostly, httprouter, and some homegrown libraries for stuff like dependency injection, configuration etc.)
Frontend: TypeScript (with React and Redux/mobx)
Other than that, I think using something like Kotlin, Swift or Elixir could be interesting in the backend, too.
Elm, Rails, Phoenix, Postgres, React, MobX, Typescript, GraphQL, Apollo, Kotlin, Mojolicious, Sprint Boot, Go, Django, Catalyst, Node, Koa, ReactRouter, Redux, C#, Bootstrap, JQuery, MongoDB, Express, Vuejs, Flask, Swift, Elixir, Cowboy, Plug, Asp.Net, Heroku, Tornado, SQLAlchemy, Celery, Clojure, Ring, Compojure, ClojureScript, Reagent, Knockout, Meteor, Haskell, VanillaJS, ReasonML, Tachyons, Flow, Redis, EventStore, Suave, Python Bottle, Preact, Play (Scala), Sanic, Loopback, Werkzeug, Laravel, AngularJS, EF Core, Dapper, Vert.x
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.
I've only used Mithril.js in those technologies though.
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).
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.
Frontend: Vue.js, ?, ?
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.
For clients: Rails, React+immutability-helper in Javascript, Tachyons+BEM combo, and Postgres. Possibly Flow or TypeScript.
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
Tiny project, Python Bottle.
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).
Otherwise Django.
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.
I'd be really tempted to use Fable's F# -> javascript for the frontend, but I don't know the ins and outs of that yet.
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.
If it's a big project / still not sure of the requirements - django
For the frontend: React
Meteor is smooth. And react makes me feel good.
The client side would depend on the complexity of the user interaction, but the Web part would probably involve React.
- Do I want to use the latest technology?
- Do I want to bootstrap fast?
- Do I want to experiment/learn or do I want to build a business?
Depending on these questions, everyone has to decide on their own. If it would be me, I would take MERN stack (MongoDB, Express, React and Node).
Backend: Node for popularity, Elixir or Haskell to try something new, or Python Flask which I already know.
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
Front end would depend on the project. JQuery for simple things, Vue for website components or single page apps and react for games.
I _do_ believe they'll get there, but it's been painful maintaining apps built with these technologies over the past couple of years.
Frontend: vuejs or react with ssr on both
Db: Postgres
Frontend: jQuery and Bootstrap