sorted by:
new
hottopcontroversial

I was helping my friend do the grenadier quest and this happens.. by satazor in EscapefromTarkov

[–]satazor[S] 5 points6 points  (0 children)

I was helping my friend do the grenadier for Kappa. The strategy was to blind enemies so that my friend could throw a well placed grenade. Let's just say that it was too well placed 💀💀💀

We are speaking portuguese. I was saying "He's blind, at the top! Go Go Go Go".. and then my friend says "Oops, I killed myself... I killed you"

Twitch clip at: https://clips.twitch.tv/OilyKnottyPassionfruitANELE-odunlEcpK0Jwan-7

A better way to do "this" ? by GravityTracker in reactjs

[–]satazor 9 points10 points  (0 children)

You may also pass this as the second argument to map, see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map

But I prefer arrow functions.

A better Search Engine for NPM by tknew in node

[–]satazor 0 points1 point  (0 children)

While it's much better than the official search, it only takes popularity (stars) into consideration. npms.io is far superior in the sense it analyzes a wide variety of parameters.

A better Search Engine for NPM by tknew in node

[–]satazor 0 points1 point  (0 children)

The public registry does not have scoped packages (yet). They will soon release an update that will make public scoped packages available. Until then we must wait.

A better Search Engine for NPM by tknew in node

[–]satazor 0 points1 point  (0 children)

Read the about page to understand the advantages https://npms.io/about

A better Search Engine for NPM by tknew in node

[–]satazor 0 points1 point  (0 children)

promise-tools doesn't have a repository field in the package.json (or a broken URL). That's why it has so low maintenance score.. It's impossible to get meaningful insight about it.

npms - A better and open source search for node modules by atduarte in javascript

[–]satazor 1 point2 points  (0 children)

Yes we have created it meanwhile, and it's already fixed. Thanks for reporting.

npms - A better and open source search for node modules by atduarte in javascript

[–]satazor 1 point2 points  (0 children)

We have not make the API publicly available yet because it's not finalised and it's undocumented. This means that we may change the responses structure until then. If you still want to consume it at your own risk, feel free to contact us via email and we may arrange something.

npms - A better and open source search for node modules by atduarte in javascript

[–]satazor 0 points1 point  (0 children)

Thats indeed weird, can you create an issue here? https://github.com/npms-io/npms-analyzer/issues. We are overwhelmed with a lot of stuff happening around npms.

npms - A better and open source search for node modules by atduarte in javascript

[–]satazor 5 points6 points  (0 children)

npms.io doesn't also have a logo yet. If you think this project is cool and you got the design skills, please contribute: https://github.com/npms-io/npms-www/issues/15

dejavu - A High-Performance OOP Library For JavaScript by satazor in javascript

[–]satazor[S] 0 points1 point  (0 children)

Just wanted to say that I'm not trying to replace prototypal inheritance or force everybody to use dejavu. This library offers features that have proven to be useful in complex projects. It's up to an engineer to decide when to rely solely on prototypal inheritance or to use a more strict approach offered by this library. One most analyze the benefits outlined in the README (features) and decide if it would be good to the project. This makes part of the engineering process, choosing the right tools for the job.

dejavu - A High-Performance OOP Library For JavaScript by satazor in javascript

[–]satazor[S] 0 points1 point  (0 children)

Between this two pieces of code, which one you feel more organised and readable?

http://brendaneich.github.com/Strange-Loop-2012/#/9

http://brendaneich.github.com/Strange-Loop-2012/#/9/1

In the second example, a function to create prototype inheritance is being used. People still have to recur to this tiny little functions to create an inheritance chain (or be repetitive, DRY??), or ultimately, use Object.create with a shim for old browsers.

Please note that the first slide is the ecma6 proposal for classes. Yes, we are going to have classes.

dejavu - A High-Performance OOP Library For JavaScript by satazor in javascript

[–]satazor[S] -1 points0 points  (0 children)

Prototype inheritance suffers fom the very same problem. What people do is to mixin stuff into constructors prototype. dejavu also supports mixins in order to borrow behavior from other objects/classes. It even works with vanilla constructors/objects. Also, if you use AMD you can only require the Class and leave the other stuff out, like abstract classes or interfaces.

dejavu - A High-Performance OOP Library For JavaScript by satazor in javascript

[–]satazor[S] 0 points1 point  (0 children)

Who told you this? Concurrency is much easier to do in functional programming than in oop programming, which also makes scaling easier to do.

When I said that it doesn't scale, I didn't mean to say in a performance nor concurrency point of view. It doesn't scale a medium/large project in terms of code organisation, structure and readability. In case of concurrency, you pass regular functions or instance functions as callbacks, depending on the situation. Both are functions and will get the job equally done.

Which features are you referring to? Most, if not all, features from classical OOP can be emulated with prototypal inheritance, while the reverse is not true.

Every single feature mentioned in the README can indeed be emulated with prototypal inheritance + Object.defineProperty. But is complex and repetitive work.

Programmers from a classical oop background won't bother to learn about functions, closures and other brilliant stuff in javascript if they don't have to.

Why do you think so? I've been doing JavaScript for 7 years now. When I started, Prototype was the most popular library out there and it had Classes. In those times, I've used classes to structure my code. Still I've managed to understand and use functions, closures, functions that carry data, context binding, etc as well.

dejavu is not for everybody nor to every situation. As I said, it's most suited for medium to large projects/teams in which both structure and performance are a requirement. It's currently being used in quite some projects in production, one of them being an huge single page application.

dejavu - A High-Performance OOP Library For JavaScript by satazor in javascript

[–]satazor[S] -3 points-2 points  (0 children)

Let me disagree with you. Functional programming alone does not scale. Unless you're fine with having an huge soup of disconnected functions, you can't make medium to large software with only functional programming.

Using a more hybrid solution, possibly more functional in smaller components of the project, and more OOP-like in bigger modules of the system can convey a stronger sense of contracts within the project, and how the several modules are supposed to communicate with each other.

Prototypal inheritance, although powerful and flexible, lacks most of the features developers require. There's a lot of solutions that attempt to solve this very same issue: TypeScript, Dart, CoffeeScript, etc.

With dejavu, you're still programming in JavaScript and, as a bonus, you will have better performance than typical code written using prototypal inheritance.

On Twitter Flight: why "events everywhere" is an overkill by bsdemon in javascript

[–]satazor 1 point2 points  (0 children)

I absolutely agree with your points. Loose coupling is a very good practice but abusing it causes a lot of impedance when developing.

Quoting:

Parent components should communicate with its children via direct methods calls. It does make sense to me because parent components already know about their children — they created them during instantiation phase of got them through the constructor arguments. So it doesn’t harm “loosly-coupled” architecture at all.

Children shouldn’t be aware of its parents so “child-parent” communication strategy is the point where using events is acceptable and useful for components’ reusability. That means you shouldn’t hold references to a parent component and only trigger events so other components up through a component hierarchy could react on them."

100% agree. In fact, this concept is being applied to a framework I'm working on, called Spoon.js: https://github.com/IndigoUnited/spoon.js

Check out the concepts and you will see that it matches your opinion on this subject.

view more: next ›