segphault

VuePress pulls in nearly a thousand transitive dependencies. In light of recent security incidents[0][1] and the relative ubiquity of poor security practices[2] in the npm ecosystem, that seems like an unacceptably large attack surface.

I don't want to have to worry about somebody injecting malicious code or cryptocurrency miners into my website by compromising a little-watched transitive dependency in my static site generator.

[0] https://blog.npmjs.org/post/175824896885/incident-report-npm... [1] https://blog.npmjs.org/post/173526807575/reported-malicious-... [2] https://www.bleepingcomputer.com/news/security/52-percent-of...

I really like the idea of a non-intrusive analytics system that just shows you useful aggregate traffic data while maintaining the privacy of your site's visitors.

I experimented with using GoAccess (https://goaccess.io) on CloudFront logs instead of using Google Analytics. It gave me a lot of what I needed, without the overhead or intrusiveness of client-side code—and it provided a more complete view of my traffic because it isn't stymied by browser plugins that block tracking.

The downside was having to save the logs, periodically run it to generate reports, etc. It's not a lot of work, but it's more work than GA. I think CDN providers should just include managed analytics tools of this caliber as either part of the package or for a modest extra fee.

Off topic, but the totally pointless animated gifs in this article are distracting and made it painful to read. I don't understand why they felt the need to make an article about a serious topic look like a teenager's tumblr post.

It's an electron wrapper around the official Evernote web app, but with some color themes. Why do I want to use this instead of Evernote's high-performance native desktop client?

I really like the idea of declarative and machine-readable validation and API descriptions, but JSON schema is often pretty frustrating to work with in practice. Building a compliant implementation is quite difficult.

The $ref resolution, as defined in the spec, is hideously complicated, to the point where many implementations just don't even bother supporting external $refs. It feels like it really should be a totally separate concern from validation, especially since how you store and compose schemas may end up being somewhat specific to a given use case.

Also worth checking out Kni, an authoring language inspired by Ink but written in JavaScript, ideal for bringing this kind of content to the web: https://github.com/kriskowal/kni

Integrating nsp is a very welcome move. It's heartening to see npm taking the security issue seriously and taking steps to start addressing the problem.

That said, the problem remains largely cultural rather than technical. The community needs to make significant changes to how it consumes and publishes dependencies in order to reduce the attack surface. The massive, bloated dependency graphs that developers who use Node tolerate with cavalier indifference are not safe or sustainable in the long term.

You should consider using the window.history APIs to make it so that navigating your blog doesn't break the back button.

What I suspect is going to happen is that frontend people will just shrug and adopt the .mjs extension. Browsers don't care what extension you use as long as the mime type sent by the server indicates that the file is javascript.

> I've heard it said before that you're responsible for every line of code you ship to your users.

This is a great way of thinking about it. I wish that more people took it to heart when choosing third-party dependencies to adopt, especially in the Node.js ecosystem where people are tragically cavalier about adding literally hundreds of under-scrutinized transitive dependencies to their projects.

Santana Row is fantastic, I can imagine that it'd be a great place to live. That kind of mixed-use development is something that really ought to be more ubiquitous. It's worth noting that there are even companies, like Splunk, that have offices there. I considered living at Santana Row when I moved to San Jose, but I ended up a few miles further down Steven's Creek because I wanted to be closer to Diridon.

And you don't care if a malicious party compromises the development machine on which it runs? I can think of a whole lot of really damaging things that somebody could do running arbitrary JavaScript code with user-level privileges on thousands of developer workstations.

With various CI setups and some server-side rendering configurations, there are potentially scenarios where build tooling actually do run in environments where there are higher risks, though it's not as applicable in this specific case.

It literally just removes a line from the package.json file of one of the sub-dependencies: https://github.com/babel/babel/pull/5484

It's crazy to me that a package that is downloaded from npm over 4 million times a month gets so little scrutiny that nobody but me noticed a 5MB dependency on all of lodash that wasn't even being used.

689 packages is enormous surface area for a leftpad-like (or worse) failure. Given that nobody is auditing those packages and many of the people who maintain them aren't adhering to best security practices[1], I don't think taking nearly 700 dependencies that you are going to treat like a black box is a safe or responsible choice.

Xcode and the Android SDK each come from a single vendor who provides an integrated development stack and presumably vets the contents. Does anybody do that with these npm packages?

It seems like every time I run the du command in my node_modules folder, I find some crap that shouldn't be there. Earlier this year, I submitted a PR that reduced the size of the babel react preset install footprint by about a third, just by removing a totally unused dependency that nobody noticed. I don't think the contents of npm packages get nearly enough scrutiny and it scares the hell out of me.

[1] https://www.bleepingcomputer.com/news/security/52-percent-of...

With transitive dependencies, the total install footprint for this is 689 packages weighing in at 77MB.

This isn't reducing complexity, it's just taking all the junk you'd normally have in your bloated boilerplate and putting it directly into the build tool. I'm not convinced that's a good idea.

This pulls in over 200 dependencies, with a total weight of 37MB. I'll pass.

What this amounts to is an attempt to solve the challenges of monetizing open source software by no longer writing open source software. The encumbrances that this license places on the downstream modification and redistribution of code largely eliminate any of the material advantages that come from the code being open in the first place. This is a terrible idea.

Wait, what? The official React wrapper for Elements is on GitHub: https://github.com/stripe/react-stripe-elements

Really wish there was more momentum on adding a safe access operator. Even Ruby has that now, it's disappointing that we still don't have it in JS.

That gets me the exact same thing. And afaik what you get from --production is the default behavior when you install a package directly from npm.

So, I just did "npm install next react react-dom" which isn't bringing in next's development dependencies. Is there something that I'm missing?

Interesting concept, but it seems rather heavy. Installing it from npm pulls in over 400 packages, weighing in at about 60MB.

I'm also very interested in i3-style tiling instead of pre-configured layouts. I like being able to manage the splits more dynamically. I also really like i3's concept of hierarchies, being able to nest the splits. And being able to switch a particular group between tabbed and horizontal/vertical organization.

Regarding your $3 price for the paid version, I think you should be careful not to set the price too low. I happily paid $18 for the professional version of AquaSnap.

Facebook is the world's largest PHP shop. Does that mean that everyone should use PHP?

As it turns out, moving fast and breaking things isn't all that conducive to quality engineering[1][2]. Facebook has a massive legacy code base maintained by an enormous team that is under pressure to iterate quickly while supporting what is arguably the world's largest user base. They are dealing with extremely specialized constraints that most of us will never encounter. Many of the trade-offs they consider acceptable aren't trade-offs that make sense elsewhere.

And that's exactly what the blog post is getting at. A lot of these emerging technologies are situationally useful in a particular set of scenarios and environments, but developers with cargo cult mentality convince themselves that these things will solve all of their problems if they use them everywhere. When the disappointment sets in and they figure out that isn't the case, yesterday's darling stack becomes the subject of today's "considered harmful" essays and everybody moves on to the next shiny thing.

The point here is that maybe you should make a sober assessment of new technologies and objectively evaluate whether they are actually practical for your usage scenario rather than just blindly jumping on the bandwagon and using something.

The examples from the blog post are totally on point. I previously worked at a company that built a NoSQL database and I have great affinity for the technology, but there's no question that too many people adopted NoSQL databases without really understanding the trade offs. People want to be "web scale" so they go straight to using databases that are designed for high-availability clustering even when they are building applications that would be perfectly fine running forever on a single postgres instance.

[1] https://www.darkcoding.net/software/facebooks-code-quality-p... [2] http://blog.timac.org/?p=1707

> That issue you linked to is 4 years old and is clearly a reflection of the poster being unfamiliar with React/JSX

And yet the underlying issues still remain unaddressed. There aren't better ways to handle the cases raised in that issue, which is why people resort to adding additional non-standard syntax to work around the warts.

> Also, I'm not entirely sure what the do/while plugin has to do with JSX.

The "do" keyword is not do/while, it's a non-standard language feature that you can use to turn statements into expressions by wrapping them. It's like using an IIFE with a return value so that you can use a conventional "if" or "for" statement in place in JSX.

> I would argue if you can write your code as easily with template literals as React/JSX your application isn't complex enough to warrant using a framework.

I don't think you really understand how template literals work. Tagged templates can be used for more than just basic string interpolation. You can read more on the subject here: https://appendto.com/2017/02/advanced-javascript-es2015-temp... Or have a look at t7, which uses tagged template literals for virtual DOM templating: https://github.com/trueadm/t7

JSX is not JavaScript, it's a non-standard bastardization that will never be supported natively in browsers. Its reliance on JavaScript for flow control is so problematic[1] that people have started working around its many glaring inadequacies by adding new language primitives to JavaScript itself via Babel plugins[2].

I do my templating in template literals because using standards-based JavaScript means that I don't need 50MB of fragile packages from npm or a largely superfluous build step during development.

[1] https://github.com/facebook/react/issues/690

[2] https://www.npmjs.com/package/babel-plugin-syntax-do-express...

> And the other great thing about these tools is you can add/remove them as needed.

In order to get that freedom, you need to build the tooling in such a way that it aligns with the web standards, so that when the standards catch up you can drop what you don't actually need anymore. We all switched from coffescript to ES6 and Babel because ES6, being standards-based, will eventually be supported in browsers, right?

And yet, with JSX we have a gratuitously non-standard dialect of JavaScript that isn't on the standards track and will never be natively supported in browsers. So, even when browsers catch up and offer full support for modern ES6 syntax, we're still stuck with transpilers because Facebook thought it was a good idea to tightly couple their custom templating language to JavaScript itself instead of wrapping it in template literals, which is the standards-based approach that ES6 actually provides for embedded DSLs and templating.

Today, in Europe and North America, roughly ~85% of users run a browser version that has native ES6 support. IE marketshare fell off a cliff in 2016, and now IE11 is at less than five percent and still falling. I don't actually need to transpile during development today, and I won't need to do it in production either in a year or two, and yet everything written with JSX will need a transpiler forever.

There are a ton of great ideas in Vivaldi's user interface. And it's built on Chrome, so you still get all the standards and extension compatibility. They regularly add clever new features that materially improve tab management and navigation. I'm looking forward to making it my default browser at some point in the future when they add sync for bookmarks etc.

The conventions they use look like BEM, which is a relatively common approach for component-based design in CSS: https://css-tricks.com/bem-101/

I find the idea interesting, but the execution leaves much to be desired. I'm using it on Windows and some of the basic readline shortcuts don't appear to work correctly (e.g. ctrl+a is doing select all instead of moving the cursor to the beginning of the line.) It also doesn't seem to have any mouse support, like the ability to scroll or resize panes in tmux. There's a very real need for better terminal emulation on Windows, but this doesn't seem to deliver.