DEV Community: Yeom suyun

Implementing Drag-and-Drop using Svelte 5

Yeom suyun — Sat, 25 Nov 2023 18:18:51 +0000

It's been two weeks since Svelte 5 was published on npm as the next version.
During that time, I had the chance to try out Svelte 5 in my free time, and working with runes was quite a fun task.
In this post, I'll introduce drag-and-drop functionality using Svelte 5.
For projects using the CLI, as Dev.to's embed feature doesn't seem to fully support StackBlitz, I'll provide a REPL link instead.
Svelte 5 preview

Synergy between Runes and Module Context

The new feature in Svelte 5, Rune, is a kind of macro that allows you to write reactive programs outside Svelte files in js files, just like in Svelte files.
This is particularly convenient when leveraging Svelte's module context, which is compiled in the following way.

<script context="module">
// scripts in module
// scripts in module
</script>
<script>
// scripts in default
// scripts in default
</script>

<template></template>

// scripts in module
// scripts in module
export default function App() {
  // scripts in default
  // scripts in default
}

The module context is a great space for writing reactive instance creation functions using runes.

<script context="module">
export function create_counter(count = 0) {
  let count$ = $state(count)
  return {
    get $count() {
      return count$
    },
    increment() {
      count$ += 1
    }
  }
}
</script>
<script>
let counter = create_counter()
</script>

<button onclick={counter.increment}>
  clicks: {counter.$count}
</button>

Considerations for mouse move and mouse up events

To implement drag and drop, I used mousedown, mousemove, and mouseup events.
I chose this approach instead of using draggable="true" because I wanted to display an HTML element instead of a dragImage.
One thing to note here is that the mousemove and mouseup events need to be connected to the window.

<svelte:window
    onmousemove={handle_mousemove}
    onmouseup={handle_mouseup}
    ontouchmove={handle_touchmove}
    ontouchend={handle_touchend} />

DragContainer and Draggable

When dragging begins, the draggable passes the drag target to the drag container.
Since there is only one drag target, a drag container with drag-related logic can control multiple draggables, even with just one instance.

<DragContainer bind:setDragElement={set_drag_element}
    ondragend={todo_list.end_drag}>
  <DragItem index={i}
      {todo_list}
      {set_drag_element}
      type="todo" />

Conclusion

While Svelte 5 hasn't been officially released yet, the current preview version is already quite intriguing.
What's astonishing is how convenient and rational the syntax of runes becomes the more you use it.
Declarative frontend frameworks, originating from React, seem to already have a familiar feel to the implicit magic executed by runes, given their nature of meta-programming.

Managing the types folder with a simple script

Yeom suyun — Sun, 19 Nov 2023 10:57:10 +0000

A few weeks ago, I wrote an article on setting up a project for an npm package using JSDoc.

How to configure JSDoc instead of TypeScript

Yeom suyun ・ Sep 2

#javascript #typescript #beginners #tutorial

When using JSDoc, it generates d.ts files using tsc.
However, if there are deleted js files during this process, the corresponding d.ts files are not automatically removed.
If I delete the types folder before running tsc, this issue can be resolved.
However, when working with VSCode, it can be quite annoying that unchanged files are marked as modified in the Git tab.
To address this problem, I've written a simple script.

import {
  readdirSync,
  rmdirSync,
  statSync,
  unlinkSync
} from "node:fs"

import { exec } from "node:child_process"
import { fileURLToPath } from "node:url"
import path from "node:path"

const dir = fileURLToPath(new URL("..", import.meta.url))
const pacakge_path = `${dir}/packages/${process.argv[2]}`
const current_time = Date.now()

exec(
  `cd ${pacakge_path} && tsc`,
  () => {
    /**
     * @param {string} dir_path
     * @returns {void}
     */
    function clean_dir(dir_path) {
      const files = readdirSync(dir_path)
      let length = files.length
      for (const file of files) {
        const file_path = path.join(dir_path, file)
        const stat = statSync(file_path)
        if (stat.isDirectory()) clean_dir(file_path)
        else {
          const modified_time = new Date(stat.mtime).getTime()
          if (modified_time < current_time) {
            unlinkSync(file_path)
            length--
          }
        }
      }
      if (!length) rmdirSync(dir_path)
    }
    clean_dir(pacakge_path + "/types")
  }
)

The principle is simple.
Record the current time in JavaScript, run tsc, and then delete the unchanged files.
If you're curious about the entire project, check out the StackBlitz link below.

Thank you.

https://stackblitz.com/edit/github-p9xwsc?file=scripts%2Ftsc_with_clean.js

Is JavaScript's freedom a strength or a weakness?

Yeom suyun — Sun, 12 Nov 2023 11:30:41 +0000

JavaScript is a very interesting programming language.
It is easy and quick to code, runs immediately in runtimes like the web or Node.js, and is quite fast despite being a dynamic type language.
However, the freedom of JavaScript seems to be somewhat controversial.
For example, many developers believe that strict comparison is essential when comparing values.

Implicit Casting in JavaScript

I like to use implicit casting when writing JavaScript. All values in JavaScript can be implicitly cast to boolean.

True

1, -1 // non-zero number
" " // non-empty string
{}, [], function() {}, () => {}, this // non-null object

False

0 // zero
"" // empty string
null // null object
undefined // undefined

Loose Comparison in JavaScript

Loose comparison in JavaScript casts the compared values to the number type if they are of different types. Object types are compared by their address values, but the equality comparison of null and undefined is exceptionally treated as true.

123 >= "00123" // 123 >= 123
2 == true // 2 == 1
{} == {} // *{} == *{}
null == undefined // true
null >= undefined // *null >= undefined

Conclusion

JavaScript is a very liberal language, and the features of JavaScript such as implicit casting may seem confusing at first, but I personally think this is one of the advantages of JavaScript.

Thank you.

Introduction to eslint-plugin-lube

Yeom suyun — Sat, 04 Nov 2023 03:57:56 +0000

ESLint is quite a useful tool for code linting.
When used with vsce, it notifies you of coding convention violations in real time and even supports auto-fix features.
However, if you look at the GitHub star history, ESLint's indicators are relatively low compared to Prettier.

That may be because ESLint's fix features are not as good as Prettier's formatting features, which enforce coding styles.
For example, ESLint's max-len rule will warn you if a line is too long, but it does not provide an auto-fix feature to automatically insert line breaks, unlike Prettier.
To be honest, I don't know if there are any other examples.

Prettier's strictness is inconvenient

Many people use ESLint and Prettier together.
This is a good choice because the two libraries have their own roles for linters and formatters.
However, Prettier has one drawback.
In order to pass the check option after modifying a file, you must always run Prettier with the write option.
No matter how fast Prettier's performance is, this restriction is quite inconvenient for me.
Since ESLint already provides auto-fix features for most coding styles, I decided not to use Prettier and support the missing features through eslint-plugins.

Additional rules provided by the plugin

eslint-plugin-lube provides the following four rules that support auto-fix features.

Rule	Docs	Code	Test
pretty-imports	docs	code	test
pretty-jsdoc-casting	docs	code	test
pretty-sequence	docs	code	test
svelte-naming-convention	docs	code	test

pretty-imports

export { a, b as c, d } from 'module'
export { fff, ggg, hhh, iii, jjj, kkk, lll } from 'module/2'
import {
    aaaaa_bbbbb,
    aaaaa_ccccc,
    aaaaa_ddddd
} from "module"

pretty-jsdoc-casting

var v = func(
    a
)
var v = /** @type {A} */(/** @type {B} */(/** @type {C} */(a)/**/)/**/)/**/
var v = /** @type {A} */(a)/**/()
var v = { b: /** @type {A} */(a)/**/ }

pretty-sequence

var value = [ a, b, c ]
var value = [
    aaaaaaaaaa,
    bbbbbbbbbb,
    cccccccccc,
    dddddddddd
]
var value = { a, b, c, d, e }
var value = {
    aaaaaaaaaa,
    bbbbbbbbbb,
    cccccccccc,
    dddddddddd
}
function func(a, b, c) {

}
function func(
    aaaaaaaaaa,
    bbbbbbbbbb,
    cccccccccc,
    dddddddddd
) {

}
var value = `${[a,b,c]}`

func(
    aaaaaaaaaa_bbbbbbbbbb_cccccccccc
)
    .a(
        aaaaaaaaaa_bbbbbbbbbb_cccccccccc
    )
    .b(
        aaaaaaaaaa_bbbbbbbbbb_cccccccccc
    )
    .c(
        aaaaaaaaaa_bbbbbbbbbb_cccccccccc
    )

var value = {
    a: [ a, b, c ],
    b: true,
    c: {
        aaaaaaaaaa: a,
        bbbbbbbbbb: b,
        c: [
            aaaaaaaaaa,
            bbbbbbbbbbb,
            ccccccccccc
        ],
        d: {
            aaaaaaaaaa,
            bbbbbbbbbbb,
            ccccccccccc
        }
    }
}

svelte-naming-convention

var snake_case = 'Hello'
var snake1_2_3case_4 = 'Hello'
var SNAKE_CASE = 'Hello'
var SNAKE1_2_3CASE_4 = 'Hello'
var PascalCase = 'Hello'
var P1ascal2Case345 = 'Hello'
var __ = 'Hello'
var $$ = 'Hello'
var __snake_case$$ = 'Hello'
var $$snake_case$$ = 'Hello'

Conclusion

eslint-plugin-lube is still in version 0.4.2, and the minor version is incremented by 1 whenever a new rule is added.
All rules support auto-fix features, and they are created on the premise of not using Prettier.
If you find Prettier inconvenient, try this plugin.

Thank you.

Performance of Runtime CSS Generation using MutationObserver

Yeom suyun — Sat, 28 Oct 2023 14:18:09 +0000

Recently, I found an interesting tweet on Twitter.
// Detect dark theme var iframe = document.getElementById('tweet-1714081079840154017-875'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1714081079840154017&theme=dark" }
The contents of the commit attached to the above tweet were as follows.

// before
let cssFunctions = ['min', 'max', 'clamp', 'calc']
function isCSSFunction(value) {
  return cssFunctions.some((fn) => new RegExp(`^${fn}\\(.*\\)`).test(value))
}

// after
let cssFunctions = ['min', 'max', 'clamp', 'calc']
let IS_CSS_FN = new RegExp(`^(${cssFunctions.join('|')})\\(.*\\)`)
function isCSSFunction(value) {
  return IS_CSS_FN.test(value)
}

I think most people will be able to tell immediately what was changed when they see the original code.
The original code was very inefficiently written.
I would have changed it in the following way, but regardless, the performance of isCSSFunction has been greatly improved through the commit.

let IS_CSS_FN = /^(?:calc|clamp|max|min)\(.*?\)/
function isCSSFunction(value) {
  return IS_CSS_FN.test(value)
}

Tailwind is still slow

I once attached a benchmark result using a site called PageSpeed Insights while writing an article about the CSS Library I created.

CSS Lube: Highly-optimized CSS Interpreter

Yeom suyun ・ Aug 22

#webdev #javascript #opensource #css

However, this site runs on a local PC, so there is a large deviation every time and the reliability is low.
I found a site called WebPageTest that can get more reliable measurement results.And the following are the numbers measured using this site.

Here's something to keep in mind.
Tailwind is ultimately used in production as a built-in result, so the performance expectation is the same as Atomic CSS, regardless of whether or not jit mode is used.
The Tailwind CDN used in the test is a feature that allows you to try Tailwind using MutationObserver without going through the build stage, and is not suitable for production use.
Recently, I saw an argument in an article titled Tailwind vs Semantic CSS that Tailwind is slow and requires much more markup to compensate for the lack of selector functionality.
This is not true.
So why is tailwind-jit included in the benchmark?
It's because CSS Lube is implemented using the MutationObserver feature, just like Tailwind's Play CDN feature.

Why is CSS Lube fast?

That's the topic of this article.
CSS Lube has a total blocking time of over 2 seconds, which is a bit long, but it is still scoring a speed index score that is almost the same as inline style.
And as you can see from the test page, the test page has 11,186 elements, and the blocking time includes the time it takes to parse the remaining invisible elements outside the first screen after quickly loading the first screen.
This performance was actually possible thanks to the extremely simple logic.

Using RegExp instead of querySelectors

MutationObserver is basically used by creating two.
One detects changes in className, and the other detects new nodes being added.
It is enough to simply iterate through the classList and check if it is a new className and execute compile_style, but it is a bit different in the case of a new node being added.
When CSS Lube detects childList, it first selects the top nodes that do not overlap, and then executes a regular expression on the outerHTML to get the className.

  /** @type {Set<Element>} */
  let elements = new Set
  /**
   * @param {Element} target
   * @returns {void}
   */
  let collect_unique_top_nodes = target => {
    if (target.nodeType != 1 || elements.has(target)) return
    for (let e of elements) {
      if (e.contains(target)) return
      if (target.contains(e)) elements.delete(e)
    }
    elements.add(target)
  }

  let get_class_name_regex = /class="([^"]+)"/g
  let get_cname_regex = /\S+/g
  /**
   * @param {Element} target
   * @returns {void}
   */
  let detect_childs_with_classes = target => {
    let class_name = ""
    for (let [, substr] of target.outerHTML.matchAll(get_class_name_regex)) {
      class_name += " " + substr
    }
    class_name.match(get_cname_regex)?.forEach(get_cname_handler)
  }

One interesting thing here is that it was much faster to execute get_cname_regex once after connecting the classNames than to execute get_cname_regex for each className.

Previous version problems

Before version 2, CSS Lube used the readystatechange event or the defer attribute on the script tag to use MutationObserver on document.body.
However, I saw that the Master CSS library had a speed index of 2 seconds, which was faster than CSS Lube.
Even though the total blocking time was over 6 to 8 seconds, which was quite bad.
After analyzing the cause, I was able to speed up the speed index from the late 2 seconds to the early 1 second by simply using document.documentElement instead of document.body.

Simple compilation logic

Ultimately, the most important factor for fast performance is simple logic and a simple syntax that makes it possible.
This is also mentioned in my first article attached above.
Basically, CSS Lube can be written the same way as inline styles, and _ is replaced with a space to support spaces.
If the first letter is a special character other than -, the characters before / become the selector.
In addition, if the first letter is @, the previous characters before the next @ become the media query.
The abbreviation function is simply a function that can be used to shorten media queries or some styles.
Through this simple syntax, it was possible to provide powerful styling features without restrictions while still being lightweight and fast, with a size of 2,655 bytes in gzip, half of which is filled with mappings for abbreviations.

Conclusion

CSS Lube uses MutationObserver to achieve Atomic CSS-level performance without the need for a build step.
It requires no configuration and runs at runtime, so you can manipulate CSS like inline styles using JS, and there are no restrictions on using selectors and media queries.
The concise syntax minimizes the learning curve and improves workflow.
Does all of this sound like hype?
Check it out for yourself in the REPL - CSS Lube.

Thank you.

JavaScript and Basic Security

Yeom suyun — Sat, 21 Oct 2023 10:24:45 +0000

JavaScript is one of the most widely used languages in the world.
It is not only the basic programming language that runs on the web, but also appears to have high demand as a server-side programming language since the advent of Nodejs.
However, how well do programs made with JavaScript, especially web services, protect their security?
We will learn about the basic security policies of JavaScript that must be observed regardless of programming skills.

XSS

XSS, or cross-site scripting, is a type of attack that injects malicious code into a web page. It can be classified into two main types reflected and stored.
Web browsers have a number of security policies in place, including one that invalidates script blocks inserted by the browser. This means that even if someone were to manipulate something like HTMLElement.innerHTML to inject a script block into a page, the script would not execute.
So what's the problem? The problem occurs when malicious scripts are downloaded from the server.

Reflected XSS

Reflected XSS is a vulnerability that occurs when user-supplied parameters are inserted into a page without validation.
For example, when showing search results based on the value of the query parameter q, if the value of q is inserted into the search bar directly, it can be used to create a URL that executes malicious scripts to a domain such as Dev.to.
One way to address this is to escape tag characters to make them strings.

Stored XSS

Stored XSS is a type of attack that works on the same principle as reflected XSS, but it stores malicious scripts on the server's database using functions such as a bulletin board.
It may seem that it can be dealt with in the same way as reflected XSS, but the thing to consider here is functions such as WYSIWYG.
To support WYSIWYG, only the function that executes scripts without invalidating HTML should be filtered.
The filtering targets are as follows.

<script>alert('Attack')</script>
<a href="javascript:alert('Attack')"></a>
<a href="javas&#x09;cript:alert('Attack')"></a>
<button onclick="alert('Attack')"></a>
<div onmousemove="alert('Attack')"
    style="position:absolute; z-index: 12345;
    left:-100vw; top:-100vh; width:200vw; height:200vh;">
</div>

Of course, script tags should be filtered, and href attributes with javascript or event handlers starting with on should also be filtered, even though they are executed when the user clicks.
Here, it is important to note that filtering can be bypassed using \	, or malicious scripts can be executed without clicking using onmousemove and some styles.

Unverified Redirection

If you use the URL sent by the user without validation in the redirection, it can be used to create URLs such as dev.to?redirectUrl=attacker.site, similar to reflected XSS.

SQL Injection

SQL injection is a vulnerability that allows an attacker to escape the string range using comments and manipulate SQL freely if the user's input is inserted into the query directly.
It is a vulnerability that can lead to fatal damage, such as the theft of all personal information on the server or the deletion of data, but if you use the Prepared Statement function, you can treat all user input as simple strings, so no problems occur.

SELECT * FROM user
FROM id = '{id}' AND pw = '{pw}'

// id = " ' OR 1 == 1 --"

SELECT * FROM user
FROM id = ' ' OR 1 == 1 --' AND pw = ''

Check permissions on the client side

Web apps are vulnerable to attacks because they allow users to freely execute JavaScript through features like the console, and attackers can intercept communications, send manipulated requests, or receive manipulated responses.
All validation logic should be handled on the server.
Client-side validation is almost useless except for reducing server traffic due to bad requests.

Conclusion

I have listed various security vulnerabilities and their solutions, but in fact, all of these methods are based on not trusting the user's request.
This also includes business logic processing.
Even when processing basic CRUD, use the data from the database rather than the user's input values.

Thank you.

How to write types for better usability

Yeom suyun — Sun, 15 Oct 2023 14:09:44 +0000

TypeScript is a very popular JavaScript tool with over 94.7k GitHub stars as of the time of writing.
Of course, there are also 5,676 open issues, of which only 1,693 are labeled as bugs.
I will briefly mention the problems with this, but it is still a very useful tool.
The important fact is that the usability of TypeScript is greatly affected by how well the types are written.
In this article, I will introduce some tips for TypeScript and JSDoc that I have used while actually writing simple libraries.

More intelligent union type

Let's consider the case of defining Bird and Fish types simply.
The Animal type has a function called eat, and Bird and Fish have functions called fly and swim.

type Animal = {
  eat(food: any): void
}
type Bird = {
  type: "Bird"
  fly(): void
} & Animal
type Fish = {
  type: "Fish"
  swim(): void
} & Animal

The above types seem appropriate, but they are not very convenient.
Let's write a function called move, for example.

function move(animal: Animal) {
  if (animal.type == "Bird") {
    (animal as Bird).fly()
  } else if (animal.type == "Fish") {
    (animal as Fish).swim()
  }
}

Logically, it seems possible to use type values to use type guards, but it is not actually the case.
The following is how to fix the above types to work logically.

type BaseAnimal = {
  eat(food: any): void
}
type Bird = {
  type: "Bird"
  fly(): void
} & BaseAnimal
type Fish = {
  type: "Fish"
  swim(): void
} & BaseAnimal
type Animal = Bird | Fish

To use type guards, Animal must be made a union type.
Real example: dom-eater

Support for stronger type checking using `infer`

infer keyword is a function that can be used to infer types in code using the extends keyword.
By using infer to implement types such as Parameters and ReturnType, or by directly using infer, you can provide even more sophisticated and powerful type support.
For example, to strengthen the type check of setTimeout using Parameters, you can write the code as follows.

declare function setTimeout<T extends (...args: any[]) => any>(handler: T, timeout?: number, ...arguments: Parameters<T>): number

// Argument of type 'number' is not assignable to parameter of type 'string'.ts(2345)
setTimeout((a: string, b: number) => a + b, void 0, 123, 123)

// is ok
setTimeout((a: string, b: number) => a + b, void 0, "abc", 123)

In fact, setTimeout can execute eval by passing a string as a callback, but we will not consider this part.
Real example: async-lube

Avoid `d.ts` and optimize the `ts.map` by maximizing type inference.

Defining d.ts files for complex type types is not only a very tedious task, but it also makes IDEs move to d.ts files instead of actual sources when using the source tracking function using ts.map files.
If you use the infer keyword and typeof keyword introduced above to make the most of the type inference of actual code, you can define types more simply, support strong type checking, and also enjoy the benefits of ts.map files.
I will only attach actual usage cases on this topic and move on.
Real example: async-lube

Do not be surprised at the bugs in TypeScript

As mentioned earlier, TypeScript has a lot of bugs.
One of the critical bugs I encountered is that when using the typeof keyword in a generic function when generating d.ts files using tsc and JSDoc, the compiler does not reflect it properly and converts it to any type.
However, there are many bugs in TypeScript, and contributing to the project is quite cumbersome.
Even to report a bug, you need to search the issue list of thousands to see if it is already a known bug.
If you encounter a bug, the best way is to create a PR to fix it, but also consider clunky solutions.
I solved the above bug by writing a script to convert the returns type of any type JSDoc.
autogenerated d.ts
I will attach a playground for some of TypeScript's bugs.
TypeScript Bugs
JSDoc d.ts Bugs

Simple tips for using type conversions in JSDoc

The syntax of JSDoc is definitely not as good looking as TypeScript, but the most unique one is the type casting syntax.
TypeScript adopted this syntax from Google Closure, but I think it would have been better to create a syntax like @cast.
The simple solution I came up with for this problem is to add additional comments after the type casting syntax.

// ts
const value = func(something as SomeType)

// JSDoc
const value = func(/** @type{SomeType} */(something)) 

// JSDoc with extra comment
const value = func(/** @type{SomeType} */(something)/**/)

It may seem even more cumbersome, but I personally recommend this method because the readability of the code was greatly improved when I used it.

Conclusion

TypeScript has become a very convenient tool over the past 10 years.
If you handle it in the right way, as introduced in this article, TypeScript will give you great satisfaction when writing code.
However, the many issues that exist in the TypeScript project have dampened my willingness to contribute and made it difficult to actually contribute to the project.
I commented on the issue, but since the existing issue was reported several years ago, I don't expect it to be resolved soon.
Nevertheless, TypeScript is already a very attractive tool, so I hope you will enjoy the convenience that this tool provides.
Thank you.

Who can overthrow the authority of React?

Yeom suyun — Fri, 06 Oct 2023 16:30:28 +0000

I recently discovered an interesting project called nuejs on GitHub.
The syntax of this front-end framework, which has gained over 3k stars in just a few weeks, is quite interesting.

<button @click="count++">
  <p :if="!count">No clicks yet</p>
  <p :else-if="count == 1">First click!</p>
  <p :else-if="count == 2">Nice. Another one.</p>
  <p :else>Clicks: { count }</p>
  <script>count = 0</script>
</button>

nuejs / nue

The UX Framework for the Web

Nue

What is Nue?

Nue is a web framework for UX developers. What used to take a React specialist, and an absurd amount of JavaScript can now be done by a UX developer and a small amount of CSS.

Learn how it works

Who is it for?

Nue is designed for the following people:

UX developers: who natively jump between Figma and CSS without confusing designer-developer handoff processes in the way.
Beginner web developers: who want to skip the redundant frontend layers and start building websites quickly with HTML, CSS, and JavaScript.
Experienced JS developers: frustrated with the absurd amount of layers in the React stack and look for simpler ways to develop professional websites.
Designers: aiming to transfer their design skills to CSS code, but find the React/JavaScript/CSS-in-JS ecosystem impossible to grasp
Parents & Teachers: who wants to educate people how the web works

…

View on GitHub

The code above is an example of implementing a simple counter, and if we write it in React and Svelte(with Runes), it will look like the following.

import { useState } from "react"

export function App() {
  const [count, set_count] = useState(0)

  return (
    <button onClick={() => set_count(count + 1)}>
      {!count
        ? <p>No clicks yet</p>
        : count == 1
          ? <p>First click!</p>
          : count == 2
            ? <p>Nice. Another one.</p>
            : <p>Clicks: { count }</p>}
    </button>
  )
}

<script>
let count = $state(0)
</script>

<button on:click={() => count++}>
  {#if !count}
    <p>No clicks yet</p>
  {:else if count == 1}
    <p>First click!</p>
  {:else if count == 2}
    <p>Nice. Another one.</p>
  {:else}
    <p>Clicks: { count }</p>
  {/if}
</button>

Recently, Svelte also released the runes system of Svelte5 through the article "Rethinking 'rethinking reactivity'", and I thought about what features are necessary for a front-end framework while looking at these things.

What are the requirements for declaratively embedding data in HTML?

React gained its current popularity by providing a way to write UIs in declarative programming, unlike the traditional methods like jQuery.
React and modern front-end frameworks implement binding between JS data and DOM elements and conditional rendering or list iteration in their own way.
My thoughts on the essential features of modern front-end frameworks

I believe that the following features are essential for modern front-end frameworks

JS to Text: The value of a JavaScript variable can be displayed - in HTML, and the value will be automatically updated if it changes.
Components: JavaScript and HTML code can be managed as components and used like HTML.
Dynamic rendering: Conditional rendering and iterative rendering are possible with statements such as if statements and for loops.
State management: Callbacks are called based on the lifecycle of components and changes in JavaScript values.
SSR support: In addition to SSR, there are concepts that I am not familiar with, such as resumability, islands, and server components, but it provides features that support SSR or its superior user experience and SEO optimization.

These features are so common that they don't even need to be listed. However, I want to make it clear that the controversial methods, such as virtual DOM, state management, and signals, are not that important.
Of course, the most important thing is "What framework does the company that employs us use?" However, the following are the criteria for judging frameworks as follows.

Can the function be implemented and the code analyzed in a simpler and more convenient way?
Can it provide faster loading times?
Does it have a larger ecosystem and how many different features can be implemented?
To what extent can it be optimized if necessary?

Thoughts on React

jQuery is treated as a relic of the past since its release in 2006, but it is still being updated regularly, and surprisingly, 94.5% of websites that use JavaScript libraries still use jQuery.
However, if someone asks us what will happen if we use jQuery for a new project, we can confidently say that we should never use it for several reasons.
But what about React?
Of course, React is still a viable library with a huge ecosystem and a variety of third-party libraries.
However, relatively new frameworks such as Svelte and Solid highlight React's shortcomings in some areas such as performance and productivity, and new frameworks such as nue are also joining this competition.
However, React's position is still solid, and it does not seem to change its position even after a few years, according to the state of js survey results.
When I see React, I think of Einstein's quote, "To punish me for my contempt for authority, fate made me an authority myself."
React succeeded in overthrowing the authority of jQuery, but who can overthrow the authority of React?

How to create a simple VSCE for CSS Lube

Yeom suyun — Thu, 28 Sep 2023 12:12:35 +0000

CSS Lube is a CSS library that I created. I personally use the term "CSS interpreter", but it can also be seen as a general utility-first library.

CSS Lube: Highly-optimized CSS Interpreter

Yeom suyun ・ Aug 22 '23

#webdev #javascript #opensource #css

One of the slogans of this library is "It takes only 3 minutes to learn this".
In order to make this claim a reality, I created a vscode extension.
The features required for VSCE were simple autocompletion and hover messages to prevent the need to memorize shortcuts, and I decided to add code highlighting features as a side benefit.

VSCE's basic API

First, I looked at the tutorials for VSCE.
The sample repository I found in the tutorial had many examples, and I copied the source code for autocompletion and code highlighting, and then proceeded with the work by finding additional information through Google search.
I wish the sample code was more helpful, but I was able to learn how to use the VSCE API required for feature implementation with the help of Stack Overflow.

const hover_message = new vscode.MarkdownString()
hover_message.supportHtml = true
hover_message.appendMarkdown("**" + compile_style(cname) + "**")

How to find the class name using AST

After I learned the basic usage of the VSCE API, I needed a way to find where the parts of the code corresponding to the HTML's className are.
At first, I tried to use regular expressions naively.

const class_name_regex = /(?<=class(?:Name)?=")[^"{]*/g

However, since common front-end frameworks use JavaScript code blocks together when writing HTML, it was necessary to support the functionality of the extension for JavaScript strings used in className.

<script>
const name = "world"
</script>

<div className={`c=red
    bg=blue
    ${is_left ? "pr=1" : "pl=1"}`}>
  <span>Hello {name}!</span>
</div>

My solution to this was to implement an HTML AST parser and use it, even if support for JSX would be postponed until later.
Looking at the issues of Svelte, it seemed that there was no parser that met my requirements, and I created an AST parser for it myself.
The principle is simple.
The starting point of a script block can be identified using {.
The starting point of a string can be identified using ', ", or backtick.
If } appears outside of a string, it indicates the end of the script block.
The challenge is to determine when a string ends.
For example, in the case of backticks, I used the following regular expression to find the end point of backticks.

const stop_backtick_regex = /(?<=(?<!\\)(\\\\)*)(?:`|\${)/

I was able to determine the end point of an unescaped string using (?<=(?<!\\)(\\\\)*).
Ultimately, the AST was composed using the types below.

import type ast_syntax_error from "./src/parse_dom/src/AstSyntaxError.js"

export type AstNode =
  Attribute
  | Script
  | String
  | Style
  | Element
  | Text

export type AstSyntaxError = ReturnType<typeof ast_syntax_error>

export type Attribute = {
  type: "Attribute"
  name: string
  value: (
    true
    | Script & { subType: "block" }
    | String & { subType: "single" | "double" }
  )
} & BaseAstNode

type BaseAstNode = {
  end: number
  start: number
}

export type Element = {
  attributes: Attribute[]
  children: AstNode[]
  name: string
  subType: "close" | "closed" | "open"
  type: "Element"
} & BaseAstNode

export type Script = {
  strings: String[]
  subType: "block" | "content" | "template"
  type: "Script"
} & BaseAstNode

export type String = {
  scripts: Script[]
  subType: "backtick" | "double" | "single"
  type: "String"
} & BaseAstNode

export type Style = {
  type: "Style"
} & BaseAstNode

export type Text = {
  type: "Text"
} & BaseAstNode

Other than this idea, the code was not very elegant, as it was written in a way that simply wrote and debugged repeatedly until it was completed without a clear design.
Still, if you are curious about the actual code, please refer to the link below.
dom-eater
css-lube/intellisense

TODO?

Writing Ast test code is very difficult.
I am thinking about how to write test code simply.

JSX support seems to be more difficult than expected.
It is necessary to support parsing for code that is being written, but even in the case of acorn, it seems that JSXElement parsing is not working properly if the loose(syntax error allowed) option is enabled.

Thank you.

A few things about regular expressions in JavaScript

Yeom suyun — Thu, 21 Sep 2023 08:21:16 +0000

Regular expressions are a powerful tool for matching and manipulating text in JavaScript. They have been supported since the ES3 specification in 1999, as JavaScript was originally designed for processing HTML strings.
While complex regular expressions can be slower than optimized JavaScript logic, in general, using regular expressions to process strings is faster than not using them.

Processing order of regular expressions

JavaScript regular expressions work in three steps.

When we declare a regular expression, the JavaScript engine compiles it.
When we call a function on the regular expression or the string, the compiled regular expression program is passed the string, and match data is returned.
The function that was called returns the appropriate result using the string and regular expression match data.

// 1. A regex that matches all n~n ranges behind or in ahead of "AAA"
const regex = /(?<=AAA)|(?=AAA)/g

// 2. A total of 6 ranges from 0 ~ 0, 1 ~ 1... 5 ~ 5 are matched by the regex.
"AAAAA".replace(regex, "B")

// 3. The result is "BABABABABAB" because the ranges are replaced with "B".

Reading order of regular expressions

JavaScript regular expressions can use backtracking to find a match, which can lead to catastrophic backtracking problems if there is a mismatch.
For example, the number of backtracking attempts of a regular expression can be represented by a function, depending on the number of a's in a regular expression of the form /(a+)+b/.test("aaac").

function cases(n) {
  if (n == 1) return 1
  let acc = 1
  for (let i = 1; i < n; i++) {
    acc += i
  }
  return acc + cases(n - 1)
}

/(a+)+b/.test("ac")// 1: (a)c
/(a+)+b/.test("aac") // 3: (aa)c, (a)(a)c, a(a)c
/(a+)+b/.test("aaac") // 7: (aaa)c, (aa)(a)c, (a)(aa)c, (a)(a)(a)c, a(aa)c, a(a)(a)c, aa(a)c
/(a+)+b/.test("aaaac") // 14: ...
/(a+)+b/.test("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaac") // 4525

Lookaround's evaluation method

Lookaround in regular expressions can be considered a kind of conditional statement.
It evaluates the condition at the current position.

Pattern	Type	Matches
X(?=Y)	Positive lookahead	X if followed by Y
X(?!Y)	Negative lookahead	X if not followed by Y
(?<=Y)X	Positive lookbehind	X if after Y
(?<!Y)X	Negative lookbehind	X if not after Y

For example, the regular expression /a(b)c(?=.*\1)/g first matches the string "abc", then checks if the first group, "b", is present in the following characters.

"abczb".match(/a(b)c(?=.*\1)/g) //=> ["abc"]

Similarly to how positive lookahead assertions test all possible cases until a match is found, negative lookahead assertions also test all possible cases until a match is found.
This can be used to determine if a string does not contain a specific character, even without using the $ symbol.

with (console) {
  log(/^[^a]*$/.test("bcdef")) //=> true
  log(/^[^a]*$/.test("bcdefa")) //=> false
  log(/^(?!.*a)/.test("bcdef")) //=> true
  log(/^(?!.*a)/.test("bcdefa")) //=> false
}

Conclusion

I personally like regular expressions very much. This is because it is a way to improve the performance and simplify the code of JS, while reducing the number of characters, unlike WASM, which increases the number of characters due to glue code and its own size. I hope you will check and use some of the precautions of regular expressions.

Thank you.

JSDoc in TS and JS

Yeom suyun — Mon, 18 Sep 2023 01:08:37 +0000

Two days ago, I wrote a post about JSDoc.
The post was about using JSDoc for type checking, and it received over 60 comments, including my own replies.

Throw away the "Script" from "Type""Script".

Yeom suyun ・ Sep 16 '23

#typescript #javascript #webdev #discuss

Some of the comments were critical of JSDoc's type checking capabilities, while others defended JSDoc's ability to provide complete type checking.
I was curious about the repetition of the same question and answer, and I realized that we were talking about different JSDoc.

In TypeScript, JSDoc is a pure comment.
Although it provides some information when we hover over the code, it does not support type checking at all.
But it's different in JavaScript.

By adding a few settings to tsconfig.json, TypeScript can read JSDoc in JavaScript and support the same level of type checking as TypeScript.
This is in stark contrast to the incompetent JSDoc of TypeScript.
Also, even in cases where JSDoc is written but not used with TypeScript, such as in an eslint project, JSDoc is simply a comment.
I agree to some extent that JSDoc can be aesthetically horrible, and it is hard to argue against that.
However, I hope that the misunderstanding that JSDoc does not support adequate type checking will be cleared up, and I will leave an example below of how TypeScript and JSDoc can be used to perform the same type checking.

Thank you.

TypeScript DeepReadonly

JSDoc DeepReadonly

JSDoc function overloads

JSDoc discriminated unions

Throw away the "Script" from "Type""Script".

Yeom suyun — Sat, 16 Sep 2023 14:03:01 +0000

Before writing this article, I will first attach a post that was posted on a community a few days ago.
Turbo 8 is dropping TypeScript
After seeing the title of the above article, I thought it was about the library turbo8 migrating from TypeScript to JSDoc.
However, it was not.
The team removed the type annotations from their codebase, changed the file extensions to js, but did not add comments.
Yes, what they wanted was freedom from types.
At this point, I will attach the post that was posted the day after the above post.
Open source hooliganism and the TypeScript meltdown

TypeScript is not productive.

I mostly agree with DHH's post, and I think that some of the older JavaScript-based libraries that support @types are supporting TypeScript simply because they don't have the courage to stand up to the TypeScript zealots.
There are many cases where libraries support @types because TypeScript users demand it, even if they think TypeScript is unproductive.
However, I am very positive about types.
I am a fan of the JSDoc tool, to be exact.
Therefore, in this article, I will introduce how convenient JSDoc is.

JSDoc's type is just a comments.

JSDoc is a tool that provides type hints for JavaScript using comments.
Some TypeScript programmers criticize this, arguing that comments should only be comments and should not affect code.
However, TypeScript does not have runtime type checking, and JSDoc types are only used for IntelliSense, linting, and code summarization.
Therefore, comments are a very appropriate place to write types.
JSDoc does not affect the source code in any way. It also skips the unnecessary compilation step of TypeScript, allowing you to enjoy the freedom of JavaScript to the fullest.
Of course, there are a few exceptions.
For example, if the type is incorrectly declared or shadowing is attempted, I had to use @ts-ignore to work around the issue.
I have never studied TypeScript separately, so there may be other elegant solutions that I am not aware of.

/// lib.es5.d.ts
charCodeAt(index: number): number;

/// js-source
// @ts-ignore: index -> index?
const code = str.charCodeAt()

/** @type {RegExp} */// @ts-ignore: string -> RegExp
let regex = ".[:=]."
// @ts-ignore: string -> RegExp
for (let key of map.keys())  += "|" + key
regex = RE(regex)

Do types make JavaScript harder?

Let's reverse the question.
How can types make JavaScript difficult?
Could it be a long learning curve, adding verbose syntax, or difficult types?
Here, it seems that the only thing that can be established for JSDoc is difficult types.
I had no problem using JSDoc even with a basic knowledge of Java and a quick glance at a Svelte codebase written in JSDoc.

1. How to set up JSDoc

For more information, please see my article titled How to configure JSDoc instead of TypeScript.
I have made several improvements to make it possible to apply JSDoc to library code concisely and to use it in both JS and TS projects.

2. Applying types to code with JSDoc

This is also all covered in the TypeScript - JSDoc Reference.
The important points can be summarized as follows.

/**
 * @template T
 * @param {T|import("../../private.js").SomeType} my_parameter
 * @returns {Map<T, number>}
 */
function my_func(my_parameter) {
  /** @type {[T, number][]} */
  const array = [
    [/** @type {T} */(my_parameter), 1]
  ]
  const my_map = new Map(array)
  return my_map
}

TypeScript has excellent type inference, so JSDoc only requires a few additional syntaxes.
Here is an example of my actual code.

/**
 * @param {Map<*[], Function>} nodes
 * @param {number} index
 */
const run_dag = (nodes, index) =>
  new Promise(
    (resolve, reject) => {
      /** @type {Map<*[], Function>} */
      const jobs = new Map()
      /** @type {Map<Function, *[][]>} */
      const dependents = new Map()
      /** @type {[number]} */
      const count = [ nodes.size ]

      for (const [dependencies, callback] of nodes) {
        const clone = [...dependencies]
        jobs.set(clone, callback)
        for (const p of clone)
          if (typeof p == "function") {
            const array = dependents.get(p)
            if (array) array.push(clone)
            else dependents.set(p, [ clone ])
          }
      }
      for (const [dependencies, callback] of jobs)
        if (
          dependencies.every(p => typeof p != "function")
        ) {
          run_node(resolve, reject, jobs, dependents, count, dependencies, callback, index)
            .catch(reject)
        }
    }
  )

JSDoc is used in the above code to specify the types of parameters, the generic type of a Map object, and the length of a number[] used as a pointer.
The rest of the code is typed with type inference.
JSDoc also supports auto-completion, making it easy to write function parameters.

How to write complex and challenging types

So, there is one reason left why we should not use JSDoc.
The reason why DHH said "Things that should be easy become hard, and things that are hard become any. No thanks!" is probably because defining complex and challenging types is literally complex and challenging.
Adding types to JavaScript provides several improvements to the developer experience, such as autocompletion support and better syntax highlighting.
However, in the case of complex types, typing can be cumbersome, and features like type checking may not work properly.
I will use the types of eslint that I recently worked on as an example.

export interface Property extends BaseNode {
    type: 'Property';
    key: Expression | PrivateIdentifier;
    value: Expression | Pattern; // Could be an AssignmentProperty
    kind: 'init' | 'get' | 'set';
    method: boolean;
    shorthand: boolean;
    computed: boolean;
}
export interface NodeMap {
    AssignmentProperty: AssignmentProperty;
    CatchClause: CatchClause;
    ...
    Property: Property;
    ...
}
type Node = NodeMap[keyof NodeMap];
interface Identifier extends BaseNode, BaseExpression, BasePattern {
    type: 'Identifier';
    name: string;
}
interface NodeParentExtension {
    parent: Node;
}
Identifier: (node: Identifier & NodeParentExtension) => void

Identifier(node) {
  const parent = node.parent
  const type = parent.type
  if ("Property" == type) {
    if (parent.value == node) {
      if (parent.key.name == parent.value.name) { // TS error here
...
}

eslint's Rule.RuleListener.Identifier generates a lot of type errors in normal JS code, making autocompletion impossible.
This is despite the incredibly verbose and detailed d.ts files of eslint and estree.
My initial solution was to make things that are hard become any, as shown below.

/// private.d.ts
interface ASTNode extends Node, Pattern {
  computed: boolean
  id: ASTNode
  imported: ASTNode
  key: ASTNode
  left: ASTNode
  local: ASTNode
  name: string
  object: ASTNode
  parent: ASTNode
  property: ASTNode
  range: [number, number]
  right: ASTNode
  shorthand: boolean
  type: string
  value: ASTNode
}

/** @param {import("../private").ASTNode} node */
Identifier(node) {
...
}

It was a "No Thanks" solution, but I finished coding by fixing type errors and getting some Intellisense support.
After that, I considered how to use the verbose types of estree, and the result is as follows.

/// private.d.ts
export type ASTNode = {
  end: number
  parent: ASTNode
  range: [number, number]
  start: number
} & (
  estree.ArrayExpression
  | estree.ArrayPattern
  | estree.ArrowFunctionExpression
  | estree.AssignmentExpression
  | estree.AssignmentPattern
  | estree.AwaitExpression
  | estree.BinaryExpression
  | estree.BlockStatement
  | estree.BreakStatement
  | estree.CallExpression
  | estree.CatchClause
  | estree.ChainExpression
  | estree.ClassBody
  | estree.ClassDeclaration
  | estree.ClassExpression
  | estree.ConditionalExpression
  | estree.ContinueStatement
  | estree.DebuggerStatement
  | estree.DoWhileStatement
  | estree.EmptyStatement
  | estree.ExportAllDeclaration
  | estree.ExportDefaultDeclaration
  | estree.ExportNamedDeclaration
  | estree.ExportSpecifier
  | estree.ExpressionStatement
  | estree.ForInStatement
  | estree.ForOfStatement
  | estree.ForStatement
  | estree.FunctionDeclaration
  | estree.FunctionExpression
  | estree.Identifier
  | estree.IfStatement
  | estree.ImportDeclaration
  | estree.ImportDefaultSpecifier
  | estree.ImportExpression
  | estree.ImportNamespaceSpecifier
  | estree.ImportSpecifier
  | estree.LabeledStatement
  | estree.Literal
  | estree.LogicalExpression
  | estree.MemberExpression
  | estree.MetaProperty
  | estree.MethodDefinition
  | estree.NewExpression
  | estree.ObjectExpression
  | estree.ObjectPattern
  | estree.PrivateIdentifier
  | estree.Program
  | estree.Property & { key: estree.Identifier }
  | estree.PropertyDefinition
  | estree.RestElement
  | estree.ReturnStatement
  | estree.SequenceExpression
  | estree.SpreadElement
  | estree.StaticBlock
  | estree.Super
  | estree.SwitchCase
  | estree.SwitchStatement
  | estree.TaggedTemplateExpression
  | estree.TemplateElement
  | estree.TemplateLiteral
  | estree.ThisExpression
  | estree.ThrowStatement
  | estree.TryStatement
  | estree.UnaryExpression
  | estree.UpdateExpression
  | estree.VariableDeclaration
  | estree.VariableDeclarator
  | estree.WhileStatement
  | estree.WithStatement
  | estree.YieldExpression
)

/** @param {import("../private").ASTNode & import("estree").Identifier} node */
Identifier(node) {
...
}

The second solution works amazingly well, and I was able to find and fix errors in my first solution's code using typecheck.
The type error was caused by incorrect NodeMap, Identifier, and NodeParentExtension types.
I think that almost all of the unpleasantness of using JSDoc comes from incorrect type declarations.
However, I think it would be difficult to have incorrect type declarations if you coded using JSDoc from the beginning.
This is because you can use JS code as a type directly.

Getting the most out of type inference

JavaScript has implicit types, which allow TypeScript to perform type inference.
We can use JavaScript's basic types without declaring separate types.

export const number = 0 // number
export const string_array = ["string"] // string[]
export const object = { key: "Hello" } // { key: string }
export const map = new Map // Map<any, any>
export class Class {} // class Class
export function func() { return new Set } // function (): Set<any>

Of course, it is also possible to use the inferred types from JavaScript.

import * as js from "./export.js"

typeof js.number // number
typeof js.string_array // string[]
typeof js.object // { key: string }
typeof js.map // Map<any, any>
new js.Class // Class
typeof js.func // function (): Set<any>
ReturnType<typeof js.func> // Set<any>

As you can see from the above examples, TypeScript is able to infer the complex types that occur in JavaScript, so we can simply use them.

Conclusion

Are you using TypeScript?
Use JSDoc.
Are you using JavaScript?
Use JSDoc.
Does TypeScript's unnecessary compilation harm the developer experience?
Use JSDoc.
Does JavaScript's lack of IntelliSense harm the developer experience?
Use JSDoc.
Does TypeScript's typecheck harm JavaScript's freedom?
Make use of type inference.
Is it cumbersome to write d.ts to support TypeScript for a JavaScript library?
Use JSDoc to generate it automatically.

Thank you.

DEV Community: Yeom suyun

Implementing Drag-and-Drop using Svelte 5

Synergy between Runes and Module Context

Considerations for mouse move and mouse up events

DragContainer and Draggable

Conclusion

Managing the types folder with a simple script

How to configure JSDoc instead of TypeScript

Yeom suyun ・ Sep 2

Is JavaScript's freedom a strength or a weakness?

Implicit Casting in JavaScript

True

False

Loose Comparison in JavaScript

Conclusion

Introduction to eslint-plugin-lube

Prettier's strictness is inconvenient

Additional rules provided by the plugin

pretty-imports

pretty-jsdoc-casting

pretty-sequence

svelte-naming-convention

Conclusion

Performance of Runtime CSS Generation using MutationObserver

Tailwind is still slow

CSS Lube: Highly-optimized CSS Interpreter

Yeom suyun ・ Aug 22

Why is CSS Lube fast?

Using RegExp instead of querySelectors

Previous version problems

Simple compilation logic

Conclusion

JavaScript and Basic Security

XSS

Reflected XSS

Stored XSS

Unverified Redirection

SQL Injection

Check permissions on the client side

Conclusion

How to write types for better usability

More intelligent union type

Support for stronger type checking using infer

Avoid d.ts and optimize the ts.map by maximizing type inference.

Do not be surprised at the bugs in TypeScript

Simple tips for using type conversions in JSDoc

Conclusion

Who can overthrow the authority of React?

nuejs / nue

The UX Framework for the Web

Nue

What is Nue?

Who is it for?

What are the requirements for declaratively embedding data in HTML?

Thoughts on React

How to create a simple VSCE for CSS Lube

CSS Lube: Highly-optimized CSS Interpreter

Yeom suyun ・ Aug 22 '23

VSCE's basic API

How to find the class name using AST

TODO?

A few things about regular expressions in JavaScript

Processing order of regular expressions

Reading order of regular expressions

Lookaround's evaluation method

Conclusion

JSDoc in TS and JS

Throw away the "Script" from "Type""Script".

Yeom suyun ・ Sep 16 '23

Throw away the "Script" from "Type""Script".

TypeScript is not productive.

JSDoc's type is just a comments.

Do types make JavaScript harder?

1. How to set up JSDoc

2. Applying types to code with JSDoc

How to write complex and challenging types

Getting the most out of type inference

Conclusion

Support for stronger type checking using `infer`

Avoid `d.ts` and optimize the `ts.map` by maximizing type inference.