In the Developer Interview series, we talk to engineers who use Semaphore and pick their brains about how they work, what wisdom they would like to pass on, and the most challenging problems they’ve faced during developing.

This month we had a chat with Avichay Eyal, the man behind Slim.js – the fastest open source web-components library around.

1. First, please tell us more about Slim.js, and why you think it’s unique in today’s world of JavaScript libraries and frameworks.

The project was derived from the desire to create a simple but powerful library that enables developers to create custom elements, using the web components standard and API. After working with Polymer, I came to realize that the learning curve may be too steep for the common developer. Other solutions like x-tags or skate-js did not provide the most-wanted feature: data binding. I was looking for something that would provide solutions for most use cases while keeping performance and ease of use as top priorities.

Slim.js is both a base class and a set of tools that does the trick, without requiring from developers to be too declarative. It is pluggable and extensible, so the core features that come with the library are also built as extensions. The performance tests show that it is the fastest web-components library around.

2. When creating Slim.js, you’ve put emphasis on the weight of the library, its developer friendliness and extensibility. Are there any business-related factors that came to your mind when creating Slim.js?

Of course! Ease-of-use means fast ramp-up of new developers into an existing project and quick turnarounds for delivering UI. Extensibility means that any team can write extra functionality at any level: project level, component level or even add generic behaviors and provide them as a holistic library side-by-side with Slim.js.

Simply put, it’s easier to deliver components with Slim.js because any component is unaware of the library that the other components may be written in – this makes any rewrites or migrations unnecessary.

3. You refer to yourself as a Web Components advocate – what’s so special about them and why should we care?

The Web Components standard is the missing piece of UI development for web browsers that we were looking for. After years of using hacky solutions how to manipulate the DOM in order to make components behave like they do in any other runtime (i.e. Windows UI, Java, Silverlight, Flex…), it is finally doable with this API.

The most important thing to understand is that Web Components work with ANY framework and are friendly to other components, regardless of the technology. This means that if you choose to write your UI with Web Components, you don’t need to port it when the next fancy framework arrives (as opposed to components written in React, Vue or Angular).

This is not just a matter of comfort – it’s a true money saver for companies. People can focus on writing new features instead of rewriting the old ones over and over again.

4. In one of your articles you mention that “we have all the alternatives in the ‘bare metal’ of browsers and servers: everything that needed a work-around became a standard.” Do you think that it’s only the JavaScript world that suffers from fatigue and over-engineering, or is it a common issue in the software development world?

Not quite. I think that hypes come when things become popular. JavaScript is de-facto the most used language in web development and has an enormous community. Companies like Facebook, Google and Microsoft have the desire to be part of it. This encourages the community even more (which is a good thing) – but the side effect is the JavaScript fatigue. I truly believe that if the GO language, for example, will set its foot deeper in server development, the language fatigue will follow.

5. Are there any common pitfalls of doing continuous integration and continuous deployment of JavaScript projects?

Yes. There are many runtimes for JavaScript – Node (with multiple versions), browsers (Chrome’s V8, Firefox’s SpiderMonkey, Safari’s JavaScriptCore…) as each one differs in behavior and features, testing and shipping code becomes complicated. When you write code that runs in the browser, you need a graphical interface and that was complicated to achieve on a build server, until recently Chrome introduced the headless mode.

Most CI/CD platforms do not support browser testing out of the box, forcing developers to use tools that mimic the browser – but these are never up to date with the latest features.

6. What were the most important Semaphore features that made you choose our solution?

Semaphore CI was able to run a full-featured test for the modern Web Components Standard on a headless browser BEFORE it was introduced in Chrome. Setting up the project required zero effort as other popular platforms required too much configuration and did not provide the solution I needed.

The same build and test configuration that runs in my development environment works on Semaphore and this is something worth mentioning. Minimal effort is what developers need so they could focus on the code (like what Slim.js is doing for component developers) – Semaphore did that for me. Semaphore CI/CD platform covers all the features I needed and I don’t have to configure anything – it just works.

7. Your open source project receives regular contributions and is up-to-date. Do you have any tips for maintaining an open source project and attracting contributors?

The most important thing is to listen to the users – they are the most important part of any project. When something comes up in the issues section or communication channels, you should always take it very seriously. When a developer uses your code not as intended and things don’t work for him – it is a chance for you to make your API more friendly, and maybe rephrase the documentation. Today’s developers don’t read the documentation when they first meet a new tool – they expect things to be simple and straightforward. You should always try to see things from a user’s perspective.

Reproduce anything that comes up. Make sure your code works before and after transpilation. Make sure it has typings for Typescript developers. Expose as little API as possible in the beginning: it is easy to open it up later, but very hard to deprecate stuff. Write real-life projects and use your own library. Take something from work and rewrite it using your open source library. Write your code as simple as possible. Avoid micro performance tweaks at the expense of readable code.

Always remember that tech leaders and super developers are the people who will decide whether to use or discard the project in their own workplace – and these people do read your code!

8. Are there any other open source tools or projects you’re particularly excited about?

I am a big fan of tiny libraries that ease up things for developers. Things GTween (originally made for Flash) that enables you to animate everything, even your data.

Lit-html is a smart project – it takes modern concepts (like jsx and unidirectional data flow) and makes them fat-free. Polymer on their main website recommends ditching Polymer elements in favor of lit-html. The guys in Google labs do awesome work.

Pixi.js – just below 100K but very very powerful runtime as you can write full-featured games, just like you could with Flash or Unity.

Last but not least – I am always excited about Babel plugins. The community keeps adding new stuff that actually extends the language and its’ features. This is a very unique phenomenon in the programming world – making ECMAScript more awesome every time.

Big thanks to Avichay for taking the time to answer our questions. Read our related articles below, and subscribe to our newsletter to keep up to speed with future interviews.

Happy building!

Want to focus on the code and have Semaphore take care of CI/CD in the background? Semaphore is free for open source and you can try it for free on private projects too.

Related reads: