If it's my call, Rails since 2005 because it was easier than Java and much quicker to deliver. It still is.
If it's customers call, I used Node (as sw architect), Django, Flask, Web2py. All of them are less opinionated than Rails, which IMHO is bad because any project can be different and it costs time to get on board.
Django. I like the "batteries included" aspect. Flask and Sinatra are fun, but I wind up spending more time than I'd like stitching authentication etc together instead of building the project.
I used Node and Loopback.js for my last project (massive project). It was great in the sense that it helped us avoid writing lots of boilerplate, but the ORM and the "current context" module were a constant source of frustration.
Now I'm working on a project with a smaller scope and I'm simply using express.js and knex.js, no ORM. I love the simplicity and level of control I have. It's liberating not to have to guess what the ORM is doing to my data between my code and the DB layer.
Have been newly playing around with this: Modular SPA in either Angular 2 or Webpack with a separate API backend in Go. Easy to test either in isolation or integrated.
Merry christmas! For me it's Django for around 5 years. I use it for both personal and work projects for all the following reasons (they are well known but repetition is never bad):
* A great (really great) orm
* Best documentation I've ever seen in a project
* Predictable, no magic
* Easy to start but very powerful forms
* Great community, positive attitude, always willing to help
* Batteries included and, for anything missing, lots of add-ons (in the form of apps) for all your needs
* It's in python and supports both 2 and 3
* Good i18n support (english is not my primary language)
* Good templating
* MVT (model view template) architecture works great, especually after you switch to CBVs
* Great support for REST (through django-rest-framework)
* Easy and to-the-point project configuration supporting multiple deploys (development, production etc) and non-commited to vcs settings
I've tried other frameworks in the past but I've always stuck in a missing feature or just wanted to do things in the django way.
I have done little Wordpress development (just some plugin for a prototype that my company wanted). But I don't see anything that prevented it from being used to develop a web application since the theme/plugin system seems to fulfill everything. Django also describes itself as a CMS platform on their website so I kind of thought they are comparable.
Just wanted to make sure I know what I'm getting before I jumps in further into either Wordpress or Django :D
Wordpress is technically capable of being used to build large apps, but, you're going to be rolling your own everything. Whereas a framework, is, well, a framework that has standardized and cleanly extensible ways of doing core functionalities X, Y, and Z.
Wordpress is old, and they've built up a shit-ton of technical debt for the sake of BC. To put it bluntly, it's not a pleasure to work with, at all. On the up side, something like 20% of the surface net runs on Wordpress. There's a huge market for WP skills, and it's got enormous mindshare amongst non-technical types. If you want to invest effort in WP, do it because of the adoption metrics; if you're more technically oriented, pick Django (or Laravel/Symfony if PHP is more your speed).
Well, wordpress is a cms that, through custom work, can be used as a web framework (ie you can built other, non-cms, things with it). Django is a web framework that can be used to build a cms.
Actually there are some great cms built on top of django, for example django-cms or wagtail!
If you start from scratch and want to build a simple cms it will be easier to do it with wp, if ofcourse you tolerate php - some people won't use php for reasons that should be well known to hn readers. However, for any other web development I recommed using django (or another normal web framework).
Using wp to build non-cms stuff reminds me the "when your only tool is a hammer everything looks like a nail" argument! You may use your hammer to cut (break) wood but using your saw would be easier and safer!
I've seen that line of thinking with newer devs who don't understand the right tool for the job. Unless your client specifically wants a custom solution for a custom purpose, you will spend the first week writing a CMS in Django and the next 20 recreating .1% of WP's functionality because you didn't anticipate the full list of client's needs correctly.
If you're tied to wordpress, I'd take a look at laravel it's built in php, has the largest community as far as PHP frameworks go, and you can literally build anything, and incorporate packages from packagist, etc... Wordpress is slow, has a HUGE codebase and you can't really control it as granularly as you can a fresh laravel app.
Django is a framework, Wordpress is a CMS. Django aims to be able to build pretty much any web application, Wordpress aims to make it easy to add and display content.
I'd use Wordpress when building simple websites that serve as landing pages or blogs. If the main use for the site is showing some basic static info that never changes or the owner coming in, writing a few articles and clicking save, then Wordpress might be a good fit.
I'd use Django when building more complex websites and web applications where a CMS just doesn't fit due to the complexity of the logic, functionality or data. For example you might build an inventory management system with Django since it can have complex business logic and the data doesn't really fit a blog format. You might build an online store with Django, since you need to model and handle logic for products, inventory, payments, customers and such.
I've always been curious as to how you structure your models in Django.
I'm building a personal project in Tornado and MongoExpress, and the only thing I can see about structuring my models is to put all of them in one file called models.py
I'm used to the RoR way of doing things, so this seems very counter-intuitive to me.
In addition, whenever I try to break the classes into different files, I'm not sure of where to store my DB connection logic, and how to ensure that all models are accessible from the controllers.
You can make `models` a package, where `models/__init__.py` just imports models from the package's modules (`models/thingamabobs.py` and ` from .thingamabobs import Thingamabob`).
Also, you shouldn't need to worry about database connection logic in Django unless you're doing something very specific.
Depending on the situation, I think it's usually better to seperate the models to different apps instead of using a single app with a models.py-package. This way you'll have seperate views, forms, urls, admin, templates etc.
For common functionality (ie an abstract model or a mixin that is used/inherited by multiple models/views) I like to add another django app named common or core that is used by the other apps.
I'm using Tornado, not Django. I just want to use Django as an inspiration for my app structure.
The problem with Tornado is that it doesn't come with an in-built ORM like Django, which means I need to actually create a connection to the Mongo instance I'm using. Hence the confusion. Python doesn't have initializers like Ruby does (that I know of).
I use Phenomic to generate static React websites. Served from Amazon S3/CloudFront, with Serverless (Lambda/API Gateway) for REST APIs as needed.
This appears to be the cheapest and most reliable and autoscalable way to build web apps, even though the tooling could still be streamlined. I also believe that React and JavaScript in general currently have the best ecosystem, so it's easy to find anything you need (tools, libraries, components, problem solutions).
Django, mostly. I like its batteries included approach and its maturity. I've found it's a great tool for many jobs. Every now and then I'll use something smaller, like Flask or Falcon, but as soon as I need an ORM, or auth, I use Django.
I've also used Phoenix a few times now and have been enjoying it. But I know Python much better than I do Elixir, so I skew towards that.
Hey - just curious - I love the Angular CLI, but since they hide the main webpack config I'm wondering how you deal with customizing that? Heard a few approaches, I'm interested in your solutions (if any).
net/http: The stdlib package is robust and I find myself productive working with the provided APIs.
gorilla/mux router instead of the default servemux.
I use go-kit https://gokit.io/examples/stringsvc.html for most production apps I write. I use go-kit because it provides a clean separation of decode/encode logic from the actual business logic of my application and includes some great packages for instrumentation, logging rate-limiting and bunch of other concerns.
On the frontend side, I prefer to write clients in Elm.
Rails - because Ruby is easy to learn, especially for beginners and you get great, custom things done in no time. Also Rails forces you in some patterns that make sense in my opinion. Testing is also fun.
I don't agree: from my experience (~9years of full time Ruby/Rails, including teaching and coaching) Ruby is not easy to learn, at least if you want to know what you're really doing. And Rails, as is, promotes several anti-patterns that will mess your app after 6+ months. Fat models are a bad practice, models as form objects are a bad practice, developing uour business logic almost totally on top of models is wrong. That's why some experienced Ruby devs are moving away from those anti-patterns by promoting real object oriented approaches: for some good examples check hanami web framework, rom-rb and Trailblazer.
I'm operating with Express on one end with React on the other. The big difference with this setup is GraphQL in the middle. It is a huge help to making sense of data flow, what with the strictly typed schema and the built in subscription model. I've also engineered my own event sourcing/CQRS framework with the intention of expanding the app with micro services eventually, but it's just one server node for now.
Yes, I talked with a few Python devs and they all envied the package management of Node.js.
Funny thing is, NPM is fun at the start, but in long running projects it's really bad. I mean, it feels like a huge step forward coming from PHP (where I didn't have any package manager back in the days) or Python (where pip seems to be a bit clunky) but it still could be better. Hopefully Yarn changes that.
Having the same language on front and backend is good for my own projects.
But it really is a problem on commercial projects I work on, because the people in charge tend to mix developers. I wouldn't consider myself a back-end developer, but was forced to write multiple APIs, because "it's just JavaScript, right?!"
Rails because I've been using it for a lonnnng time. Last month I got a subscription to stationcode.net and it's been handy for code gen. Talked to the owner and he said more is on the way.
Spring with Spring Boot in Java. Batteries included and easy to setup and get going. A statically typed language to catch errors at compile time. Easy to deploy by building an uberjar. Great dependency management and builds with Gradle/Maven and built-in support for pretty much any common database and message queue.
nowdays you don't use xml to define your beans so most of the things are compile checked. granted some things are happening only at runtime which is a whole point of DI :-)
All the dependency injection and spring setup is done at startup, so you won't have any of those errors during the life cycle of the app. Spring boot with spring data rest makes it so easy to create very strong REST APIs easily.
Source: I've done a lot of demos, presentations and trainings on Spring Boot, including at SpringOne in Vegas last summer.
Agreed that there is lots of magic going on in the DI container but as it resolves everything on startup most issues there are still caught during the development process.
Catching errors at compile time is mostly about avoiding subtle bugs like object.property vs object.propery or adding a parameter to a method and forgetting to update 1 caller
Front-end: Bootstrap + (Three.js or Snap.svg) + ws
I create browser-based interactive UIs for controlling Arduino robots. I like to keep the web stack as simple as possible because the tricky/hard parts are in the robotics layer.
Spring Framework on backend -> ultra power and speed, especially if you go cloud and microservices route
Angular 1 on fronted -> easy enough to learn quickly, feels good to use and is powerful with great support and add-ons. Looking to start learning angular2
Will learn elixir and phoenix for some realtime and websocket stuff.
> Spring Framework on backend -> ultra power and speed, especially if you go cloud and microservices route
As long as you're happy with your microservices needing at least a gigabyte of memory each. My current project has ~15 Spring microservices, and with two instances each and blue-green deployment, we need 60 gigabytes just to be in business.
* Largest/most solid ecosystem of 3rd party packages (except possibly rails) that does everything from authentication, CMS, CRM, ecommerce, comments, anti-spam, caching, REST APIs, file uploads, admin, emails, authorization, regular authentication, social media authentication, admin plugins, data import/export plugins, etc. etc. etc. meaning that there's an awful lot of code that you don't have to write.
* An opinionated core which means consistency which means that those 3rd party packages that all use caching, ORM, admin forms, etc. fit together and you don't have stuff like CMS plugins that just decided to use mongo for the hell of it (http://quokkaproject.org/) or 3rd party plugins forced to support 3 or more different storage backends (https://pythonhosted.org/Flask-Security/).
* Python is a terse and readable language with (relatively) strict runtime type checking and a huge ecosystem outside of just web stuff.
121 comments
[ 2.9 ms ] story [ 94.1 ms ] threadIf it's customers call, I used Node (as sw architect), Django, Flask, Web2py. All of them are less opinionated than Rails, which IMHO is bad because any project can be different and it costs time to get on board.
I've been using it for over a year, and it is fantastic. In fact, I've just started my own personal fork to streamline some things to my dev process.
Anyway, one of the many nice freebies is a full user registration / password reset / oauth solution baked in.
Also, I should mention this is created my the same guy who wrote "Two Scoops of Django".
https://github.com/pydanny/cookiecutter-django
Now I'm working on a project with a smaller scope and I'm simply using express.js and knex.js, no ORM. I love the simplicity and level of control I have. It's liberating not to have to guess what the ORM is doing to my data between my code and the DB layer.
* A great (really great) orm
* Best documentation I've ever seen in a project
* Predictable, no magic
* Easy to start but very powerful forms
* Great community, positive attitude, always willing to help
* Batteries included and, for anything missing, lots of add-ons (in the form of apps) for all your needs
* It's in python and supports both 2 and 3
* Good i18n support (english is not my primary language)
* Good templating
* MVT (model view template) architecture works great, especually after you switch to CBVs
* Great support for REST (through django-rest-framework)
* Easy and to-the-point project configuration supporting multiple deploys (development, production etc) and non-commited to vcs settings
I've tried other frameworks in the past but I've always stuck in a missing feature or just wanted to do things in the django way.
Or am i wrong?
PS... Django <3
Just wanted to make sure I know what I'm getting before I jumps in further into either Wordpress or Django :D
Wordpress is old, and they've built up a shit-ton of technical debt for the sake of BC. To put it bluntly, it's not a pleasure to work with, at all. On the up side, something like 20% of the surface net runs on Wordpress. There's a huge market for WP skills, and it's got enormous mindshare amongst non-technical types. If you want to invest effort in WP, do it because of the adoption metrics; if you're more technically oriented, pick Django (or Laravel/Symfony if PHP is more your speed).
What?
Django website have "The Web framework for perfectionists with deadlines".
You can compare WP with Drupal or Joomla. With Django you can build you own CMS.
Sorry, one of the first links when I searched for Django on Bing (currently in China) is django-cms.org.
Actually there are some great cms built on top of django, for example django-cms or wagtail!
If you start from scratch and want to build a simple cms it will be easier to do it with wp, if ofcourse you tolerate php - some people won't use php for reasons that should be well known to hn readers. However, for any other web development I recommed using django (or another normal web framework).
Using wp to build non-cms stuff reminds me the "when your only tool is a hammer everything looks like a nail" argument! You may use your hammer to cut (break) wood but using your saw would be easier and safer!
I'd use Wordpress when building simple websites that serve as landing pages or blogs. If the main use for the site is showing some basic static info that never changes or the owner coming in, writing a few articles and clicking save, then Wordpress might be a good fit.
I'd use Django when building more complex websites and web applications where a CMS just doesn't fit due to the complexity of the logic, functionality or data. For example you might build an inventory management system with Django since it can have complex business logic and the data doesn't really fit a blog format. You might build an online store with Django, since you need to model and handle logic for products, inventory, payments, customers and such.
I'm building a personal project in Tornado and MongoExpress, and the only thing I can see about structuring my models is to put all of them in one file called models.py
I'm used to the RoR way of doing things, so this seems very counter-intuitive to me.
In addition, whenever I try to break the classes into different files, I'm not sure of where to store my DB connection logic, and how to ensure that all models are accessible from the controllers.
Ideas?
Also, you shouldn't need to worry about database connection logic in Django unless you're doing something very specific.
For common functionality (ie an abstract model or a mixin that is used/inherited by multiple models/views) I like to add another django app named common or core that is used by the other apps.
The problem with Tornado is that it doesn't come with an in-built ORM like Django, which means I need to actually create a connection to the Mongo instance I'm using. Hence the confusion. Python doesn't have initializers like Ruby does (that I know of).
This appears to be the cheapest and most reliable and autoscalable way to build web apps, even though the tooling could still be streamlined. I also believe that React and JavaScript in general currently have the best ecosystem, so it's easy to find anything you need (tools, libraries, components, problem solutions).
I've also used Phoenix a few times now and have been enjoying it. But I know Python much better than I do Elixir, so I skew towards that.
net/http: The stdlib package is robust and I find myself productive working with the provided APIs. gorilla/mux router instead of the default servemux.
I use go-kit https://gokit.io/examples/stringsvc.html for most production apps I write. I use go-kit because it provides a clean separation of decode/encode logic from the actual business logic of my application and includes some great packages for instrumentation, logging rate-limiting and bunch of other concerns.
On the frontend side, I prefer to write clients in Elm.
Frontend: None/jQuery for simple sites, Angular 1 (older projects) and Vue 2 (newer) for apps
My 2cents reply.
The pros:
- programming the same language in the frontend and the backend (which becomes a big deal when you do serverside rendering of react components)
- for some reason AWS and Google App Engine have very good nodejs support
- very fast io
- very fast iteration time, faster than python
The cons:
- the lack of quality libraries and standards. With flask there are well known, well tested libraries for every use case. Not so with nodejs.
- javascript, which isn't really a big deal
Funny thing is, NPM is fun at the start, but in long running projects it's really bad. I mean, it feels like a huge step forward coming from PHP (where I didn't have any package manager back in the days) or Python (where pip seems to be a bit clunky) but it still could be better. Hopefully Yarn changes that.
Having the same language on front and backend is good for my own projects.
But it really is a problem on commercial projects I work on, because the people in charge tend to mix developers. I wouldn't consider myself a back-end developer, but was forced to write multiple APIs, because "it's just JavaScript, right?!"
Catching errors at compile time is mostly about avoiding subtle bugs like object.property vs object.propery or adding a parameter to a method and forgetting to update 1 caller
Front-end: Bootstrap + (Three.js or Snap.svg) + ws
I create browser-based interactive UIs for controlling Arduino robots. I like to keep the web stack as simple as possible because the tricky/hard parts are in the robotics layer.
Angular 1 on fronted -> easy enough to learn quickly, feels good to use and is powerful with great support and add-ons. Looking to start learning angular2
Will learn elixir and phoenix for some realtime and websocket stuff.
As long as you're happy with your microservices needing at least a gigabyte of memory each. My current project has ~15 Spring microservices, and with two instances each and blue-green deployment, we need 60 gigabytes just to be in business.
* Very little magic in the core.
* Well architected and loosely coupled (in spite of its sometimes-rep it's not actually monolithic: http://olifante.blogs.com/covil/2010/04/minimal-django.html)
* Largest/most solid ecosystem of 3rd party packages (except possibly rails) that does everything from authentication, CMS, CRM, ecommerce, comments, anti-spam, caching, REST APIs, file uploads, admin, emails, authorization, regular authentication, social media authentication, admin plugins, data import/export plugins, etc. etc. etc. meaning that there's an awful lot of code that you don't have to write.
* An opinionated core which means consistency which means that those 3rd party packages that all use caching, ORM, admin forms, etc. fit together and you don't have stuff like CMS plugins that just decided to use mongo for the hell of it (http://quokkaproject.org/) or 3rd party plugins forced to support 3 or more different storage backends (https://pythonhosted.org/Flask-Security/).
* Python is a terse and readable language with (relatively) strict runtime type checking and a huge ecosystem outside of just web stuff.