New answers tagged

1

Technically, there is no quicker or slower alternative: it's the same request to the same resource, and the processing and sending of the image would probably take much more time than the displaying on client side. The only difference is the perception by the user, with a major difference between <img> and background-image. If <img> doesn't ...


2

It is conventional in recursive functions to write the base case first. That means your first option. Your second option is testing for the inverse of the base case, which is confusing to read. Writing the base case first makes little difference in this particular case, but in the general case if you were to use pattern matching, or a switch statement, or ...


5

In terms of speed of execution they are the same. The compiled/interpreted code is going to do a test if nodetype == 3. If yes it executes a return statement next. If no it executes the other return statement next. Both cases are going to execute a return statement next. In terms of stack usage, they are the same. In both examples shown, it only drops ...


2

Are you talking about the use of <script>-elements to store HTML templates? The purpose of the script element was to embed scripts, but the HTML spec does not mandate which languages should be supported by the browser. In case the specified language is not supported by the browser, the default behavior (mandated by HTML) is simply to hide the text. ...


1

You could turn things inside out like this: function getValue(parameter) { if (active) { try { return valueStore.query(parameter) } catch (e) { // quietly fall back to non-active behavior } } return getRandomValue(); } Now there's no duplication or local exceptions. Should the fall back logic ...


1

There are, as always, tradeoffs. Your first option is simpler, more efficient, and requires less memory. Your second provides a more consistent environment for callbacks to operate in. Given the possibility of callback authors creating hard-to-identify bugs with the first option by assuming that their callback will be called asynchronously, I'd suggest ...


-2

If you take a look at how things are done in jQuery, AngularJS, ES6, you will see that what they choose is none of what you did. Instead they use 2 separate callbacks, one for success, one for error. However i don't see any issue to not wait if an error is detect automatically.


1

Also, don't be afraid tot tell me it's a silly idea. It's a silly idea :P And here's why: Data caps. The primary hog when it comes to data are things that happen in the background without any user's consent. You wouldn't want to be leeching off a person's data. Battery and heat. Of course, processing takes up resources and resources doesn't come free, ...


3

Given a variable which needs to have a scope beyond a single function call, yet be accessible by only one function, I believe it's okay to not introduce a new scope just for that one function as long as you don't make the variable global. In other words, I'd put this variable at module scope. You should already have some kind of module system which prevents ...


1

If your goal is to limit variable scoping, you are making the issue more difficult than necessary. Consider this function that achieves the same goal with a much more limited scope, both for the internal variables and the function complexity: function doIt(x) { var theAnswer = 42; return x * 42; } It does the same thing yours does, but without the ...


1

Here is a good reason not to totally abandon sync calls just yet. You have just downloaded a new tool from a vendor. You get it working in your AngularJS application. (you spend weeks at this POC) Then you are asked to use one option that has to communicate to your web server. You create OWIN secure applications, so ALL calls must be Authorized! The ...


1

So if I don't plan on reusing this component, is there any harm to fetching the data from within the component that renders it? Software design is about trade-offs. Separating container components from presentational components brings several advantages - separation of concerns, reusability, testability, etc. These advantages are probably too easily ...


1

Answering my own question: I have made some tests now. It looks like it is not possible to do this with that object in only 1 objectStore. An other example object which would work: var myObject = { "ordernumber": "123-12345-234", "name": "Mr. Sample", "shipping": {"method": "letter", "company": "Deutsche Post AG" } } ...


0

If you load the regex's from database you get a lot more dynamic solution, which I tend to like. If you don't want to create the complexity right now though, you could start with a few hardcoded patterns and then refactor into a db-driven solution. I get a bit worried about your validation in javascript though. Client side validation is only for quick ...


2

Why is this not done by default? For some reason, it wasn't done in the earliest versions of the language we now know as Javascript. Unfortunately, changing it now would break tons of existing code, so we're stuck with it. Why not make this an "opt-in breakage" like strict mode? Probably because strict mode is focused on a small set of the most ...


1

The typical way to simplify this sort of code is to create an "empty" resolved promise that you can use in place of the "real" promise if you don't need to get() the url. I don't use jQuery much, but I believe that would look like this: var promise = condition ? $.get('url') : $.Deferred().resolve().promise(); promise.done(function () { done(); }); ...


4

Your proof that you will always reach a previously used 'i' appears to imply that your mapping function is topologically mixing. This in turn suggests that your function is probably chaotic. If it is chaotic, then by definition there is no faster way of producing the result than iterating your mapping function. Looking at it less rigorously, the modulus ...


4

I think the operations you're doing are variations of SQL joins, because in most cases you're taking tuples of data, picking a kind of value from each one to associate, and returning the combination(s) that could be linked. I'd suggest you look into the jargon, algorithms, and research-papers of RDBMs systems as your first place to mine for more ...


2

By wrapping the whole thing in an IIFE, you can create private variables and functions. This way, the exposed API can wrap the private functions any which way, and persist would only be called when using the public delete: var obj; (function() { function realDelete(id) { delete obj.users[id]; //maybe some other code (ui manipulation) ...


1

For many cases, I just use the flag like your second example : deleteUser : function(id, isPersist){ delete this.users[id]; //maybe some other code (ui manipulation) if (isPersist) this.persist(); } deleteAllUsers : function(){ var me = this; var uids = Object.keys(this.users); uids.forEach(function(u, i){ ...


1

I think the interface to deleteUser() and deleteUsers() should be similar, so I'm against your second solution. In this scenario, I'd keep the deleteUser() method, and internally delegate to a private persistence method. For consistency's sake, I would do the same for deleteUsers(). By doing that you're keeping the public interfaces consistent, and the ...


0

The answer is that you should probably not be spitting out raw HTML and then attaching JS and CSS to it. The core problem is that the ids and classes are basically global mutable state, since anybody can mutate the DOM with any classname or id for an element. Alternatively, they can read or mutate your state easily by looking it up by ID or class and then ...


12

This seems like a very bad idea to me. defining css rules for classes and adding those classes to the html is a great way to make your css reusable. The way you're suggesting, with a complex selectors, sounds like a recipe for mangled stylesheets. Sure, your html is clean as a whistle, but now the css is a pain in the butt to maintain. Consider: ...


0

It is indeed good practice to declare variables as const (or readonly or final, depending on the language) if possible. The author of the linked answer also admits that is is right to mark variables as final, but the author is simply too lazy to do it. Even if the authors opinion about "clutter" was right, then it wouldn't apply to JavaScript or ...


4

*sigh*... This is why immutable needs to be the default. Even the referenced Java answer suggests this. Note that that answer does not recommend removing final modifiers, just that the author of that answer wouldn't add them in new code (for local variables) because they "clutter up" the code. However, there is a difference between JavaScript and Java ...


1

The Big Differences... While the pros & cons above are valid concerns, I don't care [too] much about them on a higher scale. Here are the pros & cons which determine whether I write in one paradigm or the other: Reference-Based Usually, this approach will lead you down paths you're not aware of. You will likely be coupling intensively -- and it ...


6

On languages such as Haskell, most datatypes have instances which allow their values to be used as keys of structures such as Maps. It's the same in ECMAScript. Any object, including primitives, can be used as the key in a Map. Even NaN, even though NaN !== NaN // true does the right thing and can be reasonably used as the key in a Map. JavaScript ...


3

What you really want is a Map, not an object: Map You need to check if the support you need to provide fits with the Map supported browsers, but that´s what you really want as objects only take strings or symbols as keys while a map can take anything Here is an example of its usage: var point1 = {"x": 7, "y": 8, "z": 9}; var point2 = {"x": 6, "y": 5, ...


0

Although, the question may be answered and you decided to accept this answer, I want to highlight the topic from another side. 1) JSP as a templating system As a templating language, I think, JSPs are good like any other. You may find, that Thymeleaf suits your needs better, but that's subjective. JSPs are an old - or better mature - technique to get ...


1

The JSTL syntax required to make highly-interactive pages via JSP's is getting awfully unwieldy. I'm worried that, when we expand our project and bring on more engineers, there will be a steep-ish initial learning curve, followed by a persistent slow-down in the dev process due to verbosity of JSTL. That is a legitimate concern. Using JSP's also ...


2

In JavaScript, functions are just objects. As such, there is no particular reason not to pass them around as parts of other objects. In fact, may JavaScript libraries do this, for instance, letting you pass in an object containing a success and an error callback. As a way of doing OOP in JavaScript, that's a perfectly reasonable way of doing things, and ...


5

I think I would want my function to be more relevant to the actual job/data being processed rather than a generic sounding shouldDeselect(). That doesn't tell you anything really. Maybe something more inclusive of why deselection is flagged? As an example: if(martians_have_landed()) { cancel_all_shore_leave(); } How we discover if martians have ...


0

Probably method clients don't need to know whether any action was actually performed o no. I think that an idempotent deselect() method is a winner here. It could return true/false to inform whether it actually deselected anything if needed.


2

As shouldDeselect() doesn't carry out the deselect action itself it can be named checkDeselect(), which I would find more clear (and consider a more common naming pattern), and I would even add what to check, e. g. checkDeselectUsers(). But as DavidArno already mentioned this is as opinion-based as many naming decisions, and I expect the opinion police to ...


2

To a certain extent, it's purely a matter of opinion. Both approaches will have their fans and neither is inherently wrong, save for under one circumstance. If the test/action code isn't atomic, then that approach should not be used, ie: if(shouldDeselect()) { // could a call to shouldDeselect() ever return false here? deselect(); } So for ...


2

This is the case for most new features and need time to be adapted and integrated. If you plan to work with multiple browsers then until it is matured I would say no as it would just be increased maintenance, however if you are in a position where you can choose what browsers your clients need to run on then by all means make the best of it and hopefully ...


9

Atomic access does not translate into thread-safe behavior. One example is when a global data structure needs to be invalid during an update like rehashing a hashmap (when adding a property to an object for example) or sorting a global array. During that time you cannot allow any other thread to access the variable. This basically means that you need to ...


70

1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is. At the moment, it sounds like you're simply "adding threads" to the language and worrying about how to make it correct and performant later. In particular: if two tasks try to access a variable ...


15

Just guessing here to demonstrate a problem in your approach. I can't test it against the real implementation as there is no link anywhere... I'd say it is because invariants are not always expressed by the value of one variable, and 'one variable' is not sufficient to be the scope of a lock in the general case. For example, imagine we have an invariant ...


1

This is needed. The lack of a low level concurrency mechanism in node js limits it's applications in fields such as math and bioinformatics, etc... Besides, concurrency with threads doesn't necessarily conflict with the default concurency model used in node. There are well known semantics for threading in an environment with a main event loop, such as ui ...


14

A decade or so ago Brendan Eich (the inventor of JavaScript) wrote an essay called Threads Suck, which is definitely one of the few canonical documents of JavaScript's design mythology. Whether it is correct is another question, but I think it had a big influence on how the JavaScript community thinks about concurrency.


6

Is your approach going to significantly improve performance? Doubtful. You really need to prove this. Is your approach going to make it easier/faster to write code? Definitely not, multithreaded code is many times harder to get right than single threaded code. Is your approach going to be more robust? Deadlocks, race conditions etc. are a nightmare to ...


2

Your implementation is not just about introducing concurrency, rather its about introducing a specific way to implement concurrency i.e concurrency by shared mutable state. Over the course of history people have used this type of concurrency and this has lead to many kinds of problems. Ofcourse you can create simple programs that works perfectly with using ...


0

I really believe it's because it's a different and powerful idea. You are going against belief systems. Stuff becomes accepted or popular through network affects not on the basis of merit. Also no one wants to adapt to a new stack. People automatically reject things that are too different. If you can come up with a way to make it into a regular npm ...


1

This is not an anti-pattern. This is a code smell, which is to say that this is the sort of thing you should avoid when it's feasible to do so, but there may be legitimate cases where nothing else does the job. I thought the Promise.all should fail fast. Yup. This is exactly why the default behavior of Promise.all is to fail fast. The rationale ...


1

If you have no additional requirements besides what you mentioned in your question, this is perfectly fine. See KISS and YAGNI. You should only consider doing something more complicated right now if you know you're going to need something like internationalization, since deciding on a satisfactory getCorrectStringForCurrentLanguage() mechanism and porting ...


3

Since it took Java a decade to go from having everything necessary to cleanly support it (i.e. since Java 5) to adding it; C# still hasn't added it to the standard library though it's been able to for about as long; and the idea has been in common use in (statically typed) functional languages since, at least, the '70s, I would actually say JavaScript is ...


0

I see 3 very important reasons for using CDNs: Reduce network latency for users in distant regions. When you have a web site for global audience, your hosting in North America would not seem fast for users in South Asia, especially, in China. The difference in user experience may be so huge that it will discourage users from using your site. In this case ...


4

If by compiler error, you mean syntax errors then yes they are. Console also gives the runtime error as for example, when trying to access an undefined property of some object at the runtime. JavaScript is an interpreted language so we cannot call them compiler errors but instead parsing errors. Browser console shows us the following: Syntax errors at ...


0

You will need to map the all tags from all the feeds to the correct field. For example in one feed if you have sku you map it to product_sku In other feed say you have an other tag sku_product and you need it mapped to product_sku. Now since only one tag will exist in one feed for a product ( hopefully) , you can have a config mapping the tags to a ...



Top 50 recent answers are included