Live data from Hacker News

Ask HN: What is your preferred/most commonly used stack and why?

news.ycombinator.com

61–70 of 71 posts

Re: Ask HN: What is your preferred/most commonly used stack and why?

#61
post #13

Django / Postgres which might evolve to React / Django+DjangoREST / Postgres / Redis / ES / RabbitMQ

I agree, although I would swap out React for Vue.js V3. Also, from experience RabbitMQ (with I assume Celery) is probably overkill for most projects and introduces more moving parts especially if you already have Redis. So I would go for Python RQ with Redis as the broker. (You can use Celery with a Redis broker but it has strange bugs and again probably overkill) Finally, Ionic framework and Capacitor for mobile app…

Why Vue over React?

Re: Ask HN: What is your preferred/most commonly used stack and why?

#62
post #42

Earlier quoted context omitted.

What, no Alfred?

Checkout Raycast, it's the new Alfred yo!

Looks interesting...but I think I'll hold off for now. Too used to Alfred 3 to even upgrade to Alfred 4.

Interesting pricing model, though. I wonder whether they'll succeed with it. In my experience, people love the idea of Alfred, but I've never had success getting anyone on my team to adopt it. (Maybe because of the "pay individually" nature of the good stuff (powerpack)? I'm not sure.)

Re: Ask HN: What is your preferred/most commonly used stack and why?

#63
post #61

Earlier quoted context omitted.

I agree, although I would swap out React for Vue.js V3. Also, from experience RabbitMQ (with I assume Celery) is probably overkill for most projects and introduces more moving parts especially if you already have Redis. So I would go for Python RQ with Redis as the broker. (You can use Celery with a Redis broker but it has strange bugs and again probably overkill) Finally, Ionic framework and Capacitor for mobile app…

Why Vue over React?

It’s as simple as I have more experience with it.

Re: Ask HN: What is your preferred/most commonly used stack and why?

#64
post #11

It's fine to ask for feedback on your prototype, but that's probably better off as a standalone Show HN. Better for both sides -- you're probably not going to get as much feedback on your project as you'd like since it isn't the actual topic at hand.

Yeah. I submitted it as a "Show HN" last Friday and received feedback from one person.

If you think the timing was bad, try the second chance pool and repost it: https://news.ycombinator.com/pool

Re: Ask HN: What is your preferred/most commonly used stack and why?

#65

Ruby on Rails, Hotwire, StimulusJS, SCSS, slim, Postgres, Redis, on Heroku or Render. Solid, mature, innovative, productive and pleasant to work with. 80% of SPA speed and reactivity with 5% of the effort. If I need complicated interactivity in a specific area, I use vuejs.

i thought Hotwire was supposed to give us js without the js, but it seems like it needs stimulusjs and/or a mix of at least three other libraries and html-polluting attributes and code snippets. i def don't understand that world yet, but i'm thinking...is there even enough of a payoff to step down from Vue? slim looks cool. guess i have to check out laravel lumen, too. i thought lumen was just api support, so maybe s…

I meant http://slim-lang.com/

Never close another HTML tag again, never type or read a single character while writing clean compliant solid html.

Re: Ask HN: What is your preferred/most commonly used stack and why?

#66
post #11

Earlier quoted context omitted.

Yeah. I submitted it as a "Show HN" last Friday and received feedback from one person.

If you think the timing was bad, try the second chance pool and repost it: https://news.ycombinator.com/pool

Oh that's interesting. I didn't even know this existed. Thanks!

Re: Ask HN: What is your preferred/most commonly used stack and why?

#67
Backend: Spring boot with Kotlin, openapi-generator for server stubs, JOOQ for database interaction.

Frontend: React, antd as a component library, openapi-generator for api clients.

Database: PostgreSQL, flyway for migrations.

Out of all the stacks I've used over the years, this is the one I'm happiest with. It's very stable, each tool has excellent documentation and active communities, and it's just plain fun and productive to work with.

Re: Ask HN: What is your preferred/most commonly used stack and why?

#68

Everyone goes through this phase of creating a “starter”. Maybe they evolve it to a pluggable framework. But nothing will last the test of time. Things change too rapidly and developers usually need to understand everything themselves when they want to customize stuff. The best is having small packages that do one thing well that do not involve buy-in to a particular framework. It’s a really tough challenge. Making s…

[deleted]

Re: Ask HN: What is your preferred/most commonly used stack and why?

#69

Earlier quoted context omitted.

i thought Hotwire was supposed to give us js without the js, but it seems like it needs stimulusjs and/or a mix of at least three other libraries and html-polluting attributes and code snippets. i def don't understand that world yet, but i'm thinking...is there even enough of a payoff to step down from Vue? slim looks cool. guess i have to check out laravel lumen, too. i thought lumen was just api support, so maybe s…

I meant http://slim-lang.com/ Never close another HTML tag again, never type or read a single character while writing clean compliant solid html.

so, slim is, in this case, a templating language/tech similar to blade, jinja, etc.

Re: Ask HN: What is your preferred/most commonly used stack and why?

#70

Earlier quoted context omitted.

> I’m eager to use Deno more, there’s a lot that appeals to me more than Node. Like what? I’m genuinely curious.

1. Its API tends to be much closer to browser/web standards. This appeals to me because it’s easier/more productive to learn and reference one thing than multiple, similar things. It also appeals to me for portability, and potentially large improvements for “isomorphic” UI. 2. TypeScript in ESM is supported out of the box without a build step. There are solutions to this in Node, but they all have trade offs: ts-node…

That's a great overview, thanks!

The only thing missing for me here is having a permission model similar to WASI, where we could potentially have sandboxing per module/dependency. IIRC in Deno this is done on the application level. I wish it was a bit more granular.

I'm not too fussed about esbuild not supporting TS as well as SWC does, e.g. I don't care about enums. But your comment made me realise that I should probably give it another shot. Cheers

Post reply on HN