Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 71 posts

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

#22

Post by eyelidlessness »

rpastuszak wrote: post #16
eyelidlessness wrote: post #12

I also primarily use TypeScript/Postgres where I have the choice. For UI I do prefer JSX but not React, I prefer something lighter and ideally supporting or amenable to partial hydration. I’m eager to use Deno more, there’s a lot that appeals to me more than Node. In the past I’ve worked extensively in Clojure/ClojureScript. I really like the FP aspects and I came to really appreciate lisp generally, but I much prefe…

> 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 is correct, but slow; ESBuild solutions are incorrect/incomplete (both because ESBuild itself lacks some TypeScript features and because the ESM loaders miss a variety of edge cases; ESM loaders are still experimental and there are large API changes coming in Node 17 (and presumably Node 18 which will be in LTS alongside the older APIs).

3. Performance: in terms of TypeScript (Deno uses SWC, which is nearly as fast as ESBuild and IIRC more correct), as well as heavy investment in Rust internals and third party extensibility.

4. Package management is both more standard (just import URLs) and more flexible (built in support for import maps, etc).

5. Related to #1 and #2, but a separate point: Deno can be expected to evolve faster while remaining relatively stable. Node has many legacy APIs that will likely never be deprecated in favor of even the standards it does adopt, and supporting those APIs already makes adopting newer standards more challenging.

6. There’s something refreshing to me about the fact that Deno’s creator was also Node’s, and that Deno is explicitly an admission of mistakes/warts in Node’s original design.

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

#26

Post by nomemory »

Kotlin with Vert.x or Spring Boot depending how complicated things are in the backend. Spring can boost your productivity if you really need it. Vert.x gives you more control, but you will have to write more code. Java is also an option, but Kotlin is simply nicer.

When it comes to FE, I don't touch that anymore. I did some react and old angular in the past, but it was more like an obligation... I don't "feel" the community, or how complicated things have become.

For programs that are closer to the hardware or operating system, I feel quite comfortable in C (not C++).

For scripting, data visualization, and anything math related I use python. I usually end up having one big script, terrible written that works.

When it comes to databases, I pick mariadb because I have the biggest experience with it and it didn't disappoint me. From the NoSQL land I've tried the most popular ones, and I had good interreactions with redis, and the elk stack.

I've tried to love Go and Rust... I still try, because some companies I follow and have interesting projects are using them. But it's more like a long term goal to learn rust.

I believe my stack is boring, if not boring conservatory.

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

#27

Post by armchairhacker »

turtlebits wrote: post #25

For web apps, Svelte + Hasura + Postgres. I try for as as minimal as a backend as I can get away with. Sometimes none, or couple of serverless functions.

No backend is entirely possible. The less tools you need, the less room for complexity, bugs, and slowness.

I've recently started an app with Vite+TypeScript and Supabase and it's exactly what I've been looking for:

- Fast development: I make a change to the webpage and it automatically reloads instantly (like 0.02sec). Starting the dev server or installing deps takes 1sec. The site itself is fast. IntelliJ inspection is fast. This might just because my site is still small, but given the insane speed I'm hoping it will hold up when I add more code

- Good integration with tools and linking: If the code is wrong the browser / console instantly shows a detailed stacktrace that actually makes sense. The Firefox dev server doesn't de-sync. So far I haven't had any issues looking into obfuscated JavaScript. Only issue is I haven't gotten IntelliJ debugging (in-browser debugging works fine though)

- Low boilerplate: I create a new table on the database, add a 4-line GET function on the frontend, add a 10-line view, and now I've added blog posts to my application. Authentication is absurdly easy, I can authenticate with Google/Facebook/Github in a single call. I don't have to write useless boilerplate. Supabase can even generate TypeScript types for database objects

I've worked on sites where reloading took a full minute (meteor); there were bugs in babel-js, bugs in the npm libraries we used, and every bug involved looking through obfuscated JS to find what code "actually" triggered an error; and every small schema change took so long as I literally had to code the database schema / ORM schema / migration / REST endpoint / fetching from the endpoint / updating from the client etc.

Those were all worst cases, but they basically made me flat-out give up and accomplish barely anything. They're what make me skeptical of 1000+libs and complex build systems in the first place. Sometimes all you need is a 100% static site and a few static ES-module dependencies, and that will take 0 seconds to compile and (provided you can actually find un-minified ES-module deps) you'll never get obfuscated JavaScript or linking errors.

Post reply on HN