r/frontenddevelopment

Following the Vanilla JS culture, I built a Javascript library that creates HTML elements associated with a variable and a CSS style with a single instruction.

This approach allows you to create web applications using "99.9%" JavaScript, so the HTML files work by importing these scripts. You practically don't create HTML elements in the HTML file; the most you use is up to the body tag. The rest is all Javascript file import.

The result is clean code, without HTML tag trees that make project maintenance difficult.

Since almost everything is done via Javascript, maintenance is much clearer and therefore easier.

A collateral benefit is the identification of created elements via browser inspection, including the CSS style associated with that element in a clear and simple way.

Only the library at: https://github.com/addller/kalida_script.git

Example available at: https://github.com/addller/kalida_framework.git

What belongs in Redux, URL state, server cache, and local state in modern React apps

As a senior developer I’ve seen many developers over-engineering the front-end system and putting too many things in Redux (or Zustand) but after years using Next.js, React Query, context providers and URL parameters, I have a clear vision on what goes and what does not go into global state, there is also a bit of server side rendering.

This is still a problem in the front-end because we don’t see clearly the difference between app state and server state, to give you an example in a social media style page app state can be the posts that you’re actually interacting with and pressing likes and server state are the new posts that are added in the meantime, we need to have a clear picture of what the user is interacting with if we don’t want them to make an update on the wrong post, or see an outdated number of likes because of the wrong cache or offline mode. When new posts come in the feed we need to implement techniques to sync with the app state taking into account a sync strategy: optimistic updates, handling race conditions, and sometimes offline queues so interactions are not lost or applied to the wrong entity.

By adding too much to the global state we’re increasing the cost in several ways: rerendering too much, having stale data that is not synced with the server source of truth, and increasing the difficulty to test components. The smaller the state, the less we need to worry about these things, I’ve seen way too many times a parent React component that rerenders on every interaction every single child component because it is subscribed to too many store updates. There are mechanisms to prevent this, like React memoisation, split slices…

First we need to break down 4 different types of state:

• Server state: TanStack Query, React Query, Server side components and anything fetched from a REST API.
• URL state: query, path, filters, pagination, selected tab, shareable views
• UI state: modals/drawers open, themes, sidebars
• App state: Shopping carts, Draft composition, optimistic updates, offline queues.

What should never go in a global state:

• Controlled input value on every keystroke
• Page content that barely changes over time (blog posts)
• This object that I need in the next page so I’m going to save it in the state so everything seems like a single page application.

For example in a shopping website, the cart needs to be global as is shared across multiple components and pages, needs to be updated from the server regularly (server is the source of truth to keep prices and discounts real) Product details doesn’t need to be stored in the global state, server side rendering takes care of caching, and pagination, filtering and search are URL properties, there is no need to over complicate things here.
In a blog the articles need to be server side cached for SEO and speed, with optimistic updates on comments etc.

It is very useful to take this into consideration when reviewing a pull request, sometimes we don’t stop to think if the use of Redux is necessary to store the list pagination state or some terms and conditions text that we need in several places. A document in the repo for developers to come back to when making a decision is also a good idea.

In conclusion: default to local state and server cache (React Query, RSC, SSR where it fits). Use global state only when several components or pages share the same piece of data

If you liked posts like this you can visit my website to read more articles: raypoly.netlify.app/blog

I built eziwiki - a simple way to create beautiful documentation sites from Markdown files.

I kept needing docs for my side projects, but.. GitBook/Docusaurus felt like overkill and I wanted something that "just works"
And mkdocs is python based, and I need hash-based routing. (to ensure secure)

Live demos

- Blog example: https://eziwiki.vercel.app

Built with Next.js 14, TypeScript, Tailwind CSS, Zustand

Github : https://github.com/i3months/eziwiki

github star would be really really really helpful.

Feebacks are welcome!
I’m still actively building this.

Hi everyone,

As a korean junior developer, I'm sharing v0.1.0 of responsive-keepalive and would genuinely appreciate any feedback before I commit to the 1.0 API. It's still early, so honest criticism is more than welcome.

The problem I was trying to solve

Most responsive libraries just toggle CSS. But sometimes mobile and desktop layouts are structurally different — different component hierarchy, different data fetching — and the usual pattern ends up being:

{isMobile ? <MobileNav /> : <DesktopNav />}

The issue is that every breakpoint switch unmounts and remounts, which blows away local state and scroll position.

What it does

It wraps React 19.2's <Activity> to keep both trees mounted but one hidden, so state survives across switches.

const { Desktop, Mobile } = createResponsive({
  breakpoints: { mobile: 0, desktop: 768 }
});

function App() {
  return (
    <>
      <Mobile><MobileNav /></Mobile>      {/* mounted, state preserved */}
      <Desktop><DesktopSidebar /></Desktop>
    </>
  );
}

It also tries to handle: anti-thrash debounce, IME-safe switching (CJK keyboards), SSR, and falls back to a clean swap on React < 19.2 — though I'm sure there are edge cases I haven't thought of yet.

If you have a moment, I'd really appreciate thoughts on

1. Does the createResponsive API feel natural, or is there anything that seems off?
2. Are there use cases where you'd reach for something like this but it would fall short?
3. Is there anything that would make you hesitant to use it in a real project?

Any feedback at all — even "this isn't something I'd ever use, because..." — would be incredibly helpful.

Architecture Docs: responsive-keepalive · Architecture & API Pipelines
GitHub: https://github.com/vi-wolhwa/responsive-keepalive
npm: https://www.npmjs.com/package/@audemodo/responsive-keepalive

Thank you for taking the time to read this!

I'm looking for a powerful, NON-developer first shopping cart platform thats not shopify, wix, squarespace, ecwid, big commerce etc.

I'm currently evaluating: medusa, snipcart, square & shiftforshop. Essentially, I'm looking for something headless I could use on a cart perspective and use my own payment method. I'm open to any workarounds. I'm not a developer, but I know my way around HTML and frontend coding environments.

If you were in college right now in the final year what would you do to or learn to get the best of your placement drives?

I have created plugins for vue 3 which has almost all the components + various premium features like form builder, report builder and svg highlighters also. just have to install and start using it
if interested, contact me.