91–100 of 318 posts
Earlier quoted context omitted.
Forgive my ignorance, I'm not super deep into the Java ecosystem, but is Spring Boot the same as just "Spring"? Or what is the difference precisely?
Spring Boot is a layer on top of Spring that makes it easier to use.
Earlier quoted context omitted.
> You set it up once. It takes a few hours, maybe a day. Until you need to update a dependency on a large codebase, which takes weeks because dependency A doesn't work with dependency B version X, and updating dependency B means that it no longer works with dependency C version Y, and so on. And nobody uses dependency C anymore -- it's unmaintained, so you need to rewrite everything to use dependency D. Then you need…
Dependency management is an unrelated issue and it exists for any platform. Unless you copy paste code or unless you just avoid dependencies. Which is easy to do in TypeScript as well. Nobody says you need to install hundreds of packages.
But it is worth emphasizing that NPM really does stand out as a hazard compared to package repositories for other dev ecosystems. I believe that dangers are more common, and unpleasant outcomes can be more severe.
This is a nice thought, but I suspect hardly anyone who uses a framework or library really understands it, or makes the commitment to try.
Obviously, a subset of really talented users eventually learn to understand the framework, but most are at its mercy.
Even then, you can't study every possible framework before choosing one to master - there are too many, and the cost of understanding the foreign code is simply too high.
So I suspect that in general, people try frameworks by taking a leap of faith, and then, sometimes, make the effort to actually understand it later - if and when it becomes necessary.
I had one of my dev's do several node/js framework POCs in _September_ last 2023 (current year is Jan 2024 at the time of this writing). Nearly all of the POCs won't even run or build any more because the developers have rewritten something and broke all backwards compatibility.
The Javascript/Node ecosystem is terrible for businesses and you're incinerating cash if your company running in the Node/Javascript rat race.
I'm hoping HTMX injects some sanity into frontend development.
So what's the problem with a bundler/transpiler etc? You set it up once. It takes a few hours, maybe a day. Then your platform _is_ TypeScript + React. This abstraction basically never leaks. I never need to look at the transpiled files to find an error. Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.
I actually did laugh out loud.
HTMX is signaling they're around for the long haul, we'll see if they break backwards compatibility or rewrite their API 15 times in the next year. I had one of my dev's do several node/js framework POCs in _September_ last 2023 (current year is Jan 2024 at the time of this writing). Nearly all of the POCs won't even run or build any more because the developers have rewritten something and broke all backwards compati…
As a devops engineer who has recently been tasked with building UIs for our team and our developers, HTMX is a godsend. I create apps that often get steadily worked on for weeks and then only maintenance once and a while after that. I used to write django apps, but recently switched to a go backend with go html templates and htmx. This allows me to push everything in one docker image and avoid the black box nature of…
Earlier quoted context omitted.
Yeah, that sentence surprised me too. While I generally would also consider React more a library than a framework, I think there are arguments to be made that it's a framework. If we go by the common "your code calls a library; a framework calls your code" distinction, then you definitely have to structure your components in a very specific manner so that the React internals can "call your code" to e.g. render one co…
One vital distinction is that even if you define 100 components, nothing will happen unless you call .render from react-dom. Nothing is automatically setup for you. Compare that to Laravel or anything else that is obviously a framework. You write code and put it in a file in the right place, and it gets picked up automatically, most of the time. This makes me still consider React a library, rather than a framework. B…
With Rails nothing will happen unless you call `run Rails.application` or run the `rails server` command. That doesn't make it a library.
Earlier quoted context omitted.
One vital distinction is that even if you define 100 components, nothing will happen unless you call .render from react-dom. Nothing is automatically setup for you. Compare that to Laravel or anything else that is obviously a framework. You write code and put it in a file in the right place, and it gets picked up automatically, most of the time. This makes me still consider React a library, rather than a framework. B…
That's as arbitrary of a distinction as many other ones you could try to draw. With Rails nothing will happen unless you call `run Rails.application` or run the `rails server` command. That doesn't make it a library.