标签：#Java

React Form Backends Compared: Serverless Functions vs. Form-as-a-Service React makes building a form straightforward. What happens after onSubmit is a different question: you still need somewhere to validate, process, store, or forward the submission. Two common approaches are writing a serverless function yourself or using a hosted form backend such as onsubmit.dev (form backend). This article compares the two, using Vercel/Netlify-style functions for the DIY approach and onsubmit.dev with its React integration as the managed example. The basic problem Imagine a typical contact form: function ContactForm () { return ( < form > < input name = "email" type = "email" required /> < textarea name = "message" required /> < button type = "submit" > Send </ button > </ form > ); } The React component is only the UI. A real application usually needs backend behavior too: accepting the HTTP request validating and sanitizing input handling errors preventing abuse or spam delivering or storing the submission keeping credentials and other secrets off the client There are two broad ways to get that backend. Option 1: Build a serverless function With platforms such as Vercel and Netlify, you can create an HTTP function alongside your application and have your React form submit to it. Conceptually, the architecture looks like this: React form | v Your serverless function | +--> validation +--> email provider +--> database +--> other services The main advantage is control. Your function owns the request lifecycle, so you decide precisely how data is validated, transformed, authenticated, stored, and forwarded. If a submission needs to update PostgreSQL, call an internal API, enqueue a job, and return application-specific data, a custom backend is usually the natural solution. Serverless functions can also reduce product-level vendor lock-in. Although platforms have their own deployment conventions, HTTP handlers and their business logic are generally portable with some work. The tr

This week's Java roundup for August 17th, 2026, features news highlighting: the first release candidate of JDK 27; JEP 541 and JEP 540 targeted for JDK 28; the GA release of Apache Tika 4.0; a maintenance release of Helidon; the first milestone releases of Micrometer Metrics 1.18 and Micrometer Tracing 1.8; an update on Jakarta EE 12; and BellSoft Critical Security Patch Updates. By Michael Redlich

The feature was a letter generator. Somebody fills in a few fields and gets a finished letter of recommendation, resignation letter or notice letter, in plain text, ready to paste into an email. The obvious build is a prompt and a model call. I wrote the deterministic version instead: a pure function, about two hundred lines, no network, no key, no tokens. I want to lay out the reasoning, because "just call a model" is the default now and the default is not always right. The three reasons, in order of weight 1. The output is short and the shape is fixed. A recommendation letter is a date block, a greeting, three or four paragraphs, a sign off and a name. There is no structural variation to discover. Generation is valuable when the space of good outputs is large and you cannot enumerate it. Here the space is small enough to write down, and once you have written it down the model is doing an expensive approximation of a switch statement. 2. It is a legal-adjacent document. Not legal advice, but it goes into an employment record. A resignation letter that invents a notice period, or a reference that invents a fact about a person, is a real problem for the person who sent it. Templates cannot hallucinate. Everything specific in the output either came from a form field or is a sentence I wrote and can be held to. 3. Zero marginal cost changes what the product can be. This is the one that actually decided it. A model call costs money per use, and anything that costs money per use needs an account, a rate limit and eventually a card. A pure function costs nothing, so the tool can stay open with no signup, forever, without a business case. That is a product decision expressed as an architecture decision, and it only works if the code path is free. What the code looks like The whole engine is one exported function over one input type. export type LetterKind = ' resignation ' | ' notice ' | ' recommendation ' ; export type LetterTone = ' formal ' | ' warm ' | ' brief ' ; expo

Every Four Pillars calculator — saju in Korea, BaZi in China — agrees on the easy 95% of the job. Feed it a birth date and it maps that instant onto a traditional calendar: four pillars, each a heavenly stem paired with an earthly branch. The remaining 5% is boundaries. And at the boundaries, nearly all of them quietly disagree with the printed almanac they claim to reproduce. I maintain a saju reading service, and getting these four cases right was most of the actual engineering. Here they are, with the failing inputs. 1. A solar term is an instant, not a date The year pillar does not turn on January 1, and not on lunar new year either. It turns at 입춘 (ipchun, "start of spring") — one of the 24 solar terms, defined by the sun's apparent longitude. In 2024 that moment was February 4, 16:27 KST . A calculator that applies solar terms at day granularity says "February 4 → new year pillar" and hands the wrong year to everyone born that morning. npx k-saju 2024-02-04 04:00 # year 癸卯 — still the old year pillar, because 04:00 < 16:27 The fix is unglamorous: store term boundaries as instants and compare instants. The subtlety is that this correction applies to the year and month pillars only — the day pillar runs on its own sexagenary count and must not be touched. 2. The 23:00 hour belongs to two days at once Traditional practice starts the day at 23:00, not midnight — the hour of the Rat (자시). So for a birth at 23:31, there are two defensible answers about which day's stem the hour pillar derives from, and schools split on it. The convention this engine declares: the day pillar keeps clock midnight , while the hour stem takes the next day's stem (the 야자시 rule). npx k-saju 2000-05-15 23:31 # day 癸酉, hour 甲子 I am not claiming this is the One True Rule. I am claiming it should be written down. Most tools pick a side in silence, which is how two calculators give one person two charts and neither can explain why. 3. The clock is not the sun Korea keeps time on the 135°E meri

Nuxt has released version 4.5, featuring updates such as a switch to Vite 8, a new Rspack 2 builder, and experimental SSR streaming. This streaming enhances Time to First Byte by flushing the HTML shell instantly. The release also includes a stable error code system and new composables, alongside important upgrade instructions for developers moving from earlier versions. By Daniel Curtis

Originally published on the WeLocale blog . Most SEO work is a matter of degree. You improve a title, you gain a little. hreflang is not like that. It either forms a valid set that search engines act on, or it does nothing at all, and the failure is completely silent. No warning, no penalty, no message in Search Console telling you the tags you carefully added are being discarded. We build a translation widget, which means we generate hreflang tags for other people's sites. This post is what we have learned about why they get ignored, including the parts where our own approach has real limits. The rule that breaks most setups hreflang is not a property of a page. It is a property of a set of pages, and every page in that set has to agree. If your English page says the German version is at /de/ , the German page has to say the English version is at / . If it does not, the declaration is one-way, and one-way declarations get dropped. Google calls these return links and treats their absence as a reason to distrust the whole set. This is why hreflang fails in a way that feels unfair. Every individual page looks correct when you inspect it. The problem only exists in the relationship between pages, which is exactly the thing you cannot see by viewing source on one URL. The corollary catches people too: each page must list itself . A German page whose tags mention English and French but not German is an incomplete set. Incomplete sets get dropped. The other four failure modes en-UK. The language code comes from ISO 639-1 and the region code from ISO 3166-1. In ISO 3166-1 the United Kingdom is GB. There is no UK. The tag is silently invalid, and it is easily the most common hreflang error on the web. Same class of mistake: lowercase regions, uppercase languages, and a region with no language at all. URLs that redirect. hreflang has to point at the final URL. If it points at http and you redirect to https, or it omits a trailing slash your server adds, the target is a redir

Building web applications today often comes with a trade-off between feature velocity and performance. Over-reliance on heavy frameworks or unoptimized third-party plugins can quickly lead to bloated bundle sizes and poor user experience. As an engineer running DevLanka , a small web and app development studio in Sri Lanka, I’ve had the opportunity to build custom web systems and mobile applications. In this article, I want to share a few practical engineering insights on modern web performance, toolchain selection, and practical security. 1. Toolchain & Bundle Size Considerations Moving from legacy build setups to modern toolchains like Vite and React 19 significantly improves development DX (Developer Experience) and build output: Module Bundling: Vite leverages ES modules during development, resulting in faster startup times and optimized production builds. Tree-Shaking: Ensuring modern JavaScript imports are properly tree-shaken prevents unused code from shipping to the client. Rendering Strategy: For public-facing, SEO-critical pages, client-side rendering (CSR) alone may not always be ideal. Combining SSG (Static Site Generation) or SSR (Server-Side Rendering) with lightweight React components ensures proper HTML pre-rendering for search crawlers. 2. When to Use Custom Engineering vs. CMS Platforms There is no single "best" tech stack for every project. Choosing between a traditional CMS (like WordPress/Wix) and custom software engineering depends entirely on project requirements: Use a CMS when: You need rapid deployment, simple content publishing, or a standard marketing site with a limited budget. Use Custom Engineering when: You require tailored business logic, seamless API integrations, custom database schemas, or fine-grained control over execution environments. Note on Security: Custom development reduces dependency on third-party plugin vulnerability exploits, but it is not inherently immune to security risks. Custom code still requires strict adherenc

The Problem with Most CI/CD Tutorials Most tutorials show you a pipeline that deploys a "hello world" app to a free Heroku instance. They skip the messy parts: secrets, rollbacks, and the moment your pipeline breaks because a dependency changed. I've been there. After years of fighting with over-engineered setups, I settled on a minimal pipeline that's easy to understand, debug, and extend. It's not fancy, but it works. The Core Idea A CI/CD pipeline is just three stages: Test - run automated checks Build - create an artifact Deploy - push the artifact to a server We'll use GitHub Actions because it's free for public repos and integrates with everything. But the same concepts apply to GitLab CI, CircleCI, or Jenkins. The Pipeline File Here's the complete .github/workflows/deploy.yml : name : CI/CD on : push : branches : [ main ] pull_request : branches : [ main ] jobs : test : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 - uses : actions/setup-node@v4 with : node-version : ' 20' - run : npm ci - run : npm test build-and-deploy : needs : test runs-on : ubuntu-latest if : github.ref == 'refs/heads/main' && github.event_name == 'push' steps : - uses : actions/checkout@v4 - run : npm ci - run : npm run build - name : Deploy to server uses : appleboy/scp-action@v0.1.7 with : host : ${{ secrets.SERVER_HOST }} username : ${{ secrets.SERVER_USER }} key : ${{ secrets.SSH_PRIVATE_KEY }} source : " dist/*" target : " /var/www/myapp" That's it. Let's break it down. Stage 1: Test The test job runs on every push and pull request. It checks out the code, installs dependencies with npm ci (which respects the lockfile), and runs your test suite. If a PR fails tests, the build-and-deploy job won't run because of the needs: test dependency. Stage 2: Build The build-and-deploy job only runs on pushes to main (not on PRs). It builds your app into a dist folder. For a Node.js app, npm run build might be a bundler like Vite or webpack. For a Python app, you'd replace with

Disclosure: I'm the founder of Popgot , which I use as the example below. The problem and the approach apply regardless of what you build on. Every price comparison project I've seen starts the same way: scrape a bunch of retailers, store the prices, sort ascending. And then it produces garbage rankings, because price is not a comparable field. Here's the classic failure. Three listings for AA batteries: Listing Price Count Brand A $5.99 16 Brand B $6.99 20 Brand C $11.94 40 Sort by price and Brand A "wins" at $5.99. Sort by cost per battery and the order flips completely: Brand C is ~29.9c per cell, Brand A is ~37.4c. The cheapest listing is the worst deal on the page. Why this is hard The naive fix is "just divide price by quantity." The problem is that quantity almost never exists as a clean number. It's buried in the title, and the title is written by whoever uploaded the listing: AA Batteries 24 Pack AA Alkaline Batteries, 1.5 Volts, 24 Count 48-Pack (2 x 24) Double A So you end up writing a title parser. Then you discover the same product needs a different unit depending on the category: per fluid ounce for detergent, per serving for protein powder, per 100g for coffee, per sheet for paper towels. Then you discover that some categories need a spec filter before unit price is even meaningful. A fish oil at 20c per serving isn't cheaper than one at 34c per serving if the first one has half the EPA+DHA. You're comparing two different products. That last part is the piece people underestimate. Normalization is only valid within a set of products that actually satisfy the same requirement, which means something has to read the label, not just the title. What a normalized record looks like This is the problem I ended up building Popgot around, so rather than describe it abstractly, here's the shape of the data. The developer API returns listings with the unit math already done: GET /api/developer-api/products?query=aa+batteries&limit=10 { "products" : [ { "display_t

GitHub热门项目 | Open-source AI browser agent for Chrome and Firefox (monorepo) 🧠 | Stars: 905 | 35 stars today | 语言: JavaScript

Ever logged into an app, closed the tab, come back, and you're still logged in — no password needed? That's almost always JWT doing its job behind the scenes. JWT (JSON Web Token) is one of the most common ways to handle authentication in modern backends. But a lot of developers use it without really understanding what's happening — and that's exactly where security bugs sneak in. Let's fix that. By the end of this post you'll know what a JWT actually is, how to use it in a Node.js + Express app, and the mistakes that quietly break real apps. What is a JWT, really? A JWT is just a string with three parts , separated by dots: xxxxx.yyyyy.zzzzz │ │ │ header payload signature Header — says which algorithm signed the token (e.g. HS256 ). Payload — the actual data (like userId , role , and an expiry time). This is not encrypted — it's just Base64-encoded. Anyone can read it. Signature — a cryptographic stamp created using a secret only your server knows. This is what stops people from faking tokens. Want to see this for yourself? Paste any token into a free JWT decoder and you'll instantly see the header and payload. Notice you can read everything without the secret — that's the key lesson: never put passwords or sensitive data in a JWT payload. Creating a token (login) Install the library: npm install jsonwebtoken When a user logs in successfully, sign a token: import jwt from ' jsonwebtoken ' // On successful login: const token = jwt . sign ( { userId : user . _id , role : user . role }, // payload process . env . JWT_SECRET , // secret (keep it in .env!) { expiresIn : ' 7d ' } // auto-expiry ) res . json ({ token }) Three things to notice: Keep the payload small — just an id and role, not the whole user object. The secret lives in an environment variable, never hardcoded. Always set expiresIn . A token that never expires is a token that can be stolen forever. Verifying a token (protecting routes) Now create a middleware that checks the token on every protected request

The Problem I was staring at my terminal during a deploy, waiting for the build to finish, when I realized something: I'd been typing figlet "Hello World" into my terminal for years to generate ASCII art for commit messages and README files. But every time I wanted to share that art with someone who wasn't a developer, I hit a wall. "Just install figlet," I'd say. "Install what now?" they'd reply. The problem wasn't that ASCII art tools don't exist online. The problem was that the ones I found were either bloated with ads, required JavaScript frameworks that made the page take forever to load, or couldn't handle non-Latin characters gracefully. I wanted something that just worked in a browser tab, no installation, no server, no fuss. So I decided to build my own. Because apparently I enjoy reinventing wheels. The AI-Assisted Development Journey Here's where things get interesting. I've been using AI pair programming for a while now, and this project felt like the perfect test case: it's well-defined, has clear requirements, and involves a lot of repetitive font data that would be tedious to type manually. The Initial Prompt I started by describing the requirements to an AI assistant in pretty specific terms: Build a single-file HTML tool that converts text to ASCII art. Must have multiple fonts (Block, Slant, Small, Standard, Mini). Real-time preview. Copy to clipboard. Download as .txt. Support dark mode. Chinese/English i18n. Vanilla JS only. The AI came back with something surprisingly decent. It had the basic structure right, the font data was embedded, and the rendering logic was clean. But there were issues. Where AI Got It Wrong The first problem was character handling . The AI assumed that all input would be uppercase English letters. When I tested with lowercase, numbers, and special characters, it just... broke. Not crashed, but silently dropped characters. // What the AI initially wrote (simplified) function getChar ( char , font ) { return font [ char .

Two audio players do not make a fair before-and-after test. If the second player restarts from zero or takes half a second to load, the user is no longer comparing two versions of the same moment. They are comparing two memories. That is a weak way to evaluate any audio effect. It is especially weak for AI processing. A denoiser can remove a fan while softening consonants. A de-reverb model can reduce the room tail while making the voice sound less natural. The output may be cleaner without being better. The preview therefore has one job: let the listener switch quickly enough to hear both the improvement and the damage. The rule I use is deliberately boring. Both versions should contain the same edit and play from the same position. Switching should not restart playback or create a pause. The interface should not hint that one version is supposed to win. Two independent <audio> elements fail surprisingly quickly. Each owns its playback state, buffering behavior, clock, and seek operation. The user ends up finding the same position twice and comparing one sound with a memory of another. A better interface has one transport and one version control: [ Play ] [ Original | Processed ] 00:18 ━━━━━━━ 00:42 The transport decides where playback happens. The segmented control decides which signal is audible. One transport, two signals For a short preview, I decode both files into AudioBuffer s, start them at the same AudioContext time and offset, and route each through its own GainNode . Both sources run; only one gain is open. decodeAudioData() decodes complete file data and resamples it to the context's sample rate. The decoded buffers can then share the same audio clock. See the MDN documentation for format and loading details. The core is small: const context = new AudioContext (); const originalGain = context . createGain (); const processedGain = context . createGain (); originalGain . connect ( context . destination ); processedGain . connect ( context . destination )

The Evolution of Web Forms — Part 3: React Hook Form, Validation Libraries, and Zod In Part 2, we learned that React solved the problem of manually updating the DOM. Instead of writing: emailError . textContent = " Email already exists " ; emailInput . setAttribute ( " aria-invalid " , " true " ); React allowed us to describe the interface from state: < input aria-invalid = { Boolean ( errors . email ) } /> { errors . email && ( < p > { errors . email } </ p > )} However, React did not automatically manage: Form values Validation errors Touched fields Dirty fields Submission state Reset behavior Dynamic fields Backend errors Performance Developers still had to build those features manually. That created the need for form-management libraries. This part covers: React Hook Form’s philosophy and architecture React Hook Form’s core APIs Validation libraries React Hook Form with Zod and TypeScript By the end, we will build a production-style registration form using: React + TypeScript + React Hook Form + Zod + An API layer Stage 9: React Hook Form Deep Dive React Hook Form is not simply a shorter way to write controlled React forms. It uses a different architectural philosophy. A traditional controlled input stores its value in React state: const [ email , setEmail ] = useState ( "" ); < input value = { email } onChange = { ( event ) => { setEmail ( event . target . value ); } } /> Every keystroke produces a state update: User types ↓ onChange runs ↓ setEmail runs ↓ Component renders again ↓ Input receives the new value React Hook Form prefers native, uncontrolled inputs when possible. < input { ... register ( " email " ) } /> The browser stores the current value inside the input element. React Hook Form registers the input, listens to its events, tracks relevant form state, and reads its value when required. React Hook Form’s official documentation describes register() as the mechanism that connects an input to validation, value tracking, and submission. Controlled vers

A user told me the .webp files my tool produced wouldn't open on their desktop. I opened one in a hex editor. First four bytes: 89 50 4E 47 . It was a PNG. With a .webp extension. The encoder wasn't broken. I had simply never checked whether the browser actually did what I asked. The spec says it's allowed to do this Here's the code. Nothing looks wrong with it: canvas . toBlob ( blob => { download ( blob , ' output.webp ' ); }, ' image/webp ' ); The callback fires. The blob isn't null. Its size looks reasonable. Everything succeeds — except it isn't WebP. This is not a bug. The HTML spec explicitly requires it: if the user agent doesn't support the requested type, it must create the file using the PNG format instead. No exception, no warning, no second argument telling you what happened. There's exactly one place that information exists — blob.type : canvas . toBlob ( blob => { console . log ( blob . type ); // iOS below 16.4: "image/png" }, ' image/webp ' ); toDataURL does the same thing, but at least there the fallback is visible to the naked eye, since the data URL literally starts with data:image/png;base64, . There is no capability query for this My first instinct was to special-case iOS. That falls apart quickly. Every browser on iOS is WebKit underneath, so "is this Safari" isn't a meaningful question. Embedded webviews inside apps track the system version in ways that don't always match the standalone browser. And a user can flip on "Request Desktop Website" and hand you a macOS user agent from an iPhone. More fundamentally: the user agent string answers "who are you" , and I need to know "can you encode WebP right now" . Between those two questions sit the engine version, OS version, host app, and build flags. Any mismatch in that chain and your lookup table lies to you. So I went looking for an official capability API. Media has them: MediaRecorder . isTypeSupported ( ' video/webm;codecs=vp9 ' ); // → boolean await navigator . mediaCapabilities . encoding

A game can be mechanically correct and still feel flat. The button works. The enemy loses health. The coin counter increases. The level completes. Everything technically functions, but the player's actions do not seem to have much weight. Particle effects are one of the cheapest ways to fix that. Not because every screen needs fireworks, but because particles give actions a visible consequence. Feedback Should Happen Immediately Imagine tapping an enemy in a mobile game. Version A: tap enemy HP decreases Version B: tap small flash impact particles enemy reacts HP decreases The underlying mechanic is almost identical. The second version communicates the result more clearly. The player sees exactly where the hit happened. That matters on mobile screens where fingers frequently cover part of the action. Particles Can Explain the Game VFX is not only decoration. It can communicate state. Damage Particles show where an impact happened. Healing A slow upward effect can visually separate healing from damage. Selection A subtle glow or ring can show which object is active. Currency Particles moving toward a counter connect the collected object with the UI value that changed. Cooldowns A burst or dissolve can show that an ability has become available. Danger Smoke, sparks, or unstable energy can communicate that an object is close to breaking. Good VFX helps the player understand the game without another label or tutorial popup. Timing Matters More Than Particle Count A common mistake is assuming better effects need more particles. They usually need better timing. Consider a button press. You could emit 100 particles over two seconds. Or you could emit 12 particles exactly when the interaction occurs. The second effect will often feel better because it reinforces the player's action. For responsive games, the sequence might look like this: 0 ms input 0 ms visual response begins 20 ms burst expands 80 ms largest particles appear 200 ms effect begins disappearing 350 ms effect

The Evolution of Web Forms Part-1 — From Plain HTML to AJAX Modern React forms can feel unnecessarily complicated when you first encounter tools such as React Hook Form, Zod, resolvers, controlled inputs, refs, formState , and server-error handling. Why do we need all of that? Why not simply read the value from an input and send it to the server? To understand why modern form libraries exist, we need to understand the problems developers faced before those libraries were created. In this series, we will evolve the same idea step by step: Plain HTML ↓ Native HTML validation ↓ JavaScript validation ↓ AJAX submission ↓ React controlled forms ↓ Form libraries ↓ React Hook Form ↓ React Hook Form + Zod ↓ Production form architecture This first part covers the first four stages: Plain HTML forms Native HTML validation Vanilla JavaScript validation AJAX form submission By the end, you will understand how forms worked before React and why each new approach became necessary. Stage 1: Plain HTML Forms Before React, AJAX, or even large amounts of client-side JavaScript, browsers already knew how to submit forms. HTML forms are not just visual containers. They are a built-in browser mechanism for collecting data and sending an HTTP request. A basic registration form <!DOCTYPE html> <html lang= "en" > <head> <meta charset= "UTF-8" /> <meta name= "viewport" content= "width=device-width, initial-scale=1.0" /> <title> Registration Form </title> </head> <body> <h1> Create an account </h1> <form action= "/register" method= "POST" > <div> <label for= "username" > Username </label> <input id= "username" name= "username" type= "text" /> </div> <div> <label for= "email" > Email </label> <input id= "email" name= "email" type= "email" /> </div> <div> <label for= "password" > Password </label> <input id= "password" name= "password" type= "password" /> </div> <button type= "submit" > Register </button> </form> </body> </html> There is no JavaScript in this example. The browser handles the ent

🚀 From FlipaClip to SitePoint: The Full Story of Kehinde Owolabi How a Nigerian teenager built a professional game engine with borrowed laptops, offline W3Schools, and pure determination. 🎮 Play the Game Try Limn Engine Live — Space Shooter Demo See what 4 years of determination built. This space shooter runs at 60 FPS on a Tecno Pop 4 with 1GB RAM. 📖 Introduction Every developer has an origin story. Some start with a fancy computer and a computer science degree. Others start with a flipbook app and a sister who trusted them with her phone. My name is Kehinde Owolabi . I'm 18 years old (born December 4, 2007), and I live in Lagos, Nigeria. I'm currently in PC103 at BYU Pathway, and I'm a member of The Church of Jesus Christ of Latter-day Saints. I built a 94/100 professional game engine called Limn Engine. It runs at 60 FPS on a Toshiba with 4GB RAM. It was published on SitePoint and ranked #3 among 2D JavaScript game engines. Nobody knew it was developed on a Chromebook, a borrowed Thinkpad (behind my sister's back), and a Toshiba that "hung like hell." That was the secret I kept for months. But that's only one part of this story. This is the full story of how I went from a button phone to a 94/100 game engine, from FlipaClip to SitePoint, from a boy who failed physics to a developer who built something that runs on a Tecno Pop 4. The one-line summary: "I'm Kehinde Owolabi, an 18-year-old developer from Lagos, Nigeria who went from FlipaClip to building a 94/100 game engine on borrowed laptops — and got published on SitePoint." 🎮🚀 🎨 The Beginning: FlipaClip and the Spark of Creativity Before I was a developer, I was an animator. I used FlipaClip — a simple animation app on mobile — to create flipbook-style animations. I loved bringing characters to life, frame by frame. I would spend hours drawing, tweaking, and watching my creations move. That creative spark stayed with me. I wanted to create interactive experiences. I wanted to build games. But I didn't know how.

What if adding Kotlin and Java compilation to your application didn't mean building an entire compilation pipeline yourself? What if you could add Bytesmith, configure the filesystem once, provide your source files and output destination, and simply compile? That's the idea behind Bytesmith . Bytesmith is a Kotlin and Java compiler toolkit designed for JVM and Android applications. It provides a unified API for Kotlin, Java, and mixed-language compilation, while also supporting filesystem abstraction, custom classpaths, boot classpaths, compiler plugins, packaging, and diagnostics. Configure the environment, provide the source, specify the output, and compile. The problem Compiler tooling can become surprisingly difficult when it is tightly coupled to the environment in which it was originally designed to run. You might need to deal with: Kotlin compiler versions Kotlin standard libraries Java compilation Bootclasspath configuration Dependency classpaths Source discovery Output handling Android storage Storage Access Framework URIs Packaging Compiler diagnostics And then there is the question of where those files actually live. On a desktop JVM, you might have traditional filesystem paths: /home/user/project/src/Main.kt On Android, you might be working with application storage or files selected through the Storage Access Framework: content://... If your compiler API directly depends on java.io.File , your compilation code becomes coupled to one filesystem model. Bytesmith takes a different approach. Adding Bytesmith The goal is to make compilation something you can plug into an application. With Gradle: implementation ( "io.github.sifisofakude.bytesmith:bytesmith-common:1.0.0" ) After adding Bytesmith, configure the filesystem your application wants to use. For a JVM application: FileSystems . current = JvmFileSystem () For Android: FileSystems . current = AndroidSafFileSystem ( context ) Once the filesystem is configured, the rest of the compilation layer can opera

How to Extract Colors From an Image Using JavaScript and Canvas Have you ever looked at an image and wanted to know the exact HEX color of a particular pixel? Designers often need to extract colors from photographs, screenshots, logos, UI designs, and illustrations. You can do this directly in the browser without uploading the image to a server. The browser Canvas API gives us everything we need. Reading pixels with Canvas The basic process is: Load an image. Draw it onto a canvas. Read the pixel data. Convert the RGBA values into a color format such as HEX or RGB. The important API is getImageData() . javascript const imageData = ctx.getImageData(x, y, 1, 1); const pixel = imageData.data; const r = pixel[0]; const g = pixel[1]; const b = pixel[2]; const a = pixel[3];