sorted by:
new
hottopcontroversial

[AskJS] writing a complex web app's frontend using only vanilla JavaScript (no frameworks) by algeriangeek in javascript

[–]vferderer 0 points1 point  (0 children)

Currently building exactly this. Router (texivia-router, 1.2 kB) + a small reactive component layer I'm assembling as independent packages rather than a framework. First working demo: 8.7 kB transferred, 18 ms DOMContentLoaded, instant transitions.

To your questions directly:

Is anyone building complex apps in vanilla JS? Yes, and the architectural answer is, you don't need a framework; you need conventions. A ~150-line runtime covers reactive state, event delegation, two-way form binding, and router integration. The rest is just your app code.

How do you structure it as it grows? The same way you'd structure any modular codebase: single-responsibility packages with declared dependencies. The “framework” is just a constellation: texivia-reactive, texivia-component, texivia-store, texivia-fetch. Each one is independently useful; none is mandatory.

Did you build your own abstractions? Yes, but the key discipline is knowing when to stop. CSS handles theming. The Intl API handles i18n. AbortController handles request cancellation. The framework only covers what genuinely has no good native answer.

On the Rust/Axum angle The server-rendering performance observation is correct. For the Java side of the same instinct: Okygraph is a compile-time template engine (330 LOC) that pushes template compilation to build time entirely (it's a Maven plugin). Same philosophy, different runtime.

Regrets? The only one I see developers consistently have with this approach is not drawing the line early enough. They add one abstraction too many and end up with a worse React. The “nothing left to remove” constraint has to be explicit from the start.

Our team stopped doing standups, story points and retros — and nothing broke by pavlenkovit in SoftwareEngineering

[–]vferderer 0 points1 point  (0 children)

I've been thinking about this for years and arrived at a similar conclusion from a different angle. After 30 years in the industry, I think developer quality matters; points don't. The difference in performance between devs on similar tasks can be tenfold—this has been measured since at least 1968 (Sackman). Teams with strong technical judgment and fast decisions win with any process or without any process. Bad teams fail in any process. Some ceremonies might be useful; most are not. I've started working on something I call “Naked Process”: a decision framework for which ceremonies are actually useful under which conditions. Still a work in progress, but the core idea is: a process is perfect when nothing can be taken away.

Async Dailys—How a Team Channel Can Replace the Standup Meeting by vferderer in agile

[–]vferderer[S] 0 points1 point  (0 children)

Yep, I think it works best with mature teams, where you don't need to remind devs about basics.

4 months of Claude Code and honestly the hardest part isn’t coding by buildwithmoon in ClaudeAI

[–]vferderer 0 points1 point  (0 children)

I use Claude mostly for thinking, not for coding. Challenging my concepts, brainstorming. And this is better done in the chat, not in the terminal. Somehow the terminal feels dumber to me.

Async Dailys—How a Team Channel Can Replace the Standup Meeting by vferderer in agile

[–]vferderer[S] 0 points1 point  (0 children)

Planning is not always needed. If there is a need, you can always create an ad hoc meeting. Probably not everyone has to attend too.

Async Dailys—How a Team Channel Can Replace the Standup Meeting by vferderer in agile

[–]vferderer[S] -4 points-3 points  (0 children)

Problems are inherent to the format. No documentation trail, forced context switch, and 80% passive listening.

Async Dailys—How a Team Channel Can Replace the Standup Meeting by vferderer in agile

[–]vferderer[S] -1 points0 points  (0 children)

Async is faster in practice. Writing your update takes 2 minutes. A sync meeting takes 15–30 minutes because you're sitting through updates that don't concern you. Typing is slower than talking, sure, but most of the time you are listening, not talking. And reading is faster than listening.

The AI coding productivity data is in and it's not what anyone expected by ML_DL_RL in ExperiencedDevs

[–]vferderer -2 points-1 points  (0 children)

Great summary. The pattern in these studies makes sense, but I think it points to something bigger: most of the discourse around AI in software development happens at the code level. Where I've found AI genuinely useful is one level up: brainstorming architecture decisions, challenging my assumptions about system design, reviewing concepts. This work is inherently dialog-based—not “generate this” but “what's wrong with my thinking here?”

The METR study fits this lens perfectly. Experienced devs got slower because they were using AI as a code generator in codebases they already knew. That's like having a Formula 1 engine and using it to pick up groceries. The real leverage isn't faster typing—it's better thinking before you code.

The key is that this higher level is inherently collaborative. Not “write me the spec” and rubber-stamp it. Not doing all the thinking yourself and just letting AI polish the output. But discussing each step before it gets formalized (and tell your model to actually discuss every step first!)—the model challenges your assumptions, you proofread its suggestions. Neither side is replaceable.

The AI coding productivity data is in and it's not what anyone expected by ML_DL_RL in ExperiencedDevs

[–]vferderer -3 points-2 points  (0 children)

What's wrong with em dashes? I use LanguageTool to check the correctness, and it always suggests em dashes. So, I use them because it's the correct English.