[gbromios]

As with most things UI, it's subjective and difficult to quantify, but in the context of a website, it could mean a few things.

If you, as a user, feel that the site is sluggish, unresponsive or difficult to use because it feels too crowded or has too many features, you might judge that site to feel bloated.

In a more technical sense, bloated might refer to very large (or poorly optimized) files, either javascript or static assets, required to run the thing, causing it to load slowly (i.e. at a speed that the user feels is "slowly").

So maybe a good summary might be: "does too much stuff and/or poorly optimized/coded"

Again, not exactly a tight definition, but UIs are inherently characterized by the perception of their users.

[debarshri]

I think becomes difficult to argue and render this question invalid if we fail to quantify a problem.

I know it is subjective thing that is the reason why I asked this question. For me all UIs are bloat the CLI experience is the best, for someone else, it might not be.

The bloating problem from my perspective might just be a UX problem that the framework you use or the library you use.

[gbromios]

> I think becomes difficult to argue and render this question invalid if we fail to quantify a problem.

It is difficult. It's probably the central difficulty of UIs on the web. However what I said is still true: The quantification inherently rests on users' perception of their experience. This is more a question of psychology than of computer science.

What percentage of your users feel that the app is too slow or confusing? What percentage would you be okay with? If you're selling some kind of enterprise software whose users will not be the buyers but rather the buyers' employees, who cares if it takes 30 seconds to load every page and another 30 seconds to find the widget you need once it's loaded?

The definition of "too bloated" is a function of both how users feel and also how much value you get from reducing it, and the measurement of "bloated-ness" (as well as many other parameters of UX) can't happen without getting feedback from users, which means there's a pretty strict limit to how much we can understand just from discussing theory.

And just to further complicate things: If I'm making a richly featured web app (something like Slack for example) I have a predefined set of features that will need to be implemented using javascript. Obviously there are many parameters that determine how well these are designed and implemented and optimized, all of which will affect how the users perceive the app as a whole. However, what about users (say, some plurality of HN readers) who intrinsically value websites which function without javascript, and will always consider those that don't to be bloated; What use is it to quantify that if it's always going to run up against my stated goal of building a chat app in the browser?