bang on, especially that last part

a bit focus of htmx, alpinejs (and htmx's sister project, https://hyperscript.org) is putting the logic on the element, so you can see exactly what a button, etc. does just by looking at it, and without trawling through ten files of indirection

i am trying to popularize the term Locality of Behavior to describe this design goal:

https://htmx.org/essays/locality-of-behaviour/

I'm curious about your thoughts on that locality of behavior idea vs aspects of precision and composability. For example, the argument goes that the behavior of `hx-get` is obvious upon inspection, but the terseness is achieved by omitting the event type (i.e. it's assumed/implied that hx-get runs on click). The quintessential widget where that breaks down is the table w/ checkboxes for batch operations over an arbitrary subset of rows. That's where less DSL-ish frameworks' abstraction via state management tend to shine, since they allow the developer to more precisely specify how disparate checkboxes relate to a bigger picture that may also involve table sorting (both client and server varieties) or nested modal structures or other forms of complexity.

Button should not have any behavior, it should generate an event. Your app can have one or multiple listeners for this event. This pattern is battle-tested for decades.

OK, but the response to that event should be localized to the button.

https://htmx.org/essays/locality-of-behaviour/

Why? Have any reading on this?

Of course :) Have you tried to find something before asking?

https://en.m.wikipedia.org/wiki/Reactive_programming

https://developer.mozilla.org/en-US/docs/Web/API/EventTarget...

1.) Don't be a jackass.

2.) I know what reactive programming is, I make extensive use of RxJS at work. And I obviously know what an event listener is. I was asking why is it wrong to have the button have functionality and only emit events. And I did google that, but nothing from your comment you posted that I googled lead to anything about reactive programming.

If your node_modules is 3.7GB, you are doing something seriously wrong. My node_modules for a 100k+ line app is 243MB and that includes all my dependencies, compiler and testing frameworks which seems very reasonable. All compiled down to a 4MB blob which seems pretty reasonable for a big app :)

3.7GB was obviously an exaggeration for comic effect, however, I laughed just as hard at 243MB. How on earth do you think that's OK?

243 MB?! If that's all code (which is unlikely, sure) and it has an average line length of 100, that's 2.4 MILLION lines! Do you really need that, (no), or have you just 'stockholm syndrome'-d yourself into believing this is not a problem?

I just tried running WinDirStat on the `node_modules` folder in a Create-React-App project I had lying around. Total size was 234 MB. Of that, 129MB was JS files. By far the biggest piece was TypeScript, which has 45MB of .js in 6 files making up its parsing and IDE language service implementation.

Beyond that, the breakdown is:

- .ts source files: 25MB

- Sourcemaps: 23MB

- Markdown: 15MB

- JSON: 10MB

It also looks like there's a 12MB Linux binary that was only in there as a publishing accident for the `user-event` library that has since been resolved ( https://github.com/testing-library/user-event/issues/266 ).

Or, take Redux Toolkit, which I maintain. If you look at https://unpkg.com/browse/@reduxjs/[email protected]/ , the published package for our current version, it adds up to about 10MB on disk. But, that's because we ship three separate entry points (RTK core, RTK Query UI-agnostic core, RTK Query with React-specific additions), and for each entry point we compile the code to multiple file formats (CommonJS, ESM legacy, ESM modern, ESM with "dev" and "prod" already built in, UMD dev, UMD production), and each of those has sourcemaps. The actual amount of code that ends up in your bundle is about 20KB min+gz.

So, it's a combination of many things: TS itself is big, libraries typically publish packages containing both the original source code plus multiple build artifacts to run in different environments, and packages also include various metadata and other files as well.

I'm not saying this is necessarily a _good_ situation :) Goodness knows that JS dependency trees _should_ be much smaller. But there's a lot more nuance to it than just "245MB of code wut lol".

There's definitely an anchoring effect going on. I remember when dart came out and people were like "lol 100kb hello world, wtf" and now people say "4mb app is reasonable" and nobody bats an eyelid.

Heh, that's actually part of the point I'm making - big difference between "size of build dependencies unzipped and extracted on disk", vs "size of actual app bundle".

As an alternative view, while living in a very unremarkable North American area I have atrocious internet service. I don't think it's particularly uncommon, but it certainly is enlightening to browse the internet. Depending on the time of day a 4MB blob by itself can take ~8 seconds to download. 8 seconds is a _long_ time.

Obviously I have no idea what your app is, I have found very frequently it is not reasonable to have blobs of similar sizes (especially if text content waits for some front end framework to download/initialize).

Certainly. My hope is things like WASM eventually make Javascript obsolete if we're into pushing giant blobs of client UI over the wire. Blazor / Bolero in C#/F# are promising starts in that direction.

How do you compile it to a single blob?

With tree shaking, and it is usually split into several files for caching purposes and to download only what's really necessary.

As a developer who worked both with Windows Forms and React, IMO the only explanation for longing for the former could be that lovely nostalgia feeling when you already know what react offers.

I think people approach it with prejudice (ew, Javascript!) and never properly learn it.

There are projects where react would be overkill but many benefit from the clear separation of the front end.

Also configuring a react project is easier than many other projects I've seen in my career. People just love getting internet points by constantly talking about left-pad, node_modules size, config files etc. I personally know how crazy managing maven or gradle (.gradle folder hell) or nuget or composer or pip (venv or virtualenv...) or [name of your favorite package manager] can get, so I'm thankful for the great community that work on the problems with the npm.

I believe the Model View Controller or Model Template View architectures provide sufficient separation of concerns without requiring separate codebases, teams, tooling, and project management.

I didn't mean the classic separation of concerns. I meant that front-end development should be taken seriously enough to (sometimes) warrant its own focused team.

A proper FE developer who knows about accessibility (not just ARIA-attributes but also contrast and usability), UX, semantics, and also being capable of delivering performant user interfaces is rare these days, because people think full-stack development really is a thing. I think it is one of those mythical things like a 1000x engineer. People think that they can get away with 90s style websites, but please test stuff with a screen-reader, and also while you're there get some front-end consulting, you will be surprised how badly you may be doing. IMHO, many need dedicated FE development. Whether they use React or not, I think many do. You can distribute many responsibilities on non-technical members of the team, but then you start thinking "couldn't they just learn a bit templating so I don't invest so much time on implementing their seemingly never-ending requirements"!

BTW, this separation is of course also possible with your traditional MVC stack, which I also use in my personal projects a lot, in which React is indeed overkill, and there are many cases that a bunch of templates deliver all the things you may ever need. If it gets complicated enough some day, return your View Model as JSON and there you have a perfect API. IMHO REST APIs aren't suitable for any dynamic front-end development anyway.

The only reason I wrote that single sentence in my previous original comment is that React forces your hand a bit, in this matter. It's a small point among other things.

Doing a ground up rewrite of our app at work. I made the call that the application needed to be semantically correct (well, mostly correct. We avoid div everywhere), have proper tab order, and be screen reader accessible. It takes more time but honestly it's not that difficult to do. Most people just.... Don't do it.

It doesn't end there. Even caring a bit for that makes a huge difference, I agree, and I appreciate the effort. The last time we had an accessibility audit, however, it was consisting of more than 200 problems with different priorities for an app with 70 something views. Our FE people were immediately up to the task of getting them fixed; a motivation I simply cannot expect from anyone who doesn't have a front-end focus. My basic checker reports in this simple comment-editor already a couple of problems.

It also doesn't end there. There's the UX part, re-usability (huge difference to have a cross-team front-end service-team), performance (not just initial load... Are the widgets you build with, say, Alpine.js tested for performance?), development speed, caching, offline-capabilities, opportunistic rendering, other best practices, branding, consistent design and interaction and so on. It's a science on its own.

Front-end is not just some basic thing which got a complex solution for no reason. It is a complicated task.

Using JS/CSS in classical Java and .NET frameworks is so easy (and bleeding fast) when compared with dealing with 1).

Unfortunely it is an option I can only dictacte on personal projects.

1) Who cares about the size of node_modules? What is the reason to care about it at all?

2) “Junior-centered” app has to be simple as a “ToDo list example”, all the time. It's not possible for the real apps - they constantly evolve, and to keep their code readable and clean you need skilled developers, not the other way around.