Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
So, I'm doing some string manipulations in javascript. Does it makes any difference in terms of execution speed or memory use, if I use s.length (, t.length, u.length,..) repeatedly in my code, or rather I assign these to variables (sLen = s.length..) once? If at all, the impact might be little, but I'm talking heavy loads server-side, which might have an effect on overall performance.
For the specific situation of string length, you can find very detailed answers on this StackOverflow question.
However as a general rule, accessing an object property is one of the fastest operations available to you, more or less equivalent to accessing a local variable. Obviously if it is a "deep" property, ie object.child.value.field.thing, it will be slightly faster to set it to a local variable, but I cannot imagine a situation where that would have a noticeable impact on performance.
An exception to this are Javascript getters. Since these are an internal implementation detail, you may not know when they are being used.
In short: accessing object properties probably won't have any impact on your performance - however, a poorly designed object with an inefficient getter may have an impact.
Personally, I wouldn't worry about these distinctions while coding and only dig into performance when there is a proven problem (measuring that is beyond the scope of this question).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have never really worked too in depth in Javascript. So just starting to dig into it more, I have learned about the "new" syntax for JS: MDN
I understand that basically it is exactly the same as before just with a different way to construct the code.
Obviously there is always a reason to learn techniques and variations, but what would make it worth my time to learn prototyping syntax, when using the updated syntax is more familiar to learn?
*One reason I can think of is just for understanding examples from before ES6. Almost everywhere the code is written with prototyping.
The only reason to avoid the class syntax is if you want your code to run in an environment where the class keyword is not supported. And, even then, you could write with class and transpile your code to ES5 compatible code if you wanted.
So, there's really no reason to avoid using class.
but what would make it worth my time to learn prototyping syntax
Even though you may code with class, here are some good reasons to fully understand how the prototype object works:
Javascript is a prototype-based language. Even though it is now using the class keyword, it's a prototype-based language, not really a class based language. You should know and understand what that means.
Older code will be written using assignments to the prototype so you will want to be able to quickly understand how that code works.
The class syntax is just manipulating the prototype under the covers so fully understanding how the class syntax works requires fully understanding how the prototype works.
There are programming structures that are sometimes very useful that the class syntax cannot create such as mixins where you may still need to work with the prototype.
So, I would suggest learning how objects are defined with the prototype object because then you will understand what the class syntax is actually doing. It's not particularly hard. Reading a few articles about how the prototype object works and then creating an object and then deriving from it using the .prototype object syntax is all you really need to do to get a handle on it. Then, I'd suggest creating the exact same object definition and then deriving from it using both the class syntax and by assigning to the prototype and then you can really see the parallels.
This question already has answers here:
Use of 'prototype' vs. 'this' in JavaScript?
(15 answers)
Closed 9 years ago.
I've been reading through JavaScript: The Good Parts and I'm currently on "Chapter 5: Inheritance."
From what I understand, using functional inheritance is preferred because it allows privacy for the properties and variables of an object while still allowing them to be called using methods outside of the object. However, it does seem like there is an advantage for prototypal inheritance because you can create a prototype object fairly easily (which makes understanding what the object is, to me, a little more concrete).
When should I choose one over the other? Should I always use functional inheritance whenever possible? Or are there "better" guidelines that I can follow to make that determination?
I've seen very little code that uses functional techniques as the primary form of inheritance. The vast majority I've seen uses prototypal inheritance. It's fast and easy to implement, and seems most natural to JavaScript.
That's not to say that functional inheritance should never be used, but I think you'll find prototypal more than sufficient for most applications.
Let's not also forget that you can still use some functional techniques within your prototypal inheritance, like giving each object it's own version of a function that closes over a variable in the constructor. So it doesn't need to entirely be one or the other.
Most important is to understand the concepts of prototypes and functions/closures. This alone will give you what you need to know in order to make appropriate decisions.
This question already has answers here:
How can I obfuscate (protect) JavaScript? [closed]
(22 answers)
Closed 9 years ago.
I am looking for the currently hardest-to-reverse JavaScript obfuscator. Bonus points if it can be run on one's own server. Performance hit and code bloat are fine.
Write it in Java, then run the bytecode in JavaScript with an obfuscated orto. That'll require two layers of decompilation in order to make any sense of it.
I'd be curious as to why you want to do this. Obfuscation offers no real protection. If you have something to protect, move it to the server-side, otherwise, why bother. If you're doing as you should and minifying/combining your JS that should be more than enough to scare away anyone not serious about knowing what your code is doing, and has performance benefits to boot. If they are serious, obfuscation isn't going to help you.
The JavaScript Code Encrypter And Obfuscator looked nice, until I actually tried to attack it. Took me about two minutes. The trivial solution:
for (i in window) { console.log(window[i]) }
That churned out a bunch of gibberish, but also the original code neatly boinked into one variable.
Note to self: Never, ever, ever, ever use anything you don't fully understand when it comes to security.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What are good questions to determine if applicant is really a pro JavaScript (browser side) developer ?
Questions that can distinguish if someone is not an ad-hoc JavaScript programmer, but is really doing professional JavaScript development, object-oriented, reusable, and maintainable.
Please provide answers, so an intermediate and ad-hoc JavaScript programmers can interview someone more experienced, coming up with answers to quite few of those advanced questions will elude me. Please avoid open questions.
Please keep one interview question/answer per SO answer for better reading experience and easier interview preparation.
Because JavaScript is such a small language, yet with incredible complexity, you should be able to ask relatively basic questions and find out if they are really that good based on their answers. For instance, my standard first question to gauge the rest of the interview is:
In JavaScript, what is the difference between var x = 1 and x = 1? Answer in as much or as little detail as you feel comfortable.
Novice JS programmers might have a basic answer about locals vs globals. Intermediate JS guys should definitely have that answer, and should probably mention function-level scope. Anyone calling themselves an "advanced" JS programmer should be prepared to talk about locals, implied globals, the window object, function-scope, declaration hoisting, and scope chains. Furthermore, I'd love to hear about [[DontDelete]], hoisting precedence (parameters vs var vs function), and undefined.
Another good question is to ask them to write a sum() function that accepts any number of arguments, and returns their sum. Then, ask them to use that function (without modification) to sum all the values in an array. They should write a function that looks like this:
function sum() {
var i, l, result = 0;
for (i = 0, l = arguments.length; i < l; i++) {
result += arguments[i];
}
return result;
}
sum(1,2,3); // 6
And they should invoke it on your array like this (context for apply can be whatever, I usually use null in that case):
var data = [1,2,3];
sum.apply(null, data); // 6
If they've got those answers, they probably know their JavaScript. You should then proceed to asking them about non-JS specific stuff like testing, workflows, version control, etc. to find out if they're a good programmer.
Basic JS programmming
Scope of variable
What is Associative Array? How do we use it?
OOPS JS
Difference between Classic Inheritance and Prototypical Inheritance
What is difference between private variable, public variable and static variable? How we achieve this in JS?
How to add/remove properties to object in run time?
How to achieve inheritance ?
How to extend built-in objects?
Why extending array is bad idea?
DOM and JS
Difference between browser detection and feature detection
DOM Event Propagation
Event Delegation
Event bubbling V/s Event Capturing
Misc
Graceful Degradation V/s Progressive Enhancement
Ask about "this". This is one good question which can be true test of JavaScript developer.
(I'm assuming you mean browser-side JavaScript)
Ask him why, despite his infinite knowledge of JavaScript, it is still a good idea to use existing frameworks such as jQuery, Mootools, Prototype, etc.
Answer:
Good coders code, great coders reuse. Thousands of man hours have been poured into these libraries to abstract DOM capabilities away from browser specific implementations. There's no reason to go through all of the different browser DOM headaches yourself just to reinvent the fixes.
Ask them how they ensure their pages continue to be usable when the user has JavaScript turned off or JavaScript isn't available.
There's no One True Answer, but you're fishing for an answer talking about some strategies for Progressive Enhancement.
Progressive Enhancement consists of
the following core principles:
basic content should be accessible to all browsers
basic functionality should be accessible to all browsers
sparse, semantic markup contains all content
enhanced layout is provided by externally linked CSS
enhanced behavior is provided by [[Unobtrusive
JavaScript|unobtrusive]], externally
linked JavaScript
end user browser preferences are respected
Ask how accidental closures might cause memory leaks in IE.
Ask "What unit testing framework do you use? and why?"
You can decide if actually using a testing framework is really necessary, but the conversation might tell you a lot about how expert the person is.
intermediate programmers should have technical mastery of their tools.
if he's passed the technical phone screen-esque questions above, make him sketch out something stupid on the spot, like an ajax url shortner. then grill him on his portfolio. no amazing portfolio = intermediate developer in this domain and not the guy you want in charge of your shiny new project.