Hacker News Reader

Comment by JoeCortopassi | Hacker News Reader

Everything has a context. If your site has:

  - minimal functionality
  - rarely if ever changes
  - is maintained by a very small group (Hacker News)

...then something like the example linked is perfect. Most web app developers don't live in this world. The more common situation is:

  - large and/or transient teams
  - large quantity of inter-dependent features
  - constant changes

...which means that the thing you need to optimize for isn't pretty/fast code. It's clarity and resiliency in the code. Can a junior and senior dev both work on the same code base? Can someone new to the project be effective with minimal ramp up time? Can you work on a feature without accidentally stepping on another persons current task?

Modern web apps are less about being performant and minimal, and more about dealing with the complexities of large software teams

View on HN

>> Modern web apps are less about being performant and minimal, and more about dealing with the complexities of large software teams

If that's true, then the app will likely have what I call a "programmer's interface" (which is especially common in most enterprise web apps I encounter). Those apps might be solid from a code perspective, but don't tend to be very user friendly.

I tend to think that modern web apps are more about dealing with the complexities of balancing functionality with ease of use to the end user while still dealing with the complexities of large product teams, which include but are not limited to designers, UX experts and developers.

The fancy-lookin' sites are the ones which hijack basic keyboard functionality, scroll in weird ways, etc.

I can't be the only person who finds browser default behavior more intuitive and usable in general.

Why does "UX" so often mean mouse-heavy and always favor the beginner over the power-user.

I agree that following browser default behavior is more intuitive in general. I'm not a fan of scroll jacking.

I'd say apps skew towards mouse-heavy because controls are on-screen and therefore discoverable. It takes a good deal of product-market fit before you can count on your users knowing/caring enough about your app to remember keyboard shortcuts.

Most apps are grown by adding users, so optimizing for the new user is more important to the business until a certain level of maturity and market saturation is reached.

Applications with a dedicated professional user base can go deeper into power-user territory sooner since they can charge more per user, and new users expect there to be a learning curve.

Yes, and just to express the same idea from a different perspective... you need to deliver the features needed by your business.

In a small, simple, established site, those needs don't change often, so the code doesn't change often, and you can focus more on performance than maintainability, as well as spend your efforts on non-coding tasks.

In a startup when you are finding your market and seeking product/market fit, and you've got investors demanding speedy delivery of a product to customers, the attempted solution is often a large team with fast and numerous code changes. And then you do have to optimize for the devs, because even though the final goal is customer satisfaction, devs need to perform efficiently to hit that goal.

The needs of the codebase still tie back to the needs of the business. One answer does not fit all.

> Most web app developers don't live in this world

Really? Most Javascript developers live in the world of trillion-dollar startups serving billions of people? That's why they need Kubernetes, React, and 2000 nodejs modules to show a couple of confirmation dialogs on the SOHO website they are working on.

Right, and "true hackers" aren't team players if they're slanging this all over the place.

Reply on news.ycombinator.com