allover

21 ms·

151.
by allover 9y ago
> Using let instead of var still breaks a few browsers. I want to move to modern javascript without the babel requirement It seems unreasonable to me to expect to run new language features on old runtimes, do you have a good reason to no
152.
by allover 9y ago
> Go's dependency management story is starting to resemble JS's modules story It's worse tbh. npm was actually always usable if you knew what you were doing. Complaints with npm were generally down to misunderstanding, peo
153.
by allover 9y ago
> Oh. And many remember Dart being optional-typed (like Typescript). So? Some could argue it's a very productive approach.
154.
by allover 9y ago
That's your opinion, but I spent weeks with the Clojure book and various exercises and could honestly never get past the syntax. Because of this I have zero interest in working with a lisp day-to-day, but there are multiple C-style lan
155.
by allover 9y ago
Am I right in thinking the main reason not to do this is memory safety (as demonstrated by Cloudbleed)?
156.
by allover 9y ago
First I'd heard of dva [1] (#6 in the frameworks section), interesting that it eases use of redux-saga as well as the usual abstractions over redux. redux-saga has been something I've avoided after initial evaluation (I also avoid
157.
by allover 9y ago
You'll always find a counterexample for 'it never hurts', it's a turn of phrase.
158.
by allover 9y ago
I have no investment in this username, so I wouldn't care. And "significantly depended upon" doesn't make sense in your example, but is relevant in terms of a package in a registry.
159.
by allover 9y ago
I'm not arguing what's legal. If your package name is a trademark, thinking you're entitled to hang on to it is naive. This is well understand with domains, so why do you think a package registry should be different?
160.
by allover 9y ago
> NPM shouldn't scare you. >> It absolutely should, just like any dependency on any other third party code or servers There's no need to be scared of any of those things if you understand the trade-offs and risks. >&gt
161.
by allover 9y ago
> and their behaviour up until now slightly suggests the opposite. Please elaborate. Afaik 'kik' wasn't significantly depended upon, and people using the old kik could still install it [1] (had the leftpad author not unpub
162.
by allover 9y ago
> but that's no reason for NPM to have dangerous policies. Oversight != 'dangerous policies'. Seems like they thought they had this fixed.
163.
by allover 9y ago
NPM shouldn't scare you. Simple fact is you should not be relying on ANY package registry at the time of deployment.
164.
by allover 9y ago
> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. You can as long as your package name isn't trademarked or likely to confuse users installing the package. >
165.
by allover 9y ago
This project isn't a library though, it's a gist. Author says it's to remind them how to hook things up.
166.
by allover 9y ago
> We should always try to strive to lower dependencies when it makes sense. Maybe, but I think 'when it makes sense', might be 'rarely'. There a 2 ways to avoid dependencies: 1. lean on a batteries-included standard l
167.
by allover 9y ago
> As someone unfamiliar with NPM, why does it not lock package names for a certain period of time? From [1]: > With the default registry (registry.npmjs.org), unpublish is only allowed with versions published in the last 24 hours. If
168.
by allover 9y ago
Disagree, it was mainly a wake up call that npm shouldn't allow package deletion, a policy they changed as a result. Every other 'these kids and their dependencies' opinion over the left-pad incident was highly subjective.
169.
by allover 9y ago
Well they aren't mutable/replaceable, at least not since after the left-pad incident where npm announced new rules to prevent package unpublishing. It seems this was a operational bug at npm inc.
170.
by allover 9y ago
Reddit thread you linked is about basic text selection via touch. GP is talking about text selection using an attached/bluetooth keyboard.
171.
by allover 9y ago
> Don't do this: > module.exports = IPFSDropzone > Do this (and change documentation accordingly) > module.exports = {IPFSDropzone} Why? Exporting a single class for this kind of lib is preferable. I'd do:
172.
by allover 9y ago
> ... and then proceed to explain why that's exactly what they did. Well they didn't, because "[...] to drive customer upgrades" is the key part they state they are not doing. > lied so blatantly about planned obs
173.
by allover 9y ago
np!
174.
by allover 9y ago
Yes! Perfect example, added to my comment :)
175.
by allover 9y ago
For things like auth/signup/forgotten-password flow I'd agree I've been more productive with server-side frameworks than client-side, and the out-of-the-box solutions for those things from Rails/Django feel more sol
176.
by allover 9y ago
Tip: To fix your CSS, you're using Bootstrap but you're missing any '<div class="container">' or '<div class="container-fluid">'. One of those around your outer 'class=&quo
177.
by allover 9y ago
Yep (including Echo Show etc).
178.
by allover 9y ago
> You could say that this is our fault for "doing it wrong" Do you have decent test coverage and use tox to run your tests against multiple versions of Django? If not I can recommend this approach from experience.
179.
by allover 9y ago
Functional 'concepts' are not niche, but functional languages still are. If you asked your average Java 8 programmer or JS programmer to write an app in Haskell or Elm, they'd struggle.
180.
by allover 9y ago
And hyperHTML [1] that preceded it and has near identical API. [1] https://github.com/WebReflection/hyperHTML

More ›