Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx Is the Future

quii.dev

Post reply on HN
Print view View original

461–470 of 875 posts

Re: Htmx Is the Future

#461

Post by ukuina »

agrippanux wrote: post #440
fridgemaster wrote: post #421

Earlier quoted context omitted.

Angular 2 works fine out of the box, and already provides a good architecture that noobs struggle to come up with in "freestyle" solutions like React. Angular's bi-directional binding is way superior and simpler to use vs React's mono-directional binding: you can just use bound variables, no need to do complicated setState or use abominations like Redux. Vue also has bi-directional binding. Essentially there are many…

You may of not used React in the past few years, but setState fell out of favor a while ago with the release of the useState hook and Redux (which I agree is an abomination) isn't necessary for 95% (imo) cases, again thanks to hooks. For bound variables you can use MobX or signals in Preact.

How does something "fall out of favor" in React?

Is it deprecated?

Re: Htmx Is the Future

#462

Post by zamnos »

pphysch wrote: post #457
tabtab wrote: post #455

Earlier quoted context omitted.

But if you don't blend the two, then you have a DRY violation. Someone should only have a say a field (column) is required in one and only one place, for example. The framework should take care of the details of making sure both the client and the server check. I myself would like to see a data-dictionary-driven app framework. Code annotations on "class models" are hard to read and too static.

DRY has its limitations. Client-server boundary is a good candidate for such a limit.

that seems like an easy way for validation logic between the two to fall out of sync. Limits want to be enforced on the back end, definitely, but if the frontend also does the same validation the user experience is better, so you want to do some there as well (eg blank username does not need to do the slow round trip to the server). Through the magic of using JavaScript on both ends, the exact same bit of code can, with a bit of work, be used on both the front and the back end, so you can get the best of both worlds.

Re: Htmx Is the Future

#463

Post by benbristow »

Glyptodon wrote: post #429
cutler wrote: post #360

Earlier quoted context omitted.

Wasn't Ember the idiomatic choice before React? I don't remember Angular being that popular with Rails devs generally.

I definitely associate it (Angular) with Python BE devs for some reason.

It was/is quite popular with .NET developers due to TypeScript being very similar to C# and implementing similar patterns like dependency injection (I know dependency injection/IOC isn't .NET specific).

Re: Htmx Is the Future

#464

Post by zamadatix »

Dylan16807 wrote: post #378
zamadatix wrote: post #72

Earlier quoted context omitted.

I understand the argument I just disagree that having a separate "bool isPasswordValid()" and "float isPasswordValid()" (really probably something that returns what's not valid with the score) function is in any way simpler than a single function used on both sides. Sure, the server may not care about the strength level but if you need to write that calculation for the client side anyways then how are you saving any…

In this situation code for a good strength meter is going to be an order of magnitude or two more complicated than the boolean validity check. Porting 50x as much code to the server is significantly worse than having two versions or having one shared function and one non-shared function.

You shouldn't have to port anything. If you mean in the opposite case of two separate languages between client and server side then yeah, of course - by definition you're rewriting everything and there is no way to reuse code. I'm not clear how you're reaching anywhere near 50x complexity though. You're writing something like this on the client side (please excuse the lazy checks):

  function basicValidatePassword(password) {
    const minLength = 8;
    const maxLength = 64;
    const isValidChars = /^[A-Za-z0-9]+$/;
    const hasUpperCase = /[A-Z]/;
    const hasLowerCase = /[a-z]/;
    const hasSpecialChar = /[\W_]/;

    const results = {minLength: password.length >= minLength,
      maxLength: password.length  item);

    return results;
  }
Then instead of writing another one on the server that only checks the password isn't blank, is less than the maximum, and has valid characters you're just reusing the full 6 check code. That's only twice as many checks, not even twice as many lines, and it's already written. You really should check all 6 again on the server anyways, but that's beside the point. Better still, if you do the reuse as a build step via shared function library file or similar you don't need to copy/paste and it stays in sync automatically.

Of particular note there is no UI code here because the meter's UI code is not related to the check function beyond it reads the return value.

Re: Htmx Is the Future

#465

Post by ukuina »

recursivedoubts wrote: post #190
cogman10 wrote: post #185

Earlier quoted context omitted.

It's not clear to me, but how and where is state managed? In the OPs article, it looks like the only thing going over the line is UUIDs. How does the server know "this uuid refers to this element"? Does this require a sticky session between the browser and the backend? Are you pushing the state into a database or something? What does the multi-server backend end up looking like?

https://htmx.org/essays/hateoas/

Doesn't this make serverless read-only apps (that only require a fileserver) effectively impossible?

In a serverless read-only app, all business logic and state is maintained on the browser.

Re: Htmx Is the Future

#466

Post by gofreddygo »

tored wrote: post #362
v0idzer0 wrote: post #234

Earlier quoted context omitted.

It really wasnt about client side validation or UX at all. You can have great UX with an MPA or SPA. Although I do think it’s slightly easier in an SPA if you have a complex client like a customizable dashboard. Ultimately it’s about splitting your app into a server and client with a clear API bounday. Decoupling the client and server means they can be separate teams with clearly definied roles and responsibilities.…

Generally you don’t want to reuse the same API for different types of clients, you want backends for frontends (BFF) that are specialized for each use and can be moved forward in their own pace. The needs and the requirements differs a lot between a browser, app and server-to-server call. And just because you serve HTML doesn’t necessary mean that you backend code is tightly coupled with the view code, HTML is just o…

> you want backends for frontends (BFF) that are specialized for each use

third time I've heard this thing and the reasoning still escapes me.

First there's ownership. Backend team owns API. Frontend teams own clients (web/android/ios/cli) etc. Do you now have a BFF for each client type? Who owns it then ? Don't you now need more fullstacks ?

there's confusion. Now you have 2 sets of contracts (API-BFF, BFF-clientIOS, BFF-clientAndroid, ...). You now have more human synchronization overhead. Changes take longer to percolate throughout. More scope for inconsistencies.

And there's performance. Adding more hops isn't making it faster, simpler or cheaper.

Isn't is better to have the API team own the single source of ownership ?

Re: Htmx Is the Future

#468

Post by bobthepanda »

v0idzer0 wrote: post #234
PaulHoule wrote: post #179

Earlier quoted context omitted.

I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React. Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real…

It really wasnt about client side validation or UX at all. You can have great UX with an MPA or SPA. Although I do think it’s slightly easier in an SPA if you have a complex client like a customizable dashboard. Ultimately it’s about splitting your app into a server and client with a clear API bounday. Decoupling the client and server means they can be separate teams with clearly definied roles and responsibilities.…

There is a third option, which is that FE-facing teams maintain a small server side application that talks to other services. That way the API boundary is clearly defined by one team.

It sounds a lot more annoying to have to manage one client and many servers instead.

Re: Htmx Is the Future

#469

Post by irrational »

PaulHoule wrote: post #277
v0idzer0 wrote: post #234

Earlier quoted context omitted.

It really wasnt about client side validation or UX at all. You can have great UX with an MPA or SPA. Although I do think it’s slightly easier in an SPA if you have a complex client like a customizable dashboard. Ultimately it’s about splitting your app into a server and client with a clear API bounday. Decoupling the client and server means they can be separate teams with clearly definied roles and responsibilities.…

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 quality. The amount of meetings is truly astonishing. I’m convinced the tech org mainly exists to hold meetings and any development work that occurs is purely accidental.

Re: Htmx Is the Future

#470

Post by unsupp0rted »

0xbadcafebee wrote: post #115

I just want Visual Basic for the web man. Screw writing lines of code. I want to point and click, drop complex automated objects onto a design, put in the inputs and outputs, and publish it. I don't care how you do it, I don't want to know any of the details. I just want to be able to make things quickly and easily. I don't care about programming, I just want to get work done and move on with my life. At this rate, w…

That’s basically what I have with Vue + Vuetify + PUG templates.

It’s a pleasure to work with so little boilerplate.

Post reply on HN