Ask HN: What is your preferred/most commonly used stack and why?
70 comments
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.
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 slim is the same? i have to watch a youtube.
https://www.slimframework.com/
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 slim is the same? i have to watch a youtube.
https://www.slimframework.com/
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.
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.
+1
:)
:)
Django / Postgres
which might evolve to
React / Django+DjangoREST / Postgres / Redis / ES / RabbitMQ
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 apps.
Oh, and increasing falling for TypeScript.
Supper quick stack to build anything.
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 apps.
Oh, and increasing falling for TypeScript.
Supper quick stack to build anything.
It depends on the problem but I stick with what I know.
Database: SQL Server at work, PostgreSQL at home (due to pricing but it's also great!).
Backend: ASP.NET Core
Front End: As little as possible but it depends on requirements going from
1. None at all
2. Use JQuery in certain spots for UX
3. Use Typescript/React (simple, no redux etc.) for a complex SPA-type app.
But 1 is the default because KISS.
No GraphQL or NoSQL DBs. Might use S3/Azure blobs though for caching.
ASP.NET/.NET/C# is used because I'm used to it. However even with that bias, I argue it is a great sweet spot for back end languages. Good typing system but not too complex like Haskell. Garbage collection works has never been something I've had to worry about. Also performant and great tooling.
Database: SQL Server at work, PostgreSQL at home (due to pricing but it's also great!).
Backend: ASP.NET Core
Front End: As little as possible but it depends on requirements going from
1. None at all
2. Use JQuery in certain spots for UX
3. Use Typescript/React (simple, no redux etc.) for a complex SPA-type app.
But 1 is the default because KISS.
No GraphQL or NoSQL DBs. Might use S3/Azure blobs though for caching.
ASP.NET/.NET/C# is used because I'm used to it. However even with that bias, I argue it is a great sweet spot for back end languages. Good typing system but not too complex like Haskell. Garbage collection works has never been something I've had to worry about. Also performant and great tooling.
> 2. Use JQuery in certain spots for UX
Yikes. Why? Vanilla JavaScript exists.
Yikes. Why? Vanilla JavaScript exists.
Yeah I should have specified I’d use vanilla first. I’m often using JQuery at work for legacy reasons. For a new project I’d try to avoid it or use one of the smaller libraries if needed.
Thank you for saying simple React. I feel like I'm insane sometimes as I can do 99.9% of what I need without Redux.
doesn't that mean you still need Redux?
No. Redux is an antipattern. Don't get me wrong it's an amazing tool for managing complex, changing global state. It's just that complex, changing global state doesn't belong in a react app. You can get all the certainty benefits of using redux by just learning to organize and abstract your stateful behavior properly.
I agree on the "what I know" (also generally called 'boring tech'). Your boring tech stack is slightly different from 'mine' but also very similar in a sense. I guess we differ in being a Microsoftie vs. a *NIXer.
I think we also see a lot of stack choices here that are really great for smaller operations but don't scale well to larger ops. Pure initial speed of untyped languages and magic frameworks are great if you're alone or work with a few co-workers that you're close with and that know all of the magic by heart. Once you reach a certain size and you can't keep the whole thing in your head at all times, typed languages w/ IDE support just become so much faster. You are no longer building new stuff all time or adjust things you intimately know. You have to figure out yet another dusty corner of the code base that was written years ago by people that have since left the company. You really want to be able to just 'click through' the code in your IDE to understand it, without having to have a complete mental model of the whole thing in your head already and remember the 13 magic incantations that make the whole thing actually do something at runtime. Languages and frameworks that allow simple string searchability are king. I see "someString" somewhere, I want to be able to find _everything_ related to that by searching "someString". I don't want to have to try "some_string" or "some-string" or "string" (because "some" is a magic prefix added by some framework) to find related things!
SQL Server, while MS (which I don't like personally in any stack), has good foundations and they evolved it nicely. SQL Server is very boring as in, they licensed an established database and developed it for their own purposes and stack (i.e. their own operating system). For the newbies: MS SQL Server is Sybase ASE basically and the SQL dialect, Transact-SQL is the Sybase SQL dialect. Awesome boring tech that I 'grew up with'.
Love PostgreSQL myself and I am so glad to see that many many more people than "in my youth" are now finally using Postgres instead of MySQL. I'm at a Postgres using place right now and that's great!
Personally as I'm a *NIX guy, my boring backend language is Java and the not quite as boring one on the same JVM is Kotlin. I have dabbled in C# privately and love it from what I've seen, but never professionally because it comes with the 'wrong' rest of stack but the language and standard library is really nice and feels 'familiar' as a Java guy.
Totally with you on the FE: less is more! ;) Unfortunately there are these pesky users that want a UI and pay our bills. For that Typescript w/ React is soooo much better than either JQuery or Angular (never had to work with others) ever were going to be in a large shop.
NoSQL is "fine". It's actually boring tech! Just with a new twist. My dad used to tell me something along the lines of "Relational databases? That new-fangled stuff that's way too slow because you gotta join this table and that table and yet another table and all those indices that take forever to update on each write? Nah! We have the tables in exactly the format we need them and we look things up by key! Way faster!". That was on IBM mainframes. Big Iron.
I think we also see a lot of stack choices here that are really great for smaller operations but don't scale well to larger ops. Pure initial speed of untyped languages and magic frameworks are great if you're alone or work with a few co-workers that you're close with and that know all of the magic by heart. Once you reach a certain size and you can't keep the whole thing in your head at all times, typed languages w/ IDE support just become so much faster. You are no longer building new stuff all time or adjust things you intimately know. You have to figure out yet another dusty corner of the code base that was written years ago by people that have since left the company. You really want to be able to just 'click through' the code in your IDE to understand it, without having to have a complete mental model of the whole thing in your head already and remember the 13 magic incantations that make the whole thing actually do something at runtime. Languages and frameworks that allow simple string searchability are king. I see "someString" somewhere, I want to be able to find _everything_ related to that by searching "someString". I don't want to have to try "some_string" or "some-string" or "string" (because "some" is a magic prefix added by some framework) to find related things!
SQL Server, while MS (which I don't like personally in any stack), has good foundations and they evolved it nicely. SQL Server is very boring as in, they licensed an established database and developed it for their own purposes and stack (i.e. their own operating system). For the newbies: MS SQL Server is Sybase ASE basically and the SQL dialect, Transact-SQL is the Sybase SQL dialect. Awesome boring tech that I 'grew up with'.
Love PostgreSQL myself and I am so glad to see that many many more people than "in my youth" are now finally using Postgres instead of MySQL. I'm at a Postgres using place right now and that's great!
Personally as I'm a *NIX guy, my boring backend language is Java and the not quite as boring one on the same JVM is Kotlin. I have dabbled in C# privately and love it from what I've seen, but never professionally because it comes with the 'wrong' rest of stack but the language and standard library is really nice and feels 'familiar' as a Java guy.
Totally with you on the FE: less is more! ;) Unfortunately there are these pesky users that want a UI and pay our bills. For that Typescript w/ React is soooo much better than either JQuery or Angular (never had to work with others) ever were going to be in a large shop.
NoSQL is "fine". It's actually boring tech! Just with a new twist. My dad used to tell me something along the lines of "Relational databases? That new-fangled stuff that's way too slow because you gotta join this table and that table and yet another table and all those indices that take forever to update on each write? Nah! We have the tables in exactly the format we need them and we look things up by key! Way faster!". That was on IBM mainframes. Big Iron.
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 prefer FP style in a statically typed language. I may look at Rust for some performance-sensitive stuff, and possibly Typed Racket for some DSL ideas I’ve been wanting to explore.
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 prefer FP style in a statically typed language. I may look at Rust for some performance-sensitive stuff, and possibly Typed Racket for some DSL ideas I’ve been wanting to explore.
> I’m eager to use Deno more, there’s a lot that appeals to me more than Node.
Like what? I’m genuinely curious.
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.
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.
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
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
C++ for shared mobile libraries, though the more recent projects are going the way of Rust.
Objective C and Java on clients, some Kotlin.
JVM in other places with Java for services, and Scala for EMR/Spark jobs.
Most of my back end runs through AWS though I moved some services on Azure now (mainly just to learn but it worked fine enough to move it for a couple production environments).
For storage I have my own Postgres instances. Way cheaper than any cloud. If I need regionalization and better redundancy, might move to AWS eventually.
Day to day tools involve Omnigraffle, Omnifocus, and iTerm2. Yes, everything on a MacBook Pro with a 1440p 120hz monitor.
Objective C and Java on clients, some Kotlin.
JVM in other places with Java for services, and Scala for EMR/Spark jobs.
Most of my back end runs through AWS though I moved some services on Azure now (mainly just to learn but it worked fine enough to move it for a couple production environments).
For storage I have my own Postgres instances. Way cheaper than any cloud. If I need regionalization and better redundancy, might move to AWS eventually.
Day to day tools involve Omnigraffle, Omnifocus, and iTerm2. Yes, everything on a MacBook Pro with a 1440p 120hz monitor.
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.)
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.)
They seem like a very bright team capable of tackling it to me. Alfred was cool 10, or like 5y ago, but like last time I got into packal (alfred community marketplace) it was all errors over the place, which didn't inspire much confidence to a casual user...
I don't know, I just like what they're doing, The new Extensions api looks really powerful. I ported an alfred script to raycast in like 2min...
YMMV
I don't care about the paid/team offerings honestly, I use it myself, my teammates can use whatever they want. But hopefully they will have enough enterprise customers to make the company thrive
I don't know, I just like what they're doing, The new Extensions api looks really powerful. I ported an alfred script to raycast in like 2min...
YMMV
I don't care about the paid/team offerings honestly, I use it myself, my teammates can use whatever they want. But hopefully they will have enough enterprise customers to make the company thrive
The CPU stack, it's much preferable over the heap for memory management and passing data around ;)
Boring old LAMP stack here. Sure, it's not fancy, but it gets the job done, and it's fast to develop, deploy, and debug without all the fancy abstractions.
One of the reasons we're vanilla is to make it much easier to find people to hire.
Instead of limiting the applicant pool to those who know a particular combination of the frameworks-of-the-day, we can hire from a much larger pool of candidates who are familiar with all of the basics.
One of the reasons we're vanilla is to make it much easier to find people to hire.
Instead of limiting the applicant pool to those who know a particular combination of the frameworks-of-the-day, we can hire from a much larger pool of candidates who are familiar with all of the basics.
Nothing wrong with good old LAMP. Best kept secret is how good PHP has become over the years
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.
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.
Architecture - microservices mostly connected through GraphQL and gRPC (certificate based auth is the shit)
Languages - Java for backend, pure JS for frontend
Frameworks - Spring Boot on backend, pure React on frontend (I like to keep it simple)
Infrastructure - Mostly k8s (with helm to make life easier), Nix for more complex stuff
Databases - Postgres, Mongo, Redis, Elastic... Really depends on use-case...
Languages - Java for backend, pure JS for frontend
Frameworks - Spring Boot on backend, pure React on frontend (I like to keep it simple)
Infrastructure - Mostly k8s (with helm to make life easier), Nix for more complex stuff
Databases - Postgres, Mongo, Redis, Elastic... Really depends on use-case...
I feel like this question is poorly formed in the age of resume-driven development. I prefer types of problems to tackle. But, I don't have preferred stacks so much as stacks I dislike less that are prescribed for my consistent employment.
My least disliked stack is the one that doesn't make me obscure, keeps my future career progression options sub-/Pareto- optimally open, while still making my pay competitive. So in essence I align with whatever is the easiest to adopt and train others on with minimal supervision.
i.e. JS, React, Express, Docker, AWS
My least disliked stack is the one that doesn't make me obscure, keeps my future career progression options sub-/Pareto- optimally open, while still making my pay competitive. So in essence I align with whatever is the easiest to adopt and train others on with minimal supervision.
i.e. JS, React, Express, Docker, AWS
Sounds like we're on the same page.
I think TypeScript will actually overtake JavaScript eventually. It's just so nice to work with. JavaScript will of course always be supported and a prerequisite, but in terms of professional web and Node.js development on a broader scale, it's hard to imagine going back to writing plain JavaScript when TypeScript provides so much value for relatively little effort.
Also, I've updated the original title in light of your comment.
I think TypeScript will actually overtake JavaScript eventually. It's just so nice to work with. JavaScript will of course always be supported and a prerequisite, but in terms of professional web and Node.js development on a broader scale, it's hard to imagine going back to writing plain JavaScript when TypeScript provides so much value for relatively little effort.
Also, I've updated the original title in light of your comment.
I don't know why this was downvoted, but I agree fully regarding Typescript, and was going to post the same thing. I've read good arguments against it by some people, and I agree, it does slow things down a lot.
But if you're not able to write things bug-free on the first try already, Typescript can bring a lot of value as well.
But if you're not able to write things bug-free on the first try already, Typescript can bring a lot of value as well.
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.
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.
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.
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.
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.
For web apps:
F# + .NET + ASP NET on the backend F# + Fable on the frontend
Otherwise just F# + .NET - basically runs everywhere and is good for anything.
F# + .NET + ASP NET on the backend F# + Fable on the frontend
Otherwise just F# + .NET - basically runs everywhere and is good for anything.
Stack:
- Application:
- Flask
- PostgreSQL
- Nginx
- Infra:
- Google Cloud Platform
- Monitoring:
- Prometheus
- Grafana
- Sentry
- Analytics:
- PostHog
- Containers:
- Docker images on GitLab registry
- Repository management:
- GitLab:
- Issue templates for:
- Bugs
- Features
- Incidents
- Communications:
- SlackEveryone 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 something flexible yet works out of the box.
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 something flexible yet works out of the box.
[deleted]
"It depends" is my preferred stack. First define the problem, then we can look at how to implement it. If you mean most websites with simple crud and maybe some user interaction?
Very simple model: DynamoDB, especially if it fits in the free tier to start. More complex model: PostgreSQL, especially for anything between a trivial model and 10 million users (which is most projects). Database migration with Sqitch.
Data access method (middleware): GraphQL, because it's a spec rather than an implementation. My preference all things being equal is the database-driven solution Postgraphile, but I've had good experiences with other solutions like Hasura and Apollo Server depending on the problem. Hides complexity of DynamoDB access. Acts as an ORM layer for relational. The only GraphQL engine I avoid unless there is a good reason/requirement is AWS AppSync; I don't consider it fully baked yet as a general purpose data access solution from dev perspective.
Authorization: JWT, because I don't have to do an extra lookup, especially in a serverless environment with an API Gateway in front. Row-level security if I'm using PostgreSQL.
Authentication: Typically AWS Cognito, because most of my dev work is on AWS, and after you've done it once, redoing is trivial. Google auth for general public access. Simple identity pool for cases with a finite set of users such as an internal tool. If Google Auth on Google Cloud is dead simple, so I give that an honorable mention.
Front end: Svelte, because I know HTML, CSS, and JS very well, and Svelte is little more than that while still allowing fast component-driven development, data binding, and other modern features. Svelte calls the GraphQL API. Once all queries are clarified, the GraphQL layer is given an allowlist of acceptable queries and authorized through the JWT.
I prefer PWAs to native mobile coding or frameworks like React Native. If a PWA is insufficient, my preference would be Ionic due to my stated earlier experience with HTML, CSS, and JS.
I prefer AWS to Azure or Google Cloud. I also prefer regions other than us-east-1. Between those big three, I find prices similar, but options on AWS to be more mature and cover a wider breadth. CDK, CDK Pipelines, and CDK Solutions Constructs is by far my preferred method of developing infrastructure as code. I prefer writing in TypeScript mostly because it allows homogeneous language development from UI on down.
If I ever run into a performance problem that is CPU bound (happens fairly rarely), optimizing the lambda or whatever in Rust would be enticing. Most of the time though, it's just cheaper to scale up the instances/provisioning and move on. Developer time is almost always more expensive.
Very simple model: DynamoDB, especially if it fits in the free tier to start. More complex model: PostgreSQL, especially for anything between a trivial model and 10 million users (which is most projects). Database migration with Sqitch.
Data access method (middleware): GraphQL, because it's a spec rather than an implementation. My preference all things being equal is the database-driven solution Postgraphile, but I've had good experiences with other solutions like Hasura and Apollo Server depending on the problem. Hides complexity of DynamoDB access. Acts as an ORM layer for relational. The only GraphQL engine I avoid unless there is a good reason/requirement is AWS AppSync; I don't consider it fully baked yet as a general purpose data access solution from dev perspective.
Authorization: JWT, because I don't have to do an extra lookup, especially in a serverless environment with an API Gateway in front. Row-level security if I'm using PostgreSQL.
Authentication: Typically AWS Cognito, because most of my dev work is on AWS, and after you've done it once, redoing is trivial. Google auth for general public access. Simple identity pool for cases with a finite set of users such as an internal tool. If Google Auth on Google Cloud is dead simple, so I give that an honorable mention.
Front end: Svelte, because I know HTML, CSS, and JS very well, and Svelte is little more than that while still allowing fast component-driven development, data binding, and other modern features. Svelte calls the GraphQL API. Once all queries are clarified, the GraphQL layer is given an allowlist of acceptable queries and authorized through the JWT.
I prefer PWAs to native mobile coding or frameworks like React Native. If a PWA is insufficient, my preference would be Ionic due to my stated earlier experience with HTML, CSS, and JS.
I prefer AWS to Azure or Google Cloud. I also prefer regions other than us-east-1. Between those big three, I find prices similar, but options on AWS to be more mature and cover a wider breadth. CDK, CDK Pipelines, and CDK Solutions Constructs is by far my preferred method of developing infrastructure as code. I prefer writing in TypeScript mostly because it allows homogeneous language development from UI on down.
If I ever run into a performance problem that is CPU bound (happens fairly rarely), optimizing the lambda or whatever in Rust would be enticing. Most of the time though, it's just cheaper to scale up the instances/provisioning and move on. Developer time is almost always more expensive.
Backend: Phoenix + Postgres
Frontend: Fairly variable, plain/embedded HTML or React
Deployment: PAAS first then terraform if it ever needs to be fine tuned
Frontend: Fairly variable, plain/embedded HTML or React
Deployment: PAAS first then terraform if it ever needs to be fine tuned
Frontend:
- NextJS
- TailwindCSS + TailwindUI
- react-query
Backend: - nestjs - PostgreSQL - docker on Hetzner or digital ocean for deployment
Im currently looking into Hasura/PostGraphile as a possible substitute for large parts of my backend stuff. I mostly build fairly simple CRUD apps, so I’m confident I can reduce complexity by quite a bit
Backend: - nestjs - PostgreSQL - docker on Hetzner or digital ocean for deployment
Im currently looking into Hasura/PostGraphile as a possible substitute for large parts of my backend stuff. I mostly build fairly simple CRUD apps, so I’m confident I can reduce complexity by quite a bit
Postgres, because it’s rock solid and usually a good choice.
Go for the backend because it’s really quick and painless to produce something robust and that will last.
React (with Typescript) for the frontend because I love it’s component model and am personally pretty productive with it. For styles I just use CSS modules.
Go for the backend because it’s really quick and painless to produce something robust and that will last.
React (with Typescript) for the frontend because I love it’s component model and am personally pretty productive with it. For styles I just use CSS modules.
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
Oh that's interesting. I didn't even know this existed. Thanks!
Backend: Haskell, Postgres, Ceph
Frontend: TypeScript, React
Scripting: Python with mypy (static type checking)
Deployment: nix, NixOS, nixops
Frontend: TypeScript, React
Scripting: Python with mypy (static type checking)
Deployment: nix, NixOS, nixops
Backend: Django, DRF, Postgres, Redis, Ray Serve
Frontend / Mobile: React, React Native, MobX, TypeScript
ML: Pytorch
Ops: GCP, K8s
Frontend / Mobile: React, React Native, MobX, TypeScript
ML: Pytorch
Ops: GCP, K8s
what do you think about react native? i hear a lot of bad things
Go / HTML / CSS / Vanilla JS / Postgres
Backend: TypeScript, Node
Frontend: TypeScript (no frameworks)
Lint: TypeScript-Lint
Linux: Bodhi Linux
Database: no preference
I tend to build most everything else myself, the cost of low abstraction high performance execution.
Frontend: TypeScript (no frameworks)
Lint: TypeScript-Lint
Linux: Bodhi Linux
Database: no preference
I tend to build most everything else myself, the cost of low abstraction high performance execution.
Backend: FeathersJS (typescript) + postgresql + nginx
Frontend: Angular + Bootstrap + nginx
Landing Page: Bootstrap + JQuery + nginx
Automation: Ansible
Edit: formatting
Frontend: Angular + Bootstrap + nginx
Landing Page: Bootstrap + JQuery + nginx
Automation: Ansible
Edit: formatting
Bash, Emacs, C.
Deployment: GitHub Actions and Pages
No databases, hashtables are good enough and around 1000x easier and faster.
Deployment: GitHub Actions and Pages
No databases, hashtables are good enough and around 1000x easier and faster.
What type of systems are you building where hashtables are good enough?
Can you provide examples of a range of apps you've worked on with this stack?
Can you provide examples of a range of apps you've worked on with this stack?
See my github. Mostly system stuff: languages, libraries.
https://github.com/rurban/
E.g. I preferred hashtables as database in phpwiki. There I needed sorted pagination, but even without btree's the simple server-less hashtable architecture was 20x faster than mysql/sqlite with its overhead. Also, why logarithmic btree's when you can have constant lookup. Not everything needs to be sorted.
https://github.com/rurban/
E.g. I preferred hashtables as database in phpwiki. There I needed sorted pagination, but even without btree's the simple server-less hashtable architecture was 20x faster than mysql/sqlite with its overhead. Also, why logarithmic btree's when you can have constant lookup. Not everything needs to be sorted.
Scala, Akka, Postgres (or sqlite for smaller projects).
Dash/python for frontend.
Dash/python for frontend.
React SPA
AWS API G/W
AWS lambda running NestJS
AWS dynamodb
AWS SNS/SQS
Managed with SLS and terraform via gitlab and gitlab-ci
AWS API G/W
AWS lambda running NestJS
AWS dynamodb
AWS SNS/SQS
Managed with SLS and terraform via gitlab and gitlab-ci
My preferred stack is:
- Linux OS
- TCP Cubic
- nftables
- BPF
so i can host my Suricata, Zeek, and Snort.
- Linux OS
- TCP Cubic
- nftables
- BPF
so i can host my Suricata, Zeek, and Snort.
backend:golang, sqlite
frontend:html,bulma css, cash js
deployment:terraform
frontend:html,bulma css, cash js
deployment:terraform
If you want to sell on premise enterprise software then Java is a big plus.
Also if you plan on exiting the company to a strategic buyer then your stack will come up in the due diligence and if it is a stack they are not familiar with then they can call off the deal. That is another, minor, reason why enterprise software companies chose Java.
But stacks are always a moving target. Todays hipster stack might be tomorrows mainstream. Postgres was an obscurity compared to MYSQL in the early 2010s and it has picked up tremendous stream since then.
And getting product market fit is more important than choosing the right stack. You can always use duct tape if you get lucky enough to have problems with scaling.
Also if you plan on exiting the company to a strategic buyer then your stack will come up in the due diligence and if it is a stack they are not familiar with then they can call off the deal. That is another, minor, reason why enterprise software companies chose Java.
But stacks are always a moving target. Todays hipster stack might be tomorrows mainstream. Postgres was an obscurity compared to MYSQL in the early 2010s and it has picked up tremendous stream since then.
And getting product market fit is more important than choosing the right stack. You can always use duct tape if you get lucky enough to have problems with scaling.
There's a lot to choose from and it seems like a few are really taking the lead. Maybe I'm biased but I prefer TypeScript, React w/ Styled Components, and PostgreSQL, all of which seem to be pretty dominant. TypeDoc is also really nice for generating clean documentation from type definitions and comments, and Jest for both front-end and back-end unit tests. I usually deploy (static) progressive web apps to Netlify and APIs to Heroku, but I'll probably try Render next.
If you're like me, you probably like to keep things to a minimum, optimized for a specific purpose without any bloat or unnecessary loose ends. I've built many different apps over the years and found myself repeating the same core functionality for each of them, each with their own slightly different stack and implementation as tools and ecosystems have evolved. I'd imagine this is the case for most experienced developers who enjoy building things from the ground up, without becoming dependent on an elaborate framework.
Last Friday I launched a project called Molecule.dev which aims to provide developers (and professional teams especially) with the most solid foundation possible for full-stack apps, skipping all of the most common tedious core functionality. It was originally built for my own purposes, but I've decided to provide it as a sort of "Foundation as a Service". Maybe there's a better way to classify it, but it isn't really a framework. It's a highly specialized codebase designed for the task at hand, complete with thorough documentation, tests, and guides, something I wish I had readily available when building apps over the years, as it would have saved me thousands of hours and tens of thousands of dollars.
Sorry for the (not so) thinly veiled advertisement, but I absolutely need feedback to turn Molecule.dev into something people actually want, and HN is probably the best place to get it. I think there is a lot of potential here.