HN user

atirip

665 karma
Posts5
Comments262
View on HN

I only buy from merchants that offer PayPal (there are few I trust by card, like Amazon). And the reason is that whatever it happens, I can always get my money back with PayPal. It happened 3 times in last 5 years that seller took the money and never shipped anything. I got all them resolved very quickly.

Meta Myths 4 years ago

Reels usage is still growing

But of course, as Meta put gun to the head of everyone - you WILL make Reels, or else - and now all the people I follow, increasingly make Reels. I hate Reels.

Drip Europe | Frontend Engineer | Full Time | Remote, but significant overlap (at least 4 hours) with Central European Time | https://www.drip.com

We’re an ecommerce marketing automation platform that’s generated more than $2 billion in revenue for our customers since 2018, and we’re only getting smarter and better at what we do: help independent retail thrive.

We’re looking for a frontend engineer that knows Javascript very well for Drip Onsite Team. We write lots of Vanilla Javascript that should not affect our customer’s performance or functionality, no matter how good or bad their website is made. Also, many of our customers do not know how to code, so we’ve built a flexible yet easy-to-use HTML editor to help them make their campaigns. In short, we get to solve some pretty technical problems for a lot of non-technical users.

Specifically, we’re looking for someone who is not primarily a framework user but who likes to tinker with problems no one has discovered before. Pragmatic, not politician. Can ask questions and give answers.

Apply here: https://www.drip.com/careers/dfd748af-c99a-40be-95e8-b06ec3c...

Most my coworkes are introverts. We do not do anything above. Unexpected enough? And we are lean and mean highly functional team. The most helpful for my team is let people be themselves and not force rituals.

Oh for fucks sake people. There seems to be 5 lines of text on that page and to see them I needed to turn off content blockers. Jeez…

Sleeknote | Frontend Engineer | Full Time | Remote, but significant overlap (at least 4 hours) with Central European Time (Denmark based) | https://www.sleeknote.com

We’re a growing, stable company that creates tools that help websites turn their visitors into customers with popups. We are the good guys, as unobtrusive as possible. We are the most expensive, and our customers love us.

We’re looking for a frontend engineer that knows javascript very well since we have to write vanilla javascript that doesn’t affect our customer’s performance or functionality, no matter how good or bad their website is coded. Also, many of our customers do not know how to code, so we’ve built a flexible yet easy-to-use HTML editor to help them make their campaigns. In short, we get to solve some pretty technical problems for a lot of non-technical users.

Specifically, we’re looking for someone who is not primarily a framework user but who likes to tinker with problems no one has discovered before. Pragmatic, not politician. Can ask questions and give answers. We have multiple nationalities at Sleeknote and many work remotely.

P.S. We do not use React, nor Typescript directly, but we are inspired some of the ideas.

Apply here: https://sleeknote.com/careers/frontend-engineer

Not everyone needs mobile internet. I'd argue that most people don't. Mobile phones were extremely popular when they didn't have any internet connectivity.

I am not mocking you, but here the case is that people do not know what true mobility for laptops is, that they literally can leave power brick behind, not to think about whether the battery lasts or not and use it freely during the day everywhere. This has been impossible until now, there has always been the constraint of do I really need to open my laptop, what if it dies, where is the power plug. As soon as masses realize that this is now no worry, everyone wants and needs 15+ hours battery life.

I would not say obsessed. Instead I divide engineers to implementors (people who are masters of using frameworks/libraries to implement features, but are not capable of writing one) and developers (people who can write a framework/library if that is the ticket).

But yes, there are lots of implementors around and very few developers. We currently try to hire a developer and that is not easy.

We always look for “rough diamonds”. It is a creative process, lots of tea leaves reading, but will yield excellent results if you have the ability to read these tea leaves. I am not sure we ever hired “the best on paper” candidate. But we have had great success with people who had no knowledge of out stack, down to the programming language.

I initially just mimicked the React version into Vanilla, so this was a show-off how to do that somewhat exactly the same way. But in this particular case it serves no meaning, we can always read 'checked' from DOM.

This was just taking the final React code in the article and rewriting it in vanilla as close as possible.

Your comment is fully correct, but I would like to point out:

- with such a tiny DOM to rerender, it is equivalent, probably even faster

- custom element encapsulates DOM and it is fairly trivial and extremely fast to pick DOM (like you can even use id's everywhere) in the 'old jquery' way, with simple library functions

- updating DOM with simple render() call is way more elegant, but if you keep custom elements DOM small (and one should), this way is not that bad at all

Like this:

  <!doctype html>
  <body>
  <custom-element></custom-element>

  <script>
   const CHECKBOX_ID = "my-checkbox";
   const defaultLabelContent = "Toggle me, you newbies";
   const beforeDiscountText = "You have not availabled discount";
   const afterDiscountText = "Discount Availed!";
   const beforeLabelText = "Click on me to remove fake discount"
   const afterLabelText = "Click me to apply fake discount!"

   const state = new WeakMap();

   // 'library' code
   function qs(selector) {
    return this.shadowRoot.querySelector(selector);
   }

   function getElem(nodeOrSelector) {
    return nodeOrSelector === String(nodeOrSelector) ? qs.call(this, nodeOrSelector) : nodeOrSelector;
   }
     
   function replaceText(nodeOrSelector, text) {
    let elem = getElem.call(this, nodeOrSelector);
    if (elem) elem.textContent = text;
   }

   function updateAttribute(nodeOrSelector, name, value = '') {
    let elem = getElem.call(this, nodeOrSelector);
    if (elem) elem[(value ? 'set' : 'remove') + 'Attribute'](name, value);
   }
   // end of 'library' code

   class CustomElement extends HTMLElement {

    connectedCallback() {
     this.attachShadow({ mode: 'open' });
     this.shadowRoot.innerHTML = `
      <input type="checkbox" id=${CHECKBOX_ID}>
      <label for=${CHECKBOX_ID}></label>
      <div></div>
     `;
     this.shadowRoot.addEventListener('change', (event) => {
      state.set(this, event.target.checked);     
      this.update();
     })
     this.update();
    }
 
   
    update() {
     let isChecked = state.get(this);
     updateAttribute.call(this, 'input', 'checked', isChecked);
     replaceText.call(this, 'label', isChecked ? beforeLabelText : afterLabelText);
     replaceText.call(this, 'div', isChecked ? afterDiscountText : beforeDiscountText);
    }
   }

   customElements.define('custom-element', CustomElement);

  </script>

Oh please, if you want to compare, use modern vanilla too...

  <!doctype html>
  <body>
  <custom-element></custom-element>

  <script>
   const CHECKBOX_ID = "my-checkbox";
   const defaultLabelContent = "Toggle me, you newbies";
   const beforeDiscountText = "You have not availabled discount";
   const afterDiscountText = "Discount Availed!";
   const beforeLabelText = "Click on me to remove fake discount"
   const afterLabelText = "Click me to apply fake discount!"

   const state = new WeakMap();

   class CustomElement extends HTMLElement {

    connectedCallback() {
     this.render();
     this.shadowRoot.addEventListener('change', (event) => {
      state.set(this, event.target.checked);     
      this.render();
     })
    }
 
    constructor() {
     super();
     this.attachShadow({ mode: 'open' });
    }

   
    render() {
     let isChecked = state.get(this);
     const discountText = isChecked
      ? afterDiscountText
      : beforeDiscountText;
       const labelText = isChecked
      ? beforeLabelText
      : afterLabelText;
     this.shadowRoot.innerHTML = `
      <input
       ${isChecked ? 'checked ' : ''}
       type="checkbox"
       id=${CHECKBOX_ID}
      >
      <label for=${CHECKBOX_ID}>
       ${labelText}
      </label>
      <div>${discountText}</div>
     `;
    }
   }

   customElements.define('custom-element', CustomElement);

  </script>

Load all resources with fetch(), store to cache by yourself, take the response, clone and transfer into anything that can be sent with postMessage()

I use Safari User Stylesheet. This is mine:

  /* "custom" */
  [class*="as-oil"]:not(body, html),
  [class*="optanon"]:not(body, html),

  /* "generic" */
  [class*="consent"]:not(body, html),
  [id*="consent"],
  [class*="gdpr"]:not(body, html),
  [id*="gdpr"],
  [class*="announcement"]:not(body, html),
  [id*="announcement"],
  [class*="policy"]:not(body, html),
  [id*="policy"],
  [class*="cookie"]:not(body, html),
  [id*="cookie"] {
   display: none!important;
   visibility: hidden!important;
   transform: scale(0)!important;
   opacity: 0!important;
   width: 0!important;
   height: 0!important;
   z-index: -1!important;
   background: transparent!important;
   color: transparent!important;
   font-size:0!important;
  }

Yep, you are correct about generic truthy. We have standard library function empty(), which is custom (agreed internally what is empty) and which everyone knows. That solves many issues you pointed.

Probably bad ;-) Seriously speaking all that comparison tables are pure academic stuff. In real code I honestly ever encountered a case where I have no clue whatsoever what both sides of equation are. To the claim that when you have such conditions, then you need to fix that and such code is bad to the bones. Real life code is much more boring - if (a == “b”) where there is no value possible for a where === would give different result. But, I like to alleviate that there is no beef for me in this discussion, i just wanted to show that, yes, someone still uses == and he is not looney ;-)

Disagree. Nothing clever in this, just elementary JS knowledge. I claim that relying in types in dymanic language (always ===) is actually worse. Better is not rely on types.

We fully embrace Javascript as dynamically typed language and when one does this, types on most cases will become irrelevant. Then also using === in the code means that the usage is explicitly required in this specific place and == will cause wrong result. But when === and == are the same, then we use strictly ==. Also read this: http://dmitry.baranovskiy.com/post/typeof-and-friends

If you are curious, please post some real life real working code where in your mind usage of === is absolutely needed and I try my best to explain how I would tackle that with ==.

Yes. In our codebase it is forbidden to test for true/false, only truthy/falsy is allowed. The only place where === is needed and allowed is testing for if function argument is omitted. Otherwise == and yes, all developers understand that and agree and no, we haven’t had any bugs because of that. Big and complex web app, not my first, the previous gig was even bigger, same approach. Works like a charm.