DEV Community: Aleksandar Maletic

Meet BlokJS - 9 KB, No Build Step, Standalone, Full FE Framework

Aleksandar Maletic — Mon, 02 Mar 2026 20:32:12 +0000

BlokJS - Zero-Build, Zero-Dependency, Standalone, Reactive, Lightweight UI Framework

New project, new frontend. Install Node. Pick a bundler. Configure TypeScript. Install a router package. Install a state management package. Set up hot reload. Debug the config. Twenty minutes later you still haven't written a single line of UI code.

BlokJS is a reactive UI framework that skips all of that.

One <script> tag. 9 KB gzipped. Zero dependencies. No virtual DOM, no JSX, no template compiler. Your views are plain JavaScript objects - the browser runs them directly.

<script src="https://cdn.jsdelivr.net/npm/@maleta/blokjs/dist/blokjs.min.js"></script>

That's your entire setup.

Philosophy

BlokJS is built around a few ideas:

No build step required. A framework that needs a compiler before it can run has already added complexity. BlokJS app is plain JavaScript object - it run directly in the browser. You can still use a bundler if you want to have code well organized in files , but it's never a requirement.

Batteries-included, not batteries-heavy. Reactive state, components, routing, stores, and async tracking are all built in. One 9 KB package instead of assembling five separate libraries. But "included" doesn't mean "bloated" - the goal is to cover common needs without unnecessary weight.

Simplicity over cleverness. The API surface is small on purpose. There are no special directives, no lifecycle alphabet soup, no framework-specific syntax to learn. If you know JavaScript objects and functions, you already know most of the BlokJS.

Direct DOM updates, no virtual DOM. Instead of diffing a virtual tree and patching the real DOM, BlokJS tracks exactly which state each binding depends on and updates only that binding when the state changes. This avoids the overhead of a full diff/patch cycle, making targeted updates fast and predictable.

Counter in 15 Lines

Let's start with the most basic example - a counter. No install, no config, no build:

<script src="https://cdn.jsdelivr.net/npm/@maleta/blokjs/dist/blokjs.min.js"></script>
<div id="app"></div>
<script>
  blok.mount('#app', {
    state: { count: 0 },
    methods: {
      inc() { this.count++ },
      dec() { this.count-- },
    },
    view: ($) => ({
      div: { children: [
        { h1: { text: $.count } },
        { button: { click: 'dec', text: '-' } },
        { button: { click: 'inc', text: '+' } },
      ] }
    })
  })
</script>

That's it. state is reactive. When count changes, the h1 updates automatically. The $ proxy creates reactive references that the framework resolves at render time. No useState, no useEffect, no ref(). Just state and a view.

Why Objects Instead of JSX or Templates?

Instead of <div class="card"> or React.createElement('div'), BlokJS uses plain objects:

// This...
{ div: { class: 'card', children: [
  { h1: { text: $.title } },
  { p: { text: $.description } }
] } }

// ...renders this:
// <div class="card">
//   <h1>My Title</h1>
//   <p>Some description</p>
// </div>

Why? Because it's just JavaScript. No parser. No compiler. No template language to learn. You can refactor with standard tools, and there's nothing between your code and the browser.

The key elements of the view DSL:

text - text content, static or reactive ({ text: $.name })
children - array of child elements
class - string, object, or array ({ class: { active: $.isActive } })
model - two-way binding for inputs ({ input: { model: $.search } })
when - conditional rendering ({ when: $.isVisible, children: [...] })
each - list rendering ({ each: $.items, as: 'item', children: [...] })
Events - just the event name as key ({ button: { click: 'save' } }) with optional arguments ({ click: 'remove(item)' })

Negation works too. $.not.isLoggedIn evaluates to true when isLoggedIn is falsy. No ternaries, no ! operators in templates.

Components - Not a Toy

BlokJS has a component system with props, events, slots, and lifecycle hooks:

blok.component('TodoItem', {
  props: ['todo'],

  methods: {
    remove() { this.emit('remove', this.todo) }
  },

  view: ($) => ({
    li: { children: [
      { input: { type: 'checkbox', model: $.todo.done } },
      { span: { text: $.todo.text } },
      { button: { click: 'remove', text: 'x' } },
    ] }
  })
})

Use it in a parent by name. Pass props, listen to events with the on_ prefix:

{ each: $.todos, as: 'todo', key: 'id', children: [
  { TodoItem: { todo: $.todo, on_remove: 'handleRemove' } }
] }

Components also support slots for content projection, computed properties, watchers, and mount/unmount lifecycle hooks.

Stores - Global State with Automatic Async Tracking

Most frameworks require you to manually wire up loading spinners and error messages for every async operation. BlokJS handles this automatically.

Define a store:

blok.store('auth', {
  state: { user: null },

  computed: {
    isLoggedIn() { return this.user !== null }
  },

  methods: {
    async login(email, password) {
      const res = await fetch('/api/login', {
        method: 'POST',
        body: JSON.stringify({ email, password }),
      })
      this.user = await res.json()
    },
    logout() { this.user = null }
  }
})

Now in your template, you get loading and error on the spot:

// Loading spinner - appears automatically while login() runs
{ when: $.store.auth.loading.login, children: [
  { p: 'Signing in...' }
] }

// Error message - appears automatically if login() throws
{ when: $.store.auth.error.login, children: [
  { p: { class: 'error', text: $.store.auth.error.login } }
] }

// Logged in state
{ when: $.store.auth.isLoggedIn, children: [
  { p: { text: $.store.auth.user.name } }
] }

Any method that returns a Promise is tracked. The framework wraps it, sets loading.methodName = true, and if it throws, captures the error into error.methodName. You just bind it. This works for both store methods and component methods.

Routing - Built In

No separate router package. Routes, dynamic params, guards, hash and history modes are all included:

blok.mount('#app', {
  routes: [
    { path: '/', component: 'Home' },
    { path: '/product/:id', component: 'ProductDetail' },
    { path: '/admin', component: 'Admin', guard: 'requireAuth' },
    { path: '*', component: 'NotFound' },
  ],

  guards: {
    requireAuth(to, from) {
      if (!this.store.auth.isLoggedIn) return '/login'
      return true
    }
  },

  view: ($) => ({
    div: { children: [
      { a: { href: '/', link: true, text: 'Home' } },
      { a: { href: '/admin', link: true, text: 'Admin' } },
      { div: { route: true } },
    ] }
  })
})

Inside components, access route data via this.route.params, this.route.query, and navigate programmatically with this.navigate('/path'). Guards can return true (allow), false (block), or a redirect path string.

Security

I wrote about CORS, XSS and CSRF before, and web security was on my mind when building BlokJS.

The text binding is always safe - it uses textContent, so HTML in user input is rendered as literal text, not parsed. The html binding sets innerHTML directly without sanitization, same as Vue's v-html. If you need to render HTML, make sure you trust the source - never pass unsanitized user input to html.

URL attributes (href, src, action) are validated - javascript: and data: URIs are blocked.

What BlokJS is Not

BlokJS is not trying to replace React, Angular or Vue for enterprise dashboards with hundreds of components. It doesn't have SSR yet - though since views are plain objects rather than DOM-dependent templates, server-side rendering is a natural future addition. It doesn't have a virtual DOM (by design - fine-grained reactivity means direct DOM updates, which works well for most use cases).

Where it fits:

Prototypes and MVPs where you want something running quick
Internal tools and admin panels
Small to medium apps - todo lists, dashboards, forms
Learning - the entire API fits in your head in an afternoon
Embedding - drop reactive UI into any existing page

LLM-Friendly by Design

BlokJS ships with a dedicated LLM reference document - a condensed version of the entire API optimized for LLM consumption.

The document is ~2,900 tokens (measured using Anthropic's official token counting API). That's small enough to paste into any LLM's context window - less than 1.5% of a 200K context window.

The idea: include it in your prompt, and an LLM can write working BlokJS code with accurate API usage. The reference is part of the npm package (llm-reference.md), so it's always available alongside the framework itself.

Getting Started

CDN (zero setup):

<script src="https://cdn.jsdelivr.net/npm/@maleta/blokjs/dist/blokjs.min.js"></script>

Without a bundler, you have full control over what loads and when. Split components into separate files, load them conditionally, defer what isn't needed on first render - the browser handles it natively.

npm:

npm install @maleta/blokjs

With Vite:

npm create blokjs my-app
cd my-app
npm install
npx vite

The Vite plugin adds automatic component and store registration from file directories, bundled output, and hot module replacement during development.

Links:

BlokJS is MIT licensed. If you try it, I'd love to hear what you build.

Transforming Internet Browsing Experience on Desktop: A Proof of Concept

Aleksandar Maletic — Wed, 05 Jun 2024 20:23:56 +0000

Over time, desktop internet browsing can become clumsy due to the accumulation of numerous open tabs. You may become attached to tabs you've opened or you forget to close them, and you end up carrying them over to each new browsing session. This issue has been recognized in recent years, and some solutions have been developed to enhance the browsing experience.

The most valuable solution for me was the introduction of tab grouping in Chrome. It helped keep my tabs organized. Before this, there were similar tools to tackle this problem, such as Session Buddy, a Chrome extension that allows you to store and manage sessions effortlessly.

However, both solutions share a common drawback: web browsing now requires time for tab management. While the time involved isn't substantial, it disrupts the browsing flow, requiring a cleanup after each session or cleaning opened tabs during browsing, and that is not fun.

After my last browsing session cleanup, I reflected on how having so many tabs open had become normal. I realized that the web browsing experience hasn't fundamentally changed since the introduction of tabs. When opening a link, you either replace the current page or open in a new tab.

What if there was a way to open a link in the same position as the link itself, without replacing the current page?

This approach should lead to fewer open tabs per session and provide a smoother browsing experience, as your eyes wouldn't need to readjust to a new position.

To test this browsing experience, I built a simple Chrome extension (source).

Here's a preview of how it works:

The extension works partially due to multiple security concerns and the fact that it utilizes the iframe HTML element. If this browsing experience is properly integrated, users should have an isolated and safe browsing experience.

Feel free to share your thoughts or suggestions.

CORS, XSS and CSRF with examples in 10 minutes

Aleksandar Maletic — Mon, 23 Dec 2019 11:15:21 +0000

This article should be your entry point for existing web security standards, most common web attacks and the methods to prevent them. At the end, you will also find out how and why Samy was everyone's hero.(except Rupert Murdoch's, I guess)

CORS

Cross-origin resource sharing, or CORS, is security feature of IE10+, Chrome 4+, Firefox 3.5+ or almost every version of browser released after 2012 except Opera Mini.

When CORS are configured on server that is available on domain website.com then resources from that domain those are requested trough AJAX must be initiated from assets that is served from that same domain.

In the other words, if we enable CORS on domain-b.com and configure it to allow only GET requests from domain domain-b.com then if you want to use image available under https://domain-b.com/images/example.png in canvas on your website which is hosted on domain-a.com, than that image will not be loaded for most of your visitors.
Your resources protected by CORS will still be available when requested by any tool or browser that doesn't respect CORS policy.

CORS configuration

CORS are disabled by default which means that there is no adequate server handler that will configure CORS which means that you cannot access resources from different origin in your XHR. Basically, if you don't do anything or specifically enable CORS only for specific domains, then any AJAX request trying to access your resources will be rejected because web browsers are respectful to the CORS policy.
This is the reason why you encounter CORS issue when you start developing SPA using VueJS and NodeJS. Your VueJS application is hosted on http://localhost:8080 and when you try to access NodeJS server application on http://localhost:8000 you get "No Access-Control-Allow-Origin header is present" because those are two different ORIGINS(combination of PROTOCOL, HOST and PORT).

Cool fix for CORS issue in VueJS development mode is to set devServer proxy in your vue.config.js file as follows:



module.exports = {
  ...
  devServer: {
    proxy: 'http://localhost:8000',
  },
  ...
}

To setup CORS in production you should add appropriate listener for OPTIONS request. That listener should send response 200 with no body but with Headers that will define your wanted CORS policy:



Access-Control-Allow-Origin: https://domain-b.com
Access-Control-Allow-Methods: GET

For more info on how to configure CORS check https://enable-cors.org/index.html, and to dive deeper in CORS policycheck https://livebook.manning.com/book/cors-in-action/part-1/

XSS

XSS stands for Cross Site Scripting and it is injection type of attack. It is listed as 7th out of top 10 vulnerabilities identified by OWASP in 2017. Cross site scripting is the method where the attacker injects malicious script into trusted website.(section updated, thanks Sandor) There are 3 types of such attacks.

Stored XSS - Vulnerability coming from unprotected and not sanitized user inputs those are directly stored in database and displayed to other users
Reflected XSS - Vulnerability coming from unprotected and not sanitized values from URLs those are directly used in web pages
DOM based XSS - Similar as reflected XSS, unprotected and not sanitized values from URLs used directly in web pages, with difference that DOM based XSS doesn't even go to server side

Attack

1. Stored XSS

Here is an example of attack. The attacker comes on your website and finds unprotected input field such as comment field or user name field and enters malicious script instead of expected value. After that, whenever that value should be displayed to other users it will execute malicious code. Malicious script can try to access your account on other websites, can be the involved in DDoS attack or similar. Visual representation(source geeksforgeeks.org):

2. Reflected XSS

Reflected XSS is attack that happens when attacker discovers page with such vulnerability, for example:

expected URL: https://mywebpage.com/search?q=javascript
malicious URL: https://mywebpage.com/search?q=<script>alert('fortunately, this will not work!')</script>



<body>
...
<div> showing results for keyword 
<script> document.write(window.location.href.substr(window.location.href.indexOf('q=') + 2))
</script>
</div>
...
...JavaScript results...
...
</body>

After discovery, attacker baits user to click on such malicious URL and voila. User sensitive data is exploited.

Lifecycle of attack ilustrated in example provided by geekforgeeks.com:

3. DOM based XSS

This kind of attack is same as reflected but with difference that malicious URL part will not be sent to server at all. For above example:

expected URL: https://mywebpage.com/search?q=javascript
malicious URL(reflected XSS): https://mywebpage.com/search?q=<script>alert('fortunately, this will not work!')</script>
malicious URL(DOM based XSS): https://mywebpage.com/search#q=<script>alert('fortunately, this will not work!')</script>

Difference is in the character # being used instead of ?. The browsers do not send part of URL after # to server so they pass it directly to your client code.

Protection

Every value that can be entered by user and is used in your app(either on server side either on client side) should be treated as untrusted data and therefore should be processed before using! You should do safety check in your server app and your client app, as well!
As showed in documentation VueJS by itself escapes string before getting value from variable. Newer versions of Angular also escape strings implicitly, so if you are using Vanilla JS, JQuery or similar you should implement string escape manually.

There are three most common approaches on processing untrusted data are listed below and ideal method depends on the actual type of the field that you need to process.

1. String validation

Validation is the method where user defines set of rules, and demand untrusted data to satisfy those rules before moving on. This method is good for number values, username, email, password and similar fields with concrete set of syntax rules.

Check for existing libraries for your framework before considering to write validators by your own.

2. String escape

Escape method is useful for cases where you should enable user to use punctuation marks. This method goes through string and looks for special characters, such as < > and replace them with appropriate HTML character entity name. Here is basic function that you could use:



function escapeText(text) {
  return text.replace(/&/g, '&amp;')
             .replace(/</g, '&lt;')
             .replace(/>/g, '&gt;')
             .replace(/"/g, '&quot;')
}

Again, check for existing libraries before writing your own.

3. String sanitization

Sanitizing string is used when user is allowed to enter some HTML tags in their comments, articles or similar. The sanitize method goes through text and looks for HTML tags that you specify and removes them. One of most popular libraries that uses this approach is Google Closure.
This method is resource expensive and considered as harmful, so do more research before choosing it.

Web browsers(no available sources since what version, IE fixed this issue in 2014.) automatically escape URLs before sending them to server side and making them available in window.location object also, so 2nd and 3rd type of attack are here just to be aware of them and to make clear that URL params should also be treated as untrusted data.

For more detailed info about XSS and how to properly protect your application if you rotate a lot of untrusted data, please check OWASP cheatsheet on XSS prevention.

CSRF

Cross site request forgery or CSRF is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user's web browser to perform an unwanted action on an other trusted site where the user is authenticated. This vulnerability is possible when browser automatically sends authorization resource, such as session cookie, IP address or similar with each request.

ATTACK

Let's suppose that user is logged in to your unprotected stock exchange web application and that you are using either session cookie either JWT cookie for authentication. Attacker also uses your service and is able to check how your API works. Attacker tricks user to execute script(by clicking on SPAM link in email or similar) that will send request to your API https://www.stockexchange.com/users/withdraw?how_much=all&address=MY_ADDRESS(terrible API design, don't ask). Since request is executed from browser that sends authentication payload with every request, your stockexchange web server will authenticate user successfully and execute transaction and tricked user will lose all his balance without even being aware of it because everything happened in the background. Visual representation(source miro.medium.com)

PROTECTION

Luckily there are easy to implement patterns that prevent this web attacks. One of the most common pattern is usage of CSRF token. Basically procedure is following:

Generate unique token for each user's request, so called CSRF token.
Store it safely on server and send it back to user as payload of response.
Store CSRF token on client side.
When user tries to execute any state-changing* request send that CSRF token with request as a payload.
Before executing that request on server side check if CSRF token is present and it is valid.

This is the easiest way to prevent CSRF attack for all users.

If you are are dealing only with visitors that uses modern browsers then you can rely on SameSite attribute of session cookie.(thanks Gergely)

Since server's responses are processable in XHR response, then there is no protection on CSRF attack if your web application is XSS vulnerable!

To dive deeper check OWASP cheatsheet on CSRF.

BONUS

Short documentary about Samy, author of worm that took down MySpace back in 2005 abusing XSS vulnerability, passing MySpace's CSRF defense.
https://youtu.be/DtnuaHl378M

More info on Samy's worm
https://samy.pl/myspace/tech.html