Expertise
JavaScript and TypeScript developer — web and mobile fed by one API
Shipping the same feature across three layers — a Laravel API, a web UI and a React Native app — taught me the hard part is the contract, not the code.
- Since
- 2008 Since
- years
- 18 years
- posts
- 39 posts
- projects
- 6 projects
Me in the JavaScript & TypeScript ecosystem
My identity in this ecosystem comes down to one sentence: I am the person who writes the product’s back end and then puts its web and mobile surfaces on the same contract. I am not building a design system; I am building the interface that talks to the API. JavaScript and TypeScript are not a preference on this page — they are the language of the layer where the product meets the user.
The parts of interface architecture that touch the system side — server-side rendering decisions, caching strategy — are written on sade.dev.
What I deliver in this ecosystem
What they have in common is one contract underneath all of them; I am not building a design system, I am building the interface that talks to the API.
-
Three layers, one contract
The same feature ships as a REST API, a web UI and a mobile app at once. I keep the split strict: web and mobile never talk to each other, only over the shared API.
-
The mobile client
The iOS and Android half of the same product, with React Native and Expo. Getting it through the stores is part of the job too.
-
The type layer
TypeScript carries one contract from API to UI. Writing the contract twice, once at each end, means there is no contract.
-
Build and styling pipeline
The build pipeline that cuts dev server startup to seconds, and a utility-first styling layer. The toolchain keeps changing; the job of these two layers does not.
The hard part is the contract, not the code
Most of the errors I meet on the interface side look like interface errors and turn out to be contract errors. When a field name, a date format or the meaning of an error code drifts between layers, the result is a cluster of failures that all look unrelated and share one root. So I start from what the back end promises, not from how the interface will look.
Not tied to a single library
All three are different answers to the same question; which one gets opened is decided by the product's needs.
-
The Vue side
I spent a long time here — component-based interface architecture, routing and state management. Not a lost investment: it is where I can compare the two approaches.
-
The React side
The centre of gravity moved here through mobile needs, and having the same mental model on web and mobile made things easier.
-
Interfaces out of a server-side frame
Approaches that pull a modern interface out of a server-side frame and cut the code shipped to the browser.
What makes me replace a tool
The longest-running thing I have watched in this ecosystem is the tooling changing — AJAX with jQuery, then Gulp, then Webpack, then Vite. The decision went through the same order every time.
- 01 The bill is always configuration
- Every migration cost the same thing: configuration. What is expensive is not the tool itself but the setup weight of making it run.
- 02 The return has to beat the bill
- I take on a new tool when it returns more than the configuration bill I pay for it. When it does not, the old tool stays where it is.
- 03 "More modern" is not a reason
- The age of a tool is not a measure. The measure is which concrete job it makes cheaper in this product.
- 04 Build time is a line item too
- I apply the same measure on the compiler side: build time is a cost line, not a detail.
What sets its own rules on mobile
My expectation that React experience from the web would transfer turned out half right: the component thinking is the same, the rest is not.
-
Navigation architecture
Navigation is built together with the screen architecture; router habits from the web do not carry over as they are.
-
List rendering performance
List rendering performance is one of the headings I work on separately on the mobile side.
-
Versioning with OTA updates
Being able to ship an update without a store round makes version management a subject in itself.
-
Store submission
Getting it through the store is part of the job as well — and a craft independent of the app's code.
What I do not do
Accessibility auditing, building a design system and advanced animation work are not my field, and I say so when it needs saying. The parts of interface architecture that touch the system side — SSR decisions, caching strategy — are written on sade.dev.
Recent writing in this area
TypeScript's new compiler and why build speed matters
TypeScript's compiler ported to Go, and why a fast feedback loop is so valuable for developers.
One architecture rule, three languages: archlint now does Go + TypeScript + Python
In a polyglot repo, 'domain must not import infrastructure' is the same rule in every language — only how the import resolves differs. I added TypeScript and Python to archlint: one architecture.json enforces all three in CI.
From Idea to Three Platforms: My End-to-End Feature Delivery Flow
The mature, repeatable process I follow when shipping a feature across API, web, and mobile simultaneously.
What I have built in this area
Garajdaş: model-specific community without the forum sprawl
A Reddit-like community platform where every vehicle make and model has its own club, holding ICE and EV under one roof; web and mobile run in parallel.
What it does today
A community platform where every car make and model has its own club; identity, content, notifications and moderation all run on a single-schema API, with the web and mobile clients sharing that one schema. Anyone looking for a community specific to their car's model can join today.
Swipenor: if the client computes the score, what does the server trust?
A swipe-based true/false trivia game; the real subject is not the game but making a client-computed score verifiable through a signature.
What it does today
The swipe-based true/false quiz runs end to end in its core loop as a mobile app; the score is produced on the client but verified server-side with a server_nonce and an HMAC signature. swipenor.com is the app's landing page, not the game itself.
Devrazzi: filtering developer news through layers of models
A content pipeline that screens software and AI news locally with Ollama, hands survivors to larger models, and publishes Turkish and English syntheses.
What it does today
Filters software and AI news through a local Ollama pass and hands the upper layers to the larger models, then writes and publishes the TR/EN synthesis on its own; the web and App Store builds are live. Anyone who wants their daily developer news in one feed can read it.
What shipped in this area
Parantaj
OngoingOwner
A personal and corporate financial management platform. It offers income-expense tracking, budget planning, detailed reporting, and multi-account management.
Looplio
OngoingOwner
Looplio — a recurring automation platform (Web + iOS + Android) that turns repeating tasks, maintenance, and checks into reusable templates and automatically generated checklists.
sakinkal
OngoingFounder & Editor
sakinkal is a rational, evidence-based, and offline-accessible preparedness resource that strips crisis readiness in Turkey of fear and hype. It distills complex information into clear steps, checklists, and guides anyone can apply. 'No panic, just preparedness.' — a non-profit, ad-free, mission-driven publication.
Technologies I pair it with
-
TypeScript
The type layer that carries one contract from API to UI.
-
React
The component side.
-
React Native
The iOS and Android half of the same product.
-
Expo
Builds, store submission and OTA updates.
-
Vite
The build pipeline that cut dev server startup to seconds.
-
Tailwind CSS
Utility-first styling layer.
-
Node.js
Where the toolchain runs.
Frequently asked
7 questions
-
How long have you written JavaScript?
Since 2008, so 18 years — the same year as PHP. The two were two faces of one job: PHP on the server, first jQuery and later Vue and React in the browser.
-
Are you a frontend developer?
Not exactly. I am the person who writes the product's backend and then puts its web and mobile surfaces on the same contract. I am not the one building a design system from scratch; I am the one building the interface that talks to the API.
-
Vue or React?
I have written both. On the Vue side about component architecture, routing and state management (Vuex, later Pinia); on the React side about hooks, concurrent rendering and the form actions that arrived with React 19. Today mobile work makes React Native mandatory, so the weight sits on the React side.
-
Do you build mobile apps?
Yes, with React Native and Expo. Two of the recorded projects have their mobile client written that way, and one of them is live on the App Store and Google Play. I have separate posts on OTA updates, navigation architecture and list rendering performance.
-
Do you use TypeScript?
Yes, and the reason collapses into one thing: end-to-end type safety from API to UI. Writing the contract twice, once at each end, means there is no contract.
-
How much have you written in this area?
This site carries 39 posts and 6 projects tagged across the JavaScript ecosystem; the oldest is AJAX with jQuery, the newest is TypeScript's new compiler.
-
Doesn't the toolchain change constantly?
It does, and I moved that chain from Gulp to Webpack and from Webpack to Vite myself. But every migration cost the same thing: configuration. Replacing a tool is only the right call if it returns more than the configuration bill you pay for it.
Let us work together
If you have work in this ecosystem, tell me what you are building and we will talk about how to build it.