DEV Community: Omar Alshaker

4 Creative Ways to JavaScript Timing in Browsers

Omar Alshaker — Sat, 15 Feb 2020 13:38:28 +0000

Photo by Lukas Blazek on Unsplash

This article assumes the availability for Web APIs, therefore, most methods suggested here don't work in NodeJS.

Using an infinite synchronous loop in a Web Worker (not Service Worker)

Since Web Workers are essentially web threads, you can infinitely loop inside them without blocking the main thread. This gives you access to sub-millisecond time resolutions. This is especially good to make time critical decisions within the worker, and let the main thread know when (accurately) you see fit. Eg. Rerender something whenever microseconds are a prime number. To get access to microseconds, you can use performance.now.

Pros and cons

Pros

Sub-millisecond resolution.
Near zero cost on the UI thread.
Fully asynchronous from a UI thread perspective. Thanks to Web Workers messaging design.
Safe ending. Unlike setInterval, calling worker.terminate guarantees no more messages will be received. Quoting MDN, "The terminate() method of the Worker interface immediately terminates the Worker. This does not offer the worker an opportunity to finish its operations; it is simply stopped at once."

Cons

Even though you can make sub-millisecond decisions, messaging back to the UI thread is asynchronous. You can't render as timely as you make the decision in the worker.
Keeps a thread fully occupied. Might be heavy on phone batteries.
Requires Web Worker support.
Doesn't pause when the tab isn't focused.

Codesandbox example

Using CSS animations for time events (particularly `animationiteration`)

If you create a div (don't use a div though, see point 2 of cons) with an infinite animation. You can subscribe to its animationiteration event and get notified whenever animation-duration passes.

Pros

Automatic suspension when the tab isn't in focus. The event doesn't fire at all when the tab isn't in focus. You don't need to worry about jammed calls that will all run at once when the tab is in focus again.
Automatic clean up when the your hidden div is removed from the DOM. For example, if you have a React component that renders the time, you don't need to do anything on unmounting. The div will me removed and the event will not fire anymore.
This is subjective but the subscription logic is beautiful. Eg. .addEventListener("animationiteration", fun).
Super clean way to delay the start of the timer by using animation-delay.

Cons

A little too clever, might confuse your teammates/contributors.
Depends on the DOM and CSSOM. Other CSS rules can interfere with yours. That's why I suggest to create an arbitrary non-existent tag like <just-a-timer-element></<just-a-timer-element>. Maybe create a custom element with the CSS animation code neatly tucked within? 🤯 (don't come after me, kthx).
Doesn't work if the element has display: none;.
Inaccurate. According to my testing, it can be off by a full 1ms. You can try yourself in the example CSB below.

Codesandbox example

Using SVG tag (SMIL Animations)

If you do animate.addEventListener('repeat', fun), your function will be called every dur (1s) period.

Pros

Works even when the SVG is display: none;.
Stops automatically when the SVG is removed from the DOM.
Doesn't begin until full page load.
Auto-pauses when the tab isn't in focus.

Cons

A little too clever, might confuse your teammates/contributors.
Depends on the DOM and CSSOM. Same caveats as above. Other CSS rules can interfere with your configuration.
Isn't supported in IE and Edge (before Chromium).
Inaccurate. According to my testing, it can be off by a whopping 15ms. You can try yourself in the example CSB below.
Doesn't begin until full page load. Yup, can be a bug and a feature.

Codesandbox example

Using Web Animations API

Web Animations API allows you to animate DOM elements from within JavaScript.

Interestingly, you can animate unmounted elements! This gives you access to a timing mechanism in pure JS (and Web APIs).

Here is an alternative implementation of setTimeout

function ownSetTimeout(callback, duration) {
  const div = document.createElement('div');

  const keyframes = new KeyframeEffect(div, [], { duration, iterations: 1 });

  const animation = new Animation(
    keyframeRequestAnimationFrames,
    document.timeline
  );

  animation.play();

  animation.addEventListener('finish', () => {
    callback();
  });
}

Neat, isn't it?

Pros

Atomic. Doesn't need DOM interactions.
Easy to understand by an unfamiliar person.
Pauses when the tab isn't focused.

Cons

Still a proposal. Don't use in production.
Dire support situation. Probably only works in Chromium.
Still a little counterintuitive.
Pauses when the tab isn't focused. Can be bad if used as an alternative for setTimeout.
Can't be used for intervals. Only onfinish event is available.
Inaccurate. According to my testing, ±5ms can happen easily.

Codesandbox example

This was fun

I realize this is a niche article. But I felt compelled to write it because I always thought setTimeout and setInterval were the only paths towards asynchronous delays and intervals. But turns out there are a few other options! And who knows, someone might have some strange constraints and might find this useful.

Do Not Use Your Employer's Email Account to Negotiate Anything Legal

Omar Alshaker — Tue, 11 Jun 2019 09:36:32 +0000

Photo by Samuel Zeller on Unsplash

TL;DR: because they can delete everything.

By employer's email account I mean something like you@youremployersdomain.com.

I recently parted ways with my previous employer. It all went super smoothly and my previous employer was nothing but super nice and compassionate. However, after a while, they naturally shut down my email account. And I was so close to losing some important documents like contracts, hardware receipts, promotion agreements, and such. Luckily I had a copy of everything on my email client and I could save a backup. But it made me realize that my employer had absolute power over my account all along. I trust my previous employer with this power, they're great people, but why trust when you can know?

Obviously, it is normal to use the company's email for work-related communication, but when it comes to negotiating your very contract, the counterparty shouldn't have access to deleting your side of the argument. Use your personal email when negotiating your salary, contract, or whatever unshared interest with your employer.

This is especially relevant for remote workers where contracts and negotiations are mostly digital.

[advice needed] Using a huge distant monitor

Omar Alshaker — Thu, 06 Dec 2018 17:52:40 +0000

My vision is considerably deteriorating due to my lifestyle. Pretty much 80% of my waking time I'm focusing on <2m away objects/monitors/screens.

I'm considering a ~56" TV that I would hang 5m away from me to relax my eyes a bit. But I'm wary of this solution because I have never seen such setup.

Anyone has tried/seen this before?

Any links to stories would be appreciated, too.

Thanks

[discontinued] Run a green-badge local HTTPS server with zero configuration

Omar Alshaker — Mon, 30 Jul 2018 18:20:48 +0000

⚠️ Apparently, this goes against letsencrypt's ToS and I can't use their certificates in such manner. And I have to drop this tool. I would have issued a non-free certificate to keep this tool up, but it doesn't sound like a great idea to publish a private key that is officially registered to my name.

No certificate creation, no tunnels and no hassle ⚡️

The importance of using HTTPS locally

One might assume that HTTPS isn’t needed for local development. But that’s not always the case. You need to test for mixed-content, secure cookies, service workers, etc. This thread by @getify makes the point perfectly.

getify

@getify

I so often get re-explaining from others that "localhost doesn't need local https". eyeroll.

this is not universally true. this tweet thread is the last time i'm gonna explain. henceforth it will just be linked to.

13:42 PM - 28 Jul 2018

4571071

Running a local HTTPS server can be pain in the neck. You have to create your own certificates, add them as trusted etc. You know the deal.

Using tunnels, at least the freely-available choices, isn’t the best experience either, they create a different URL everytime, they can get really slow, and 3rd parties will have access to your app in plain text.

But what if you could use a static, short and memorable URL to access your app without 3rd parties involvement? ez-s does exactly that. You run ez-s and access https://ez-s.io and you’ll see your app with a green badge.

What is EZ-S?

It’s a fork of zeit/serve that gives you the ability to locally run a green-badge HTTPS server. You can see it on GitHub here.

Quick steps

$ npm i -g @alshakero/ez-s
$ ez-s
# => go to https://ez-s.io to see your app

How does it works?

The domain ez-s.io has a single A DNS record pointing to the IP address 127.0.0.1.
ez-s package includes SSL certificates generated by letsencrypt.
There is also a small HTTPS server that uses the aforementioned certificates including the private key. So when you access ez-s.io the certificate provided will actually match letsecrypt's, and you get a green badge. The IP address of the host does not matter. As long as letsencrypt records match the certificates provided by the server, Chrome will not object.

Wait what? Public private keys?! Yes. Because the domain will forever point to 127.0.0.1, impersonating it will not take the impersonator anywhere. Unless the impersonator has power over the victim’s DNS server, which makes ez-s the least of the victim’s worries 😁

Caveat

Since ez-s.io points to 127.0.0.1, your app will be only accessible locally. You can't test it on your phone or using another machine.

Due to this caveat, serve's --listen argument is useless in this case. The only configurble network-related parameter is the port (-p or --port).

Questions

If you have any questions please go ahead and comment below.

The True Delight of React’s Error and Warning Messages

Omar Alshaker — Sat, 07 Jul 2018 12:25:07 +0000

Photo by Štefan Štefančík on Unsplash

Introduction

There is this fascinating idea that hasn’t left me for years now, that software developers, with all their prejudices, biases, and humanness in general, shape the world around us.

Think about it. Software, just like music, is an intangible good. It’s not wine or chocolate where raw materials can limit the product quantity then the number of people who enjoy it. There exists thousands of software pieces that are written by individuals on a Saturday night and are used by millions of people everywhere.

It’s fair to say that those individuals have an impact, small or big, on people’s lives. And even if we consider corporations, the number of people who produce software is a microscopic number in relation to the number of said software users. For instance, Google has ~18K engineers worldwide, while around 1.17 billion people use Google, that’s a ratio of 0.000015%. We can see the huge dependence on software developers’ opinions and ideas to shape the world. There is obviously a developer society and a sub-culture. And if a meme or an idea spreads in this society, it would inevitably shape the technology used by everyone.

Now imagine, in a sci-fi kind of way, that there is an imaginary software technology that solves a world problem. Say it can cure cancer or completely eliminate poverty. But, this technology has the cost of ruining the life of the software developer who uses it. Would that technology ever see the light? Hardly. This imaginary story is an extreme example of the conflict of interest between the software developer and the end user. If good software meant the developer being uncomfortable, we will not see good software. And a big part of software developers’ lives is error messages. They’re key to the experience, and paying attention to them goes a long long way. They are directly important to the developer, and indirectly important to everyone of us.

React

Of all the libraries and packages I’ve used in the last ~10 years, I haven’t seen a library where errors and warnings are as beautiful. Developers, including me, usually try to detect errors that break their own code and report them to the user along with the data they have on hand (scope?). Maybe mention the most common mistake that can cause the error along with an automatically-generated stack trace and that’s it.

TypeError: undefined is not an object

But with React, the library works overtime trying to guess for you what went wrong. The error guessing effort is quite obvious and it’s tremendously helpful; it saves you a lot of time debugging and tries its best to save your day.

To help you enjoy the experience like I do writing React apps, I’ll make this article a ride. I’ll show React snippets with mistakes in them, you may try to find the issue or just look at the warning/error below and decide whether it would be helpful for you. This is not to list every message React logs. It’s a very small sample for inspiration.

Let’s start!

1. A simple one

class MyComponent extends React.Component {
  componentWillMount() {
    console.log('Component mounted!')
  }
}

What’s wrong with this component?

Here is the message:

Warning: MyComponent(…): No `render` method found on the returned component instance: you may have forgotten to define `render`.

Beautiful, isn’t it? The component name and a correct suggestion. Super easy to fix.

2. A trickier one

class MyComponent extends React.Component {
  componentDidUnmount() {
    console.log('Unmounted!');
  }
  render() {
    return <h1>Hi!</h1>
  }
}

What’s the issue here?

Here is the message:

Warning: MyComponent has a method called componentDidUnmount(). But there is no such lifecycle method. Did you mean componentWillUnmount()?

React went out of its way here. It expected you to make this mistake and waited for you there. Silence wouldn’t break React in this case, it would only break your app. Quite sympathetic of the library.

3. A little obvious one

class GreetingComponent extends React.Component {
  constructor() {
    super();
    this.state = {name: 'Omar'};
  }
  render() {
    this.setState({name: 'Not Omar'});
    return <div>Hi {this.state.name}!</div>
  }
}

What’s the issue?

Here is the warning:

Warning: Cannot update during an existing state transition (such as within `render` or another component’s constructor). Render methods should be a pure function of props and state; constructor side-effects are an anti-pattern, but can be moved to `componentWillMount`.

4. Not quite obvious

class MyComponent extends React.Component {
  constructor() {
    super();
    this.setState({name: 'John'});
  }
  render() {
    return <h1>Hi {this.state.name}!</h1>
  }
}

What’s the issue?

Here is the message:

Warning: setState(…): Can only update a mounted or mounting component. This usually means you called setState() on an unmounted component. This is a no-op.

Please check the code for the MyComponent component.

5. Pure elegance


const type = true;

ReactDOM.render( 
  <input type={type} />,
  document.getElementById("root")
);

What’s wrong with type here?

Here is the warning:

Warning: Received `true` for non-boolean attribute `type`. If this is expected, cast the value to a string.
 in input

And that’s another example of an error that doesn’t affect React, rather affects your app.

6. The beginner’s rescuer

class greetingComponent extends React.Component {
  render() {
    return <h1>Hi!</h1>
  }
}

ReactDOM.render( 
  <greetingComponent />,
  document.getElementById("root")
);

The two warnings:

Warning: <greetingComponent /> is using uppercase HTML. Always use lowercase HTML tags in React.

Warning: The tag <greetingComponent> is unrecognized in this browser. If you meant to render a React component, start its name with an uppercase letter.

I definitely fell for this at least once.

7. OK I fixed it, but it still doesn’t work

class GreetingComponent extends React.Component {
  render() {
    return <h1>Hi!</h1>
  }
}

ReactDOM.render( 
  GreetingComponent,
  document.getElementById("root")
);

What’s wrong now?

The message:

Warning: Functions are not valid as a React child. This may happen if you return a Component instead of <Component /> from render. Or maybe you meant to call this function rather than return it.

Yup, it should be:

ReactDOM.render(<GreetingComponent />, document.getElementById("root"));

8. A very common mistake in the first couple days


class GreetingComponent extends React.Component {
  render() {
    return <h1 class="bold">Hello!</h1>
  }
}

ReactDOM.render( 
  <GreetingComponent />,
  document.getElementById("root")
);

What’s up here?

The message:

Warning: Invalid DOM property `class`. Did you mean `className`?
 in h1 (created by GreetingComponent)
 in GreetingComponent

Enough data to land you exactly at your mistake

9. Why don’t you come back? 🎼


class GreetingComponent extends React.Component {
  render() {
    <h1>Hello!</h1>
  }
}

ReactDOM.render( 
  <GreetingComponent />,
  document.getElementById("root")
);

You said goodbye
I was trying to hide what I felt inside
Until you passed me by
You said you’d return
Will you ever return? 🎵

Uncaught Error: GreetingComponent(…): Nothing was returned from render. This usually means a return statement is missing. Or, to render nothing, return null.

10. And the one that doesn’t need an example:

You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

This one is a personal favorite.

Obviously, I haven’t used every framework and library ever existed. And there may be better examples of nice and helpful error messages. But as a frontend developer, I can safely say that React easily stands out. I’ve been inspired by it and now I am trying my best to guess the areas my code users could make mistakes, and provide them with eleborate and helpful error messages when they do. For I am a true believer that a better developer experience means a better world.

If you know some other nice examples of React warnings, please feel free to mention them in the comments and I’ll add them.

This was also published on Medium.

My Thoughts on Working Remotely, One Year in

Omar Alshaker — Fri, 29 Jun 2018 17:08:17 +0000

A little intro

It’s been a little more than a year since I joined Starcounter. Working full-time as a Javascript developer mostly on Palindrom, JSONPatcherProxy, and fast-json-patch. All the team I work with is in the same timezone. We use Github, Slack and Google Hangouts for meetings.

I have never been happier and more satisfied with my life than I am now. It’s been a great year and I learned much more than I ever thought I will before I started.

Before I dive in, it is important to note that a lot of this experience has to do with my nature and my personality; everything I say in this post only applies to me, and may or may not apply to other people.

Socially

One the personal level, I truly enjoy socializing. But the way I define socializing is meeting once a week for a couple hours. I tend to think that meeting people every morning is a burden. And working remotely is a godsend for me.

However, in this year I learned several lessons when it comes to socializing:

Your social attitude is as important as your skill set. We are social animals after all. Internally, I have never decided whether I liked a workmate based on how clean their code was. Or how their jsperf results scored. As much as I try to be professional and objective, I find myself liking and respecting nicer workmates more. And obviously, this applies to me too. And proving yourself nice remotely is harder than in real life.
Networking is a different challenge when working remotely. There is no coffee break or lunch chitchat**. **You’ll have to step up your social media game, conference attendance and other networking activities.
We project on people. In real life, we project all the time. We don’t know enough about people to understand them, so we assume a lot about them to sympathize (or the opposite) and understand what they’re saying without much effort. This can be a good thing, but can easily go wrong. When working remotely, you know less, so you assume more. When I first met my team after two months of text communication I was astonished how nice and cheerful they are. I painted wildly different images of every one of them based on the way they communicated on Slack. Not to say that my imagination was grim, but it was largely off. This was eye-opening for me.
Seeing the informal side of my workmates was key. It was key to seeing them as nice human beings who joke, have fun and have some weaknesses just like I do. Partying with my teammates helped me a great deal to feel secure about myself, to express who I am as a person (not an engineer). And this is a two-way street, it helped me to know who they are, as people, not robotic professionals.

What I learned from the above is that meeting the team was absolutely essential for my morale, satisfaction, and mutual trust.

The efficiency factor

One of the upsides of text communication is the ability to think, research and even later-edit what you have to say. When a workmate asks me a question on Slack, I give them a solid well-researched answer with links to specific lines of code. This saves us a lot of time and energy. Every question is a chance to learn and feel more confident.

Also, I rely much less on memory now. I can go back to any conversation I want, and I use Slack search all the time to do that. Even though Slack uses a ton of memory, at least it’s not mine 😄. To me this is a priceless upside; I always struggled to remember the conclusions made in a meeting three days later. This gives me a clear head and the ability to only process one thing at a time. Because I don’t even try to memorize conversations anymore.

There is no lack of wishing sometimes that I could walk up to a workmate and ask them a quick question and instantly get my answer and move on. But the experience is close enough on Slack.

Another huge upside to remote work is readiness to work open-source. If you think about it, most of the time open-source work is remote work. You almost never meet your contributors nor the project owners of where you contribute. Having a job that trains you to work open-source is a blessing. I’m now trained to be unambiguous, direct and to more communicative. Add to that, most the libraries I work on are in fact open-source. This gives me endless satisfaction and pleasure.

One thing I don’t know about is how much extra effort my workmates are putting to support me working remotely. I try my very best to eliminate that burden but I’m pretty sure there is an extra mile they walk sometimes to support the remote part of the team. I don’t have a decent insight on this.

Commuting

Now, I’m much more efficient than the times I used to commute. Personally, I find it hard to read or do anything constructive whlist commuting. Those are at least 60 minutes saved every day, which I spend in the gym. In a nutshell, I work + exercise in the same amount of time a commuter only works, and with less focus and energy.

Health

Working from home is reputated to be unhealthy. Well, not in Warsaw. The only thing I can confess to missing is morning sunlight. But there isn’t a lot of it either ways here. And I try to make up for that:

I go out in the morning during weekends.
I work with a huge window next to me that is always uncurtained.

And smog is a big issue in Warsaw nowadays, so staying in can be even healthier than commuting to downtown everyday at peak pollution hours.

Regarding sitting for a long time. Working in an office isn’t a whole lot better. So remote or not, without going to the gym, my job would be extremely unhealthy. I can’t stress this enough; going to gym is crucial to my health now.

Food

Another cool thing about working from home is the food. Everyday I have a decent breakfast. And recently I started cooking my lunch the night before. When it’s lunch time, I heat my food and make some salad in quick ten minutes, and enjoy every bite of it. Much healthier than eating at work; has the exact amount of protein and other nutrients that I plan to eat.

Conclusion

I would definitely recommend working remotely for a friend, but they need to make sure to meet their team occassionally, exercise and always give the benefit of the doubt when things are unclear. It’s also very important to find alternative ways for networking and self marketing.

This is my first post here, please excuse any mistakes or errors.

This was originally posted on Medium

DEV Community: Omar Alshaker

4 Creative Ways to JavaScript Timing in Browsers

Using an infinite synchronous loop in a Web Worker (not Service Worker)

Pros and cons

Pros

Cons

Codesandbox example

Using CSS animations for time events (particularly animationiteration)

Pros

Cons

Codesandbox example

Using SVG tag (SMIL Animations)

Pros

Cons

Codesandbox example

Using Web Animations API

Pros

Cons

Codesandbox example

This was fun

Do Not Use Your Employer's Email Account to Negotiate Anything Legal

[advice needed] Using a huge distant monitor

[discontinued] Run a green-badge local HTTPS server with zero configuration

The importance of using HTTPS locally

What is EZ-S?

Quick steps

How does it works?

Caveat

Questions

The True Delight of React’s Error and Warning Messages

Introduction

React

1. A simple one

2. A trickier one

3. A little obvious one

4. Not quite obvious

5. Pure elegance

6. The beginner’s rescuer

7. OK I fixed it, but it still doesn’t work

8. A very common mistake in the first couple days

9. Why don’t you come back? 🎼

10. And the one that doesn’t need an example:

My Thoughts on Working Remotely, One Year in

A little intro

Socially

The efficiency factor

Commuting

Health

Food

Conclusion

Using CSS animations for time events (particularly `animationiteration`)