Have you ever thought about that?

The editor knows we can call fill or filter! How does the editor know that elements is an array of numbers? How do those things work under the hoods?!

The language server does that magic! ✨

The editor (e.g. VS Code) plays the client-side role and takes care of presenting UI elements and firing UI events. On the other side, each language has its LSP implementation to take care of realizing possible methods, variables, etc. Hmm, ok.. things may be getting a bit confusing, so let’s take a step back, and get some terms out of our way first:

• LSP (Language Server Protocol) is an Open-Source project that defines a common protocol for language servers. So, for example, when users press Ctrl + Space in the editor, it knows it needs to send the "textDocument/completion" message to the language server to get some code completions. On the other side, language servers follow that standard and answer that message

• Language Server is a process that receives requests and provides responses. As you’re probably wondering each language has its language server: Rust has Rust Analyzer, Liquid has Theme Check, TypeScript has the typescript-language-server, and so on

• Intelligent code completion refers to context-aware code completion features, like in the example above (notice that the suggestions had the context of the elements variable and cursor position)

• IntelliSense is a set of code editing features built into VS Code. I’ve noticed that sometimes this term is used interchangeably with intelligent code completion, but IntelliSense incorporates more features than that

So, when you want suggestions and press Ctrl + Space, the following process happens in a matter of a couple of milliseconds:

• Notice how the language server builds an AST to get more information about the current context
• After that, it considers the cursor (█) position and realizes it needs to list fields for the foo variable
• With the AST, it knows that foo is a product
• With the metadata for types, it also knows that product objects have the fields available, collections, and compare_at_price
• Finally, the language server answers that JSON-RPC message with proper suggestions.

The fun part

There are many roles to play when it comes about building a good editor DX. Language servers clearly have one the most challenging, fun, and critical ones, as they need to understand what’s happening in the code even when it’s broken to guide developers towards the solution.

Months ago, I built a tiny context-aware language server for the FEEL language, and these weeks I’ve been working on the Liquid context-aware code-completion. Now, I can notice so many patterns, but also how the language design heavily impacts the language server implementations.

If you’re interested in learning more about that hands-on part or the conceptual part of building a language servers, please don’t hesitate to reach out to me. I’m planning to write even more articles related to LSP and how to make our lives as developers more fun. Follow my RSS feed to stay updated on the latest posts :)

This week the winner is The master guide to smooth, realistic shadows in CSS: dev.to/devang/the-master-guide-to-smooth-realistic-shadows-in-css-463p.

I got myself surprised by the use of multiple shadow layers to achieve such excellent results. Still, the support of most of the browsers for this feature is quite extensive.

I hope you like this CSS tip too!

Last week I had the pleasure of present my talk How to play with DMN at the KieLive#36:

During the presentation, I created a simple snake game using a DMN model (it has an interesting plot twist in the end).

Also, if you’ve enjoyed it, I’d recommend KieLive#11, KieLive#26, and KieLive#31 - all these lives approach the use of DMN models from different perspectives.

I hope you like it!

This week the winner is React: Glossary + Explain Like I’m Five: github.com/reactwg/react-18/discussions/46.

Even if you already know the topics mentioned in this thread, it is still worth checking. Sometimes, we already comprehend something, but we do not have good enough words to clarify it for other people.

It has many one-tweet definitions and quick explanations that help you when you need to explain something quickly. For me, the “debouncing and throttling” part was quite pleasant to read.

I hope you like this URL too!

I believe the main exciting point of the talk lives in the fact that WebAssembly is designed to run on the Web, but it’s not limited to Web ². Many developers are already taking advantage of WASM capabilities to use whatever language they want in near-native performance.

However, that kind of WASM usage was losing some main principles of WebAssembly, and applications were getting too aware of the environment for performing operations involving, for example, IO. That’s where WASI shines.

WASI exposes system interfaces to WebAssembly ³ programs and hides all the implementation details so that you may have a file system based on cloud, Git, or even ext4. It does that by relying on an abstract modular OS that preserves the effectiveness of standard WASM applications.

If you want to know more about this, I highly recommend the Bytecode Alliance website - bytecodealliance.org - it’s an excellent source of apprehensible information :-)

First of all, let’s remember that our browsers have five major phases during the rendering lifecycle:

Image source: https://developers.google.com/web/fundamentals/performance/rendering

Generally, we pay too much attention to the first one. However, today, I will show how the second and the third one may impact your web app’s performance. Check this simple example:

The JavaScript code of the “Click me” button is:

const button = document.querySelector("button");
const elements = document.querySelectorAll(".element");

button.onclick = (e) => {
  elements.forEach((element) => element.classList.add("element--left"));
};

When users click on that button, all 5000 elements receive the new CSS class and move. That seems a bit drastic, but some operations in an IDE may affect other components at a comparable level.

Now, let’s finally check the following two examples and understand how different CSS properties impact the page’s performance differently.

1. The slow approach

All right, let’s take a look at the performance of this page:

It takes 567ms during the rendering phase! This approach relies on the transform property to move the elements and the opacity to change their color when they move.

2. The fast approach

Now, let’s quickly tweak our CSS logic a bit to do the same thing but getting a considerable faster result:

It takes only 92ms for rendering now 🚀 We just changed the CSS by using margin-left instead of the transform property and the color instead of the opacity.

Some CSS properties demand more browser resources than others. During my investigations, I found that the following properties may harm your web app performance, so let’s keep one or two eyes on them:

• border-radius
• box-shadow
• opacity
• transform
• filter
• position: fixed

Happily, some new properties may help us, like the new content-visibility, which enables the user agent to skip some elements from the rendering phase ¹.

I hope that after this reading, you may think about CSS as a powerful, measurable, and understandable tool :-)

–

This week the winner is the Rust GameDev Workgroup’s monthly newsletter (#21)”: gamedev.rs/news/021/.

That’s one of my favorite newsletters. It’s refreshing to see the fantastic results people already reach with Rust.

This month, I’ve noticed the “Requests for Contribution” section, where everyone may find simple issues to start contributing on some repositories. That’s an inspiring community-friendly approach for engaging people, which is something that worths a try on other communities/projects as well :-)

This week the winner is Notes on “Philosophy of Software Design”: jmoiron.net/blog/notes-on-philosophy-of-software-design.

Reading other’s people notes about books is a fun way to find the next picks :-) “Philosophy of Software Design” entered on my list this week.

I hope you like this URL as well!

Last week I had the pleasure of seeing my friend Eder demonstrating the DMN Runner prototype at the KieLive#30 session:

That’s a game-changer on how users built DMN models. If you enjoy the presentation, I’d recommend the KieLive#24, the KieLive#25, and the KieLive#26, yeah, 3 in a roll! These lives have enjoyable and heterogeneous content for DMN enthusiasts.

I hope you like it! ;-)

This week the winner is Hyrum’s Law: hyrumslaw.com.

It has pretty intriguing thoughts about APIs, which I believe are actually appliable in many other contexts involving user experience as a whole.

Reading that, I recalled situations when I was updating my profile picture on some website, and the image appeared outdated right after I submitted the form. Generally, we somehow guess: - ohh, probably that’s a cache issue or even eventual consistency, I don’t know! 🤪.

However, I don’t think users should need to guess that. Also, knowing all the clauses we’re singing on our APIs contracts help us on having more simple and predictable implementations, which benefits API users as well :-)

I hope you find this URL interesting too!