Coder Legion - Recent posts tagged stilljs

Integrating Still.js into Next.js: A Hands-On Guide to Remote Microfrontend Components - Part2

Fri, 29 Aug 2025 00:43:31 +0000

In this second part of the Microfrontend series we’re answering another posed question, we explore integrating Still.js with Next.js, focusing on using remote Vendor components. The video includes a real-world use case and a project built from scratch, follow the Design System for implementation

What points will be addressed in the video:

Creation of Next.js project
Generating and embedding Still.js app inside Next.js App
Embedding remote component (straight from npm) into the application
Data exchange between Still.js and Next.js (React)

Remote components

This approach is key in Microfrontends, as it enables embedding components from outside the project structure. It enhances feature sharing, increases decoupling, and reduces the size of the deployable package (e.g. bundle).

The idea behind remote component is for them to be served from somewhere which is not the embedding application itself, as we can see in the bellow architecture:

The above architecture promotes reusability by allowing the same component, available via NPM/GitHub, to be embedded across different applications built with various frameworks. Still.js can play a key role, serving as proxy as needed, by being embedded within these apps as well. Additionally, Still.js enables components to be written in Vanilla JavaScript rather than relying on framework-specific code.

Although NPM and Github are the approaches depicted in the architecture, Still.js adapts well with any other source for embedding remote components.

Self-contained components

This is the optimal situation in which a component can be used remotely, as the idea is that not external dependency exists so to avoid cascade importing, which can be harmful in terms of performance, also might cause JavaScript bloating issues.

Coding snippets specific considerations

Step1:
The Still.js app is integrated into the Next.js project by placing it in a subfolder (we’ll call still-mf/) inside the public/ directory. It is then loaded using the apploader with additional parameters:

useEffect(() => {

    const stillApp = new StillAppLoader();
    stillApp
      .cdn({ env: { STILL_HOME: '/still-mf/', PATH_PREFIX: 'still-mf/' }, version: '1.3.13'})
      .load();

  },[]);

Step2:
Next.js listens to Still.js events via subscription. The Apploader SDK now supports init/on(‘load’) event, improving memory and CPU usage, so no setTimeout needed:

useEffect(() => {
    // …. Above code
    stillApp.on('load', () => {
    
        stillApp.component.ref(ref1).variableName.onChange(newData => {
           console.log(‘Still.js updated the value of variableName to ’, newData);
        });

    });
},[]);

Compared to part one of the series, the main differences in the Still.js app setup for Next.js is the need to specify PATH_PREFIX and, optionally, the framework version to define which Still.js version is used.

Embedding NPM remote component

The video tutorial demonstrates how the StillTreeView vendor component from Still.js is used in a real use case with Next.js + Still.js integration. The component is embedded directly from NPM as a remote as shown in the example below code snippet:

<st-element component="npm/@path/to/package/ComponentName”></st-element>

As conclusion:

While not a bulletproof, Microfrontends are highly effective for complex, enterprise-scale applications. Remote components further enhance this architecture by promoting decoupling, feature sharing, and scalability. Ideally, these components should be self-contained for optimal results. Also, don't forget to check the video for more details.

What’s Next?

Don't forget to check the video
Try implementing a more complex Microfrontend with Still.js including navigation/routing ( routing documentation )
Try to compare different Microfrontend approaches with the way Still.js does disruptively
Share your thoughts and ideas in case you have any concerning to this topic
Bear for the next parts of this series

Se you next time.

From Vanilla Template to Still.js Components: A Full Build and Deployment Guide

Mon, 11 Aug 2025 02:56:47 +0000

A full Still.js build from raw HTML to deployment — with zero dependencies.

A few days ago, I was asked about migrating a project to Still.js, this article is accompanied by a video demonstrating it.

Because it’s built in Vanilla JavaScript, Still.js combines perfectly with a template that is based with pure/raw HTML, CSS and JavaScript, even if some library (e.g. jQuery, Bootstrap) was used, Still.js helps you to ease separate things into components, as show cased in this video.

What will be covered:

Migrating a Vanilla web template to Still.js
Back down the template into components conveniently
Load template’s JavaScript code properly according to Still.js architecture
Deploy to the cloud

Key Considerations:

When using templates with a lot animations, or that depends on different javaScript library to load, it’s important to deeply understand it (the template) so to orchestrate each
Script dependency just the same way it happens with raw HTML, CSS and JavaScript.

Minimalist third party Script dependency approach:

Now a days a lot of features like animation and more (e.g. parallax, singlePageNav, dialog, IntersectionObserver - Lazy animation) are browser native, hence, this would impact a lot in the choosing on what/when to use libraries especially when it comes to animation which some web pages are depending a lot.

Vanilla JavaScript is one of the core philosophy of Still.js, hence you can use everything as natural as possible from Web Semantic to straight DOM manipulation.

We’ll use this template, and we’ll be deploying our page to Render which will provide us with a custom domain.

In summary, on the coding and structure side of things the steps will be as follow:

the HTML code will be moved to the Still.js template/template file (.html)
Run template JavaScript animation in the stAfterInit hook, ensuring it executes after component load
Convert sections into autonomous components

Conclusion

Still.js helps turn vanilla templates into fast, modular, and lightweight sites with zero dependencies, giving you full control using pure JavaScript. Proper code organization is key to avoid issues like bloating or conflicts, and a vanilla-first approach is recommended, external libraries should only be used when necessary.

What’s Next?

Don't forget to follow the hands-on video till the end so we can make the deploy.

Expand Your Still.js Skills

Explore advanced Still.js features like state management, routing, or
integrating APIs.
Try building a small SPA or dashboard using
Still.js components capabilities.

Contribute to Still.js

Still.js is open-source, consider contributing or helping improve documentation.
Join the discord channel to get fast updates and follow the discussions

Ask more if needed

Share any topic you want to see cover so content (e.g. video, article) can be produced.

Se ya in the next one

Will Three.js Ever Match Native Mobile Game Performance for Complex AR or 3D Resumes

Sat, 26 Jul 2025 21:32:05 +0000

Will Three.js Ever Match Native Mobile Game Performance for Complex AR or 3D Resumes as Devices Get Stronger?

The world of interactive digital experiences is evolving at breakneck speed, with augmented reality (AR) and 3D visualizations becoming mainstream for everything from gaming to professional portfolios like 3D . Tools like Three.js, a JavaScript library built on WebGL, have democratized 3D development by enabling developers to create stunning browser-based experiences without the need for native app development. But a critical question looms as mobile devices grow more powerful: can web-based tools like Three.js ever match the performance of native mobile game engines, such as Unity or Unreal Engine, for complex AR applications or innovative 3D resumes? This blog post dives deep into the technical, practical, and future-facing aspects of this question, exploring the strengths, limitations, and potential of Three.js in the context of increasingly powerful mobile hardware.

The Rise of Three.js and Web-Based 3D

Three.js has become a cornerstone of web-based 3D development since its inception in 2010. Built on WebGL, it abstracts the complexities of low-level GPU programming, allowing developers to create 3D scenes, animations, and AR experiences that run directly in web browsers. From interactive product visualizations to immersive games, Three.js powers a wide range of applications. Its appeal lies in its accessibility: no app installation, cross-platform compatibility, and a relatively low learning curve compared to native game engines.

For professionals, Three.js has opened new doors for showcasing work in creative ways, such as 3D resumes. Imagine a portfolio where a user can interact with a 3D model of a project, explore an AR environment that showcases skills, or navigate a virtual resume with animated elements—all accessible via a browser link. These applications are lightweight compared to full-fledged games but can still demand significant computational resources, especially when incorporating AR features like real-time object tracking or spatial mapping.

However, native mobile game engines like Unity and Unreal have long been the gold standard for high-performance 3D and AR applications. Built to leverage device hardware directly, these engines power AAA games and professional AR apps with unparalleled smoothness and visual fidelity. As mobile devices become more powerful—think Apple’s A18 chip or Qualcomm’s Snapdragon 8 Gen 3 with console-level GPUs—the question arises: can Three.js, running in the constrained environment of a browser, ever compete with native performance for complex AR or 3D resume applications?

Understanding the Performance Landscape

To answer this, we need to break down the factors that influence performance in both web-based (Three.js) and native (Unity/Unreal) environments, particularly for mobile devices. Let’s explore the key technical considerations.

1. Hardware Acceleration and API Access

Modern mobile devices are equipped with powerful GPUs that rival entry-level consoles. For example, the iPhone 16 Pro’s A18 Pro chip boasts a 6-core GPU capable of 1.2 teraflops, while high-end Android devices like the Samsung Galaxy S25 series leverage Adreno GPUs with similar capabilities. Both WebGL (used by Three.js) and native engines like Unity (via Metal on iOS or Vulkan on Android) can tap into this hardware acceleration, but they do so differently.

Three.js/WebGL: WebGL, the foundation of Three.js, provides a JavaScript API for rendering 3D graphics using the device’s GPU. It’s built on OpenGL ES, which is well-optimized for mobile hardware. The upcoming WebGPU standard, which Three.js is beginning to support, promises even closer-to-metal performance with features like compute shaders and better memory management. However, WebGL/WebGPU operates within the browser, which introduces overhead from JavaScript execution, DOM rendering, and sandboxed environments.
Native Engines: Unity and Unreal Engine use low-level APIs like Metal (iOS) and Vulkan (Android) to communicate directly with the GPU. This minimizes overhead, allowing for faster draw calls, better memory allocation, and tighter control over rendering pipelines. For complex AR scenes—say, a 3D resume with real-time lighting, physics, and spatial tracking—native engines can push hardware to its limits more efficiently.

Verdict: Native engines have a clear edge due to direct hardware access, but WebGPU’s adoption could narrow the gap significantly, especially as browsers optimize their rendering pipelines.

2. Overhead of the Browser Environment

The browser is both a strength and a weakness for Three.js. On one hand, it enables instant access to 3D content without app installation. On the other, it imposes significant overhead:

JavaScript Engine: Three.js relies on JavaScript, which is interpreted and slower than compiled languages like C++ (used by Unity/Unreal). Even with just-in-time (JIT) compilation in modern browsers, JavaScript execution adds latency, especially for complex logic in AR or physics-heavy scenes.
DOM and Sandboxing: Browsers manage multiple tasks (e.g., rendering web pages, handling user inputs, enforcing security). This creates contention for CPU/GPU resources, unlike native apps, which can monopolize device capabilities.
Memory Limits: Browsers impose stricter memory caps than native apps. For a 3D resume with high-poly models, detailed textures, or AR tracking, Three.js may hit memory constraints faster, leading to stuttering or crashes.

Verdict: The browser’s overhead is a persistent bottleneck, but as devices gain more RAM (e.g., 8–12 GB in flagship phones) and browsers optimize resource allocation, Three.js can handle increasingly complex workloads.

3. AR-Specific Challenges

AR applications, even for something as “simple” as a 3D resume, require real-time processing of camera feeds, spatial mapping, and sensor data (e.g., gyroscope, LiDAR). Three.js supports AR via WebXR, which interfaces with device AR capabilities. For example, iPhones with LiDAR can use WebXR for occlusion and depth mapping, while Android devices leverage ARCore.

However, native engines integrate more deeply with device-specific AR frameworks (e.g., ARKit on iOS, ARCore on Android). These frameworks provide optimized access to sensors, reducing latency and improving tracking accuracy. For instance, a native AR resume built in Unity could seamlessly overlay 3D elements on a real-world desk with minimal jitter, while Three.js might struggle with frame drops on lower-end devices.

Verdict: WebXR is improving, but native AR frameworks offer superior integration and performance, especially for complex scenes requiring precise tracking.

4. Optimization and Tooling

Three.js has made strides in optimization, with features like:

Instancing: Rendering multiple copies of an object efficiently.
Compressed Textures: Support for formats like KTX2 reduces memory usage.
Level of Detail (LOD): Dynamically adjusting model complexity based on distance.
React Three Fiber: A React-based wrapper that optimizes rendering for complex scenes.

However, native engines like Unity and Unreal have decades of refinement. Features like Unreal’s Nanite (virtualized geometry) and Lumen (dynamic global illumination) are far beyond Three.js’s capabilities. These tools also offer robust profiling and debugging, making it easier to optimize for specific devices.

Verdict: Three.js is catching up, but native engines’ mature toolsets give them an edge for high-end applications.

The Role of Device Advancements

Mobile devices are becoming monstrously powerful, blurring the line between phones and gaming consoles. By 2025, flagship devices boast:

GPUs: Capable of 1–2 teraflops, supporting ray-tracing and high frame rates.
RAM: 8–16 GB, sufficient for complex 3D scenes.
Sensors: LiDAR, advanced IMUs, and high-resolution cameras for robust AR.
Connectivity: 5G and emerging 6G for low-latency cloud rendering.

These advancements benefit both Three.js and native engines, but they disproportionately favor web-based tools. Why? Because the browser’s overhead becomes less significant as raw hardware power grows. For example, a 3D resume with low-poly models, basic AR overlays, and simple animations is already performant on a 2025 flagship phone using Three.js. As devices push toward 20 GB of RAM and 3–4 teraflop GPUs in the next 5–10 years, Three.js could handle scenes rivaling native apps in many cases.

Cloud rendering is another game-changer. Services like NVIDIA’s GeForce Now or AWS’s cloud infrastructure could offload heavy computations, allowing Three.js to stream high-fidelity 3D/AR content to mobile devices. However, this introduces latency and cost concerns, which native apps can avoid by leveraging local hardware.

3D Resumes: A Case Study

Let’s consider a specific use case: a 3D resume. This might include:

A low-poly 3D avatar of the candidate.
Interactive project showcases (e.g., spinning 3D models of designs).
AR features, like placing the resume in a real-world environment.
Animations, text overlays, and basic physics (e.g., objects falling into place).

Three.js Feasibility:

Pros: Three.js excels here. It can render low-to-medium-poly models, handle basic animations, and integrate AR via WebXR. Tools like React Three Fiber streamline development, and browser delivery ensures accessibility. For example, a designer could share a link to their 3D resume, viewable on any modern phone without an app download.
Cons: For high-poly models, complex shaders, or advanced AR (e.g., real-time occlusion with multiple objects), Three.js may struggle, especially on mid-range devices. Frame rates could drop below 60fps, and memory limits might cause crashes.

Native Feasibility:

Pros: Unity or Unreal can handle high-fidelity visuals, smooth 60–120fps performance, and robust AR integration. A native 3D resume could include photorealistic avatars, dynamic lighting, and seamless AR tracking, even on mid-range devices.
Cons: Development is more complex, requiring platform-specific builds (iOS/Android) and app store distribution. This adds time and cost, which may not justify the effort for a resume.

Verdict: For most 3D resume use cases, Three.js is sufficient and more practical due to its accessibility and lower development overhead. Native engines are overkill unless the resume demands AAA-game-level visuals or complex AR interactions.

The Future: Can Three.js Catch Up?

Looking 5–10 years ahead, several trends suggest Three.js could close the gap with native performance for many applications:

WebGPU Adoption: WebGPU, now supported in Chrome and other browsers, offers near-native GPU access. It supports compute shaders, better memory management, and faster rendering pipelines. Three.js’s integration with WebGPU will unlock performance levels closer to Metal or Vulkan.
Browser Optimizations: Browsers like Chrome and Safari are reducing overhead through better JavaScript engines (e.g., V8) and WebAssembly, which compiles code to near-native speeds. This could minimize the browser penalty for Three.js.
Device Power: By 2030, mobile devices may approach PC-level performance, with 20+ GB of RAM and GPUs capable of 5–10 teraflops. This raw power will make browser overhead less noticeable for all but the most demanding applications.
Cloud Rendering: As 5G/6G networks mature, cloud-based rendering could offload heavy computations, making Three.js viable for high-end AR experiences. However, latency and bandwidth costs remain challenges.
Ecosystem Growth: The Three.js community is vibrant, with tools like React Three Fiber and libraries for physics (e.g., Ammo.js) improving rapidly. While not as mature as Unity’s ecosystem, it’s closing the gap for web-specific use cases.

However, native engines will likely maintain an edge for the most complex scenarios:

AAA AR Experiences: Applications requiring photorealistic rendering, advanced physics, or real-time ML (e.g., gesture recognition) will favor native engines due to their low-level control and optimization.
Battery Efficiency: Native apps can fine-tune power usage, critical for AR, which taxes CPU, GPU, and sensors. Browsers, with their multitasking nature, are less efficient.
Consistency: Native apps can be optimized for specific devices, ensuring consistent performance across hardware. Web apps depend on browser variations, which can introduce unpredictability.

Practical Considerations for Developers

For developers building 3D resumes or AR applications, here’s how to approach the Three.js vs. native decision:

Choose Three.js if:
- You prioritize accessibility and cross-platform delivery.
- Your project is lightweight to moderately complex (e.g., low-poly models, basic AR).
- Development speed and cost are concerns.
- You want to avoid app store hurdles.
Optimization Tips:
- Use compressed textures (KTX2, Basis).
- Implement LOD and instancing to reduce draw calls.
- Leverage WebXR for AR but test across devices for compatibility.
- Use React Three Fiber for efficient scene management.
Choose Native if:
- You need photorealistic visuals or complex AR (e.g., multi-object tracking, real-time physics).
- Performance (e.g., 120fps) and battery efficiency are critical.
- You’re targeting specific high-end devices and can afford longer development cycles.
Optimization Tips:
- Use Unity’s Universal Render Pipeline (URP) for mobile optimization.
- Leverage device-specific APIs (e.g., ARKit’s LiDAR support).
- Profile extensively to avoid thermal throttling.

Conclusion

Three.js is already a powerful tool for creating compelling 3D resumes and AR experiences in browsers, especially for lightweight to moderately complex applications. As mobile devices grow stronger—potentially reaching 20 GB of RAM and 5–10 teraflop GPUs by 2030—and WebGPU matures, Three.js could rival native performance for most use cases. However, for the most demanding AR applications, native engines like Unity and Unreal will likely retain an edge due to their direct hardware access, mature toolsets, and optimization capabilities.

For 3D resumes, Three.js is often the better choice today due to its accessibility, lower development cost, and sufficient performance for most creative showcases. As hardware and web technologies evolve, the gap will narrow further, making web-based 3D and AR increasingly viable. Developers should weigh their project’s complexity, target audience, and performance needs when choosing between Three.js and native engines. With the right optimizations, Three.js can already deliver stunning, browser-based experiences that captivate users on modern mobile devices.

Rethinking Microfrontend Architecture combining Still.js with React (or other Framewok) - Arch Serie

Sun, 13 Jul 2025 21:35:39 +0000

Why Microfrontend

Building and modernizing large, and/or legacy enterprise level applications is often challenging, as it requires rewriting significant portions or even the entire application when moving to newer technology versions. Microfrontends offer a practical solution to this problem, much like microservices do for backend. They're not just a buzzword, but a meaningful architectural approach for handling complexity and scalability. Still.js enhances this by providing powerful and flexible means for building microfrontends, with seamless integration into frameworks like React.

What problems and use cases can be addressed with Microfrontend?

Application decoupling;
Progressive migration from old to new version (e.g. migrate
framework from v2 to v15);
Fast implementation of new feature without disrupting the existing
ecosystem;

Fast Modernization of old/legacy application yet keeping things
stable;
and more...

How Still.js (with React or others) for Microfrontend?

Still.js is an open source modern, complete and full-featured (with known capabilities and more) frontend framework built with vanilla JavaScript, designed for easy and scalable development and integration like embedding its app inside React apps in form of components. Bellow is a high level architecture of the integration we'll go through.

Quite a lot can be done in terms of Microfrontend with Still.js, however in this article we're going to focus in introductions aspects, there is also a video on youtube with a hands on tutorial.

Integrating with React (using Vite to generate the project)

Step 1. Create your React App, using vite (follow React official documentation using Vite).

npm create vite@latest my-app -- --template react

Step 2. Install React app dependencies.

npm i

Step 3. In your React app, install the Still.js app loader from @stilljs/apploader (on npm), this is a regular (not dev) dependency.

npm i @stilljs/apploader

Step 4. Loading Still.js application inside React is done when the React component is mounted, we'll use the App.js(jsx,tsx,ts), which is the default React entry component.

import { useEffect } from 'react';
import './App.css';
import { RegularReactComponent } from "./components/RegularReactComponent";
import { StillAppLoader } from '@stilljs/apploader';

function App() {

  useEffect(() => {

    // Creating App loader instance
    const stillApp = new StillAppLoader();
    stillApp
     .cdn({ env: { STILL_HOME: 'public/micros/stillapp1/' }   })
     .load();

    // Unload the App when React component gets unmounted
    return () => stillApp.unload();
  },[]);

  return (
    <>
      <RegularReactComponent></RegularReactComponent>
      React validating local Still component embeding
    <>
  )
}

export default App

Step 5. Creating the Still.js App

React project generated with Vite provides a folder named public/ right on the root along with src/ and others, there (public) we generate our Still.js app.

Still CLI provides the still lone command to create a Microfrontend/Lone project, providing it with very minimal setup, having the CLI installed, type in your terminal. (follow the link to a short video):

still lone

Step 6. Create a Still.js lone component in the CDN approach

It’s called “lone” because Still.js isn’t installed locally, just the component and routes file are there and it behaves the same. With CLI installed type the bellow in terminal. (follow the link to a short video):

still c cp app/components/TestComponent --lone

Step 7. Embed Still.js component inside React app/component
We'll change the return portion and add the Still component as follow:

  return (
    <>
      <RegularReactComponent></RegularReactComponent>
      React validating local Still component embeding
      <st-element component="TestComponent"></st-element>
    <>
  )

Step 8. Running the React app:

npm run dev

Final result

Intercommunication between React and Still.js

Communication is feasible between React and Still.js once App/component is embeded, for that, we use the AppLoader as Proxy. but for the sake of size of this article we're not depicting it here, instead you can see this tutorial on Youtube which an implementation is done in practice step by step.

To wrap up

Microfrontends aren’t a one-size-fits-all solution, but they’re ideal for highly modular and fast-evolving applications, such as modernizing legacy systems. Still.js enhances this flexibility by being framework-agnostic and built entirely in vanilla JavaScript, making it easy to adapt to any scenario, even when traditional frameworks fall short.

Give it a try and leverage the full potential of this architectural approach.

See you next time!

Still.js - A way to leverage Vanilla JavaScript for Complex and Enterprise Level Web Development

Mon, 30 Jun 2025 00:03:03 +0000

When it comes to complex web application development on the frontend, we often encounter the need to implement features using vanilla JavaScript—whether it’s for direct DOM manipulation or integrating a specific jQuery plugin. Sometimes, a from-scratch implementation using plain HTML, CSS, and vanilla JavaScript is the best (or only) choice.

What is Still.js

Still.js is a modern Open Source framework that offers the same capabilities as Angular, React, and Vue—without abandoning vanilla JavaScript.

Because of its pure JS approach, Still.js:

Does not require preprocessing
Does not depend on bundlers like Webpack or Vite
Is ideal for teams and developers who prefer direct, no-compromise access to native web technologies in addition to those modern features a Web Framework provides.

Check it up:

Visit stilljs.dev or the github page
See youtube playlist
Join and discuss on
Discord channel
Still.js is an Open Source, contributions are welcomed, check the Github Repo

Suitable for complex and enterprise applications

Enterprise-grade web applications need more than just rich UI features. They require: modularization, user permission management, component routing, validation, separation of concern, communication management, Micro-frontend architecture (e.g. Frontend embedding and interaction), and more.

Still.js supports all of this features natively without the burden of a bundler increasing build time and potential complexity or even tooling overhead.

Some code samples

Note: Those will only work within a Still.js project with the correct setup, which is thoroughly explained in the official documentation.

Basic component:
Bellow is a simple component implementing a counter, inspite the template is placed inside the class, it can be moved to a .html file which is appropriate in complex apps.

import { ViewComponent } from "../../../@still/component/super/ViewComponent.js";

export class CounterComponent extends ViewComponent {

    isPublic = true;
    count = 0;

    template = `
    <div>
        <p>My counter state is @count</p>
        <button (click)="increment()">Increment (@count)</button>
    </div>
    `;

    increment() {
        this.count = this.count.value + 1;
    }
}

Basic User authorization management:
In the bellow implementation we're stating that some components won't be accessible by the user, this can be done with proper business logic according to the user role checking.

import { StillAppMixin } from "./@still/component/super/AppMixin.js";
import { Components } from "./@still/setup/components.js";
import { AppTemplate } from "./app-template.js";
import { CheckingAccount } from "./app/components/BankAccount/CheckingAccount.js";
import { NewAccountForm } from "./app/components/BankAccount/NewAccountForm.js";
import { SavingAccount } from "./app/components/BankAccount/SavingAccount.js";

export class StillAppSetup extends StillAppMixin(Components) {

    constructor() {
        super();
        //Bellow the entry point component is being set
        this.setHomeComponent(NewAccountForm);
        const blackListComponents = [SavingAccount, CheckingAccount];
        //Make components black-listed by passing it to setBlackList App configuration
        this.setBlackList(blackListComponents);
    }

    async init() {
        return await AppTemplate.newApp();
    }

}

Basic Form validation
Still.js provides built-in validators, but custom ones can be implemented effortlessly.

import { ViewComponent } from "../../../@still/component/super/ViewComponent.js";

export class BasicForm extends ViewComponent {

    isPublic = true;
    firstName = '';
    shoeSize;

    template = `
    <div>
        <form>
            <div class="form-group">
                <label>Shoe Size</label>
                <input 
                    (value)="shoeSize" 
                    (validator)="number" 
                    (validator-warn)="Invalid shoe size, number is required"
                    placeholder="Enter valid shoe size"
                >
            </div>
        </form>
    </div>
    `;

}

Global State management:
A service serves for both Global reactive storage and data flow (e.g. HTTP requests) implementations. Services path can be set in the application level, and we can overriden for specific service with @Path annotation.

import { ViewComponent } from "../../../@still/component/super/ViewComponent.js";
import { CustomersService } from "../../service/api/CustomersService.js";

export class BiddingDisplay extends ViewComponent {

    isPublic = true;

    /** Service declaration, will get injected automatically due to Inject anottation
     *  from the specified Path path due to the annotation
     * @Inject
     * @Path service/api/
     * @type { CustomersService } */
    custService;

    template = `<div></div>`;

    /** Component Hook which takes place when it's completly render and startder */
    stAfterInit() {

        this.custService.customerList.onChange((newValue) => { 
            console.log('Ths customerList store got updated with: ', newValue);
        });

    }

}

Hurry up, get yourself started with Still.js

Contribute for the project as you can, check the GitHub repository

Still.js is available through NPM on @stilljs/cli. Watch the Youtube ▶️ playlist and bear for more coming ones.

Watch this Tudo App tutorial on Youtube ▶️, clone or download the provided GitHub Todo app project and run locally. It demonstrates key concepts like component communication, event and state binding, reactive updates, @Proxy, and component styling.

Connect and share your feedback on the Discord channel.