Hi, we added competence map on our site.
https://dartway.dev/learn
Each page contains key topics, questions and usefull links.
Post #13
70
Channel Public Channel
DA DartWay En | Flutter & fullstack Dart
@dartway_dev
- Subscribers
- 32
- Photos
- 1
- Videos
- 0
- Links
- 4
Recent Posts 13 shown
Post #12
70
The hardest part of a module is flexibility
DRY is one of the core principles of software engineering. Every self-respecting developer wants to package recurring functionality into a module: solve the problem once, reuse it everywhere.
But every project comes with its own particular requirements. That's why the hardest part of building a module isn't the functionality. The hardest part is flexibility: making the module work not just for its author, but for a thousand other projects — each wanting something slightly different.
An anti-example: Serverpod modules.
Serverpod ships ready-made modules for authentication and chat. Looks like a gift: plug one in and the project gets login and a messenger out of the box. Exactly what every "batteries included" framework promises.
Now the reality. The models of these modules live inside the module. The user is their UserInfo, the message is their model, the tables are their tables. For a demo it's all wonderful. But a real product always needs more: an extra field on the user, a custom verification flow, attachments in messages, custom channel permissions. And there's the wall: someone else's model can't be extended. Two options — bolt parallel tables on with joins, or fork the module. And a fork is forever: it has to be dragged through every framework update. Maintenance hell, no exaggeration.
This is not a complaint about Serverpod — it's an excellent foundation, and DartWay is built on top of it. It's the trap almost every "ready-made module" falls into: the more functionality is baked into someone else's models, the faster the tool turns from an accelerator into a brake. And the wall doesn't show up on installation day — it shows up a month later, when redoing things is already expensive.
DartWay is designed around the opposite principle: the framework must not own the application's models.
Authentication: the entire flow is ready — phone number, one-time code, sessions that survive restarts. But the user is the application's own UserProfile model, in the application's database, with whatever fields the domain needs: roles, avatar, anything. Adding a field = adding a field. Not a fork.
Hence the DartWay formula: tools should take away the routine without taking away flexibility. All the hard parts — authentication, permissions, realtime, CRUD — are solved once, properly. But every model stays the application's model, all the logic stays the application's logic, and at no point is there a door marked "beyond this, fork only."
In a few days DartWay lands on pub.dev — and this claim becomes something anyone can test on their own project.
DRY is one of the core principles of software engineering. Every self-respecting developer wants to package recurring functionality into a module: solve the problem once, reuse it everywhere.
But every project comes with its own particular requirements. That's why the hardest part of building a module isn't the functionality. The hardest part is flexibility: making the module work not just for its author, but for a thousand other projects — each wanting something slightly different.
An anti-example: Serverpod modules.
Serverpod ships ready-made modules for authentication and chat. Looks like a gift: plug one in and the project gets login and a messenger out of the box. Exactly what every "batteries included" framework promises.
Now the reality. The models of these modules live inside the module. The user is their UserInfo, the message is their model, the tables are their tables. For a demo it's all wonderful. But a real product always needs more: an extra field on the user, a custom verification flow, attachments in messages, custom channel permissions. And there's the wall: someone else's model can't be extended. Two options — bolt parallel tables on with joins, or fork the module. And a fork is forever: it has to be dragged through every framework update. Maintenance hell, no exaggeration.
This is not a complaint about Serverpod — it's an excellent foundation, and DartWay is built on top of it. It's the trap almost every "ready-made module" falls into: the more functionality is baked into someone else's models, the faster the tool turns from an accelerator into a brake. And the wall doesn't show up on installation day — it shows up a month later, when redoing things is already expensive.
DartWay is designed around the opposite principle: the framework must not own the application's models.
Authentication: the entire flow is ready — phone number, one-time code, sessions that survive restarts. But the user is the application's own UserProfile model, in the application's database, with whatever fields the domain needs: roles, avatar, anything. Adding a field = adding a field. Not a fork.
Hence the DartWay formula: tools should take away the routine without taking away flexibility. All the hard parts — authentication, permissions, realtime, CRUD — are solved once, properly. But every model stays the application's model, all the logic stays the application's logic, and at no point is there a door marked "beyond this, fork only."
In a few days DartWay lands on pub.dev — and this claim becomes something anyone can test on their own project.
Post #11
61
Yesterday I said I'm building DartWay in the open. Before I start showing code — let me say what it actually is and where it came from.
We started building fullstack on Dart over three years ago. Not individual screens — whole products: client, server, database, realtime, deployment. Over those years, and through a fair amount of pain, I landed on two things.
First. Most developers — even strong client-side ones — don't have the experience to architect fullstack well. It's a separate skill. Not "learn one more framework," but understanding how to run data all the way from the database to the widget so it doesn't fall apart around your twentieth screen. You don't pick that up in a month.
Second — and this one turned out to matter more. The hardest parts of every project are the same. Auth, access control, realtime sync, CRUD, pagination, filtering — project after project, it's literally the same problem. Each has a handful of sensible ways to solve it. Pick a good one once, and reuse it everywhere — instead of solving it from scratch on every new project.
That's how DartWay came to be.
It's a fullstack framework for Dart where the hardest, most repetitive pieces are already solved — once, and properly. Not a code generator, not low-level glue: a layer that takes on exactly the architecture most people spend years assembling the hard way. What's left is building the product, not the plumbing underneath it.
Next — on real code — I'll show how a feature lives end to end in this stack: from the server to a live list on screen, in a few dozen lines.
We started building fullstack on Dart over three years ago. Not individual screens — whole products: client, server, database, realtime, deployment. Over those years, and through a fair amount of pain, I landed on two things.
First. Most developers — even strong client-side ones — don't have the experience to architect fullstack well. It's a separate skill. Not "learn one more framework," but understanding how to run data all the way from the database to the widget so it doesn't fall apart around your twentieth screen. You don't pick that up in a month.
Second — and this one turned out to matter more. The hardest parts of every project are the same. Auth, access control, realtime sync, CRUD, pagination, filtering — project after project, it's literally the same problem. Each has a handful of sensible ways to solve it. Pick a good one once, and reuse it everywhere — instead of solving it from scratch on every new project.
That's how DartWay came to be.
It's a fullstack framework for Dart where the hardest, most repetitive pieces are already solved — once, and properly. Not a code generator, not low-level glue: a layer that takes on exactly the architecture most people spend years assembling the hard way. What's left is building the product, not the plumbing underneath it.
Next — on real code — I'll show how a feature lives end to end in this stack: from the server to a live list on screen, in a few dozen lines.
Post #10
51
I've been building this channel around Flutter development and fullstack Dart for quite a while. I have a content plan mapped out a month ahead, with sensible proportions: some Flutter, some Dart, widgets, libraries, architecture decisions.
But over the past few weeks I've been watching all of it lose relevance in real time.
Not the knowledge itself — its value to a developer.
I've switched to writing code exclusively through AI. And judging by what colleagues post, a huge number of professionals already work this way.
This changes everything — starting with which skills matter and which don't.
Hand-writing code is going away entirely. The competencies that actually matter now:
— broad IT expertise: from SQL and algorithms to Docker configuration;
— deep understanding of your stack and what it's really capable of;
— architectural vision;
— product thinking;
— and above all — the ability to build development processes around AI.
So this channel is changing direction. It's now about the profession of the developer of the future, not about specific Flutter and Dart tools.
What that means in practice:
1. I'm building DartWay — an open-source fullstack Dart framework — and from now on I'm doing it fully in public: decisions, code, numbers, mistakes. Real build in public, no gloss.
2. I'll be showing what development looks like when agents write the code and the developer designs, sets constraints, and verifies the result.
3. Flutter and Dart aren't going anywhere — but through the lens of "how a product gets built from this", not "widget of the week".
If this resonates — stick around. The best part is ahead.
And tell me in the comments: are you already writing code through AI — or still by hand?
But over the past few weeks I've been watching all of it lose relevance in real time.
Not the knowledge itself — its value to a developer.
I've switched to writing code exclusively through AI. And judging by what colleagues post, a huge number of professionals already work this way.
This changes everything — starting with which skills matter and which don't.
Hand-writing code is going away entirely. The competencies that actually matter now:
— broad IT expertise: from SQL and algorithms to Docker configuration;
— deep understanding of your stack and what it's really capable of;
— architectural vision;
— product thinking;
— and above all — the ability to build development processes around AI.
So this channel is changing direction. It's now about the profession of the developer of the future, not about specific Flutter and Dart tools.
What that means in practice:
1. I'm building DartWay — an open-source fullstack Dart framework — and from now on I'm doing it fully in public: decisions, code, numbers, mistakes. Real build in public, no gloss.
2. I'll be showing what development looks like when agents write the code and the developer designs, sets constraints, and verifies the result.
3. Flutter and Dart aren't going anywhere — but through the lens of "how a product gets built from this", not "widget of the week".
If this resonates — stick around. The best part is ahead.
And tell me in the comments: are you already writing code through AI — or still by hand?
- 👍 1
Post #9
36
Experience isn't the years you've logged
Last time I asked whether you're a junior, middle, or senior. But I split those by years on the job — and honestly, that's not quite right.
A developer's skill doesn't grow on a timeline.
You can write code for a decade and stay roughly where you started. And you can cover ground in a couple of years that usually takes far longer. Time in the chair barely tells you anything.
What actually moves you is the complexity of the problems you deal with.
And here's the part most people miss: that complexity isn't handed to you by the outside world. You set most of it yourself — through the bar you hold for your code, your architecture, and the quality of your decisions.
When the only goal is "make it work," the solutions stay shallow. Experience trickles in, and you hit a ceiling early — usually somewhere around junior, or freelance-that-works-well-enough.
The moment you start caring about quality — clean architecture, a structure someone can actually read, principles you don't break — the curve gets steep. That's how you become a middle who knows not just *what* they're doing but *why*.
And senior? Senior starts where the work is less about tasks and more about constraints.
Trimming calls to the backend. Cutting rebuilds. Working around a platform limit. Deliberately turning down the convenient solution for the correct one. That's a different order of difficulty — and a different way of thinking.
If I compress the whole thing into one line:
Experience isn't tenure. Experience is the total complexity of the different problems you've actually solved.
So — what's the hardest constraint you're wrestling with in your work right now?
Last time I asked whether you're a junior, middle, or senior. But I split those by years on the job — and honestly, that's not quite right.
A developer's skill doesn't grow on a timeline.
You can write code for a decade and stay roughly where you started. And you can cover ground in a couple of years that usually takes far longer. Time in the chair barely tells you anything.
What actually moves you is the complexity of the problems you deal with.
And here's the part most people miss: that complexity isn't handed to you by the outside world. You set most of it yourself — through the bar you hold for your code, your architecture, and the quality of your decisions.
When the only goal is "make it work," the solutions stay shallow. Experience trickles in, and you hit a ceiling early — usually somewhere around junior, or freelance-that-works-well-enough.
The moment you start caring about quality — clean architecture, a structure someone can actually read, principles you don't break — the curve gets steep. That's how you become a middle who knows not just *what* they're doing but *why*.
And senior? Senior starts where the work is less about tasks and more about constraints.
Trimming calls to the backend. Cutting rebuilds. Working around a platform limit. Deliberately turning down the convenient solution for the correct one. That's a different order of difficulty — and a different way of thinking.
If I compress the whole thing into one line:
Experience isn't tenure. Experience is the total complexity of the different problems you've actually solved.
So — what's the hardest constraint you're wrestling with in your work right now?
Post #8
41
Too many juniors, too few jobs — and the real problem is somewhere else
I post a Flutter developer opening fairly regularly.
Within 2–3 days I get 200–300 applications. Not bots — real people.
The market is flooded with juniors and early middles right now. And it's genuinely hard for them:
— landing that first job
— standing out among dozens of candidates
— proving they're actually competent in an interview
But here's what most people miss.
Even once you get the offer — that's only the beginning of the trouble.
Here's what I see with almost every candidate. A developer can:
✅ build a feature
✅ wire up an integration
✅ get it to "work on my machine"
But can't:
❌ fit it into an existing project
❌ keep the architecture coherent
❌ hold to basic engineering principles
❌ think ahead
So you end up with a pile of code that's painful to maintain and grow. And the saddest part — a couple of months later, even the author can't read their own code.
Why does this happen?
Because the internet is packed with tutorials:
— complex animations
— custom widgets
— flashy UI tricks
And almost nothing about:
• how to organize code
• how to make architectural decisions
• how to think in projects, not screens
• how to write code that outlives you
Flutter isn't the problem. The missing piece is systems thinking.
And that's exactly what separates a developer from an engineer — someone who just executes from someone who's actually valuable.
In the next posts I'll break down:
— common architecture mistakes
— how to untangle messy code
— how to be useful instead of just cranking out code
If you recognized yourself here — that's fine. The only real question is whether you want to climb out.
Where are you right now — junior, middle, or senior?
I post a Flutter developer opening fairly regularly.
Within 2–3 days I get 200–300 applications. Not bots — real people.
The market is flooded with juniors and early middles right now. And it's genuinely hard for them:
— landing that first job
— standing out among dozens of candidates
— proving they're actually competent in an interview
But here's what most people miss.
Even once you get the offer — that's only the beginning of the trouble.
Here's what I see with almost every candidate. A developer can:
✅ build a feature
✅ wire up an integration
✅ get it to "work on my machine"
But can't:
❌ fit it into an existing project
❌ keep the architecture coherent
❌ hold to basic engineering principles
❌ think ahead
So you end up with a pile of code that's painful to maintain and grow. And the saddest part — a couple of months later, even the author can't read their own code.
Why does this happen?
Because the internet is packed with tutorials:
— complex animations
— custom widgets
— flashy UI tricks
And almost nothing about:
• how to organize code
• how to make architectural decisions
• how to think in projects, not screens
• how to write code that outlives you
Flutter isn't the problem. The missing piece is systems thinking.
And that's exactly what separates a developer from an engineer — someone who just executes from someone who's actually valuable.
In the next posts I'll break down:
— common architecture mistakes
— how to untangle messy code
— how to be useful instead of just cranking out code
If you recognized yourself here — that's fine. The only real question is whether you want to climb out.
Where are you right now — junior, middle, or senior?
- ❤ 1
- 🔥 1
Post #7
89
🔥 dartway_router 1.1.0
Update to go_router 17.2.3 — plus new features and an important fix.
—
⚠️ Breaking change
All route enums implementing
The compiler will show you exactly where.
—
What's new
Fix:
—
github.com/dartway/dartway_router
GitHub GitHub - dartway/dartway_router Contribute to dartway/dartway_router development by creating an account on GitHub. Update to go_router 17.2.3 — plus new features and an important fix.
—
⚠️ Breaking change
All route enums implementing
DwNavigationRoute must add a new getter:@override
DwStatefulShellRouteBuilder? get statefulShellRouteBuilder => null;
The compiler will show you exactly where.
—
What's new
statefulShellRouteBuilder — the right way to build a bottom nav bar with independent navigation branches. Scroll position, nested routes and widget state are preserved when switching tabs. Recommended over shellRouteBuilder for any tab-based layout.onEnter — a hook that fires before redirect and zoneGuards. Useful for analytics or any logic that needs to run before route matching.caseSensitive (default true) — set to false and /Profile resolves the same as /profile.shellNotifyRootObserver (default true) — controls whether ShellRoute / StatefulShellRoute zones trigger root navigator observer callbacks on internal navigation.Fix:
DwPageBuilder.slide — the from parameter now describes the direction the page enters from. AxisDirection.right means the page slides in from the right. Previously the offset was inverted.—
dart pub add dartway_router
github.com/dartway/dartway_router
DartWay En | Flutter & fullstack Dart pinned «Welcome! This channel is about becoming a stronger developer in the Dart ecosystem. A bit about me: I’m Evgenii Novikov (LinkedIn) the founder of a software development agency and the creator of DartWay (dartway.dev) — a fullstack Dart framework built for…»
Post #5
212
Welcome! This channel is about becoming a stronger developer in the Dart ecosystem.
A bit about me:
I’m Evgenii Novikov (LinkedIn) the founder of a software development agency and the creator of DartWay (dartway.dev) — a fullstack Dart framework built for Flutter developers on top of Serverpod (serverpod.dev).
Here you’ll find:
— practical breakdowns from real projects
— approaches to structuring apps
— experiments with workflows and architecture
— thoughts on developer growth
And of course news about DartWay
If you're working with Flutter or Dart — welcome 👌
Links
💬 Community chat: @dartway_dev_community
💻 GitHub: github.com/dartway
📖 Docs (WIP): https://dartway.dev/docs/intro
A bit about me:
I’m Evgenii Novikov (LinkedIn) the founder of a software development agency and the creator of DartWay (dartway.dev) — a fullstack Dart framework built for Flutter developers on top of Serverpod (serverpod.dev).
Here you’ll find:
— practical breakdowns from real projects
— approaches to structuring apps
— experiments with workflows and architecture
— thoughts on developer growth
And of course news about DartWay
If you're working with Flutter or Dart — welcome 👌
Links
💬 Community chat: @dartway_dev_community
💻 GitHub: github.com/dartway
📖 Docs (WIP): https://dartway.dev/docs/intro
- 👍 2
Channel name was changed to «DartWay En | Flutter & fullstack Dart»
Channel photo updated
Post #2
158
Hi, channel description and first content coming
Channel created
About this channel
- How can I read @dartway_dev without a Telegram account?
- TGViewer shows the public web preview Telegram publishes for DartWay En | Flutter & fullstack Dart: recent posts, photos, videos and the subscriber count, with no app, login or account.
- How many subscribers does DartWay En | Flutter & fullstack Dart have?
- DartWay En | Flutter & fullstack Dart (@dartway_dev) has 32 subscribers on Telegram, refreshed roughly every 30 minutes.
- Does DartWay En | Flutter & fullstack Dart know I viewed it here?
- No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.