591–600 of 875 posts
Earlier quoted context omitted.
according to the latest stackoverflow developer survey, NodeJS is extremely common and used quite a bit more than things like ASP.net ( https://survey.stackoverflow.co/2022/#most-popular-technolog... )
is node included when choosing front ends like react or vue?
Earlier quoted context omitted.
Ouch! I’ve worked in two kinds of organizations. In one of them when there is a ‘small’ ticket from the viewpoint of management, one programmer is responsible for implementation but might get some help from a specialist (DBA, CSS god, …) In the other a small ticket gets partitioned to two, three or more sub teams and productivity is usually reduced by a factor more than the concurrency you might get because of overhe…
I’ve worked at the same company for a long time. For about 15 years, my team was embedded in a business team and we managed things however we wanted. We could move very quickly. Then, about 5 years ago, we were moved into the tech organization. We were forced to adopt agile, sprints, scrum masters, jira, stand ups, etc. It probably takes 10 times longer to get the same amount of work done, with no improvement in qual…
Earlier quoted context omitted.
I don’t agree that Go is more common than node (or other options you did not mention like .NET).
I wonder if part of the confusion here is that “backend” is pretty overloaded. There are backends like API servers, and web server backends (which at Google they call “frontends”!) I’d guess that Go is relatively more popular than Node for API servers, and Node is more popular for web servers. And as you note, both are probably less popular than languages like Java and PHP.
Earlier quoted context omitted.
Sounds like the problem is having "sprints". As far as I know, most teams at Google and Meta don't.
They need scaled agile, where every 5 or 6 sprints you group them into an program increment, with extra overhead and even more ridiculous symbolic rituals. Your team is held to an arbitrary commitment months out, then executives shift the ground under your feet and make everything irrelevant. Dev teams love it!
Earlier quoted context omitted.
How is it fundamentally any different than 10s of thousands of clients requesting JSON or whatever other serialized data format?
Insofar as only retrieving data and returning it as json is way less work for the server than retrieving data plus rendering it.
HTML is more verbose, so I would guess that JSON serialization is slightly faster, but I doubt there's an order of magnitude difference. (I could be proven wrong though)
I agree that taking HTMX to the extreme where _all_ interactions require a request to the server is too much overhead for interactive web apps. But there's likely a good middle ground where I can have mainly server side rendering of HTML fragments with a small amount of client side state/code that doesn't incur particularly more or less server load.
Earlier quoted context omitted.
>simplicity Can be achieved in MPAs and SPAs alike. I'd also argue that having state floating around in HTTP requests is harder to reason about than having it contained in a single piece in the browser or in a server session. Granted this is not a problem of HTMX, but of hypermedia. There is a reason why HATEOAS is almost never observed in REST setups. > two-codebase problem This is a non-problem. In every part of a…
> There is a reason why HATEOAS is almost never observed in REST setups. I saw the HTMX creator floating around the thread so hopefully he can confirm, but my understanding is HATEOS is a specific implementation of a REpresentstional State Transfer API. JSON is often used for the API, HTMX uses HTML instead but it is indeed still a REST API transferring state across the wire. My shift key really doesn't appreciate al…
https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
HATEOAS (or the hypermedia constraint) is a requirement for a REST-ful system, as the creator of the term (Roy Fielding) says here:
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
I have an rewritten wikipedia article on HATEOAS here:
https://htmx.org/essays/hateoas/
And I agree it doesn't make much sense outside of a hypermedia system (like the web), being consumed by humans:
https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
Earlier quoted context omitted.
https://htmx.org/essays/splitting-your-apis/
What if we need the same backend to be usable by more than one client? What if those clients aren't even a SPA, but a wrapper library, or a native app? What if we need internal scripts that manage the content in the backend using the same API? What if we need to redesign the client without touching the backend? HTMX doesn't address any of that. YAGNI is often only true for the original developers, not everyone else w…
The data API can address all of the concerns you have.
The hypermedia API, being consumed by an htmx front end, can then take advantage of the strengths of hypermedia (e.g. the uniform interface giving you a lot of flexibility in aggressively refactoring your API.)
Please, read the article.
Earlier quoted context omitted.
> BINGO. At times, it seems everyone is talking through each other because we are thinking of different things Glad to hear. Yes, it seems like the post and the comments are largely missing the functional issue at play. > the blog post we are talking about which displays awful without running JavaScript Yeah, case in point, perhaps.. I mean if you have two paths (incremental and full) to reach the same state, you bet…
> I have an app based on Tauri which is web based, and the msi is 10Mb. It’s never had any perf issues. And that's on the heavy side! Tauri is awesome, it's unfortunate most developers opt for Electron to reduce the amount of testing needed between browser engines. I agree with you that a well-made web app is snappy and works well. I don't think we'll go back to native apps (for now), what I hope for is simply that i…
The browser engine differences isn’t that big of a deal, because you already have standard ways of dealing with it on the web. I think today the main reasons people pick Electron today are tooling, desktop integration features and Node. Tauri is catching up insanely fast though. I am very happy that I jumped on the bandwagon fairly early.
> in which case I hope lighter weight engines purpose-made for web applications get adopted as an alternative to shipping the entirety of Chromium with each program I download
Absolutely, shipping a browser engine is insanity and should always have been a stopgap at best imo. Even servo is way too heavyweight to ship with each app. Good news is with OS having native webviews we’re 80-95% there already, so we don’t even have to deal with that tradeoff – this let’s an app have a perf overhead of ~1 typical browser tab. It’ll take a moment to iron out all kinks but it’s already perfectly acceptable on most deployment targets. Honestly, Linux is just as bad when it comes to distribution. Distros have been in some perpetual siloing mindset and have not been able to get behind a decent and unified distribution story. It has nothing to do with web though.
> it's just that there is currently no interest from the big players to keep funding these developments
The big players have been so awful that even if you disregard the abysmal interop story, distributing native apps is still orders of magnitude more hassle than the web ecosystem. Imo Electron was born as an escape hatch from that disaster, not because frontend developers conspired to eat all the worlds RAM for fun. I absolutely agree that the big players should passively fund projects like servo and tauri. I don’t want them anywhere near strategic decision making though.
Earlier quoted context omitted.
What if we need the same backend to be usable by more than one client? What if those clients aren't even a SPA, but a wrapper library, or a native app? What if we need internal scripts that manage the content in the backend using the same API? What if we need to redesign the client without touching the backend? HTMX doesn't address any of that. YAGNI is often only true for the original developers, not everyone else w…
In the article I recommend splitting your hypermedia and data APIs up into two separate concerns. The data API can address all of the concerns you have. The hypermedia API, being consumed by an htmx front end, can then take advantage of the strengths of hypermedia (e.g. the uniform interface giving you a lot of flexibility in aggressively refactoring your API.) Please, read the article.
I use tech like HTMX because, as a team of one, I have no other choice. I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted. After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with J…
I use htmx on my current project, and it's like a dream. I'm happy to sacrifice a bit of bandwidth to be able to do all the heavy lifting in python. On top of that, it makes testing much much easier since it turns everything is GET and POST requests. I'd add a couple features if I were working there (making css changes and multiple requests to multiple targets standard), but as it stands, it's a pleasure to work in.