DEV Community: Ibrahim Tanyalcin

simple-chat-demo

Ibrahim Tanyalcin — Wed, 28 May 2025 19:21:40 +0000

A drop in native web component that you can use with any framework.

This is native web component written by Cahir (https://github.com/IbrahimTanyalcin/Cahir) that can be used in conjunction with ChatGPT like LLM APIs.

The UI is separate from the backend representation so you are completely free to customize and use your parser as you see fit. The parser function has an extensive signature that allows you to simulate or stream node strings.

Vantage Point - Combining the imperative and the declerative

Ibrahim Tanyalcin — Fri, 20 Oct 2023 15:30:15 +0000

I always take the new shiny bits from TC39 with a pinch of salt. I have been honest about some of the additions to the language before, but this will be a good one.

For me it has always been a pain, not to be able to respond to arbitrary property accesses without some safety net. Whether we are talking about a Class or an Object, your options were:

hardcode the property from an array-like using [[Set]] or defineProperties
dodge the error using optional chaining or nullish coalescence
create a method on the prototype chain that accepts an arbitrary string, corresponding to the property to be accessed.

None of the above feels natural, aka, you cannot do: someObj.someArbitraryString and return something other than undefined. For that reason Proxy was a great addition to the language simply because a polyfill was not possible.

Proxies empowered ALL of the objects in JS. Not just Arrays, Objects, Maps etc, but functions too. I want to talk about the function part, because a pattern that I unconsciously started using for over a year kept coming back and proved to be extremely useful. It stayed on the shelf for some time while I used it, and now I have at least something little to show.

Consider this:

ch.li /* returns a li DOM object */
ch.div /* returns a div DOM object */

One would think it is some sort of a class or object that has a method, no it is not:

ch.whatever /* <whatever></whatever> */
ch(ch.whatever).set("innerHTML", "what?") /* <whatever>what?</whatever> */

taking it a step further:

ch(ch.li)`
sappend ${ch.span}
set innerHTML ${"what?"}
style ${[["width","40dvw"],["height", "auto"]]}
`

Above 'sappend' is short for 'select and then append'. A bit more with shortcuts to commands:

ch(ch.li)`
+-> ${ch.span}
>> innerHTML ${"what?"}
style ${[["width","40dvw"],["height", "auto"]]}
`

and why not alternate between template literals and classic function calls:

ch(ch.li)`
+-> ${ch.span}
>> innerHTML ${"what?"}`
.style([["width","40dvw"],["height", "auto"]])
.select(ch.div)...

or maybe this is better?:

ch.dom`
    <li>
        <span style="width: 40dvw;">what?</span>
    </li>
`

what about children?:

ch.dom`
    <li>
        ${Array(10).fill().map(d => `<span style="width: 40dvw;">what?</span>`)}
    </li>
`

wait a second, what if:

ch[`li{"attr":[["data-name", "I am a li"]]}`]

styles, attributes may work like above, what about props??

ch[`li{
"attr": [["data-name", "I am a li"]],
"prop": [["a",${3}], ["b", ${4}]]
}`]

does it mean you could do?:

ch[`li{
"attr": [["data-name", "I am a li"]],
"prop": [["innerHTML", "what?"]]
}`]

can we combine them all?:

ch(ch[`li{
"attr": [["data-name", "I am a li"]],
"prop": [["innerHTML", "what?"]]
}`])`
    +> ${Array(5).fill().map((d,i) => {
        return ch.dom`
            <span>
                <i>HELLO!</i>
            </span>
        `
    })}
`.selected //logs the li element

Marking a parentNode or any other variable to do something with it later:

ch`
-> myLi:${
    ch[`li{
        "attr": [["data-name", "I am a li"]],
        "prop": [["innerHTML", "what?"]]
    }`]
}
+> ${Array(5).fill().map((d,i) => {
    return ch(ch.dom`
        <span>
            <i>HELLO!</i>
        </span>
    `).on("pointerover@mynamespace", () => console.log("mouseover!")).selected
})}
=> ${({values}) => () => console.log(values.myLi)}
`

And if you were to call function parameters inside a tagged template literal, you would need spreading. Sure, why not?:

ch`
-> ${ch.li}
on ...${["click@someNameSpace", (e) => {console.log(e.clientX)}]}
+< ${document.body}
`

Here we created a li element, added a click event listener on it with someNameSpace (so that we can later remove all the listeners registered with that namespace) and appended that to the body. The event and the handler is passed in an array inside a template literal which is spread to on function.

In none of the examples there is a build step involved. It all is based on about 160 lines of ES6 - ES2018 JavaScript. Here is a codepen with some of the examples above.

At this point you might ask what a TODO list would look like, there you go:

Many of you are using frameworks, I won't be giving names here, and it is totally perfect when it comes to getting the job done. Programming is somewhat bit of an art when compared to positive sciences like physics and math, and for that reason, there is more than one optimal way of doing things, I definitely cherish the differences. Also different stacks for rendering the same "Hello World!" page has packed a lot of documentation through the years, so it is not possible for an average person like me to know everything.

Here is the thing, the examples you saw in this article are imperative compared to declarative. Due its nature, imperative programming has been a bit more verbose because the programmer has to instruct the how to rather than what to. But in the face of ES6+, it does not have to be like that anymore. I hope I could prove a point.

Why is the above important? Because imperative represents control and declarative represents abstraction. You want to abstract because you want to avoid the pain and make it easier. You want imperative because you want to specifically control the flow of your functions to create the exact effect desired. Both can be combined.

Using this small library, I was able to create complex data visualizations, interfaces using simple routines and web components. When it came to fine tuning and controlling rendering cycle, I was able to control the DOM operations because the setup is imperative by nature with declarative bits.

Complex visualizations or interfaces go through a process called Enter - update - exit cycle. Which is reminiscent of how D3 works, and most of the frameworks today use that logic behind the scenes by specifying a key value to decide with nodes to add/remove/change. This also can be done, here is a static example I put together. You can pause and call Array methods on the data in the inspector. See for yourself.

There is a lot of work to do. The helper methods that are mounted on the Proxy needs documentation in JSDoc. If you are interested, here is the repository:

Cahir

Almost a decade and half of developing open source/proprietary visualizations in bioinformatics has thought me that what works >>> what is trendy. I understand people refraining from taking risks of dunking into works of others and instead going for the safe route of frameworks because "they know better than you do." There is also a large cohort of young people who desperately need a paycheck and have no option other than investing into whichever soup of the day stack that lands a job in this VC poisoned market.

I get all of the above. I also get the idea of standing in the shoulder of giants. We all, whether we want or not, stand in one way or another in the shoulder of a giant. I believe the key is to find a balance, and sometimes try to ask the question "what if". I think the only sustainable leverage is a vantage point, a vantage point that can incorporate the old and the new, that can keep what works and discards what doesn't.

If you like the repository, please try to help me to make it better by submitting PRs and documentation suggestions. If you like it, a star would not hurt.

Have a great weekend,

Ascii Glitch Animation with js

Ibrahim Tanyalcin — Wed, 17 Apr 2019 23:40:32 +0000

I've been working on this for a bioinformatics project, turns out it can also be used to animate ascii characters as well:P.

And here is the library:
https://github.com/IbrahimTanyalcin/lexicon-mono-seq

I'd really appreciate bug reports.

ES6 Modules and Declarative Dependencies in HTML

Ibrahim Tanyalcin — Sun, 15 Jul 2018 22:31:24 +0000

ES6 Modules and Declarative Dependencies in HTML

This is a follow up write up of my previous work:

IbrahimTanyalcin / taskq

Async module loader with declerative dependency management in HTML and compatibility with ES6 import/export

taskq

Async Modules Supporting ES5 & ES6 with Control Flow

⇩ First, your 1 min cheatsheet ⇩

Navigation

If you want you can jump straight into the examples.

Advantages ⏎

0 dependencies
No polyfill required
No transpiling required.
No config file etc.
About 6kB when minimized
Will work on ie9+.
Will play nice with other technologies/patterns you use in your page
Non-render blocking
You can pause/resume the main thread
Aware of document state (hidden, minimized etc.)
Fine grained control on execution of all imported scripts.
Uses Promises combined with requestAnimationFrame(rAF). Falls back to rAF on older browsers (ie etc).
Supports nested/single dynamic imports. Your main thread will wait until a module finishes dynamically importing other modules.
Supports then , catch phrases for dynamic imports.

You can do things that you cannot do with ES6 directly

 taskq.load("./scriptDynamic1.js")
    .then(function(res){
        res.init
        setTimeout(function(){

…

View on GitHub

It tries to reason about what it would be like to have your dependencies declared in HTML as attributes.

Taskq.js is not new, I have released it on October 2017, since then I have been using it to upkeep a fairly large project and add new stuff to it as I see fit.

As you might know, one of the hottest debates going around in the js landscape is the comparison of module loaders/bundlers and their advantages over each other. The problem is quite clear: they are not compatible with each other, at least not without putting together another “middle man” build time tool.

It is quite understandable that consumers of modules do not wanna deal with dependency management but if you think about your own projects, there are ALWAYS parts of the app that you want to retain some control if not completely. You can bundle or do whatever you want with some parts of your app while still having control on the flow of the newly added parts. This is what Taskq was designed for, to create a future compatible(combine with ES6 import/export) module system that operates with async scripts (parallel + HTTP2 alleviates need for bundling) and gives you control over their order of execution while reducing your job of managing dependencies (point to crucial leafs in dependency tree, Taskq will work the rest out).

Today I want to go over a small exercise, we will have a minimal html with 3 async scripts that depend on each other and we will embed the dependencies right in the HTML (a version for ie11 would have to be more verbose). You can complicate this by adding several scripts with comma separated dependencies several layers deep, but I will keep it simple here. Here is the html we have:

We have 3 async scripts A, B and C which should execute in this order. From my previous write-ups, you perhaps know that we declare the _taskqId and _taskqWaitFor properties on the modules, this time instead of adding these within the module, we will directly grab it from the attribute:

X._taskqId = document.currentScript.dataset.taskqid; X._taskqWaitFor = document.currentScript.dataset.taskqwaitfor.split(",").filter(d=>d);

So instead of hard coding the properties, we can grab them from data-taskqid and data-taskqwaitfor attributes. We do not need to know the script name as we can use the document.currentScript in evergreen browsers. So what do the scripts look like?:

They are almost identical to each other, they only export their own variables. If you open the HTML file you will get this:

You can go ahead and add more script tags and make the dependencies several layers deep or add more dependencies such as data-taskqwaitfor='X,Y,Z,...'. You can even try to add circular references, in that case Taskq will try to resolve and also display a console message.

Another interesting part here is that you can still use ES6 import/export. For instance nothing is barring you from doing this:


\<script type="module" src="./B.js" data-taskqid="B" data-taskqwaitfor="A" charset="UTF-8" async>
\</script>

And then within the module you can do:
import someExport from "./A.js"; !function(){ function X(exportA){ ...





In ES6, as far as I know, the imported modules are guaranteed to be run before the current script that imported them, but the order of execution of the imported modules cannot be guaranteed and is vendor implementation dependent. In these cases, let ES6 figure out its own dependency and import these variable as it wants, we could care less when the iief is executed!

You will still have control on the execution order of what is pushed to taskq within the outer iief. This way you take advantage of ES6 while retaining control on the execution order of the bits you care about.

DEV Community: Ibrahim Tanyalcin

simple-chat-demo

Vantage Point - Combining the imperative and the declerative

Ascii Glitch Animation with js

ES6 Modules and Declarative Dependencies in HTML

ES6 Modules and Declarative Dependencies in HTML

IbrahimTanyalcin / taskq

Async module loader with declerative dependency management in HTML and compatibility with ES6 import/export

taskq

Async Modules Supporting ES5 & ES6 with Control Flow

⇩ First, your 1 min cheatsheet ⇩

Navigation

Advantages

API

Reading

What does it do?

Usage

Changelog

Examples

Advantages ⏎