标签：#webdev

Hello Dev Community! 👋 It is Day 32 of my continuous web development run, and today I jumped into a project that pushed my array manipulation and conditional logic to a whole new level: A complete Snake and Ladder Board Game using HTML5, CSS3, and Vanilla JavaScript! After building Rock Paper Scissors yesterday, I wanted to tackle a game that requires tracking persistent coordinate states across a 100-cell mathematical grid. 🛠️ The Game Architecture & Logic Breakdown Building this wasn't just about random numbers; it was about managing spatial transitions on a dynamic interface. Here is how I structured the core backend mechanics: 1. The 100-Cell Grid Layout Instead of manually hardcoding 100 divs inside my index file, I engineered the grid programmatically. I mapped out a loop running from 100 down to 1, building individual cell elements and using CSS Grid properties to wrap them perfectly into a standard 10x10 layout matrix. 2. Mapping Snakes & Ladders (The Jump Engine) To build the shortcuts and traps, I didn't write massive, messy if-else trees. Instead, I utilized a clean JavaScript Object Map tracking key-value pairs where the key is the trigger tile and the value is the destination tile: javascript const gameModifications = { // Ladders (Climbing up) 4: 14, 9: 31, 21: 42, 28: 84, 51: 67, 72: 91, 80: 99, // Snakes (Sliding down) 17: 7, 54: 34, 62: 19, 64: 60, 87: 36, 93: 73, 95: 75, 98: 79 };

Tools like Claude Code and Codex have completely reshaped how software engineering is done. This new tooling allows for much faster development and iteration, but it's important to keep the code maintainable and scalable to make sure the project can continue evolving over the long term. A template project with an initial structure using all of the technologies described here is available on GitHub: https://github.com/MartinXPN/nextjs-firebase-mui-starter When working on a startup, the speed of iteration is key. The requirements change quickly, features are added daily, and code gets modified rapidly. In those conditions, picking technologies that enable fast iteration, while ensuring your users get the best experience possible, is crucial. During the last four years or so, we have experimented with many modern technologies while building Profound Academy . So, in this blog post, I'd like to present the whole tech stack that enables building quickly, while having a highly maintainable codebase, scalable infrastructure, and a great user experience. We'll cover everything from Authentication to UI, we'll talk about the backend, hosting, testing, and much more! AI Agents, Skills, and MCP servers AI Agents enable quick iteration and rapid improvement, including bug fixes, the addition of new features, and performance improvements. Yet, it's important to keep the code maintainable for the long run. AI tools make it really easy to overengineer things and add thousands of lines of code to a project. It's important to resist the urge to solve problems that don't exist yet, and keep things simple (both in terms of the code, the infrastructure, and the user experience). Even in the Agentic Software Development Era, having a small and simple setup helps. Agents coordinate better, features are added faster, bugs are fixed more easily, and the code is maintainable by humans, too. So, we have chosen to take a balanced/nuanced approach to how we use AI Agents when it comes to worki

Is FAANG Becoming MANGO in the AI Era? For years, FAANG was the gold standard for innovation and engineering excellence. If you were a developer, working at companies like Facebook (Meta), Apple, Amazon, Netflix, or Google was often seen as the ultimate career goal. But the AI revolution is changing the conversation. Today, some of the most influential companies aren't just building products—they're building intelligence. The spotlight is increasingly shifting toward AI-native organizations such as OpenAI , Anthropic , NVIDIA , and others that are shaping the future of software. The Bigger Shift This isn't really about replacing FAANG with another acronym. It's about a fundamental shift in technology: Search → Answers Automation → Agents Software → Intelligence Features → Capabilities As developers, we're entering an era where understanding AI is becoming as important as understanding frameworks, databases, and system design. What This Means for Engineers The most valuable engineers of the next decade will likely combine: Strong software engineering fundamentals AI-assisted development skills Prompt engineering LLM and agent integration AI-powered product thinking The goal isn't to compete with AI. The goal is to learn how to build with it. Read the Full Article This post was inspired by a thought-provoking article that explores the FAANG-to-MANGO idea in much greater detail. 👉 Read the complete article here: https://www.saurabhsharma.dev/blogs/mangos-vs-faang-ai-era/ What do you think? Are we witnessing the rise of a new generation of AI-first companies, or will traditional tech giants continue to lead the next wave of innovation?

By Sailee Shingare | M.S in Computer Science, Northern Illinois University Every time you visit a website, your browser and the server have a conversation. That conversation happens over a protocol — either HTTP or HTTPS. You’ve seen both in your browser’s address bar. But what’s actually different between them, and why does it matter? Let’s break it down. What is HTTP? HTTP stands for HyperText Transfer Protocol . It’s the foundation of data communication on the web — the set of rules that defines how your browser requests information and how servers respond. When you visit a website over HTTP, here’s what happens: You type a URL in your browser Your browser sends a request to the server The server sends back the webpage Your browser displays it Simple. But there’s a problem — everything is sent in plain text . Anyone sitting between you and the server can read it. Your passwords, your credit card numbers, your messages — all visible. This is where HTTPS comes in. What is HTTPS? HTTPS stands for HyperText Transfer Protocol Secure . It’s HTTP with an extra layer of security called TLS (Transport Layer Security) — previously known as SSL. The S in HTTPS means everything between your browser and the server is encrypted . Even if someone intercepts the data, they see nothing but scrambled gibberish. What Actually Happens When You Visit an HTTPS Website When you visit an HTTPS site, your browser and the server perform a TLS Handshake before any data is exchanged. Here’s what happens step by step: Step 1 — Client Hello Your browser says hello to the server and shares which encryption methods it supports. Step 2 — Server Hello The server picks an encryption method and sends back its SSL certificate — a digital document that proves the server is who it claims to be. Step 3 — Certificate Verification Your browser checks the certificate against a list of trusted authorities. If it’s valid, the connection proceeds. If not, you see a warning — “Your connection is not private.”

You’ve built something with Playwright. It works perfectly in your local environment. CI is green....

When you double-click WP Maintenance Manager, it opens a browser tab — and the entire UI lives inside that tab. No native window is created. It's an unusual structure for a first-time user, and the natural question is: "why a browser?" That choice was an intentional design decision when building a Python desktop application. Here's the comparison that led to it, and the side effects of the choice. Four realistic options For a WordPress maintenance automation tool, four implementation styles were practical: Approach UI Distribution size Dev cost Per-OS extra work Native (Swift / WPF) OS-native windows Small–medium High (separate impl per OS) Heavy PyQt / PySide Qt widgets Medium (~80 MB) Medium Light Electron Chromium-embedded web UI Large (~150 MB+) Medium Light Local Flask + system browser System browser tab Small (~50 MB) Medium Light PyQt was a serious early candidate. A Python-only stack is appealing, but widget styling drifts subtly between OSes, Qt's layout system demands constant attention, and resolving Qt plugins under PyInstaller is fiddly. Dev velocity was not where it needed to be. Electron is the industry-standard choice for cross-platform UI, with the big benefit that HTML/CSS-based UIs are quick to write. But the distribution is well over 100 MB, and memory consumption is heavy. For a tool that often runs in the background, that overhead is too much to justify. Why local Flask + browser won The final structure was Flask (Python's lightweight web framework) + the system browser for UI. The decision rested on three axes: 1. The backend had to be Python anyway SSH connections via fabric / paramiko , browser automation via playwright , encryption via cryptography — every library at the core of WordPress maintenance lives in the Python ecosystem. Writing the backend in another language wasn't really an option. If Python is already required on the backend, putting the UI in Python too keeps distribution simple. 2. HTML/CSS/JS makes UI iteration fast Flask r

At Inithouse — a studio running parallel product experiments — we built Be Recommended , a tool that checks how visible your brand is across ChatGPT, Perplexity, Claude, and Gemini. The idea sounded simple: query multiple AI models, score the results, show a report. It was not simple. Here are four technical mistakes we made shipping v1 — and the fixes that actually survived production. Mistake 1: Rate Limiting Was an Afterthought We treated rate limits as edge cases. They were not. Every AI provider has different rate-limit headers, different backoff expectations, and different definitions of "too many requests." Our first architecture just retried on 429. That turned a rate limit into a cascade — one provider throttling triggered a retry storm that cascaded to the others. The fix: Per-provider circuit breakers with exponential backoff. Each provider gets its own state machine. When a circuit opens, we serve cached results for that provider and mark the score as "partial" in the UI. Users see real data, not a spinner that never resolves. At Audit Vibe Coding — another tool in our portfolio focused on code quality audits — we observed the same pattern in a different domain: external API dependencies need isolation. The lesson transferred directly. Mistake 2: The Caching Strategy Was Too Naive Our first cache key was query + model . That breaks immediately — AI model responses drift over time, and a cached result from two weeks ago is misleading. We also had no invalidation strategy beyond TTL. The fix: Cache by query + model + week_number . Weekly invalidation with stale-while-revalidate: serve the cached score instantly, trigger a background refresh, update the display when new data arrives. Users get instant feedback and fresh data within the same session. We measured the impact across our portfolio: stale-while-revalidate cut perceived load time from 8+ seconds to under 1 second for returning visitors. The background refresh means scores stay current without the

Yesterday, as I was working on a CORS configuration, AI generated a block of code for me: const allowedOrigins = [ process . env . FRONTEND_URL || " http://localhost:3000 " , process . env . ADMIN_URL || " http://localhost:3001 " , ]. filter ( Boolean ); I was wondering... why use .filter(Boolean) here? 🤔 The fallbacks already guarantee strings. So I hovered on the variable. The type definition read: const allowedOrigins : string [] Fine. Made sense. But then I got curious. What if I removed the hardcoded fallbacks? const allowedOrigins = [ process . env . FRONTEND_URL , process . env . ADMIN_URL , ]. filter ( Boolean ); My type definition changed to: const allowedOrigins : ( string | undefined )[] I was shocked. I just filtered the array. How can TypeScript still think there's an undefined in there? First: What Does .filter(Boolean) Even Do? Boolean used as a filter function removes any falsy value from an array: false null undefined 0 "" NaN So: [ " https://app.com " , "" , undefined ]. filter ( Boolean ) // Result: ["https://app.com"] At runtime, this works exactly as you'd expect. No undefined survives. So why does TypeScript disagree? 🤷‍♀️ The Real Answer: TypeScript Doesn't Run Your Code TypeScript is a transpiler. It doesn't execute .filter(Boolean) — it only looks at types. When it sees this: array . filter ( Boolean ) It knows the callback returns a boolean . But it doesn't know what that means for the type of the elements that survive. It can't infer "if Boolean(x) is true, then x must be a string." So the undefined stays in the type — even though it'll never actually be there at runtime. That's the gap: your runtime behavior is correct, but your types are lying. The Fix: Type Predicates TypeScript lets you close that gap with a type predicate — a way of explicitly telling the compiler what a filter function guarantees: const allowedOrigins = [ process . env . FRONTEND_URL , process . env . ADMIN_URL , ]. filter (( origin ): origin is string => Boolean ( o

Let's be honest: standard AI chatbots are getting a bit boring. You ask them a question, they write back a beautiful paragraph of text, and then... nothing. They don’t actually do anything for your business. If you want to add a customer to your CRM, update a product on your website, or change something in your database, you still have to do it manually. That is why we decided to build something different. Instead of another chatbot that just talks, we created Gaotus Gaotus! See . It is an "execution AI" layer. This means it doesn't just reply to you—it actually connects to your tools (like WordPress, custom dashboards, or APIs) and does the manual work for you. Think of it like this: No more boring web forms to fill out. You just talk to the system, and it updates the database automatically. It checks the data for mistakes and logs everything securely before making any changes. It saves hours of manual data entry for small businesses. We are currently testing it with real-world scenarios, like automatic customer onboarding and syncing car dealership listings straight to web marketplaces. Since we are launching and improving this system, we would love to hear from other developers and creators: What is the most boring, repetitive task in your daily workflow that you wish an AI could just execute for you? Let’s chat in the comments!

So you have heard about the Tailwind CSS and want to incorporate into your new project. But those...

A data export endpoint dumps system diagnostics when it hits an invalid field. Feed it garbage, read the debug output, grab the flag. A data export feature lets you pick which profile fields to download. The UI only offers valid fields through checkboxes, so everything looks locked down. But the API behind it accepts arbitrary field names -- send it one it doesn't recognize, and instead of a clean error, it dumps full system diagnostics including internal feature flags. That's where the flag is. You'll bypass the frontend, hit the endpoint directly, and read what comes back. Lab setup Start the lab: npx create-oss-store@latest Or with Docker (no Node.js required): docker run -p 3000:3000 leogra/oss-oopssec-store The app runs at http://localhost:3000 . What you're targeting The app has a profile page at /profile with a Data Export tab. It lets users download their own data in JSON or CSV by selecting fields through checkboxes ( User ID , Email , Role , Address ID ) and clicking "Export Data". The UI looks safe -- you can only pick from a fixed set of valid fields, so there's no way to submit an invalid one through the browser. But that's just client-side validation. The endpoint behind it is POST /api/user/export , and it accepts a JSON body with two parameters: { "format" : "json" , "fields" : [ "id" , "email" , "role" ] } The fields value is an array of strings. The API checks each field against an allowlist. Valid fields? You get your data back. Invalid fields? The API throws an error -- and that error says way too much. Step-by-step exploitation 1. Log in You need an authenticated session. Use one of the seeded accounts: Email: alice@example.com Password: iloveduck Log in through the UI at /login , or grab a session cookie via curl: curl -c cookies.txt -X POST http://localhost:3000/api/auth/login \ -H "Content-Type: application/json" \ -d '{"email":"alice@example.com","password":"iloveduck"}' 2. Explore the Data Export tab Go to /profile and click the Data Export

Built Vidilearn — an AI-first CLI for extracting YouTube transcripts, subtitles, chapters, articles, and structured metadata locally with zero API keys. Supports MCP servers, AI agents, RAG pipelines, Codex CLI, Gemini CLI & more. GitHub: https://github.com/Alfo-Tech-Lab/vidilearn

UI IP Toolkit - A standalone static visual catalog for CSS/JS components I built UI IP Toolkit to solve my own workflow problem: I kept losing useful UI snippets (buttons, loaders, CTA blocks, glassmorphic cards, layout grids) across old projects and directories. Live site: https://ui-ip-toolkit.vercel.app/ GitHub Repository: https://github.com/ikerperez12/UI-IP-Toolkit-v4.0 Design Philosophy Zero dependencies: Raw HTML, CSS, and vanilla JS. No NPM packages, framework configurations, or build steps required. Copy-paste ready: Visual preview cards with one-click copy buttons for immediate use in any stack. Light/Dark mode: Clean design system focusing on micro-interactions, sleek gradients, and responsive layouts. Visual catalog: Catalog of gradients, buttons, fonts, loading states, hover treatments, glass surfaces, layout fragments, and UI patterns. How do you manage your personal code/CSS snippet collections? Hope this is useful to others!

I built a browser-based desktop environment (IP Linux) with React, TypeScript and Vite I have been working on a project called IP Linux : a browser-based desktop environment that runs as a static web app. Live site: https://ip-os-linux.vercel.app/ GitHub Repository: https://github.com/ikerperez12/IP-OS-LINUX It is not a real Linux distribution, and it does not run native binaries. The idea is different: I wanted to explore how far a polished desktop-like experience can go inside a normal browser tab. The result is a small web OS-style environment with: A splash / entry screen A desktop with icons, folders, and widgets A top panel with system controls A dock and app launcher Resizable and draggable windows Virtual workspaces Snap assist A global search / Spotlight-style command palette Local-first apps (Files, Terminal, settings, player) Reactive wallpapers Glass UI and visual effects Why I built it Most web demos are landing pages, dashboards, or small single-purpose apps. I wanted to build something that feels more like an environment. I was interested in questions like: Can a web app feel physical and desktop-like? How should windows behave inside a browser viewport? How far can local-first storage go before a backend is actually needed? How do you organize many small apps without making the UI messy? IP Linux became a way to test all of that in one project. The app includes a catalog of built-in apps and tools: Files, Terminal, Browser, Settings, App Store, Music Player, Matrix Rain, games, developer tools, productivity apps, and visual utilities. The virtual file system and user preferences are stored locally in the visitor's browser with IndexedDB/localStorage. There is no backend, no account system, and no required environment variables for the public release. Would love to get feedback on the interaction design, responsiveness, or features!

A blunt playbook for devs who don’t want to turn into autocomplete zombies. The first time an AI wrote code for me, I felt like I had unlocked cheat codes for real life. I typed a half-baked function name, hit enter, and suddenly I had a block of code that looked legit. It was magical. The second time, though? It suggested something so catastrophic basically the programming equivalent of pulling the fire alarm that I realized: this thing is less “mentor” and more “overconfident intern who thinks they know pointers but actually just broke prod.” That’s where most of us are right now. AI is everywhere: in our IDEs, our docs, even sneaking into PR reviews. Some days it feels like rocket fuel; other days it feels like an autocomplete with a drinking problem. The tricky part isn’t whether AI is “good” or “bad.” The tricky part is how we, as developers, use it without becoming lazy, dependent, or worse complacent. Because here’s the uncomfortable truth: AI won’t replace you, but bad AI habits absolutely will. TLDR : This article is a survival guide for developers in the AI era. We’ll break down why AI feels both magical and mid, the five switches that make AI actually useful, when to trust and when to verify, how to use AI as a research assistant (not a code monkey), the dangers of autocomplete brain, and a playbook for building a healthy workflow. Why AI feels both magical and mid Every dev I know has had that moment with AI. The first time it autocompleted a function and nailed it, you probably thought: “Wow… this thing just saved me half an hour.” It’s the same dopamine hit as discovering ctrl+r in bash or realizing you can pipe grep into less . Pure wizardry. But the honeymoon ends quickly. The same tool that wrote a clean utility function also happily hallucinates imports that don’t exist, invents APIs, and will confidently explain things that are flat-out wrong. It’s like pair programming with someone who sounds senior but has never actually shipped code. The magic-

Why I Chose GoFr for My Backend Project When starting a new backend project, one of the first decisions I need to make is choosing the right framework. Over the years, I’ve experimented with different backend technologies, each offering its own strengths and trade-offs. For my latest project, however, I decided to try something different: GoFr. At first, I was simply exploring the Go ecosystem and looking for tools that could help me build production-ready services faster. What caught my attention wasn’t just that GoFr was built in Go—it was the philosophy behind it. Instead of forcing developers to spend days configuring infrastructure, wiring dependencies, and setting up observability, GoFr focuses on helping developers get from idea to deployment quickly. In this article, I’ll share the reasons why I chose GoFr for my backend project and what stood out during my experience. The Problem with Starting Backend Projects Every backend project begins with excitement. You have an idea, a feature roadmap, and a vision of what you’re trying to build. Yet before writing meaningful business logic, developers often spend hours or even days configuring: Logging Database connections Metrics Tracing Health checks API routing Environment management Deployment configurations While these tasks are necessary, they rarely contribute directly to solving the actual problem your application is meant to address. As a developer who frequently builds side projects and prototypes, I wanted a framework that reduced this setup overhead while still following good engineering practices. That’s where GoFr entered the picture. What Initially Attracted Me to GoFr The first thing I noticed was how quickly I could get a service running. Instead of navigating through multiple configuration files and third-party packages, GoFr provides many essential backend capabilities out of the box. This means less time deciding which libraries to install and more time focusing on application logic. The framework

Every developer who has written a Playwright test for OTP verification has written this line: const otp = email . body . match ( / \b\d{6}\b / )?.[ 0 ]; It works. Until it doesn't. The email body changes format. The OTP appears inside an HTML table. The sending service wraps it in a <span> . Your regex matches a phone number instead of the code. The test fails intermittently and you spend an hour debugging something that has nothing to do with the feature you're testing. The regex problem OTP extraction via regex is brittle by nature. You're pattern-matching against a string that your email sending service controls — not you. Any time the template changes, your tests break. Here's what a typical OTP test looks like today: import { test , expect } from ' @playwright/test ' ; import { ZeroDrop } from ' zerodrop-client ' ; const mail = new ZeroDrop (); test ( ' user can verify OTP ' , async ({ page }) => { const inbox = mail . generateInbox (); // 1. Trigger OTP send await page . goto ( ' /login ' ); await page . fill ( ' [data-testid="email"] ' , inbox ); await page . click ( ' [data-testid="submit"] ' ); // 2. Wait for email const email = await mail . waitForLatest ( inbox , { timeout : 15000 }); // 3. Extract OTP — the fragile part const otp = email . body . match ( / \b\d{6}\b / )?.[ 0 ]; if ( ! otp ) throw new Error ( ' OTP not found in email body ' ); // 4. Enter OTP await page . fill ( ' [data-testid="otp"] ' , otp ); await page . click ( ' [data-testid="verify"] ' ); await expect ( page ). toHaveURL ( ' /dashboard ' ); }); The test works — but line 14 is carrying all the risk. Change the email template and the test breaks. Add a phone number to the footer and the regex matches the wrong number. Send a 4-digit OTP instead of 6 and you need to update the pattern. OTP extraction at the edge ZeroDrop extracts OTPs before they reach your test. The Cloudflare Worker that catches incoming emails runs a pattern match on the plain-text body and stores the result alongsi

Most developers have done this at least once. You get a messy API response. You need to inspect a JWT. You have a webhook payload, a log object, or a config file that is hard to read. So you open a JSON formatter, paste the content, and move on. That habit is convenient. But it also deserves a second look. Not every JSON tool behaves the same way. Some tools process your input entirely in the browser. Some send content to a server. Some store snippets for sharing. Some extensions have permissions that are broader than you expect. The problem is not that every online formatter is unsafe. The problem is that you often do not know what happens after you paste. What you should avoid pasting blindly Before using any random online tool, be careful with: production JWTs API responses containing user data logs from real systems config files webhook payloads database URLs cloud keys internal endpoints tenant IDs error traces from production systems A JSON payload does not need to contain an obvious password to be sensitive. Sometimes the risky part is context: user IDs, internal URLs, tokens, customer data, or system structure. A quick DevTools check You can do a basic check with your browser’s DevTools. Open the JSON tool. Open DevTools. Go to the Network tab. Clear existing requests. Paste a harmless test JSON first. Run format, validate, diff, decode, or whatever action the tool provides. Watch the Network tab. Look for POST, PUT, fetch, XHR, or beacon requests after your input. Inspect request payloads if they exist. Check whether your pasted JSON appears in any request. Do this with harmless test data first. If the tool uploads the test JSON, do not paste production content into it. What to look for A few signs deserve attention: POST requests after you paste or click format request bodies containing your JSON share-link features that save snippets server-side validation APIs analytics events that include pasted content extension background requests that are not clearly

Modern software delivery pipelines can deploy code dozens or even hundreds of times per day. Traditional penetration testing models, where security teams perform assessments quarterly or before major releases, simply cannot keep pace. Attackers do not wait for the next security review. Every pull request, dependency update, infrastructure change, or container image introduces potential risk. Integrating penetration testing into CI/CD enables organizations to identify vulnerabilities before they reach production. The goal is not replacing human penetration testers. The goal is automating everything that can be automated so security experts can focus on complex attack paths and business logic flaws. Understanding Security Testing Layers in CI/CD Security testing is often misunderstood because multiple categories overlap. Testing Type Purpose SAST Analyze source code SCA Detect vulnerable dependencies DAST Test running applications IAST Runtime security analysis Penetration Testing Simulate attacker behavior Penetration testing combines elements of all these approaches. A mature CI/CD pipeline continuously performs automated penetration testing while reserving manual testing for sophisticated attack scenarios. Designing a Security-First CI/CD Architecture A security-centric pipeline typically looks like: Developer Commit ↓ Pre-Commit Security Checks ↓ Pull Request Validation ↓ Build Stage ↓ Container Security Scan ↓ Infrastructure Validation ↓ Deploy to Staging ↓ Automated Penetration Testing ↓ Security Gate ↓ Production Deployment Each stage eliminates vulnerabilities before they become more expensive to fix. Stage 1: Pre-Commit Security Controls The cheapest vulnerability is the one that never reaches Git. Secret Detection Install TruffleHog or Gitleaks before code reaches the repository. repos : - repo : https://github.com/gitleaks/gitleaks rev : v8.20.0 hooks : - id : gitleaks Developer installation: pip install pre-commit pre-commit install Now every commit is aut

Since the Umbraco 16 release, Umbraco ships only with the TipTap Rich Text Editor. This was unfortunately something that Umbraco was forced to do. TinyMce 7 has a license that is incompatible with the open source license of Umbraco and TinyMce 6 was going out of support. So an alternative had to be found. Umbraco did a pretty good job at abstracting the rich text data. In Umbraco 15 both TinyMCE and TipTap were still present and exchangeable because of this abstraction. And arguably, the way you can set up your toolbars for the TipTap editor is superior to TinyMCE. But still, a new Rich Text Editor is a big change that presents real challenges. These challenges are most obvious when looking at the Umbraco forum's tip-tap tag . Topics vary, but a few come up again and again: Additional HTML tags getting added to the markup, like a <p> tag inside a <li> The inability to add certain tags to TipTap, like <script> tags The inability to add styling to an element, for instance to create a link that looks like a button These are valid challenges, especially if you're upgrading from an existing TinyMCE setup. But this is also a good moment to ask two questions: Why do I want the same behaviour? And was the old behaviour actually any good to begin with? You don't have to migrate everything at once Before getting into that, it's worth knowing that TinyMCE is still available as a community package for Umbraco 16+. If you're in the middle of a project, dealing with a large codebase, or just not ready to rethink your Rich Text Editor setup right now, that's a valid escape hatch. Swap in the package, keep things running, and give yourself time to migrate properly. But "later" should still be on the roadmap. The package is community maintained, not an official Umbraco product, so there are no guarantees around long-term support or compatibility with future Umbraco versions. Relying on it indefinitely carries the same risk as the situation Umbraco just came out of with TinyMCE 6. So