[sametmax]

I like the fact minimalist approaches, like svelte, htmx and alpine.js are getting more and more traction.

I felt like fighting this fight alone for years in the golden years of node, webpack and react where everybody was creating crazy stacks and adding GraphQL and so on, to basically get what Django + jquery did 10 years ago in a tenth of the time and code.

So far I also survived:

- xml is the future

- let's use nosql for all the things

- you must use the same language at the back and front

- yes, you site must have an AMP version (ah, you forgot this one, didn't you? It was sooo imporant, and then pouf, it was gone like tear in the rain)

- yes, your home page must be an SPA

- you can't code anything without async

- you can't live without a message queue

- everything must become a micro service

- of course you need a container for that

- of course you need a orchestrator to organize those containers

- of course you need the cloud, it would be crazy to deal with those containers and orchestrators yourself

- dude, why do you have a server? Use a serveless backend!

- dude, why do you have a backend? Just call saas from the edge!

Every year, some generation of engineers have to learn the concepts of "there is no silver bullet", "use the right tech for the right problem", "your are not google", "rewriting a codebase every 2 years is not a good business decision", "things cost money".

[papito]

It's the second, younger generation of devs who are realizing that "complexity kills". Those of us who started in 2000's have already seen this. It's a natural cycle. We are seeing a spring-back to monoliths and away from micro-services and crazy tooling chains.

It was completely unnecessary, and most importantly, cost the industry a fortune. If you are older, you have been wondering why you need to work more to achieve less. To me this has been demoralizing, and actually put me through some tough cycles of depression. I no longer enjoy this job. I used to DO things and walk away from my desk every day having a sense of achievement. Now it takes 3 days to set up your microservices locally just to reproduce a bug, apparently because your system with moderate traffic needs to look like Shopify.

Bad example - Shopify is a monolith.

[Gasp0de]

I think technology choices should be made depending on the team. If you have 5 teams with 10 people each, then it is a great idea if your service is comprised of 5 microservices that talk to each other across team borders through well defined APIs. If it takes you 3 days to run your microservice locally, then you somehow didn't set up your development environment when you should have.

[gpderetta]

> If it takes you 3 days to run your microservice locally, then you somehow didn't set up your development environment when you should have.

The fact that setting up your dev env takes such complex rituals and incantations that need to be prepacked in a spellbook is itself a red flag.

[EnragedParrot]

A well-tooled development environment takes minutes to set up.

[papito]

A well-tooled environment does not just spring out of an ether. Maintaining proper tooling in a distributed system often requires more work than the system itself. In a lot of cases, the business does not even consider this kind of time commitment, pushing the team to churn out features, and who eventually just bog down in insane complexity.

[EnragedParrot]

This strikes me as a, "poor carpenter blames his tools" situation. Obviously if a business does a bad job considering the needs of their engineers then the needs of their engineers won't be met, but that doesn't mean that the modern development environment is the problem.

[yurishimo]

> then you somehow didn't set up your development environment when you should have.

This is great! ...in theory. But why do so many teams seem to have these kinds of problems? I think we have to come into these conversations with an over abundance of good faith that people are trying their best. Something in this microservice architecture conversation of the past decade isn't working as elegantly for a huge portion of the devshops that try it.

People should do lots of things, but that doesn't mean they always get done. There is merit to the argument that you may do things in a simpler way and adopt a different approach to cross team communication and complexity management. Your final sentence reads as a moral judgement equivalent to "your doing it wrong" without offering a solution.

We've had a decade of telling people they're doing it wrong and it's still being done with the same problems over and over and over again.

[chasd00]

> If you have 5 teams with 10 people each, then it is a great idea if your service is comprised of 5 microservices

i've always thought a micro-service architecture should be decided and defined by the org chart and not technology.

[EnragedParrot]

This sounds like a symptom of you falling behind the technology curve more than a problem with the technology curve. Most people are achieving vastly more with newer tech than ever could have been done in the early 2000s. You've gotta be looking through some densely rose colored glasses if you think that that the web in the 2000s was just as powerful as the web of today.

[papito]

I resisted learning a lot of it knowing that there will be a snap-back to simpler designs long-term, and it's happening now.

And when I tried, it went nowhere. After months of work on my side project with Electron, Typescript, and Vue, I was in the same place because every time I opened IntelliJ, it seemed all of my effort went into just having it build again.

Now I chose ArrowJS for my project, and it's been a delight. Look, I get it, but I would refrain from accusing the other person of laziness in this case.

Learnings from 5 years of tech startup code audits: https://kenkantzer.com/learnings-from-5-years-of-tech-startu...

The very first two points prove that it's not just me.

[EnragedParrot]

I don't think there is laziness in falling behind the technology curve - the things that worked ten years ago still work today and if you're shipping code then what you're doing is working. But new technologies aren't overly complex and they generally make a developer's life easier, not harder, but they all come with a learning curve. And the landscape evolves quickly, so in order to leverage them you have to stay on top of it.

[metalforever]

This comment is arrogant and objectively isn't correct.

[lolinder]

Your parent comment definitely came off as arrogant, but your reply doesn't come off any better. If it's objectively incorrect, then you can contribute to discussion by explaining how and why. A low effort drive-by dismissal isn't appropriate for HN.

[metalforever]

This is anecdotal, but I have been in the industry > 10 years now and worked for a lot of employers. What they have required of me for the frontend has pretty much been the same more or less throughout. But recently, with the large amount of funding, companies have had a large blow up in payroll and a talent shortage. The talent shortage has resulted in some juniors getting hired that would not have gotten hired during the great recession. These juniors, on average, need to know a lot more now than back then due to the complex stack. This has resulted in a lot of breadth of knowledge but not a lot of depth. Over time , large teams of inexperienced people have turned what could be a simple frontend created by 1-2 developers in a large 15 developer behemoth that is difficult to maintain and keep secure. It is difficult to reason about for most newer developers so a lot of the time is spent handling edge case bugs instead of getting the job done. Usually their needs really aren't different. It's often just an intranet app or b2b. These don't have scaling needs and you can create reactive asynchronous websites without the complexity here and without reinventing the wheel. Sometimes, the complexity introduced by this complex stack is required (i.e. the app being created is complex). Everyone thinks their app is complex. It almost always is not complex, at least on the frontend, and it could have shipped earlier and with less bugs if the complex stack was not introduced.

[azangru]

> it takes 3 days to set up your microservices locally

Why do you need all microservices locally? Why wouldn't you set up just the relevant one, and proxy the traffic to the rest of the services already deployed? Or, failing that, why don't you have a docker-compose file that has already pre-configured your services to run locally?

[papito]

What about the database contents?

[jonatron]

There's a HN world of what's gaining traction and what "everybody" is using, and the real world reality. If I search for Django jobs on indeed, I get way more results for Django than if I search for Svelte (183:11). If I ctrl+f on "Who is Hiring?", the ratio gets a lot closer (13:4).

[prometheon1]

I think sametmax was saying that "everybody" is using React for usecases that Django could do long ago, and that Svelte is in the "gaining traction" category.

On indeed.com I get 311 Django jobs and 3421 React jobs so in that sense it looks like "everybody" moved from Django to React.

[EnragedParrot]

I hear the argument being made, it just doesn't make any sense. We are using React to do things vanilla JS could do eyears ago. That doesn't mean React doesn't make doing those things easier. I like Svelte as well, but it likely wouldn't exist today without lessons learned from other frameworks like React.

[pmarreck]

Chasing what's popular right now is a recipe for ending up in a has-been tech

[EMM_386]

> Every year, some generation of engineers have to learn the concepts of "there is no silver bullet", "use the right tech for the right problem", "your are not google", "rewriting a codebase every 2 years is not a good business decision", "things cost money".

Ah, yes, the wheel of time. I've been through all of the things you've listed and more. My first job programming was in 1996 and involved HTML/JS/CSS and SQL. JS came out in 1995. CSS in 1996.

First it was cgi-bin, ASP, then ASP.Net and ASP.Net MVC, now I work with SPAs. When I hear the term "SSR" it instantly throws me back 20 years, when everything was server-side rendered.

As you mentioned, it's the same with things like SQL. When JavaScript exploded, we got NoSql, because it's easy to toss JSON into a KV store. Then a few years later, you see many more posts about people discovering how powerful relational SQL is, or awesome SQLite is, etc. It's the next generation realizing that things may have been done a particular way for a reason.

On the front-end, I work with enterprise Angular now. I have no desire to move on to the next shiny object/framework, because if it's bleeding-edge, that means the community is small. And if it doesn't explode in popularity, that community will disappear and you'll be left with an application running on something nobody knows. I try to keep pace with Angular's 6 month cadance and so far, so good. My current project has gone from 13-16 without any issues.

And don't get me started on microservices. Get off my lawn.

[stcredzero]

> Ah, yes, the wheel of time. I've been through all of the things you've listed and more.

Heh. "The Wheel of Time." It's a very good name for what Alan Kay called, "not quite a field." In the modern era, fields of knowledge aren't supposed to forget what they learned every 5 years or so.

[cageface]

I like Svelte but I’m not sure I’d describe it as “minimalist”. It’s a new language with its own compiler and reactivity system.

[RamblingCTO]

Yeah, I did a project in sveltekit + go and then one in htmx, alpinejs + golang. Sveltekit is quite big and not low maintenance.

Not sure what exact use case sveltekit would be good for, that can't be solved with htmx + alpinejs.

[michaelcampbell]

> Not sure what exact use case sveltekit would be good for, that can't be solved with htmx + alpinejs.

I mean, reductio ad absurdum:

    s/sveltekit/<anything>/; s/htmx + alpinejs/assembly/;

Of all of pg's writings, the one with "the blub paradox" in it has proven to me to be the one I see crop up again and again.

[devbent]

Svelte by itself is super tiny.

Sveltekit does a lot more stuff and is accordingly bigger.

[biomcgary]

htmx, alpinejs + golang is the exact stack I've been thinking about. I'm not a front-end developer, but want to be able to prototype things quickly. Are you aware of any public examples of this stack that go beyond "Hello, World!"?

[RamblingCTO]

I'm not actually, but I found it very easy to learn. The documentation really is enough. Htmx is used for requests and replacing content. You just need to figure out when to replace what. Alpine is used for on-site interactions. You can hit me up on twitter if you have questions, love to help other people with that stack! https://twitter.com/andinfinity_eu

[ravenstine]

[removed]

[10xDev]

Reactive declarations that work using syntax outside of JS thanks to the compiler does make it a bit more than just JS. https://twitter.com/youyuxi/status/1057291776724271104

[pcthrowaway]

Kind of like how JSX is actually JSXScript, sure

[zdragnar]

JSX is, imho, more akin to a macro; the syntax is replaced with simple expressions. Technically, the JSX syntax isn't even necessary to use React, though most people prefer it.

Svelte bakes itself fully into your code in a way that you can't do without the compiler and still be using svelte.

[cassepipe]

So you're saying that svelte does not just transpiles to js/css/html ? Could you expand on that a bit more ?

[waboremo]

JSX is necessary to use React otherwise you create even more footguns in a library that's littered with them.

[DigitalSea]

One of the exact reasons I've been working with Aurelia as my Javascript framework of choice since 2015. Aurelia 1 has served me well and I have apps that have been in production for eight years untouched. They just keep running without fail and they're so simple. Similarly, Aurelia 2 (currently in beta) is even better and as stable (same templating syntax, DI, etc). I tend to avoid all of the hype in the front-end space. The only thing clients and companies care about at the end of the day are results.

- Simple syntax

- Convention over configuration, but gives you the ability to configure it when you need too

- Standards compliance

- Has state management, routing, validation, Fetch client and translation packages

- Completely written in TypeScript, so everything is strongly typed

- Great docs

- HTML templating syntax is standards compliant, so everything looks similar to native HTML. None of this weird curly, banana in a box, square bracket and weird symbol nonsense that is not intuitive.

People always ask, "Why not React?", "Why not Vue?", "Why not Svelte?", etc. People think you need to use the most popular option like it's a popularity contest. I find it laughable to build a React application in 2023 you don't just `npm install react`, people tell you to use something like Next.js which is a framework built on React (the very thing developers tried arguing for years you didn't need to build apps and that libraries were enough). I can guarantee that most of the people in this comments section either tried Aurelia years ago when it was v1 or have never heard of it. Then you would have some that won't use it because it's not big or popular enough.

I can build an app using Aurelia faster than most developers could using React or any other convoluted framework or library. Even Vue used to be nice and basic, before Vue 3 where they decided they would become React Lite and introduce complexity in the way you build things because everyone bought into the myth everything has to be functions and classes are bad.

At the end of the day the safest strategy is to use what works for you and ignore everything else.

[stephenhuey]

2015 was when I used Aurelia, too. As someone who used the first version of Angular, it was a breath of fresh air, and I agree that you can get results quickly using Aurelia. I left that company so haven't been using it, but I've secretly hoped people would catch on and switch to it somewhere down the road. But as you say, it's fine that it's not popular--quite often, the best things are not the popular things.

[DigitalSea]

Sadly, Aurelia didn't quite catch on like other options. But, it's funny when you look at libraries like Svelte, many of their touted features like reactivity not only existed in Aurelia, but in Durandal before it. I think it comes with age. I'm in my mid-thirties now, so I just use what I want to use that gets results. But I remember being young and hungry as a developer in my twenties, you used what everyone else used because of job prospects.

I think Aurelia 2 still has the potential to make a comeback. Maybe not popular like React or Vue, but still. The beta has been quite good. It just needs more awareness.

[duringwork12]

I used to love knockout.js. this brought memories

[npsomaratna]

This reflects my experience from the 00's onwards. Survived and avoided most of these—except the nosql bandwagon. A worn out and wiser man, ended up switching back to relational DBs several years later.

[lewhoo]

Unfortunately it takes time and experience to filter out the hype and marketing but hype and marketing usually acts against good experience. I thought something is wrong with me when a thought came to mind that (early) no-sql really really could use relations. People said I'm silly for trying to make no-sql sql-like.

[tarkin2]

> it takes time and experience to filter out the hype and marketing

When you have that experience, you subsequently apply for jobs that demand you be up-to-your-elbows in the over-hyped and over-marketed tech.

The industry, eagerly lapping up any and all shiny-marketing and advocacy, financially incentivises bandwagon-jumping over listening to experience.

[danjac]

I think (or rather, hope) that this is a symptom of the low interest-rate era, and companies may be less willing to waste money and development cycles on chasing the latest shiny.

[hardwaregeek]

Honest question: how is htmx/svelte/alpine any different than other trends? Could it just be that you prefer this particular spot in the trend cycle?

[comte7092]

I think that’s parent comments point. They like that the trends are swinging from complexity to simplicity.

[lolinder]

But that was the line that noSQL advocates were pushing. You don't need this big complex relational database, just make everything simple JSON and call it good.

Then it turned out that data actually is just complicated, and managing that complexity is off and easier with a relational database.

Sometimes simplicity can be an illusion.

[cxr]

> in the golden years of node, webpack and react where everybody was creating crazy stacks and adding GraphQL and so on, to basically get what Django + jquery did

What if I told you jQuery was itself a "crazy stack"?

[willio58]

My org uses serverless to great success. I highly recommend trying it out if you haven't. It's just so nice to create a function and know we don't have to configure any part of the server to know it'll run, and then the true benefit comes from the almost infinite-feeling scale we can get at a super low price.

Of course, serverless is a misnomer. But it does mean you have to think of the server much less.

[amadeuspagel]

I love svelte, but how is it minimalist? How is requiring a compiler for a web app minimalist?

[tmnvix]

Maybe the limited number of dependencies? I consider fewer dependencies to be one part of a minimalist approach.

[tacker2000]

Exactly my words!

The only thing that I would single out here as actual progress is the container thing. This really has helped me a lot, with local dev and deployment. I havent touched any orchestration like k8s yet though, so I am still on the “lite” side.

[rgrieselhuber]

Totally agreed on containers but I’ve noticed so many developers promptly ignore using the containers that are set up for them when developing locally. Then days are wasted again on deployment issues down the road.

[ehnto]

The issue I always run into is that containers don't get maintained. I have never encountered a project where a container "just worked".

I absolutely love them when they do, but they have wasted so much of my time when they don't that I just skip them now. It takes me 5 minutes to set up a local env, and with a staging env at parity with production to test on there's never any issues.

[tacker2000]

Do you mean you skip the project’s container config and set up your own? Or just skip containers entirely?

[ehnto]

Skip containers usually, if one isn't provided that works it's unlikely there's time or budget for me to maintain my own.

[andsoitis]

> you can't code anything without async

I'd like to understand what you mean by this. As soon as you introduce network requests in a system, don't you need to deal with asynchrony?

[ehnto]

You can just wait for the network request to finish before continuing. Many actions require it anyway.

Asynchronous code should be intentional and deliberate in my opinion, but in modern JS/Node it is the default which leads to all kinds of crazy workarounds, callback hell and race conditions. Node has the same issue PHP had now, where green devs will crank out code without realising they need to be watching out for these things.

Is it cool that a .forEach loop could be async? Heck yeah, should it be the default? The shit people write around .forEach loops suggests, maybe not!

[c-hendricks]

What's not deliberate about marking a function as `async`, and marking calls that need to be awaited with `await`?

Callback hell? When was the last time you gave an honest effort into JavaScript?

[belmont_sup]

He still has a point. Go code and similar languages hide the concurrency. You write synchronous looking code most of the time, but underneath, libraries and runtimes ensure you’re running concurrently.

[ehnto]

Most libraries are async and some standard lib stuff is unexpectedly async as well, so you are often handling async concerns even if what you're writing is better syncronous.

My team and I don't write callback hell, it's just a very common pitfall and you still see it all the time. You can't bubble wrap everything I suppose.

[aobdev]

Everything in JS started with callbacks, then promises came on to the scene with libraries like Bluebird, then the async/await syntax was added to the spec. The language was always able to handle concurrency but it was a long road to the current state.

[pmarreck]

Ha, tell me you've been a full stack dev for over 10 years without actually doing so... ;)

[michaelcampbell]

Nice list; I am not a primarily front-end dev so I can't say I've lived this but I've been around long enough to remember all of these; sometimes painfully.

[JodieBenitez]

Wouah ! Sam&Max, je me demandais bien où vous étiez passé.

[sametmax]

En ce moment on s'amuse à générer du hentai avec stable diffusion en Python. Ca aurait fait un bon article pour le blog si il existait encore :)

[JodieBenitez]

ça m'a fait un choc de voir le domaine aujourd'hui :-P

[a_c]

The list is not complete without mentioning the site has a total number of users equal to or less than the amount of people you can spam and still consider you a friend

[kubb]

why not just use pure typescript + postgres + go/java? all these libraries bloat your app for no good reason

[willio58]

> xml is the future

Isn't that what htmx and alpine.js are essentially based on?

[xkcd1963]

Software itself hasn't "evolved" over the last 40 or 50 years. It only ever gets better because the hardware becomes better. There is no true innovation in software development. Folks that "innovate" either reinvent the wheel or capitalise on hardware improvement.

[belmont_sup]

Look at all the fascinating runtimes that have evolved. Erlang, Haskell, Go, Rust, and include any other. You don’t consider any of these evolution? Back then, programmers were still using threads for everything. Now we have “green threads”. One example of a pretty great evolution. Albeit it does feel like software evolves slower than hardware.

[xkcd1963]

I talked about my statement with a friend the other day and was able to consolidate my stance.

On an intuitive level software seems like a tool to me. Latin had much more gramatical rules than todays English but that doesn't mean it "devolved" or that English isn't as powerful as Latin.

Blockchain is a mathematical idea and software the tool to use it. And LLMs are much more about statistical problem solving enabled through more computing power than about inventing something new.

And correct me if I'm wrong but aren't virtual threads fast enough also because of more computational power? A virtual machine is usually 1/3 times slower than the native machine it runs on.