11 ms·

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 t

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".

hardwaregeek 3y ago
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 3y ago
  I think that’s parent comments point. They like that the trends are swinging from complexity to simplicity.
  - lolinder 3y ago
    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.
michaelcampbell 3y ago
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.
willio58 3y ago
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.
willio58 3y ago
> xml is the future Isn't that what htmx and alpine.js are essentially based on?
cxr 3y ago
> 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"?
papito 3y ago
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 3y ago
  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.
  - yurishimo 3y ago
    > 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.
  - 3y ago
lewhoo 3y ago
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 3y ago
  > 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 3y ago
    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.
jonatron 3y ago
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 3y ago
  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 3y ago
    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 3y ago
  Chasing what's popular right now is a recipe for ending up in a has-been tech
npsomaratna 3y ago
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.
xkcd1963 3y ago
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 3y ago
  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 3y ago
    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.
cageface 3y ago
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.
- ravenstine 3y ago
  [removed]
  - 10xDev 3y ago
    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 https://twitter.com/youyuxi/status/1057291776724271104
    - pcthrowaway 3y ago
      Kind of like how JSX is actually JSXScript, sure
      - zdragnar 3y ago
        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.
        waboremo 3y ago
        JSX is necessary to use React otherwise you create even more footguns in a library that's littered with them.
        cassepipe 3y ago
        So you're saying that svelte does not just transpiles to js/css/html ? Could you expand on that a bit more ?
a_c 3y ago
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
tacker2000 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      Do you mean you skip the project’s container config and set up your own? Or just skip containers entirely?
      - ehnto 3y ago
        Skip containers usually, if one isn't provided that works it's unlikely there's time or budget for me to maintain my own.
DigitalSea 3y ago
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 3y ago
  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.
andsoitis 3y ago
> 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?
- aobdev 3y ago
  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.
- ehnto 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
      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.
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
kubb 3y ago
why not just use pure typescript + postgres + go/java? all these libraries bloat your app for no good reason
deleted 3y ago
[deleted]
EMM_386 3y ago
> 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 3y ago
  > 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.
JodieBenitez 3y ago
Wouah ! Sam&Max, je me demandais bien où vous étiez passé.
- sametmax 3y ago
  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 3y ago
    ça m'a fait un choc de voir le domaine aujourd'hui :-P
pmarreck 3y ago
Ha, tell me you've been a full stack dev for over 10 years without actually doing so... ;)
amadeuspagel 3y ago
I love svelte, but how is it minimalist? How is requiring a compiler for a web app minimalist?
- tmnvix 3y ago
  Maybe the limited number of dependencies? I consider fewer dependencies to be one part of a minimalist approach.

hardwaregeek 3y ago

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 3y ago
I think that’s parent comments point. They like that the trends are swinging from complexity to simplicity.
- lolinder 3y ago
  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.

michaelcampbell 3y ago

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.

willio58 3y ago

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.

willio58 3y ago

> xml is the future Isn't that what htmx and alpine.js are essentially based on?

cxr 3y ago

> 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"?

papito 3y ago

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 3y ago
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.
- yurishimo 3y ago
  > 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.
- 3y ago

lewhoo 3y ago

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 3y ago
> 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 3y ago
  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.

jonatron 3y ago

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 3y ago
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 3y ago
  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 3y ago
Chasing what's popular right now is a recipe for ending up in a has-been tech

npsomaratna 3y ago

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.

xkcd1963 3y ago

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 3y ago
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 3y ago
  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.

cageface 3y ago

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.

ravenstine 3y ago
[removed]
- 10xDev 3y ago
  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 https://twitter.com/youyuxi/status/1057291776724271104
  - pcthrowaway 3y ago
    Kind of like how JSX is actually JSXScript, sure
    - zdragnar 3y ago
      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.
      - waboremo 3y ago
        JSX is necessary to use React otherwise you create even more footguns in a library that's littered with them.
      - cassepipe 3y ago
        So you're saying that svelte does not just transpiles to js/css/html ? Could you expand on that a bit more ?

a_c 3y ago

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

tacker2000 3y ago

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 3y ago
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 3y ago
  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 3y ago
    Do you mean you skip the project’s container config and set up your own? Or just skip containers entirely?
    - ehnto 3y ago
      Skip containers usually, if one isn't provided that works it's unlikely there's time or budget for me to maintain my own.

DigitalSea 3y ago

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 3y ago
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.

andsoitis 3y ago

> 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?

aobdev 3y ago
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.
ehnto 3y ago
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 3y ago
  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 3y ago
    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 3y ago
    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.

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

kubb 3y ago

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

deleted 3y ago

[deleted]

EMM_386 3y ago

> 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 3y ago
> 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.

JodieBenitez 3y ago

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

sametmax 3y ago
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 3y ago
  ça m'a fait un choc de voir le domaine aujourd'hui :-P

pmarreck 3y ago

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

amadeuspagel 3y ago

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

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