at $WORK we have swapped to Rollup for most of the browserland stuff I work with because it’s so much less headache, the entire codebase is grokable, and you can trivially extend it to do custom stuff if needed.

I do agree bundling is problematic, but for me the worst part is Babel. I’d rather write ES5 than work with Babel and their constant breaking changes everytime I upgrade something.

I seldom do front-end work, but bundling is my biggest frustration. Yeah, how come I do what I think is the exact same set up for a new project, and webpack fails me. Sometimes I yarn a particular version, it works, sometimes it doesn’t. Sometimes install –dev sometimes not. Eventually get the new project working, but never know how. Repeatability seems illusive.

Parcel has been nice to work with wrt packaging

very astute observation. The whole build pipeline for non-trivial webapps is just slightly better than the world of no-packages (eg like C++).

FB’s metro perhaps is also not a panacea, it does not let me, for example, have source files in directory folders I want (instead it is tied to node’s source file search algorithm).

From the outside, I have a bit of trouble even understanding what bundling is all about. What does Webpack to that Grunt doesn’t? And then, what does Grunt do that make doesn’t?

Well, package-lock.json would contain references to internal libraries as well, potentially giving npm a way to track down new customers for enterprise offerings (to replace artifactory and similar.)

Yeah, that’s the first thing that comes to mind. If I make a proprietary tool that replaces/augments an open source solution, or if I sell consulting services for a particular tech stack, being able to buy instant lists of potential customers sounds pretty useful.

Getting the house back under control (5 year old + 4 year old + 7 month old + wife’s injured ankle mean I need to put some extra work in there!)

Dude, just let it go, ‘cause it’s gone. You can look forward to having a clean house again in about 18 years. ;)

One man’s “clickbait” is another man’s succinct summary.

I disagree. I find Edward Tufte’s website basically unreadable.

Problems that I have reading it

• Two giant images advertising courses at the very top, taking up most of my screen
• Body of content is actually pictures, not text
• Body has multiple columns and jumps between layouts making it hard to follow
• There are slides embedded with tiny print in the references column
• The block quotes are in a smaller font than the surrounding text
• Where does the content for “PowerPoint Does Rocket Science–and Better Techniques for Technical Reports” end? This page is so tall that Superman would have trouble leaping over it.

I’ve now read the original. This summary is far, far better.

The original puts the emphasis on a particular way of constructing high information low comprehension slides, with all the nesting layers, and titles only those opposed to decisions could love. That’s not a problem just with PowerPoint.

The original cites this way of thinking as the reason PowerPoint always sucks for technical content. He is wrong. PowerPoint “simply” has to be used with low density slides. He is right: I won’t read a dense side now or ever. That doesn’t condemn all PowerPoint presentations.

I think this slide alone could have been just 3 bullet points, with no sub points. And it could have made the important point that had to be made.

The problem is not with any particular tool. It’s with engineers failing to communicate what they clearly know, and are trying to say. The summary focuses on the slide design and why it sucks, and that’s why I prefer it.

the simple fact of the matter is firefox and chromium are the only browsers I can reasonably test against as both can be run heedlessly and controlled by something like selenium.

There used to exist a SAAS tool (hehe) for testing layouts across multiple browsers. Don’t know if it still exists and if it supports modern js-heavy sites thought.

That said, as I pointed out in the post: if you actually test in Firefox it will typically also work in Chrome and other browsers.

The simple fact is, competent websites run on any browser because competent websites don’t use weirdo bizarre technologies like ActiveX or whatever the modern equivalent might be. Toy websites might get away with only supporting the specific software setup on the author’s desk, but websites which support people using assistive technologies, people in the Third World, and, most importantly, people trying to give the website owner money will be as accessible as possible, for much the same reason Walmart doesn’t install a ten-foot freeclimb wall in front of their main entrance.

My guess is it’s because the number of days in a month or year can vary, but the number of months in a year is fixed. getDay is also fixed (day of week) and is also 0-indexed.

Java as well. I believe JS copied the behavior directly.

The JS APIs were thrown together (along with the language and implementation) by Brendan Eich in ~10 days.

There wasn’t a lot of time for careful thinking - it had to ship.

It shares this behavior with (among others) Perl, which gets it from C:

https://perldoc.perl.org/functions/localtime.html

https://www.tutorialspoint.com/c_standard_library/c_function_localtime.htm

At least in Perl’s case it’s easy to map an integer from localtime’s month to a list of month names (as mentioned in the documentation). Same goes for day of week.

Days of the month in Western calendars are generally not referred to by name (at least not since the French Revolutionary calendar) so not having to add +1 to it each time they are referenced is helpful.

The problem in the JS world is npm itself. npm by default will actually upgrade packages when you run npm install even when the package.json or package-lock.json have a version specified.

Semver uses 3 .-separated decimal numbers. -rc3 isn’t semver.

There’s also ConVer (content versioning) which uses git commit hashes, although the fact that I can no longer find a link to the site/article probably speaks to how popular that idea is.

In practice, the answer to those questions is no, and earlier respectively.

And there is work on making those things official: https://words.steveklabnik.com/what-s-next-for-semver

SemVer#11 lists the ordering. >= 2.7 is not satisfied by either of your examples. As for their ordering, 2.7-rc.3 > 2.7-beta.1, as specified by SemVer.

yeah, the small files problem was more relevant in 2016

It’s not as big of a problem if you know all of them up front. But ES modules don’t let you know this without using a bundler or bundler-like tool. See this post for why http/2 doesn’t solve the problem: https://engineering.khanacademy.org/posts/js-packaging-http2.htm

…What?

What’s stopping you from using pipes in your Makefile? Or delegating to bash scripts?

It would be interesting to see a version of make designed to work with streams. It could work quite nicely.

My experience is the opposite: I switched away from gulp to rake and cut build times to a tenth of what they were. I’m also building on a 16-core machine, and taking advantage of the parallelism in rake/make.

Gulp/grunt/broccoli/webpack/etc all feel really foreign to me, but DAG-based build tools feel like home.

For those like me who have no idea who any of these people are: care to expand?

Quite aside from which, ‘is guilt by association suitable grounds for exclusion from lobsters’ is far from a settled question afaik.

…and you drive an SUV so even if you say something interesting nobody should be allowed to listen, and your wife eats meat so she should be shunned, your best friend went on a long flight to some sunny destination so ban him, his wife has her money in a bank which invests in nuclear energy so make sure she never gets a job, etcetera.

These discussions can an should be had in a different context. If Synk did something onerous by all means take them up on it but don’t do that by calling out the mob on and trying to create pariahs out of everyone and every institution which does not fit your moral standards as all that leads to is a balkanised society.

I have no idea what you’re talking about, and searching didn’t turn up any results. If you’d like to have me not submit their stuff in the future, at least a little bit of evidence would be nice.

Double equals stands for “loose equality” rather than “structural equality” in JS; all it does is cast the values to a common primitive type before comparing.

Double equals and triple equals both evaluate to false for that comparison. Object comparisons are by reference, not by the contents of the object. And each side is a separate instance of Object.

The 2nd we know of.

Do you happen to have a link to the other announcement handy? We use Flow at $WORK and today I had a great time banging my head against the wall because it was both not happy with me adding a custom matcher in Jest so that internal DateRange type tests would produce some better failing output and also had to be instructed to not freak out about jsverify so that the aforementioned tests could be property-based.

And documentation for Flow built-in types like $ReadOnlyArray simply not existing is its own level of awfulness and.. if a bunch of high profile projects are missing maybe I can get leverage to push for Typescript internally, too.

The ability to crack open and get at private members has saved people’s butts on numerous occasions. I’m not really sure why it’s needed to add a private field mechanism, unless they’re just continuing to roll up features from other languages.

That was my initial reaction as well, but the rationale made perfect sense after I read the FAQ on the subject: https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md

If it makes you feel better, people will still worry more about minifying their production code while doing stuff like that.

Hmm. It’s pretty reasonably sized on mobile. I guess Medium just makes it scale up until it’s wide enough to fill the browser width?

CSS has a lot of positive qualities but it is just plain wrong that CSS allows you to write scoped rules. It’s biggest pain point is the global nature and handling this at scale requires careful discipline and perfect adherence to a methodology.

Shadow Dom helps but comes with it’s own set of challenges around compatibility, understand-ability.

One good alternative which I think sits between CSS-in-JS and humans following naming conventions is having identifiers generated and checked at compile time, if your tech stack supports it.

Yesod/Shakespeare does this quite nicely, and I’ve been leaning on this quite a lot lately. To give an example from a project I’m working on, here’s some backend code which generates random identifiers and gives them names we use to refer to them with:

footer :: Widget
footer = do
  cityscapeClass <- newIdent
  finePrintClass <- newIdent
  $(widgetFile "footer")

In your markup, you have something like this, where we use those identifiers:

<.#{cityscapeClass}>
<p.#{finePrintClass}>Some fine print text here

And then in your stylesheet, the same idea:

.#{cityscapeClass} { /* styles.. */ }

.#{finePrintClass} { /* styles.. */ }

This gives you some sanity checking that the selectors match in all places (also works in JavaScript [named Julius]), and it also allows you to remove dead styles which is a problem I know I face when writing normal CSS. I’m never sure if I’ll break something by removing some CSS, so it just lingers. This approach also means all the style stuff doesn’t have to go through the JavaScript interpreter.

Also, I agree the author is being overly dismissive. CSS has its own set of challenges, and there’s nothing wrong with exploring ways to mitigate those challenges. The debate these days seems to be mostly between people who don’t know CSS and refuse to learn it, and people who do know CSS but refuse to learn anything else. But, that’s anecdotal and probably super biased.

There are places one hour outside of Washington D.C. that don’t have access to broadband internet at all.

Perhaps it’s not surprising coming from the author of a site which presumably makes money by educating people on “tricks” to make CSS work.

FYI, the article author is not the site owner, and appears to just be contributing an opinion piece.

This is what I have as well. The build quality and aspect ratio are fantastic, and since I’m the rare developer who prefers Windows it’s a perfect fit for me. I don’t use the pen all that often, but it’s handy for annotating screenshots occasionally.