DEV.to Icon

DEV.to

Where programmers share ideas and help each other grow.
dev.to • 22 Stories
All Sources

Fred K. Schott DEV.to

A future without Webpack

We continue to use bundlers even though ES Modules (the new JavaScript module system) runs natively on the web. Why?

Over the last several years, JavaScript bundling has morphed from a production-only optimization into a required build step for most web applications. Whether you love this or hate it, it’s hard to deny that bundlers have added a ton of new complexity to web development – a field of development that has always taken pride in its view-source, easy-to-get-started ethos.

Related ~> JS Party #69

DEV.to Icon DEV.to

HTML can do that?

10 cool things you can achieve with nothing but HTML. They don’t all work well (and they don’t all work in all browsers), but the big takeaway here is that you should know the capabilities of the tools you’re using before you layer another tool on top.

Manuel Bieh DEV.to

I will now charge my clients a fee to support open source projects

Manuel Bieh:

As an independent Freelance Developer I was wondering how I can support the Open Source community… so I had this idea: starting with my next project I will ask my clients for an hourly rate that is 1 Euro higher than I originally negotiated or I would usually charge. I will take that money (up to ~160 Euros per month) and support those projects on Open Collective that I’m basing my work upon in my client’s project.

I like the spirit of what Manuel is doing here, but I’d suggest a slightly different tactic: raise your rate by N euros/hr (where N is at least 10) and give that to open source maintainers whose software you use on the client’s behalf. No need to complicate the client relationship with additional line items or things to explain. Besides, you’re probably under charging as is. Most of us are…

Rich Harris DEV.to

Why Rich Harris doesn't use web components

Rich kicked the proverbial hornet’s nest yesterday. After you read his 10-point post, stick around for the comments, many of which rebut one or more of those points. I’ll weigh in on #3: Platform Fatigue

Every time we add a new feature to the platform, we increase that complexity — creating new surface area for bugs, and making it less and less likely that a new competitor to Chromium could ever emerge.

Co-sign! 💯

Kevin Ball DEV.to

Let’s talk testing: 4 quick lessons on the philosophy of testing

Inspired by JSParty #70, 4 quick lessons on the philosophy of testing. The motivation?

Tools like Mocha, Jasmine and Jest have made writing tests far easier… But there’s still a gap. It’s extremely hard to find information on the philosophy of testing. What to test and why. How much is enough? What type of tests should I be writing, and when does it fit into my process?

Liran Tal DEV.to

How to securely build Docker images for Node.js

Liran Tal:

Developers, often lacking insights into the intricacies of Docker, may set out to build their Node.js-based docker images by following naive tutorials which lack good security approaches in how an image is built. One of these nuances is the use of proper permissions when building Docker images.

To minimize exposure, opt-in to create a dedicated user and a dedicated group in the Docker image for the application; use the USER directive in the Dockerfile to ensure the container runs the application with the least privileged access possible.

Jonathan Carter DEV.to

In pursuit of enjoyable developer collaboration

Jonathan Carter, in a deep-dive on the why (and how) behind Live Share:

When we set out to build Visual Studio Live Share, we learned that teams collaborate in very diverse ways, with unique and meaningful perspectives about how it works most effectively for them (e.g. frequency of collaboration, session duration, whether it happens ad-hoc vs. scheduled).

Interesting insights, excellent collaboration feature. 👌

In pursuit of enjoyable developer collaboration

Nikita Sobolev DEV.to

Best engineering practices: how to fix a bug?

This is a great article that covers the 🐛 gamut:

  1. spotting bugs
  2. reporting bugs
  3. reproducing bugs
  4. fixing bugs

I love the “lifehack” snippets Nikita sprinkles in as well. Like this little gem right here:

Lifehack: sometimes you might want to submit a broken code to your branch so it will trigger a CI build. After the build, it will be saved in your project. And your colleagues will be able to link to this problem. Your next commit will have to solve the issue.

Andrey Sitnik DEV.to

How a month without computers changed me

Andrey Sitnik:

No emails left for me to read. Nor write. I’ve sent a message to my family and delegated my open source projects (Autoprefixer and PostCSS) to my friends. With my last tweet sent, I turn off my laptop, phone, and tablet. My Digital Sabbath begins in 10 minutes: no digital devices for the next month.

An absolutely fascinating read. You can visualize Andrey’s digital sabbath on his GitHub contribution graph 👇

How a month without computers changed me

Sam Thorogood DEV.to

Shipping PWAs as Chrome extensions

Have you considered using a PWA to create a Chrome extension?
Sam Thorogood writes on Dev.to:

So you’ve built a PWA, created your service worker, and followed all the guides. In my case, that is Emojityper: a simple PWA where you can enter words, and receive emoji. This is perfect for desktop and entering emoji in editors that don’t support them.

But once you’ve built this great experience, you’re not limited to distributing it only on “the web”. In this post, I’m going to detail how I shipped Emojityper as a Chrome extension, accessible via a browser action.

Ali Spittel DEV.to

Extreme makeover: code edition

Ali Spittel lays out 7 excellent tips for writing cleaner code.

  1. Use descriptive naming
  2. Functions should do one thing well
  3. Comments should tell the “why”

It’s imperative to first learn rules like these, follow them for awhile, and then (and only then) you will be equipped to know when (and when not) to break the rules.

Henry Zhu DEV.to

I wasn't ready to become the maintainer of Babel

I wasn’t ready to become the maintainer of Babel. After all, I had never published my own npm package or explored much of the codebase. But slowly (sometimes really slowly) I got used to it. I recall Kent C. Dodds saying that if you want to be a maintainer, just act like and do the things a maintainers does.

Sounds easy enough 🤣. I particularly enjoyed the linked post on imposter syndrome from Rachel Smith.

Nikita Sobolev DEV.to

I am a mediocre developer

Nikita Sobolev outlines why they’re a self-described “mediocre developer” and how they survive in such a state. What follows is a bunch of excellent advice on practical steps toward success as a developer.

Ironically, Nikita’s self-professed mediocrity and clear path toward defeating it makes them an outstanding developer in my eyes. 🤩

Go and do likewise.

DEV.to Icon DEV.to

Linked Lists — a BaseCS video series

Vaideji Joshi has teamed up with our friends at dev.to to produce an awesome educational video series to accompany her awesome CodeNewbie podcast of the same name.

The first series is on Linked Lists. Here’s the pitch:

You might have heard about linked lists, or you might think that you’re supposed to know about them. Maybe you do know a little bit about them, but don’t know why you should care or why they matter. Either way, I want to tell you about why they’re so cool.

More like this, please! 🙏

0:00 / 0:00