Ask HN: Best tech for a web site 2018? (PHP, Rails, Django, Node, Go, etc.)?
Back in the day, PHP was a great tool for getting a site up quickly.
Then Ruby on Rails took off in 2006 and took the lead.
It was the "batteries included" of web frameworks.
You could build a CRUD app very quickly.
Many other language frameworks followed and evolved.
It is almost 2018. What do you think is the best tech for a web app these days?
Here are some features I could quickly think of:
* basic HTTP handling
* good security
* i18n/translation
* ORM/persistence system
* a built-in user/authentication system
* a built-in admin UI
* a migration system for db schema changes
* easy REST (gRPC, etc) API construction
* good form/model validation
* a type system for the language
* websocket support
123 comments
[ 3.0 ms ] story [ 146 ms ] threadMaybe also a minimal go framework instead of rails for better performance...
Can completely run on Linux and Kestrel (behind NGINX) is a very fast webserver. https://docs.microsoft.com/en-us/aspnet/core/publishing/linu...
Definitely microservice friendly. Azure is reasonably priced with various serverless offerings.
And you can just run .NET Core if you want to target Linux and pick a dirt cheap host.
It was very easy to develop, test and deploy. Npgsql has support for most of the postgres features (except complex types but that's planned).
I deployed everything on Ubuntu servers and runs like a champ. (I'm saying prototype and it is indeed, but it has 100-something users across the globe testing their workflows continuously and it has a lot of CPU-intensive stuff which is child's play with .NET to manage asynchronously. A production app would have two orders of magnitude more users but I think I'll be able to get away with a single server if it comes to that).
We had a couple experiments at my company but going from 1.0 to 1.1 had breaking changes so we couldn’t upgrade easily.
Edit: many of the things you asked about, Django does exceptionally well. Migrations, built-in auth, built-in admin (what other framework has this?), APIs through DRF, form-model validation.
I've spent a good bit of time trying to find the "go-to" options for this in the Java/Scala world, and if you look into something like Play framework, the choice isn't clear for a newbie to the ecosystem. There's JPA, Hibernate, Slick, Anorm, EBean, flyway migrations, among others. Maybe I'm experiencing information overload, if that's the case, please comment below and suggest what you would use on a new Java project today.
The MyPy support for Django is severely lacking.
I've been thinking about writing a decorator to check this in development (should be doable) but then I would have to decorate every function and I really do not want to do that.
And, playing around with things like Swing or Play, the whole ecosystem feels much more mature right out of the box.
I still use php and Silex micro framework for the small sites I develop, Its not very full featured (not ticking a lot of items on your list) but its fast enough and I know it well enough to put a site together quickly.
Grails
Rails
Are all excellent technologies. Grails has excellent form/model binding and validation with what they call command objects.
Ruby follows duck-typing, so variables are not typed. If that was a strong point for you, Ruby might not be what you need.
I'm not quite sure about the admin UI (I usually use the rails console when I have things to change), though, but there's probably a gem that does exactly that (?).
Ruby on Rails is very powerful and intuitive, and I'll miss it if/when I change jobs and have to use some other language.
Edit:
> [...] so variables are not typed.
I might have used the wrong words... Ruby is dynamic, strongly typed. Variables are not limited to a certain type after they are created, and can change anytime.
In my experience it's always better to just write it on your own and better integrate it into the app, but Active Admin allows for some fast prototyping.
I can't speak for others, but I'm using PHP frameworks and as you stated, developing in PHP evolved and you have now great stuff.
I'm mostly using Laravel, easy to set up, and with a lot of features. And a bit simpler than Symfony, that I use too, mostly because working with Magento 2, you are more comfortable if you know Symfony.
For front, VueJS, perfectly integrated in Laravel
And it doesnt make sense to me to use a different tech for the backend unless you have a very specialized usecase (datascience <-> python for example).
migrations - use Python alembic. Nothing comes close. Its worth using it separately.
I use python and flask heavily with a react frontend at my current startup. But the only reason we do it is because we do crazy amount of math and data science - there is seriously no replacement for the python ecosystem here. If I didnt have that restriction, i would go full react+TS
I don't think one thing wins everything.
I'd shoot for:
1. PostgreSQL for DB
2. Admin tool in Django
3. API in Go
4. Front-end in whatever you know best.
Go I find best for APIs. But there's no out of the box admin tooling and the web stuff still feels immature (l10n and i18n).
Django admin has always proven solid, but maintaining APIs in Python over many years has been more overhead than Go APIs. I liked the web stuff, but kept finding I ended up using third party extras that didn't seem as well maintained.
PostgreSQL for the database is a no-brainer and allows easy migration to Google Cloud or whatever when you're ready.
The front-end is personal choice... whatever you can be most productive in and it handles all of the internationalisation stuff.
Not a great help I know... it feels like there are fewer one-stop shops really capable of shining at every level. C# should be a contender, it's tooling is great at all levels, but I don't know of a web framework that brings it all together to make it a few clicks and you're done.
Can you elaborate further on why you think Go is best for API work? I do like that go has goroutines, a fast compiler, and a single statically linked binary.
An example might be handling the Accept header to give back multiple formats... many frameworks try and hide this from you, and so you have to fight to get something done. But Go exposes everything in a consistent and intuitive way, and there are mature packages for all of this stuff so it becomes trivially easy to work with.
JSON work is simple, CSV work is simple, XML work is fairly easy, image work is simple. It's pretty beautiful as language/std package experiences go.
It would need a more intuitive templating workflow for web stuff though (the "page.html inherits base.html and includes []block_*.html" story is a bit janky), and I've not yet found a decent answer for the l10n and i18n stuff, and whilst Hugo has a great template funcs library they've purposefully entangled it with their code, and so there is a lack of a core template func package to deliver a lot of things along the lines of Django templates.
So Go is great for APIs, but weak for web.
Sounds like a way to artificially pad hours on a project to me.
This obsession people have with "our web app talks to our api" never made sense to me - why are they separate code in the first place? 99% of the difference between a web browser request/response and a web api request/response is down to data serialisation and the view.
It stems from APIs having bugs, and not being consumed by the writers. The flows were badly designed because they would never write a client against the API.
By making the web be a client to the API, the design, quality and maintenance of the API is very much to the fore. It also allows the implementations to evolve at their own speed, which helps a lot with maintenance, especially when one adds a mobile client, or changes some other UX flow... it becomes easier to work through things.
So yes, I agree... slower to get started and 2 codebases. But, so many advantages, higher quality, and lower maintenance costs that arise from the kind of short cuts that a single monolith codebase makes possible.
And two code bases sounds like a reason for more shortcuts to be taken not less to me.
Testing means you catch regressions.
You seem to be talking about API design, which is honestly a minor concern compared to whether it works reliably.
Have you ever tried to use the Facebook API? It breaks randomly such as endpoints suddenly return 404's, and there is no followup to bug reports.
That is what I'm talking about when I say "quality".
A "perfectly designed" API that randomly breaks because someone made a change and the lack of tests means its an end-user who discovers it is worse than terrible IMO.
- You can throw your client app away and build a new one pretty quickly without worries because it's totally decoupled from the backend. This is really nice when you have fickle stakeholders that have no idea what they want.
Team projects Use whatever your team prefers
Or if you don’t want to host api backend yourself, then a server less/lambda type implementation using nodejs or others, with the same React front end.
(Edit: missed that you wanted “admin ui” - then I’d add Django, but you might struggle with adapting it for non cms type scenarios)
I don't really see how Go would make a better job than Python at something like Django.
The upside of Django is that you write so little code and all is covered. The downside, is that you have to test it carefully.
https://bestmotherfucking.website/ is actually better than these others.
I would go with Python 3 (yes, use 3 when starting a new project) and Flask & Co. because you write less boilerplate code and have a big community.
Go is interesting but you might end up with more dead ends and more boilerplate code than Python 3 (yes I know, it's faster than Python but Python has more/bigger [proven to work] libraries/community).
If you like Java or Scala go with the Play Framework. Most beautiful documentation of all 3 and it covers more of your "requirements" with its base than Flask (which is a micro framework).
PHP was a great tool back in the day and today!
PHP with a decent framework like Laravel [1] or Zend Framework [2] really works well and addresses all the features that you have listed (except the last 2).
Uniquely among modern languages, * PHP was born in a web server *. Its strengths are tightly coupled to the context of request-oriented, server-side execution.
We've managed to develop several complex apps over the last 10 years on PHP. For Web Socket support, we use Socket.IO or Firebase and it both really well together with PHP.
If you choose PHP now, you are not alone. Many companies still choose PHP for their Web Application. Slack uses PHP for most of its server-side application logic [3]
[1] https://laravel.com/ [2] https://framework.zend.com/ [3] https://slack.engineering/taking-php-seriously-cf7a60065329
I think most important thing is picking something that you can hit the ground running fast, it doesn't matter what you build in (though I'd stay away from nosql personally... never know when you'll need rdbms on scaling, and starting w/ mysql/postgres is safer in many cases)..
(and no ratchet, php-websocket do not count)
https://www.html5rocks.com/en/tutorials/eventsource/basics/
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
https://github.com/remy/polyfills/blob/master/EventSource.js
1. Use a traditional framework that includes everything.
2. Use a microframework and stitch together individual pieces.
1. All in one - start with everything
If you know you're going to require all those things then I would focus on tools that offer that in Core, like Django. The benefit is that all the main components you need are 'guaranteed' to work together as a single unit, all go through the same security procedures and have many many people supporting the development. This can still be greatly customized and extended but you need to work within greater restraints of the framework. There are limitations, eg: NoSQL and Django don't really jive.
2. Do it yourself - only add what you need
Using the build it all yourself approach, you'll spend time doing what the above does for free by custom coding it. Be prepared to spend time reviewing individual packages that extend functionality, like Forms handling, and determining which one to use can be overwhelming. You may experience incompatibility issues and some of the smaller components have a single developer working on them for fun so you might up end having to takeover responsibility yourself or find a new drop in replacement - more time and work. The benefit is that you have nuts and bolts understanding of everything, and it can be highly customized. Lots more overhead, lots more time to get up and running. I find this works well for specific API's and not for something that includes everything in your shopping list above. Great for building very clean services, I'd argue more geared for experienced devs.