DEV Community: Firecrow Silvernight

Introducing TempLang - an abbreviated FE framework

Firecrow Silvernight — Thu, 04 Apr 2024 22:31:09 +0000

Hi All, I've created a new frontend framework. It's designed to make the most common front end task very fast to write.

I've found that during my time as a front end developer the amount of time spent wiring stuff in ways that could be automated was high enough to build something new.

https://templang.org

I'll start by introducing a few concepts that used to take a up a lot of my time.

Event Binding: you can now tag things with on:click="^update(color=key)" and it i will call the on:update handler of any parent node with the value of key as the property color.
Property Renaming: color=key is sending the value of key as the property color as the event propagates.
Access to the target and handler element: each event contains a target and dest prop so it's easy to do things with all the elements involved. vars contains any variables on either element to make it easy to do stuff!
Styles and Classes on the fly: Styles can be built per element, you'll notice in the example that base-style="background-color: ${key}" creates a new style rule as .custom-element-6 { background-color: rgb(187, 0, 0);} from the data {name: "Red", key: "#B00"} for that element.

It's still in development and getting cleaner with every generation.

Does limiting state matter on the FrontEnd?

Firecrow Silvernight — Mon, 01 Apr 2024 18:27:36 +0000

Hi all, I have a statement I just published that I'd like the communities take on.

For background, I've been a frontend and backend engineer over the years, and have noticed that there are nuances in each domain worth considering.

It has been common to encounter companies with more leadership from their backend engineers, and I question how much of the usual best-practices have been shaped without enough front end domain consideration.

here is the statement, what do you think?

The Case for Variables on Elements

It's a good idea to keep state in as few places as possible right?

Not always... locality is the best chance a user-interface has for making sense during development.

This is not a casual idea, it's because immutability is a loosing battle when there are a lot of user events involved.

Localized ownership of internal state is a more scalable solution, and it leads to a "what you see is what you get" authoring process, which is more discussable, and thereby maintainable.

https://templang.org

Closure is as Closure does

Firecrow Silvernight — Mon, 01 Apr 2024 12:40:31 +0000

I'd like to share my experience of when to use closures and when to use more basic things.

The old joke I've come to enjoy is this, "When do Senior and Junior engineers write the same thing... When the clever function is not necessary."

Let's consider to possible solutions to using data from an Array.

const items = [objA, objB, objC, objD];

function doStuff(obj){
    // do stuff here
}

// Version One - with a closure
items.forEach((obj) => doStuff(obj));

// Version Two - with a for loop
for(let i = 0, len = items.length; i < len; i++){
    doStuff(items[i]);
}

The code does the same thing, but there are a few differences in which actions are done more. The array access in version two with [] may be less efficient under the hood than having the forEach pre-load the items. And the creation of a function context for each iteration will be more expensive in version One because it will open a closure track all the variables involved each time.

Lets look at that last case, the creation of a closure and function context.

Create a scope record in memory
Retain the closure until all variables are no longer in use

By contrast, the for loop body is only ever in one place, and references one scope.

So in terms of comparing performance we have a competition of two things.

Array access vs pre-loaded execution (this is because the item.forEach is predictable, whereas [i] can be any out of order access of an element, making it harder to optimize)
or Function context creation for each item

It's highly likely (depending on the JavaScript implementation) that the array access being random is a far lower cost than the creation of a closure for each item.

You will also notice I've pulled out the length into a variable len, this is because for certain collections (such as DOM Element Collections), the length property is actually a calculation. If you have a list of DOM elements, accessing the length property will climb the elements and calculate the total length, every time the loop iteration runs, pulling out a variable will avoid this.

While the .forEach looks fantastic and is easy to look at, lets consider how it scales with human effort in how it is modified.

Lets introduce the idea of an early out, lets say we only need to run until we find 3 items.

let elidgableThree = [];
const NEEDED_COUNT = 3;

const items = [objA, objB, objC, objD];

function doStuff(obj){
    if(obj.done){
        elidgableThree.push(obj);
    }
    return elidgableThree.length >= NEEDED_COUNT;
}

// Version One - with a closure
items.forEach((obj) => doStuff(obj));

// Version Two - with a for loop
for(let i = 0, len = items.length; i < len; i++){
    let allDone = doStuff(items[i]);
    if(allDone){
        break;
    }
}

Now that we have a control flow return value, it's much easier to control our code with the for loop than the forEach. This is another example of how convenience that hides ugly details can take away flexibility.

Version Two is unquestionably uglier, and also more adjustable to a variety of circumstances.