I'm not sure why, but VSCode still doesn't feel comfortable to me. I suspect it's the best option for TypeScript and I'm missing out.
I'm really interested to try Panic's Nova. The Electron based editors have some amazing features, but I miss having a native editor. The last native editor I used was Chocolat (: https://chocolatapp.com/.
In my experience, the main difficulty is identifying, classifying, and documenting the cookies that are used... and then updating the codebase so that they are only set once the visitor has opted in. This is especially difficult when Google Tag Manager is involved, and/or swathes of tracking scripts have recklessly been bundled in over the years.
Projects and services that tout "automatic cookie consent with minimal config" are extremely frustrating, because they hide the actual issue. Implementing a cookie consent UI is itself not a particularly difficult task.
This looks great. I was looking for a replacement for Siema (https://pawelgrzybek.github.io/siema/) just yesterday (it's no longer maintained and has a few limitations). I think I'll try Embla out on a project I'm working on at the moment. Thanks 🙂.
The content at this URL will never be updated because [now](https://now.sh) issues a new subdomain for every deployment (which is pretty cool, but may mean this is out of date).
I *assume* the URL in the [readme](https://github.com/ReactTraining/react-router/tree/v4) is more up to date.
Ah yes, I remember that episode of JSJ. UMD makes perfect sense for something like Lodash, where ease of use and portability is really important, and (I don't think) external dependencies are involved*.
For most modules I've worked on, having npm manage dependencies, and being able to easily consume these is a huge advantage. As far as I can tell this approach doesn't work with UMD (again, please correct me if I'm wrong).
So I just don't see it as an approach I would want to use unless:
- Supporting all environments is critical
- The module doesn't have any external dependencies
I definitely lean in the direction – probably ignorantly – of just use CJS.
* I've only skimmed the Lodash source, I should take a closer look when I get the chance.
Is it really that straightforward, though? Making your CJS module compatible with AMD, or vice-versa, surely complicates your implementation. I have certainly experienced issues consuming cross compatible modules that just don't seem to be tested properly with my target module system.
I also assume (please tell me if I'm wrong) that by making my modules AMD compatible, I'm locked out from all of the dependency management goodness that comes with CJS and npm.
n.b. As somebody that has always steered clear of AMD, this is totally uniformed. The ambidextrous UMD approach sounds perfect, but really seems to complicate things. But I would love for someone to school me on my misconceptions (:
I think it is to reduce frivolous upvoting. Ascribing a cost to upvoting means users will be more choosy with what they upvote – similar to downvoting on SO.