Markdown with Strapdown inclusion, a pastebin, a CMS, bare Bootstrap... anything would be more readable than this.
-13 karma · joined March 4, 2016
You can downvote me as much as you can but you will still not be able to escape the truth.
The most interesting projects are the ones that can fit into a gist, so check them out: http://gist.github.com/plugnburn/
Markdown with Strapdown inclusion, a pastebin, a CMS, bare Bootstrap... anything would be more readable than this.
I'm not against new concepts. Client-side rendering is awesome, reactivity is awesome. But I'm against all that bloatware. If a new concept can't be implemented without bloatware (hint: it can), we don't really need it.
But these things can and should be done in a different way. For example, all my JS stack (Z5 + DaBi) targets ES5 and is under 4 KB altogether. Yet it provides:
- DOM manipulation and auto-polyfilling some DOM essentials (only for the stuff that's really uncomfortable to do with native APIs - Q.js);
- reactive in-memory storage (with an ability to easily populate from external objects or remote requests - Zen.js);
- easy data-to-DOM and DOM-to-data binding (DaBi library);
- ability to easily build DOM and CSS styles from JS native constructs (XT.js and XS.js - never go through escaping hell again);
- client-side routing (R.js).
And while I agree that React/Angular are the bloatware (even jQuery is), I disagree that server-side rendering is any better and that throwing in another bloatware like ClojureScript would solve this issue. Like I had said in my article about client-side development (http://clientside.surge.sh/), go native or go home.
Edit to answer "how is it invalid": is this not enough? http://validator.w3.org/check?uri=http%3A%2F%2Fnews.ycombina...
git clone https://[repo]/[module].git node_modules/[module]
...and ability to provide dependency resolution along with custom runscripts?Yes, we can. Not a rocket science. How many paranoid freaks will actually switch to it - that is the question.
Besides Chinese origin of this CA, haven't found any caveats so far.
Free is better than cheap (at least in a way you haven't to disclose any of your real data).
weekDay = (dateObj) => ['Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday'][dateObj.getDay()]Even with such a strict check of the padding character length (with an exception) and a period by default it's a four-liner at most.
leftPad = (str, len, pd = '.') => {
if(pd.length !== 1) throw 'Invalid input'
else return Array(len > str.length ? 1+len-str.length : 0).join(pd) + str
}Why does someone has more right than me to decide what's offensive, smartass or spam? Either leave that to the administration, or give that to everyone.
> The problem with downvote for everyone, including sock puppet accounts, is it becomes Reddit: "I disagree, have a downvote"
YMMV but I'm experiencing absolutely the same here.
Btw, when I agree, I upvote. Why can't I downvote when I disagree?
It seems that in order to "earn" that "ability" one has to praise Lisp, Rust and Haskell and publicly hate JS. Isn't that mass conciousness manipulation?
The selected few or a crowd thinking the same thought - what's the actual difference? The only difference is that in the second case all fresh and independent ideas get downvoted much faster.
Any karma-based resource suffers from this plague.
Ochlocracy at its worst.
Why can't I use the downvote button? It either must be available to everyone, or not available at all.
And if you, HN founders, are afraid that newcomers can be smarter than you, then remove the ability to downvote altogether. Whoever dislikes a post, can just ignore it.
P.S. The entire user rating system here contradicts the resource name. Hackers do not believe in karma.
Unique IDs, no way to change or delete (since the gists are anonymous), served right out-of-the-box with a proper content type from cdn.rawgit.com.
isPositive = (x) => +x === x && x > 0
In which conditions does it return a wrong value? I haven't found any. isPositive = (x) => +x === x && x > 0
is boring. Need more requires to require the requires...Keep in mind though that absolutely not all JS programmers are like that. Not everyone wants to be an aforementioned Dick-from-a-mountain.
If third party modules are hosted on GitHub, you can fork them.
leftpad = (str, len, pd = ' ') => Array(len > str.length ? 1+len-str.length : 0).join(pd) + str
WTF are you talking about? Making this into a module?!
Any modern standrards-compliant implementation of JS (following ES5 and especially ES6/ES2015 standard) already has everything that a sane programmer would ever need.
When the developers of such a serious library as React start to depend on a third-party one-function module made by some Dick-from-a-mountain (a russian idiom that means a random person who did nothing significant but tries to show out in all possible means), that means React developers are even more to blame than that Dick-from-a-mountain himself.
If you make any really popular piece of software, you absolutely must have a failover plan. No excuses for not having it.
But what's even sadder is that this issue had spawned a new wave of pseudo-elitist attacks on the entire JS dev community. Calm down guys, things like that could have happened for any language that has a widely-used centralized package system (Perl's CPAN, Python's pip, Ruby's gems etc).
Let me repeat that again: languages don't make software bad, people do. Just don't let such Dicks-from-a-mountain rule over your own modules with elementary stuff like leftpad, and you'll be safe.
We haven't. React developers probably have.
Exploring a "spherical algorithm in the vacuum" begins being useless at some point. One should explore its properties when used in a real environment. Protocols where OTP usage is plausible and practical definitely exist. I'm not saying that OTP is practical for every possible use case though. In fact, in my first comment here I had asked the OP about how he's going to solve key distribution problem among multiple users. Because when such a simple algorithm is used, the actual protocol matters much more.
I suggested using standardized (or non-standardized, but other than OTP) encryption algorithms for an initial key data distribution channel that completely differs from the main communication channel and exists for a relatively short period of time. That's my key point.
> Or you could...you know...just use standardized crypto across the board.
I'm not going to dive deep into the topic of why I consider "just using standardized crypto" unsafe and prefer rolling another custom end-to-end encryption layer on top of it.
> OTP is by definition impractical. I'm sorry that you don't see that.
I'm sorry that you can't see beyond the algorithms. We're far ahead of the time when OTP was the only active instrument (aside from straddling checkerboards and Enigmas). Modern crypto can be combined in such a way that every encryption scheme finds its natural place. I honestly don't see why OTP cannot have one.
But like I said, both implementations suck compared to actual coreutils.
I think neither of these beats actual coreutils and their support base (still under impression of Termux capabilities...), at least not yet.
It's akin to saying "ARMv7 assembly beats using Java for Android programming".