Ask HN: What stack should I use to build my basic web app as of 3/29/18
Maybe we can make this a monthly thing, lol :-)
29 comments
Whatever stack you know the best. The technology really doesn't matter a lot, compared to a lot of other success criteria.
Unless the objective is to learn - then picking the one that you know best is not a good strategy :)
Unless the objective is to learn - then picking the one that you know best is not a good strategy :)
This would be my answer every month ( after you this time ;))
Mine too :)
Most of my applications are built using Perl and the excellent CGI::Application module/framework.
I've used Dancer a couple of times, but that tends to be for smaller applications, and it has to be said that the last remaining dancer application I used in production was replaced by a port to golang this morning. Partly for a fun learning experience, and partly to simplify deployment.
For new projects, if they were small and self-contained, I'd probably gamble on golang. If they were more complex, or I was in a rush, I'd use Perl.
Most of my applications are built using Perl and the excellent CGI::Application module/framework.
I've used Dancer a couple of times, but that tends to be for smaller applications, and it has to be said that the last remaining dancer application I used in production was replaced by a port to golang this morning. Partly for a fun learning experience, and partly to simplify deployment.
For new projects, if they were small and self-contained, I'd probably gamble on golang. If they were more complex, or I was in a rush, I'd use Perl.
What happened to Slaughter?
Except for perhaps an unfortunate name it was an interesting project. I can see that all links to it doesn't work anymore..
Except for perhaps an unfortunate name it was an interesting project. I can see that all links to it doesn't work anymore..
It didn't seem to get much traction, so I stopped work on it. A few years later I removed references to it, but I still have the repositories if users do query me.
My recollection is that modules that are removed from CPAN are still mirrored, so they should still be available, but I admit I've not checked recently.
My recollection is that modules that are removed from CPAN are still mirrored, so they should still be available, but I admit I've not checked recently.
For reference the latest App::Slaughter can be found here:
http://backpan.perl.org/authors/id/S/SK/SKX/
Why not put it back on Github? I always find it interesting to look on other projects when I have an idea etc. Deprecated or not.
I am getting tired of puppet/ansible and dream of the pure Perl + Shell world I used to live in. :)
http://backpan.perl.org/authors/id/S/SK/SKX/
Why not put it back on Github? I always find it interesting to look on other projects when I have an idea etc. Deprecated or not.
I am getting tired of puppet/ansible and dream of the pure Perl + Shell world I used to live in. :)
Golang for components that need the speed, Perl for the rest.
Mojolicious is my preferred Perl framework.
Mojolicious is my preferred Perl framework.
http://djangoframework.com is overall one of the best documented + most stable web frameworks out there.
Besides the actual functionality, that you can also get from smaller libraries, you want a framework because it gives you standard go-to solutions for many common questions you encounter when making a basic, relational database backed application (database access, database migrations, templating, forms, validation, caching, translation, etc.)
Besides the actual functionality, that you can also get from smaller libraries, you want a framework because it gives you standard go-to solutions for many common questions you encounter when making a basic, relational database backed application (database access, database migrations, templating, forms, validation, caching, translation, etc.)
I've used Django and I liked it but it really was quite slow.
Really, I have been using Django for a while now. Its rarely the Django code that is the bottleneck, usually it needs some DB tuning.
(If you don't know the ORM well, its easy to let it generate a LOT of queries, have you added django-debug-toolbar to your project to see what it is generating?)
(If you don't know the ORM well, its easy to let it generate a LOT of queries, have you added django-debug-toolbar to your project to see what it is generating?)
If you feel like django is too big you'll probably like flask. It has the same functionality, except everything but responding to http requests is separated into 3rd party packages. Makes for a really lightweight framework if you don't need much.
The correct answer as of ${any_date_in_any_esoteric_format} is:
- It depends on what you are trying to build. Basic web app can be anything from a Trello clone to Instagram. Each has it's own limitations.
- Go with what is tried and tested. Pick up something that is supported, where if you get stuck you can reach out to people for a fix. One of the few good things of the clusterfk that the current JS ecosystem is is that many many amazing developers who are extremely responsive to questions are part of it. That makes life just a little bit easier.
- Use what you are comfortable with. Prefer a proper backend and frontend? Go for it. Everything in NodeJS is your cup of tea? Works just fine. In the end happy developer = productive developer. Just because assembly is 1000 times faster than Python does not mean you should code in assembly. Pick your tradeoffs.
- It depends on what you are trying to build. Basic web app can be anything from a Trello clone to Instagram. Each has it's own limitations.
- Go with what is tried and tested. Pick up something that is supported, where if you get stuck you can reach out to people for a fix. One of the few good things of the clusterfk that the current JS ecosystem is is that many many amazing developers who are extremely responsive to questions are part of it. That makes life just a little bit easier.
- Use what you are comfortable with. Prefer a proper backend and frontend? Go for it. Everything in NodeJS is your cup of tea? Works just fine. In the end happy developer = productive developer. Just because assembly is 1000 times faster than Python does not mean you should code in assembly. Pick your tradeoffs.
I'm just wondering if you're not from the USA? Because that date format is very common here particularly for written dates.
Whenever I write a check or sign and date something, that's how I write it.
Whenever I write a check or sign and date something, that's how I write it.
Nope I'm not, though I work at a company with 2 engineering offices in MV and Dallas. Just FYI: Other than the USA, this format is not used anywhere else:
https://s3.amazonaws.com/stackabuse/media/date-formats-world...
Working with a global company, I tend to use 29 Mar 2018, which is much more unambiguous (and in code we usually use yyyymmdd, which makes it easier to search for logs/output of a year/month/day etc.).
https://s3.amazonaws.com/stackabuse/media/date-formats-world...
Working with a global company, I tend to use 29 Mar 2018, which is much more unambiguous (and in code we usually use yyyymmdd, which makes it easier to search for logs/output of a year/month/day etc.).
Where are the hipsters in this thread? Fine, I'll be the hipster.
I've worked on pure PHP, Flask, Pyramid, Django, Laravel stacks, and I haven't warmed up to any of those. I'm in the vocal minority that says Django made me hate Python.
So here's my stack for 2018: Elixir+Phoenix on the backend, GraphQL as API protocol, React (and Typescript?) on the frontend.
Functional and immutable language on the backend + functionally-inspired data flow on the front end? Yes, please.
Now, if I could have monadic constructs and better typing on Elixir I'd be in heaven.
I've worked on pure PHP, Flask, Pyramid, Django, Laravel stacks, and I haven't warmed up to any of those. I'm in the vocal minority that says Django made me hate Python.
So here's my stack for 2018: Elixir+Phoenix on the backend, GraphQL as API protocol, React (and Typescript?) on the frontend.
Functional and immutable language on the backend + functionally-inspired data flow on the front end? Yes, please.
Now, if I could have monadic constructs and better typing on Elixir I'd be in heaven.
I feel it's important to throw Laravel + Vuejs into the mix. It's an extremely powerful framework on the LAMP side of things, fully PHP 7.2+ functional, and continues to improve w/ every major iteration from JWT, oauth2, queue workflows, console utility workflows, ORM, DBAL, Migrations, mutli-database support via PDO, blade templates. It's pretty hard to go wrong.
I’ll throw a hat in the ring for WebGL+WebAssembly and x86 assembly on the server
This guy, what a forward thinker!
Basic? You need good documentation, and Philip Greenspun's book is now available for free[1]! So go with that, although you might want to swap out Oracle with MySQL -- it's from the same company anyway! AOLServer is still fine.[2]
[1]: http://philip.greenspun.com/panda/
[2]: https://github.com/aolserver/aolserver
[1]: http://philip.greenspun.com/panda/
[2]: https://github.com/aolserver/aolserver
3/29/18? What sort of date format is that?
Regardless of your stack, use ISO 8601 for dates.
Regardless of your stack, use ISO 8601 for dates.
That's the third of Thunderfiretober of 2018, what's your problem, isn't that clear? ;)
Playing devil's advocate here. This kind of date formatting is really confusing to me (German) and I almost overread that the question asked for the current en vogue tech...
Playing devil's advocate here. This kind of date formatting is really confusing to me (German) and I almost overread that the question asked for the current en vogue tech...
> This kind of date formatting is really confusing to me
You, me, and most of the world outside the USA. Check out the map here: https://en.wikipedia.org/wiki/Date_format_by_country
You, me, and most of the world outside the USA. Check out the map here: https://en.wikipedia.org/wiki/Date_format_by_country
That's one of the most common date formats used in the United States.
Are you suggesting to use ISO 8601 format to display dates to users instead of the users local or preferred format?
Are you suggesting to use ISO 8601 format to display dates to users instead of the users local or preferred format?
Yes. This site, like many, has a large international audience. Don't assume your local (and illogical) format is your users'. It just confuses people. Use an unambiguous format: use 8601 or spell out the month.
That's my point exactly. It's an international audience but it's also an informal social environment where we can't expect everybody to be cognizant of that fact at every moment and make adjustments for it.
As such, you shouldn't be too strict about what you feel is the "logical" way of doing things.
Anyway, according to alexa, the great majority of HN readers are from the US - https://www.alexa.com/siteinfo/ycombinator.com
As such, you shouldn't be too strict about what you feel is the "logical" way of doing things.
Anyway, according to alexa, the great majority of HN readers are from the US - https://www.alexa.com/siteinfo/ycombinator.com
> the great majority of HN readers are from the US
57.5% is not a 'great majority'. It's only slightly more than half!
> we can't expect everybody to be cognizant of that fact
That's why I remind people. Use international standards/formats and be less insular. (And FFS, go metric ;)
57.5% is not a 'great majority'. It's only slightly more than half!
> we can't expect everybody to be cognizant of that fact
That's why I remind people. Use international standards/formats and be less insular. (And FFS, go metric ;)
57% is the greatest number on that chart. I didn’t see any other number past say 9% if I remember correctly. (It was actually 6%.) That’s the great majority.
Yes, be less insular too... however please try to do it in a non-snarky way that won’t provoke the other human beings.
Yes, be less insular too... however please try to do it in a non-snarky way that won’t provoke the other human beings.
The simplest stack for me is:
Frontend - Plain HTML/CSS/JS
Backend - Node, Express with Nunjucks for templating
If I want to get a bit fancy:
Frontend - Vue, Bootstrap4
Backend - Node, Express, Nunjucks
DB - SQLite3 using Sequelize as ORM
Surprisingly, you can accomplish lot of stuff with the second setup.
If im going to deploy to production:
Provider - Either small DO droplet ($5.00) or tiny AWS (free)
Webserver - nginx as reverse proxy for node (free)
Firewall - UFW (free)
Email - mailgun (free)
Domain - namecheap (depends on domain name. $10.00/yr more or less)
For a basic setup you wont need any scaling setup (CDN, load-balancer and whatnot) which like what, 99% of the time?
Frontend - Plain HTML/CSS/JS
Backend - Node, Express with Nunjucks for templating
If I want to get a bit fancy:
Frontend - Vue, Bootstrap4
Backend - Node, Express, Nunjucks
DB - SQLite3 using Sequelize as ORM
Surprisingly, you can accomplish lot of stuff with the second setup.
If im going to deploy to production:
Provider - Either small DO droplet ($5.00) or tiny AWS (free)
Webserver - nginx as reverse proxy for node (free)
Firewall - UFW (free)
Email - mailgun (free)
Domain - namecheap (depends on domain name. $10.00/yr more or less)
For a basic setup you wont need any scaling setup (CDN, load-balancer and whatnot) which like what, 99% of the time?
I like that set up.
For me its ejs over nunjucks. Mysql, and no ORM. I'd also probably use something like elastic beanstalk vs piecing it all together myself - to keep things simple.
And I'd use sendgrid over mailgun, primarily for deliverability but also I find their service/api/dashboard very user friendly.
If taking payments I'd use stripe
For me its ejs over nunjucks. Mysql, and no ORM. I'd also probably use something like elastic beanstalk vs piecing it all together myself - to keep things simple.
And I'd use sendgrid over mailgun, primarily for deliverability but also I find their service/api/dashboard very user friendly.
If taking payments I'd use stripe
I use a basic LAMP stack (CentOS, Apache, MariaDB, PHP 7). No frameworks. Some of my projects are quite large (tables with billions of rows, and over a million users). It might not be fashionable, but it works, it's fast (for development, and for end-users), it's well documented, and it's been tested for decades. I have no plans to change, and my new projects in development are using the same.
The problem with this is, when you pull in new developers - it takes them weeks or months to understand everything. Whereas a Laravel app, they need maybe a few days at best to figure out what design principles you're using and what style, and where you put repos/models and such, but then they're good to go.
I hate working on code where some systems engineer from the 80's thinks they're big and bad and can code an awesome website using just propel + plain php and then expect every new dev to just learn it and love it as much as they do.
I hate working on code where some systems engineer from the 80's thinks they're big and bad and can code an awesome website using just propel + plain php and then expect every new dev to just learn it and love it as much as they do.
Do I sense a bit of sarcasm regarding longevity of JS frameworks here?
As other commenters say, if you want results, choose whatever stack you are most productive with.
As you say 'basic' web app: I'd recommend using Firebase, if you are comfortable with the vendor lock-in. For auth, database and deployment it doesn't get much simpler than this.
As other commenters say, if you want results, choose whatever stack you are most productive with.
As you say 'basic' web app: I'd recommend using Firebase, if you are comfortable with the vendor lock-in. For auth, database and deployment it doesn't get much simpler than this.
Strapi is something I've been looking at as a self-hosted firebase competitor for just an api for mobile apps, etc.. It's pretty cool, when I don't want to build out a full-fledge laravel app.
I use Firebase too along with a simple Vue.js setup. So easy and quick to get up and running.
I really think it depends on the programming languages you know, if you know any. For example, if you know Python, just use Django or Flask. If you know c#, just use that.
However, if you don't know any programming languages and plan to do "just" web development, WAMP and MEAN stack is the way to go.
edit: WAMP -> (XAMP)
However, if you don't know any programming languages and plan to do "just" web development, WAMP and MEAN stack is the way to go.
edit: WAMP -> (XAMP)
Go for what works for you, a popular stack may not necessarily be best for you unless you, at least, have experience with the technologies. My current default stack.
Frontend: Vuejs (pwa)
Backend: Go (exposes json api endpoints for frontend)
DB: mariadb / sqlite
> Backend: Go (exposes json api endpoints for frontend)
Do you use Swagger or sth. like that to auto-generate the boilerplate from an API spec?
Do you use Swagger or sth. like that to auto-generate the boilerplate from an API spec?
AWS Serverless.
Cheap, "fresh", and scalable in complexity with too many services to mention.
It's easy, plenty of example code available and will get your feet wet in the hyped secdevops which might land you a nice project sooner or later.
Cheap, "fresh", and scalable in complexity with too many services to mention.
It's easy, plenty of example code available and will get your feet wet in the hyped secdevops which might land you a nice project sooner or later.
There really aren't any wrong answers here but I've had good personal experience with Vue, Go, and Postgres. Make sure you use vue-cli. vuefire is also very convenient if you're so inclined.
GraphQL stack :)
Frontend: React + Apollo Client + Netlify
Backend: Typescript + Node.js + Apollo Server (graphql-yoga) + Graphcool/Prisma + Apex Up to deploy to AWS Lambda + AWS RDS
Frontend: React + Apollo Client + Netlify
Backend: Typescript + Node.js + Apollo Server (graphql-yoga) + Graphcool/Prisma + Apex Up to deploy to AWS Lambda + AWS RDS
I am going to go against the grain here and say you should pick with whatever you are most skilled at and feels natural to you.
Unless you have very specific requirements, it matters very little; especially if your goal is to push a product
Nowadays there are many options and a lot of them are reliable.
E.g
Rails, PostgreSQL, React
Django, PostgreSQL, VueJs
Phoenix. PostgreSQL, Jquery
Unless you have very specific requirements, it matters very little; especially if your goal is to push a product
Nowadays there are many options and a lot of them are reliable.
E.g
Rails, PostgreSQL, React
Django, PostgreSQL, VueJs
Phoenix. PostgreSQL, Jquery
But you're saying back/frontends don't matter...but definitely use postgres... lol
Check out this recent Ask HN:
Ask HN: What stack would you use to build a CRUD web app in 2018?
https://news.ycombinator.com/item?id=16508965
It has 177 comments and some good meaty answers.
Ask HN: What stack would you use to build a CRUD web app in 2018?
https://news.ycombinator.com/item?id=16508965
It has 177 comments and some good meaty answers.
If you know Python well, tornado + mongodb(motor) is pretty neat !
Entirely depends on what you're building. If it's crazy complex go native now. Super complex web apps are as the rarest of the rare, and damn near impossible. Like a handful ever, rare. That's not to be said that it cannot be done. If it's medium to basic, use a framework like Vue or Preact and a VDOM. Everything will stem from that. Node.JS is a given, maybe Go, but all other decisions depend on what you are building.
Rails + intercooler.js gives you most of the functionality you need with a minimum of complexity.
If it's an MVP? Then anything you can use to stand up the mvp quickly.
backend on kotlin with (maybe) Spring 5; frontend with Angular 4 or Vue 2; datastore on apache cassandra ; mobile version with flutter/dart ?... probably cover all your bases for the stack-du-jour.
You can try Vue.js & Buffalo.
[deleted]
What does the app do?
Try going through the comments and you will figure it out.
Also go through https://www.tipsindeed.net
Also go through https://www.tipsindeed.net
[deleted]
html5 and nginx.