Ask HN: What web framework do you use? Why did you choose it?
Merry Christmas!
121 comments
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.
* 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'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.
Ideas?
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?
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.
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.
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).
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've never developed using Django. How does it compare to Wordpress? Or under what situation is it preferable to Wordpress?
But you cant compare Wordpress with Django, Wordpress is not a web framework is just a CMS for blogs.
Or am i wrong?
PS... Django <3
Or am i wrong?
PS... Django <3
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
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).
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!
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.
>Django also describes itself as a CMS platform on their website so I kind of thought they are comparable.
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.
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.
D:
Sorry, one of the first links when I searched for Django on Bing (currently in China) is django-cms.org.
Sorry, one of the first links when I searched for Django on Bing (currently in China) is django-cms.org.
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'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 pretty sure I'll be minority here, but I don't use any backend framework for page rendering. All my apps are pure SPAs. They render all the screen content themselves on the client and only query servers for data. I prefer this, because I can simply take any app and deploy it to server just by copying its files. I only need to scale API servers and I don't have think about app scaling, because just single instance of nginx with proper caching setup can handle hundred thousands of clients (serving static resources is cheap and fast). Also you can take same app, package it as cordova and deploy to app/play store (although this can be probably achieved with any other frameworks as well). On the frontend I use combo of react, redux, redux-saga ...
Before I've used backbone, but react with redux is night and day difference. Even you're just starting with js, your apps will be less error prone, because of concept unidirectional flow.
Maybe this is no longer special to react/redux, but I'm really not in the age I can switch frameworks everytime some new stack arrive. React serves me well. And then, there is also react-native, which is 90% same as react so you can reuse what you have learned. Other frameworks don't have this close to native counterpart. (not counting cordova, which allows to use any fw, but performance will never be same as react-native).
Before I've used backbone, but react with redux is night and day difference. Even you're just starting with js, your apps will be less error prone, because of concept unidirectional flow.
Maybe this is no longer special to react/redux, but I'm really not in the age I can switch frameworks everytime some new stack arrive. React serves me well. And then, there is also react-native, which is 90% same as react so you can reuse what you have learned. Other frameworks don't have this close to native counterpart. (not counting cordova, which allows to use any fw, but performance will never be same as react-native).
That API backend is often a Node, Python, RoR webapp. JSON output instead of HTML doesn't make much difference, only the views/templates (pick your framework's name) are different. The other code is the same.
But in some cases a SPA let's you go to a different route to Parse or Firebase backends, or Lambda/Functions. That's different.
But in some cases a SPA let's you go to a different route to Parse or Firebase backends, or Lambda/Functions. That's different.
I am wondering though ... since you are putting all the rendering load on the browser, have you had any issues with that? Slow machines, slow browsers, etc?
That's what I do as well. Except instead of React, I use Redux off the DOM. It prototypes fast and I don't run into any configuration issues
#Baller
ASP.NET MVC, because:
- ASP.NET MVC makes it much easier to keep your domain logic decoupled from the framework. This is in contrast to frameworks like Django who expect you to use their ORM, and to derive your model classes from a framework provided base class.
- It's C#. I know it well, it is common in industry, and it is statically typed. For programs of any real complexity, I find statically typed languages to be much more efficient and pleasant to work with.
Eventually I want to move more in the direction of stronger type systems, but it doesn't seem like there are many jobs out there for Haskell programmers who aren't programming demi-gods.
- ASP.NET MVC makes it much easier to keep your domain logic decoupled from the framework. This is in contrast to frameworks like Django who expect you to use their ORM, and to derive your model classes from a framework provided base class.
- It's C#. I know it well, it is common in industry, and it is statically typed. For programs of any real complexity, I find statically typed languages to be much more efficient and pleasant to work with.
Eventually I want to move more in the direction of stronger type systems, but it doesn't seem like there are many jobs out there for Haskell programmers who aren't programming demi-gods.
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.
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.
Django, because:
* 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.
* 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.
On the frontend: React, MobX, TypeScript
TypeScript, because its a fast compiler and has the best typechecker support and typings collection for existing front-end libraries, so there is almost no need to wrap anything.
React, because its conceptually simple, has wide community support and I get TypeScript's type checking inside the TSX templates too, unlike in Vue and most other frameworks.
MobX, because it needs less boilerplate than Redux, plays better with TypeScript than immutable.js, is really easy to make performant (lots of observer components + computed properties) and its intuitive to developers coming from Angular, knockout or Vue.
On the backend: TypeScript, Node, bluebird, node-sql and PostgreSQL
TypeScript, because it makes it easy to write end-to-end-typechecked programs if the backend language is the same as the frontend. The client and server can both claim to implement the same interface, and then its easy to see if any changes violate that contract. Additionally, server-side rendering with React is simpler.
Node, because its reasonably fast without thinking too much about it. The only pitfall are accidentally cpu-bound tasks, but in practice those are a problem rarely and I'm working on a tool to detect and report them: https://github.com/spion/long-task-detector
Another thing missing in node are better streams. A promise-friendly version of pull-stream would fix that.
Bluebird, because its fast and provides a great debugging experience with long stack traces
PostgreSQL, because it can go very far for many things before you need something else.
node-sql, because its an SQL query builder for node which can be made typesafe with TypeScript, and because query builders often beat ORM spaghetti in performance and maintainability in the long run.
TypeScript, because its a fast compiler and has the best typechecker support and typings collection for existing front-end libraries, so there is almost no need to wrap anything.
React, because its conceptually simple, has wide community support and I get TypeScript's type checking inside the TSX templates too, unlike in Vue and most other frameworks.
MobX, because it needs less boilerplate than Redux, plays better with TypeScript than immutable.js, is really easy to make performant (lots of observer components + computed properties) and its intuitive to developers coming from Angular, knockout or Vue.
On the backend: TypeScript, Node, bluebird, node-sql and PostgreSQL
TypeScript, because it makes it easy to write end-to-end-typechecked programs if the backend language is the same as the frontend. The client and server can both claim to implement the same interface, and then its easy to see if any changes violate that contract. Additionally, server-side rendering with React is simpler.
Node, because its reasonably fast without thinking too much about it. The only pitfall are accidentally cpu-bound tasks, but in practice those are a problem rarely and I'm working on a tool to detect and report them: https://github.com/spion/long-task-detector
Another thing missing in node are better streams. A promise-friendly version of pull-stream would fix that.
Bluebird, because its fast and provides a great debugging experience with long stack traces
PostgreSQL, because it can go very far for many things before you need something else.
node-sql, because its an SQL query builder for node which can be made typesafe with TypeScript, and because query builders often beat ORM spaghetti in performance and maintainability in the long run.
I've tried different JavaScript frameworks. I've seen Backbone, Angular, Knockout, Rx.js, React, Redux, MobX, Rails, Asp.net, Meteor and Django, I've tried almost every popular option to compile/transpile into JS - Coffeescript, Typescript, Livescript, Gorillascript, Fay, Haste, Elm, GHCJS and Babel. I've used Grunt, Gulp, Browserify and Webpack.
Nothing ever made me so happy and so excited as Clojurescript. Things are so simple, so elegant. Code has never been ever before so easy to reason about. Sharing code between backend and frontend became reality. FFI to existing JavaScript code is so natural. Ring, Compojure and Om.Next, Clojure.spec and generative testing, Figwheel, Devcards, Boot-clj. core.async and pattern matching. My goodness. I just don't understand anymore devs, choosing to struggle with other stacks. Everytime when I try to compare - CLJS feels just a few steps ahead.
could you please point me towards some good resources to get started with clojurescript?
There are plenty. https://github.com/magomimmo/modern-cljs Is a good one. You probably need to read one of the books on Clojure. I wouldn't recommend starting with "Joy of Clojure". It is definitely "must read', but do it later, after you learn some basics.
Second "The Joy of Clojure"
I use Django for my projects and I prefer it over Java Frameworks although I am an ex-Java developer. Python/Django feels quicker and lighter than Java/Spring stack which result in productivity boost. I explained in detail why I use Django on my story https://hackernoon.com/why-i-chose-django-over-java-framewor...
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.
You might want to look At cookiecutter Django [1], which is an excellent boilerplate generator for production-ready Django apps.
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
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
Yes! Danny and Audrey do fantastic work.
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.
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.
Phoenix, for a lot of the same reasons I used to have for Rails including:
* Fast development cycle
* Conventional
* Great community
* Good ecosystem of libs to take advantage of
* "Magic" (although Phoenix's magic is much different)
And some of it's own like
* Great concurrency (which feels like a free win over Rails)
* Functional programming
* How Ecto, the ORM works
* How simple it is, even with the "magic" included.
* How assets are handled, via a thin layer to Brunch, Webpack, or other JavaScript asset bundler
There's a few more, but I think those are a lot of the major talking points.
* Fast development cycle
* Conventional
* Great community
* Good ecosystem of libs to take advantage of
* "Magic" (although Phoenix's magic is much different)
And some of it's own like
* Great concurrency (which feels like a free win over Rails)
* Functional programming
* How Ecto, the ORM works
* How simple it is, even with the "magic" included.
* How assets are handled, via a thin layer to Brunch, Webpack, or other JavaScript asset bundler
There's a few more, but I think those are a lot of the major talking points.
I'm starting a project in Phoenix in the next week or so and am excited. I have done little web work and what I have done was using ASP.NET MVC so it is different than what I'm used to.
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.
My 2cents reply.
My 2cents reply.
[deleted]
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.
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.
Meteor - It's a fullstack framework that let's you write JavaScript both on the front- and backend. It let's you choose what you want to use for your frontend (e. g. React, Vue, Blaze, Angular...). Best feature: It's realtimeness.
And right now I'm trying Laravel (PHP). It has a great documentation. I like the ORM and that it's easy to use. I want to build an API with it and consume it with a SPA and react.
And right now I'm trying Laravel (PHP). It has a great documentation. I like the ORM and that it's easy to use. I want to build an API with it and consume it with a SPA and react.
Is using Javascript on the back end really a positive thing? There isn't really a choice on the front end.
This is the main criticism of Javascript on the backend. People didn't have choice on the frontend (and largely still don't unless you transpile), and for some reason people thought it was a good idea to bring this "language of necessity" to the backend.
There are plenty of better solutions like PHP, Ruby or Perl.
There are plenty of better solutions like PHP, Ruby or Perl.
Up until recently, I'd choose Node over PHP
I think the reason for bringing JS to the backend is that you have to learn it anyway for the front-end, so why not save developers from having to learn two languages. One language = easier learning curve. At least in theory, it sounds reasonable.
you might want to try lumen(larvel minus view part) created by the same author since you say you want to build API's
I'm curent developing a rest api in Laravel. I tried lumen before switching but configuring just some basic packages to work with lumen (Dingo, JTW) was such an headache that I moved to laravel.
I don't know how some of you guys have the time to get real experience with dozens of frameworks. I've only really used a few. Out of what I've used, Ruby is my favorite language, and I use Rails for anything with a database, and Sinatra for anything without. Thoughts:
ActiveRecord is the best ORM I've used so far. You don't need a ton of boilerplate or config to get up and running with it. It supports all of the basic stuff, and seems to do it well, and for more complex stuff, it makes it easy to drop down to SQL instead of trying to put a ton of ugly glue on top of doing complex stuff in SQL.
I like the way Rails has commands to output the whole route table, and the whole middleware stack it's using. Along those lines, I like the way the router works, and the way that most of the advanced functionality is neatly tucked into middleware that you can add or remove.
I like the flexibility of being able to plug in a bunch of JS processors, template languages, CSS processors, etc.
I like how much functionality you can add by just throwing a gem in the Gemfile, and the Bundler system does a good job of tracking gem versions to keep all environments consistent.
Competitors I've used:
ASP.NET MVC: Too much functionality is buried in either the IIS server or other libs that you can't debug into easily. I don't like the routing much - there's too many ways to specify routes, all of which seem unclear, and there's no single place to see all of your routes as the framework sees them and where they all route to. Plus the often-incomprehensible method argument matching. MVC tries to be all clever in deserializing arbitrary JSON and XML into .NET objects, which is handy when it works, but good luck debugging what happened when it doesn't work, and good luck if you just want it give you the freakin' request data as a plain old string. I've spent hours smashing my head against trying to get MVC to actually route my requests to the intended controller methods and do something reasonable with the request data. And I still haven't made sense of Entity Framework.
I've also toyed with things in Java, NodeJS/Express, and a few other things, but I don't feel like I've really used them enough to offer an opinion, besides noting that the "common knowledge" of Java being verbose and over-complex, and NodeJS/Express being too bare bones seem accurate.
ActiveRecord is the best ORM I've used so far. You don't need a ton of boilerplate or config to get up and running with it. It supports all of the basic stuff, and seems to do it well, and for more complex stuff, it makes it easy to drop down to SQL instead of trying to put a ton of ugly glue on top of doing complex stuff in SQL.
I like the way Rails has commands to output the whole route table, and the whole middleware stack it's using. Along those lines, I like the way the router works, and the way that most of the advanced functionality is neatly tucked into middleware that you can add or remove.
I like the flexibility of being able to plug in a bunch of JS processors, template languages, CSS processors, etc.
I like how much functionality you can add by just throwing a gem in the Gemfile, and the Bundler system does a good job of tracking gem versions to keep all environments consistent.
Competitors I've used:
ASP.NET MVC: Too much functionality is buried in either the IIS server or other libs that you can't debug into easily. I don't like the routing much - there's too many ways to specify routes, all of which seem unclear, and there's no single place to see all of your routes as the framework sees them and where they all route to. Plus the often-incomprehensible method argument matching. MVC tries to be all clever in deserializing arbitrary JSON and XML into .NET objects, which is handy when it works, but good luck debugging what happened when it doesn't work, and good luck if you just want it give you the freakin' request data as a plain old string. I've spent hours smashing my head against trying to get MVC to actually route my requests to the intended controller methods and do something reasonable with the request data. And I still haven't made sense of Entity Framework.
I've also toyed with things in Java, NodeJS/Express, and a few other things, but I don't feel like I've really used them enough to offer an opinion, besides noting that the "common knowledge" of Java being verbose and over-complex, and NodeJS/Express being too bare bones seem accurate.
Have seen Sequel? Once I tried it I can't stop fantasizing about replacing activerecord from all my rails projects.
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.
I don't think you can catch errors compile time with all the magic reflection Spring uses, such as resolving services, injected values etc.
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
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
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 :-)
For us not-so-smart-people who liked MS Access: PHPRunner.
From a programming standpoint, it's the worst thing in the world: A Windows GUI thing that builds PHP apps and it's closed source.
From a get-stuff-done standpoint: I made a tracking web-app for large expensive tools that knows about Customers, Project Locations, Scheduling, Work Orders and Invoicing - it will grab a customer signature and email them the receipt. I did it in about four hours.
It has hooks in the system for those that actually know what they're doing (not me) to embed PHP code at important points.
From a programming standpoint, it's the worst thing in the world: A Windows GUI thing that builds PHP apps and it's closed source.
From a get-stuff-done standpoint: I made a tracking web-app for large expensive tools that knows about Customers, Project Locations, Scheduling, Work Orders and Invoicing - it will grab a customer signature and email them the receipt. I did it in about four hours.
It has hooks in the system for those that actually know what they're doing (not me) to embed PHP code at important points.
Interesting. Looking at it, it seems it is a decent solution for building MVP's for those dumb clients that want stuff done in a weekend. Does it generate PHP 7? Good PHP 7?
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.
I recently switched to nodejs from flask and I like it but there are some issues
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
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
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?!"
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?!"
Django - I am learning and I think it is easier to learn. It is much easier than php.
PHP Symfony for large backend application. I rarely use front-end
Pros:
- Well structured
- Lots of bundles
- Large community
- Doctrine and Monolog support out of the box
Cons:
- Steep learning curve in the beginning
I've mainly used Ruby/Rails from ~2008 to ~2015 both for work and side projects/prototypes, then I totally switched to Elixir/Phoenix for almost all my stuff. I still use Ruby/Rails for some works (where/when I can't use Elixir due to some constraint).
I've found that Elixir and Phoenix have an awesome community and a fast-growing ecosystem. The language is very clean and I can solve problems in a cleaner and faster way. It has all the tools I need and runs on a simple but powerful virtual machine with stunning performance and easy deployement. I can use websockets and async jobs without running external processes/daemons and thanks to brunch (or webpack, it depends) I have a powerful toolchain for frontend. Speaking about frontend, I've recently moved from React to VueJS, it's a very decent compromise between React and Angular: simple like React, with features and concepts similar to Angular.
I've found that Elixir and Phoenix have an awesome community and a fast-growing ecosystem. The language is very clean and I can solve problems in a cleaner and faster way. It has all the tools I need and runs on a simple but powerful virtual machine with stunning performance and easy deployement. I can use websockets and async jobs without running external processes/daemons and thanks to brunch (or webpack, it depends) I have a powerful toolchain for frontend. Speaking about frontend, I've recently moved from React to VueJS, it's a very decent compromise between React and Angular: simple like React, with features and concepts similar to Angular.
I've been using Tornado for about a year now, and I'm incredibly happy with it. Here is some of the background and reasons for that:
* I had been using Django for some 5-6 years, until I finally realised that I'm not happy with many of its architectural decisions -- global singleton settings, the way views are organized, the way it's organised around the ORM and everything. It provides a lot of tools, but if you don't need some of them them tough luck, you still get to lug them around and it's not helping you find any workarounds.
* I've learned to prefer frameworks that don't get in your way and allow you to choose any individual components for individual needs. I've worked with Flask and Bottle, which are great but sometimes go too far in the opposite direction, focusing so much on simplicity that more complex tasks require jumping through a different set of loops (I'm looking at you, Blueprints).
* Tornado's Web framework is successfully avoiding both types of traps, and it gives you the ability to develop simple apps -- say, a REST API -- quite easily and naturally, at the same time giving you the room to grow your creation naturally as needed. I've briefly tried Falcon, which follows a similar philosophy, and is IMO a great alternative.
* Tornado, however, is not just a Web framework -- it actually provides an amazing set of tools which can be easily in your app or even without any relation to a Web app. And the best part of the toolset is its asynchronous networking capabilities, which provided things like coroutines long before they existed in Python -- and now you can combine the two in a same app.
* Last but not least, Tornado provides an amazing, production-ready, non-blocking HTTP server. Most of the other frameworks make a point of not using their built-in servers in production, instead advising you to plug your app into a WSGI server like uWSGI or gunicorn; you can do that with Tornado too, but if you don't your app can process requests asynchronously, preventing slower requests from blocking faster ones.
* I had been using Django for some 5-6 years, until I finally realised that I'm not happy with many of its architectural decisions -- global singleton settings, the way views are organized, the way it's organised around the ORM and everything. It provides a lot of tools, but if you don't need some of them them tough luck, you still get to lug them around and it's not helping you find any workarounds.
* I've learned to prefer frameworks that don't get in your way and allow you to choose any individual components for individual needs. I've worked with Flask and Bottle, which are great but sometimes go too far in the opposite direction, focusing so much on simplicity that more complex tasks require jumping through a different set of loops (I'm looking at you, Blueprints).
* Tornado's Web framework is successfully avoiding both types of traps, and it gives you the ability to develop simple apps -- say, a REST API -- quite easily and naturally, at the same time giving you the room to grow your creation naturally as needed. I've briefly tried Falcon, which follows a similar philosophy, and is IMO a great alternative.
* Tornado, however, is not just a Web framework -- it actually provides an amazing set of tools which can be easily in your app or even without any relation to a Web app. And the best part of the toolset is its asynchronous networking capabilities, which provided things like coroutines long before they existed in Python -- and now you can combine the two in a same app.
* Last but not least, Tornado provides an amazing, production-ready, non-blocking HTTP server. Most of the other frameworks make a point of not using their built-in servers in production, instead advising you to plug your app into a WSGI server like uWSGI or gunicorn; you can do that with Tornado too, but if you don't your app can process requests asynchronously, preventing slower requests from blocking faster ones.
Back-end: Node.js + Express + ws + Johnny-Five
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.
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.
For hobby stuff I use Ring with Compojure (or bidi) on the server side and re-frame on the client, so Clojure(script) all the way. Still learning web dev in clojure, came from years of rails and some JEE before that. Hope to start using it professionally in 2017.
For non-bleeding-edge projects, I use Rails, because I'm comfortable with it, and love the echo-system. I find I'm most productive in it when I need to deliver fast.
For newer/bleeding-edge I use Go with Vue.js on the frontend. I like Vue's simplicity and community - It's the only frontend framework that made sense to me and I was able to be productive in in a relatively short time. Go on the backend because it's clean, fast and stable.
At the risk of self-promotion, check out my weekend project - https://github.com/zohararad/bee-gorm-graphql (Golang on the backend, Vue on the frontend)
For newer/bleeding-edge I use Go with Vue.js on the frontend. I like Vue's simplicity and community - It's the only frontend framework that made sense to me and I was able to be productive in in a relatively short time. Go on the backend because it's clean, fast and stable.
At the risk of self-promotion, check out my weekend project - https://github.com/zohararad/bee-gorm-graphql (Golang on the backend, Vue on the frontend)
I have recently switched from flask + psycopg to sanic + asyncpg for my http APIs. I'm pretty happy with the results and the transition was pretty smooth, it only took a day each to switch out each and go from fully synchronis to fully asynchronous.
I'm considering switching from Flask to Sanic, but I worry about Sanic's ecosystem. For example, I'm using these Flask plugins: Flask-Cache, Flask-Compress, Flask-DebugToolbar, Flask-DebugToolbar-LineProfilerPanel, Flask-Login, Flask-WTF.
Node.js + Express+ SocketIO on the server side with Angular on the front end.
For my apps I have a loose framework that I built over the years with pub-sub model between client and server and similar within the server side code itself.
Node was an easy choice since I love JS and having only one language reduces cognitive load a lot.
Express is a well known mature framework, similar with SocketIO even though it has some warts.
Angular is similarly a mature framework which I use in s quite simple manner to tie pieces of code together so i haven't had any performance problems. And since I work in enterprise it is still very a very popular choice and none of the issues with strange licensing or complicated transpiling build systems.
For my apps I have a loose framework that I built over the years with pub-sub model between client and server and similar within the server side code itself.
Node was an easy choice since I love JS and having only one language reduces cognitive load a lot.
Express is a well known mature framework, similar with SocketIO even though it has some warts.
Angular is similarly a mature framework which I use in s quite simple manner to tie pieces of code together so i haven't had any performance problems. And since I work in enterprise it is still very a very popular choice and none of the issues with strange licensing or complicated transpiling build systems.
Django for work, a variety of (popular) tools for random projects.
I write in Go, and use the following libs:
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.
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.
Play Framework[1] (in Scala, its also available in Java):
* I like programming in Scala
* Play is built on Akka[2] (a lot of people use Akka instead of using a full-on framework)
* Great testing suite
* The documentation is very good
* Most components of the framework can be used separately, for example Play has a good asynchronous http client that I use in other projects
[1]: https://www.playframework.com [2]: http://akka.io
[1]: https://www.playframework.com [2]: http://akka.io
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.
I used to be J2EE guy and I have gone through nearly all J2EE Frameworks namely struts, tapestry, wicket and JSF ( all flavours) -- and I hated all of them. The problem with these frameworks is that you had to learn so many useless details of the framework , such as ui component lifcycle and events, that were of no use should you choose to go on to another project which used a different framework.
I have settled on ReactJS with Clojure REST or Spring REST. React knowledge and REST knowledge is portable across projects and jobs.
I have settled on ReactJS with Clojure REST or Spring REST. React knowledge and REST knowledge is portable across projects and jobs.
It's really sad how bad the Java web ecosystem has been. JSP was pretty good when it came out, but there was zero standards-based movement on the objects behind it (controllers, binding, helpers) for years. When it did come, it was JSF, which is like some giant monument to the mistakes of the 90s. There have been a bunch of third-party controller frameworks, but all just different enough that learning doesn't travel well. We're finally getting an MSc framework now, just as it's finally going out of fashion.
I've used Pyramid for the last 5 years to deploy highly available http api (>500K unique users daily).
- Super Modular, easy to achieve separation of concern;
- Powerful routing system;
- Consistent API;
- Elegant;
- Performant;
- Pyramid folks are super nice and super helpful on irc
- Super Modular, easy to achieve separation of concern;
- Powerful routing system;
- Consistent API;
- Elegant;
- Performant;
- Pyramid folks are super nice and super helpful on irc
asp.net core, I have tried a lot of frameworks and stacks from Laravel to Go and I have never been this productive on anything else.
Using standard asp.net, just webapi/entity framework, and Aurelia for the front end at work. Developers are very productive on this.
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).
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).
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.
ASP.NET MVC, on .NET Core.
It's super fast, C# is mad fun to develop in, and now it runs on Linux. We've even started deploying production sites to CentOS-based VPSes.
It's super fast, C# is mad fun to develop in, and now it runs on Linux. We've even started deploying production sites to CentOS-based VPSes.
Do you self-host them in Linux? Or are you using something like nginx reverse proxy?
We use nginx as a reverse proxy. It was a little bit of a pain to set up with all the SSL stuff at first, especially since we wanted to keep hosting some Wordpress blogs on URLs nested within the .NET infrastructure, but overall it's worked out well now that it's up and running.
Each site gets its own dotnet instance, and for a while I was even running them all within a screen session. It was kinda neat to be able to flip through all of them, and see the dotnet instances at a glance, but now they've got proper startup scripts.
Each site gets its own dotnet instance, and for a while I was even running them all within a screen session. It was kinda neat to be able to flip through all of them, and see the dotnet instances at a glance, but now they've got proper startup scripts.
Thanks for the info.
All in with Angular 2 using the angular-cli. TypeScript, everything is a component, good fit for enterprise projects, quickly on-board new developers.
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).
Flask.
Mainly because I do a lot of different things with web frameworks. Sometimes I'm serving a straightforward web page, sometimes I'm querying a database and rendering a template, other times I'm wiring up a json API, and other times I might be doing some weird data analysis before sending results to a dashboard template. Some of my URLs require three lines of code, some require three hundred.
In Flask, an endpoint is just a Python function, and most importantly, the URL endpoint is right next to the function declaration, so you don't have to keep track of two or three things in two or three different files. (Though the template is a separate file, of course.) To do something new just add an endpoint and a function; and most IDEs let you collapse/hide the function's code when you don't want to look at it, so it's as "clean" as it is flexible, if not elegant.
In Flask, an endpoint is just a Python function, and most importantly, the URL endpoint is right next to the function declaration, so you don't have to keep track of two or three things in two or three different files. (Though the template is a separate file, of course.) To do something new just add an endpoint and a function; and most IDEs let you collapse/hide the function's code when you don't want to look at it, so it's as "clean" as it is flexible, if not elegant.
Rails for my backend and react/redux SPA for my frontend.
I was using Rails for both but I love the freedom, ease, and capability that comes with React.
I could move to using something "lighter" than Rails on the backend but I really do like the 'batteries included' stuff that means I don't have to think about much to get up and running.
I was using Rails for both but I love the freedom, ease, and capability that comes with React.
I could move to using something "lighter" than Rails on the backend but I really do like the 'batteries included' stuff that means I don't have to think about much to get up and running.
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.
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.
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.
Rails, because I love ruby and hate sweating the small stuff.
Slim because I love simplicity and am a slow reader.
Susy grids because it fits my thinking and is very adaptable.
Vue.js because it lets me write HTML as HTML and JavaScript as JavaScript. And because it makes sense to me. Vuex because it follows the same principles used by Vue.
Slim because I love simplicity and am a slow reader.
Susy grids because it fits my thinking and is very adaptable.
Vue.js because it lets me write HTML as HTML and JavaScript as JavaScript. And because it makes sense to me. Vuex because it follows the same principles used by Vue.
Anyone using an asynchronous python library? Interested in how that's shaping up.
It depends on the use case:
- For API based work, I love Flask (Python).
- For full fledged application, I am loving Laravel (PHP). With PHP7 and package managers such as composer and the awesome laracasts tutorials, it is just a breeze.
- For API based work, I love Flask (Python).
- For full fledged application, I am loving Laravel (PHP). With PHP7 and package managers such as composer and the awesome laracasts tutorials, it is just a breeze.
+1 for laravel.
Nice documentation and really good community.
It's ORM is great, its tooling is awesome.
Instead of piling on with all the usual frameworks (which I do actually use to get work done), let me add one that I've been playing with purely for side-projects/fun:
Escher.jl - http://escher-jl.org
Yes, I primarily use it because it's Julia and I am really enjoying Julia, but it's also a very interesting take on a modern web framework for a modern language (even if it is a bit rough around the edges).
Escher.jl - http://escher-jl.org
Yes, I primarily use it because it's Julia and I am really enjoying Julia, but it's also a very interesting take on a modern web framework for a modern language (even if it is a bit rough around the edges).
- I've been working on Laravel for 3 years now. Liked the speed with which new features are introduced.
- Currently freelancing for a client and using CakePHP. Didn't choose it, the existing system was built on it.
- Worked on Codeigniter an Yii in the past. Chose them because they used to be the most popular frameworks back in the day.
- Used Slim and Lumen PHP microframeworks whenever I was working on a tiny project.
- When I'm not freelancing, I'm learning Elixir and Phoenix.
- Currently freelancing for a client and using CakePHP. Didn't choose it, the existing system was built on it.
- Worked on Codeigniter an Yii in the past. Chose them because they used to be the most popular frameworks back in the day.
- Used Slim and Lumen PHP microframeworks whenever I was working on a tiny project.
- When I'm not freelancing, I'm learning Elixir and Phoenix.
Backend: Rails (older projects) and Phoenix (Elixir) for newer ones
Frontend: None/jQuery for simple sites, Angular 1 (older projects) and Vue 2 (newer) for apps
Frontend: None/jQuery for simple sites, Angular 1 (older projects) and Vue 2 (newer) for apps
[deleted]
Rails because it's familiar, fast enough and it's a joy to work with.
I'm also using Phoenix for pet projects because Elixir is Ruby 2.0 for me.
I'm also using Phoenix for pet projects because Elixir is Ruby 2.0 for me.
If I'm making a website, I'm using Rails. I've been using Rails for years, and I know it and Ruby really well.
I'm surprised nobody mentioned Laravel. It seems to be one of the most, if not the most, used PHP Framework nowadays?
I was thinking the same!
Koa 2 with Nunjucks, Sequelize and Typescript. Koa 2 with async/await is a real pleasure to work with and Nunjucks is powerful enough for pretty much every templating need. Sequelize has been a pretty good ORM. Typescript brings the right amount of type safety to catch easy mistakes while typing. Angular 2 for SPA:s.
[deleted]
currently, i roll my own: golang net/http, gorilla/mux, eknkc/amber, and database/sql. i'm not entirely happy with amber as an html template language, prefer jade or haml, but it seems to work so far, i've had a few problems with it and the author fixed one of them in terms of nested data structures, but there's another issue pending for a long time so i don't think he has the interest to maintain this.
got into expressjs/jade, but didn't like the nested async callbacks, really annoying to read the code, but the tooling side was cool with npm, gulp, etc.
i used to use sinatra/haml/activerecord for a long time, really liked the simplicity of it, but ruby in general was just too slow in terms of performance, had to use a lot of physical resources to supplement for its slowness.
before sinatra i used ror, this was before i decided that rolling my own was more streamlined and efficient.
before ror i used python, tornado, and sqlalchemy. god, sqlalchemy was so clumsy back then, i even bought their ebook for my kindle, what a waste of money. ran ok, really liked the decorators used by tornado, but then fb went and bought friendfeed which doomed tornado to the depths of /dev/null.
before python, i used java servlets (as part of the j2ee standard) and java server pages. it was sort of nice to use html files and embed these java snippets, but still pretty primitive.
before j2ee, i used php, pear, god save me from those days. my personal blog was built on this, i saved all entries into xml documents and stored them in directories based on the date. that site was hacked and pwned so badly, thanks php security holes! this was a time before templates and orms.
and from the very beginning, there was pure html, wow, we have evolved so much since then.
golang is perfect for me, but i use it for a lot more than just a dynamic web server, it's also an api server and websocket service. i really like the ease of deployments with golang i.e. just copy a binary to my production servers. and the code is fast and scales. coming from sqlalchemy, activerecord, and sequel, i was a bit underwhelmed by gorp, but soon found out that going with sql was good enough.
got into expressjs/jade, but didn't like the nested async callbacks, really annoying to read the code, but the tooling side was cool with npm, gulp, etc.
i used to use sinatra/haml/activerecord for a long time, really liked the simplicity of it, but ruby in general was just too slow in terms of performance, had to use a lot of physical resources to supplement for its slowness.
before sinatra i used ror, this was before i decided that rolling my own was more streamlined and efficient.
before ror i used python, tornado, and sqlalchemy. god, sqlalchemy was so clumsy back then, i even bought their ebook for my kindle, what a waste of money. ran ok, really liked the decorators used by tornado, but then fb went and bought friendfeed which doomed tornado to the depths of /dev/null.
before python, i used java servlets (as part of the j2ee standard) and java server pages. it was sort of nice to use html files and embed these java snippets, but still pretty primitive.
before j2ee, i used php, pear, god save me from those days. my personal blog was built on this, i saved all entries into xml documents and stored them in directories based on the date. that site was hacked and pwned so badly, thanks php security holes! this was a time before templates and orms.
and from the very beginning, there was pure html, wow, we have evolved so much since then.
golang is perfect for me, but i use it for a lot more than just a dynamic web server, it's also an api server and websocket service. i really like the ease of deployments with golang i.e. just copy a binary to my production servers. and the code is fast and scales. coming from sqlalchemy, activerecord, and sequel, i was a bit underwhelmed by gorp, but soon found out that going with sql was good enough.
Express with Node.
Love the simplicity, speed and power. Huge ecosystem and fast rampup.
Love the simplicity, speed and power. Huge ecosystem and fast rampup.
Used almost all of the PHP MVC frameworks across multiple projects:
Laravel (2015/16), Yii1/2 (2015-now), CakePHP (2015), Zend (2009), CodeIgniter (2009-Now), Symfony 1 (2008/9)
Laravel (2015/16), Yii1/2 (2015-now), CakePHP (2015), Zend (2009), CodeIgniter (2009-Now), Symfony 1 (2008/9)
Would be curious to know more about your experience, I mostly use CakePHP, and have minimal experience with Symfony 2 and Laravel, but I always go back to CakePHP.
I got lucky to get clients who either had preferred stack in mind when they reached out to me or had a existing product developed with various frameworks I mentioned where they needed technical input.
Rails: Because it works!
As much as it works, I find Rails to do things Automagically, which makes little sense to me.
I'm the programmer, not the framework!
Maybe it is because I love the Explicit is better than Implicit approach more than the Convention over Configuration thing.
Conventions can change. Configurations, they remain!
I'm the programmer, not the framework!
Maybe it is because I love the Explicit is better than Implicit approach more than the Convention over Configuration thing.
Conventions can change. Configurations, they remain!
backend: Ninja framework behind nginx, because I can write Java in my sleep and it makes testing not-awful. prototyping is speedy and easy.
DB: Maria. again, familiarity is key. been using MySQL for almost 20 years and it does what I expect.
UI: nothing fancy. bootstrap and, if the use case absolutely requires it, jquery. have been going back to fairly js-light designs lately and clients seem happy for it.
DB: Maria. again, familiarity is key. been using MySQL for almost 20 years and it does what I expect.
UI: nothing fancy. bootstrap and, if the use case absolutely requires it, jquery. have been going back to fairly js-light designs lately and clients seem happy for it.
I'm almost done with CrocodileJS... https://CrocodileJS.com
I'm switching to Phoenix because all of the points listed above, plus Elixir is just fun to program in!
ASP.MVC Core (with ASP.Identity, EF ...)
Web API + IdentityServer4
AngularJS 2 (starting april v4)
yii2 php framework plus vue.js where inneed SPA like functionality.
Yii is the 3rd framework from the same devs, so it's modern and unincumbered by cruft. Scaffolding is fast, API gen is automatic and extension ecosystem is strong.
Yii is the 3rd framework from the same devs, so it's modern and unincumbered by cruft. Scaffolding is fast, API gen is automatic and extension ecosystem is strong.
I don't use a framework, because with PHP you don't need one.
Asp.net core