# JavaScript and TypeScript developer — web and mobile fed by one API > Feeding web and mobile from one API — React Native apps in the stores, contracts carried by TypeScript, and a toolchain that keeps changing. - Technologies: TypeScript, React, React Native, Expo, Vite, Tailwind CSS, Node.js - Experience: Since 2008 - Posts: 39 - Projects: 6 - Updated: 2026-09-02 - Source: https://www.muhammetsafak.com.tr/en/expertise/javascript/ - Language: en-US - Author: Muhammet Şafak --- ## 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](https://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. 1. **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. 2. **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. 3. **"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. 4. **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. ## Frequently asked ### 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.