Sorry for the Kumu 500s! I moved some critical parts of our service away from EC2 classic on Saturday morning. One of our servers was accidentally recreated with an 8GB volume instead of 1TB and the HN hug caused a process to blow through the remaining disk space with indexes. Should be back to working order now!
This feels a lot like Vim's built in file explorer (netrw).
I find these kinds of text based, keyboard centric explorers to be far superior for navigating around a codebase, then giving you back your screen space as soon as you're found what you're looking for.
Building network & viz tools for tackling complex problems.
React, TypeScript, Rails, Node, Postgres, CouchDB, AWS. We're currently undergoing an ambitious modernization process for our main codebase, and looking for engineers who like a challenge.
Bonus points if you're happy getting your hands dirty with AWS, Linux, and virtual machines.
We're a small and flexible remote team who place a lot of value on physical and mental health, great lifestyles, and doing meaningful work.
Looking for enthusiastic developers to help us build tools for tackling complex problems.
React, TypeScript, Rails, Node, Postgres, CouchDB, AWS. We're currently undergoing an ambitious modernization process for our main codebase, and looking for engineers who like a challenge.
Bonus points if you're happy getting your hands dirty with Linux, Packer, and virtual machines.
We're a small and flexible remote team who place a lot of value on physical and mental health, great lifestyles, and doing meaningful work.
Doesn't feel unreasonable to conflate the two. npm is the dominant way to handle dependencies for frontend and backend, even some of the most popular script-tag delivery CDNs are powered by npm (unpkg, skypack).
Why is it great to be able to publish a package quickly? You may be a smart programmer who only releases production quality, bug-free, vulnerability-free code, but is it a good thing that it is easy for inexperienced developers or malicious users to be able to publish packages at the same ease/speed?
No one wants an ecosystem with only jQuery, but there's a middle ground somewhere before you get to 2 million packages. Competing frontend frameworks fit comfortably within that space. I just don't want a world where there are 16 competing packages that all implement a slider in React.
There's a huge difference if you only use npm for personal projects, too. The consequences of picking unmaintained/undocumented/insecure/buggy software are much, much lower if you can afford to rewrite/throwaway in a weeks time.
I don't think we talk enough about the downsides of DRY.
Reinventing the wheel for the sake of reinventing the wheel (not-invented-here) is a problem, but reinventing it for the sake of learning more about wheels is a big deal.
I suppose many developers reach for libraries because they're more confident that the libraries will implement things correctly/more efficiently than they could. But if they keep reaching for libraries (instead of trying to write an `isEven` function themselves) then they never really improve either.
> Give better cues that we are in an asynchronous mental model
The `async` keyword(!) is objectively a clearer signal that the code in question is asynchronous. That's why type-checkers use it to prevent you from doing dumb stuff like awaiting in a synchronous function.
> In simple cases express the code at least as cleanly as async/await
It's pretty hard to see much of an argument here. How can the promise version ever be seen as "at least as clean"?
await someTask()
// vs
someTask().then(() => ...);
Even beyond the syntax here, the promise forces you into at least one level deep of nesting, which instantly makes it much trickier to manage intermediate variables, which either need to be passed along as part of the result (usually resulting in an unwieldy blob of data) or the promises need to be nested (pyramid of doom) so that inner callbacks can access the results from outer promises.
> Provides a much cleaner option for more complex workflows that include error handling and parallelisation.
If you've somehow come to the conclusion that `Promise.all` doesn't work with `async/await` then you have probably misunderstood the relationship between `async` functions and promises. They're the same thing. Want to parallelise a bunch of `await` statements? You can still use `Promise.all`!
I do occasionally find try-catch to be awkward, but that's because it creates a new lexical scope (just like promise callbacks do). I also think the consistency from having one unified way to handle errors in sync/async contexts justifies it.
My take is that the lack of experience for the average JavaScript developer is absolutely a factor here. I don't think it's the only factor though. Here are some of the other pieces of the puzzle.
JavaScript's standard library is so thin on the ground that there's already a culture of "reaching for a library" to accomplish tasks that many languages do out of the box.
The monoculture is wide enough that the language caters to lots of paradigms and schools of thought. If there's one library that uses classes and method chaining, you can be sure that another will pop-up to re-implement the same functionality in a pure functional style. One will focus on type safety and another will abuse the dynamic bits of the language to make the code you write as terse as possible.
Amount of code shipped has always been a more important metric for JS than other languages because the nature of the web means that users have to wait whilst the source code is downloaded before your page becomes interactive (for a huge class of applications). This encourages developers to favour smaller libraries that solve for narrower problem domains.
It's become very trendy to write a smaller, faster, better, smarter version of existing libraries. The JavaScript community loves the process of picking a catchy name, registering a domain, designing a logo, and publishing packages as though they were businesses. This creates an abundance of packages that look great on paper, but with no users, patchy/non-existent tests and maintainers that haven't ever used the code in a professional context.
Finally, I think JavaScript is a deceptively simple language. It doesn't take very long before people (mistakenly) think they're close to mastering the language. By comparison, contributing to an open source project in a meaningful way is quite difficult, so these developers assume that other libraries must be written badly if they find it hard to contribute. Then they write their own, because they believe they can do a better job.
The ecosystem as a whole sees a lot of innovation, and pays for that with a lot of churn and a lot of dependencies. From a theoretical standpoint, it's a fascinating corner of modern programming. In a professional context, it horrifies me and I wish I could sanely cut npm out of the chain.
Also a climber, and occasional soloist. You can absolutely make a bad move on a solo and not die.
The soloists who achieve notoriety are either pushing the limits, or seeking adrenaline, which skews the stats, especially when you check the number of them that passed doing non-climbing activities. It's not particularly fair to compare that demographic to the average folks who bike in traffic every day.
Soloing well within your limits is like riding a bike on a quiet road, there are things that can go wrong, but something extraordinary has to happen for it to be serious.
Soloing close to (or outside of) your limits is like riding a bike on a busy motorway. The margins for error disappear and mistakes are far more likely to be fatal.
I don't know of a JavaScript implementation where that approach would work. A synchronous implementation of `sleep` can't yield control back to the main thread to handle the asynchronous stuff. You'd just end up polling indefinitely.
Go watch Jorbs play (the author). In particular his "over-explained" runs on YouTube are good for getting in-depth breakdowns.
There's a bit of an unavoidable learning curve initially in learning the cards in each deck, because so much of the strategy comes down to analysing what your deck can currently do, and what adding (or not adding) a card to it will change.
That wasn't supposed to read as a criticism of Redux. Redux was just popular enough to be the medium where people discovered that you pay a price for the indirection you need to keep view and state separate.
It won't ever be a one-size-fits-all solution and unfortunately, Redux will have to live with the legacy of plenty of users finding that out the hard way.
That being said, I think Redux Toolkit is a great improvement to the vanilla experience and I'm always impressed by how much I see you out and about on the internet weighing in on these kinds of threads. Inspiring stuff!
I would go one step further and say that the counter-movement is the visible effect of newcomers discovering that separation of concerns was a bad decision for the simple apps they were building.
Or maybe more accurately, discovering that it's often simpler to separate by concern at the component level, than at the app level.
We all ride the pendulum until we find the shade of grey which works best for us.
Maybe overwhelming was too strong, but I don't see many people getting excited about building new projects with Redux any more. Presumably some proportion of that 1/3 are stuck on Redux, unwillingly?
I like (and use) Redux on a daily basis, and I don't think it's a sensible choice for lots of React apps. Maybe the overwhelming rejection that I've witnessed is people discovering that they used it for stuff they shouldn't have.
The React ecosystem has spent the last few years trying a model where the application layer separated from the view layer with a pure functional state management solution called Redux. The overwhelming response? People didn't like it.
Decoupling systems is a trade-off. Pull your network requests out of your components and you have two bits of code that are easier to test. Indirectly, the component is still going to call that code, and it's up to you to manage the complexity of that indirection.
Not every application needs separation of concerns, and in many, colocation of concerns reduces the cognitive burden, because you can reason about components in isolation. To me, that's a more powerful guarantee than a function being strictly pure.
Kumu | Kumu Enterprise Developer | https://kumu.io | REMOTE | Full time |
Kumu is a data visualization platform that helps people understand complex relationships, primarily through network, systems, and stakeholder maps.
We’ve worked with some of the world’s top organizations including The Omidyar Group, Gates Foundation, Hewlett Foundation, USAID, Stanford ChangeLabs, 100Kin10, Democracy Fund, World Bank, Humanity United, and more.
We're looking for an experienced developer to join our team to lead development on Kumu Enterprise, a parallel release of our product that runs in on-premises virtual machines.
Experience with Linux, Packer, VMWare and AWS is ideal. Bonus points for experience with (or willingness to learn) Rails, React, and TypeScript, for working on the product itself.
We're a small and flexible remote team who place a lot of value on physical and mental health, great lifestyles, and doing meaningful work.
Kumu | Kumu Enterprise Lead Developer | https://kumu.io | REMOTE | Full time |
Kumu is a data visualization platform that helps people understand complex relationships, primarily through network, systems, and stakeholder maps.
We’ve worked with some of the world’s top organizations including The Omidyar Group, Gates Foundation, Hewlett Foundation, USAID, Stanford ChangeLabs, 100Kin10, Democracy Fund, World Bank, Humanity United and more.
We're looking for an experienced developer to join our team to lead development on Kumu Enterprise, a parallel release of our product that customers run in virtual machines on premises, or on dedicated servers in AWS.
Experience with Linux, virtual machines, AWS, and an understanding of networking is expected for this position. Additionally experience with Rails, React, and TypeScript is a large bonus, for working on the product itself.
We're a small and flexible remote team who place a lot of value on physical and mental health, great lifestyles, and doing meaningful work.