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 3 years ago.
Improve this question
Some things, like modern assembly languages, are meant to be easily read by the computer, and not by developers.
I'm wondering if the ECMAScript specification is similar in this sense, that is, it something meant to be read only by the compiler or by someone who wants to implement said compiler. Is that the case?
Or is it not the case, and much like the users of a tool (such as React JS) are expected to read its documentation, are developers who use JavaScript expected to read the ECMAScript specification?
I don't want this question to sound opinion-based, so perhaps a slight rewording: Is the ECMAScript specification meant to be developer-readable, in general?
Nobody is ever expected to read the specification. You'd probably need to at some point or another to try to understand certain methods and their behaviors, but no - the only thing most people use is documentation, especially MDN.
The specification is only really useful if you try to understand how JavaScript is interpreted (thanks Bergi), rather than just how to use it. Up to you if you want to read it or not, but no - you're most certainly not expected to read the specification, or anything for that matter - sometimes, self-learning is the most effective method.
Related
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 3 years ago.
Improve this question
Given that V8 execution of ES6 code is slower on some operations, compared to ES5.
According to this: http://incaseofstairs.com/six-speed/
Can anyone point to an article/paper/post where tests were performed in order to find out if such performance difference will impact in the normal operation of an API developed with node.js?
Should I use ES6 or greater to build a node.js API, considering it is slower to ES5?
That's a false premise right off the bat, as demonstrated by the chart you linked to.
No, this is not "premature optimization"
Yes, it is. Choice of language dialect is much more about ease of development, compatibility with libraries, and reliability. There is nothing in common implementations of ES6 that are "slower" across the board. You haven't even built your application yet, and you're worried about something that is unlikely to make a significant impact at all.
If you find that there some particular code that could be optimized, Node.js allows you to implement native binaries where you can optimize all you want.
I know some may wonder, if the API is going to get millions of hits, but again, I'm more interested in the correct pattern to use.
Use ES6.
In the back-end, we're talking about hundreds or thousands of clients, and that performance hit will be compounded.
And yet, you don't even know what the pain points are in your application because you haven't built it yet. For most applications, it's going to come down to I/O.
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 6 years ago.
Improve this question
when I do not want to use a transpiler. I want to write straight Javascript? For example if I feature detect that let is available, so what I can not re-write my code to use block level scoping.
For example when should I start using let? Is it even possible to form a general strategy?
Feature detection doesn't really work for syntax. While you can test for syntax features using eval and try...catch, you cannot use that information to write your code one way or the other. It also doesn't really make sense to write the same code twice but with different syntax.
If you don't want to use a transpiler, you will simply have to avoid using any ES6 features until your target audience uses browsers that support it.
Is it even possible to form a general strategy?
One way would be to say that you are going to use feature X if Y% of your visitors use a browser that support it. But that also means that your site might not properly work for (100-Y)% of your visitors.
That's exactly the problem transpilers are solving...
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 6 years ago.
Improve this question
What are the differences and similarities between QML and Javascript?
I am doing research on it, as I will probably give of a small presentation about QML soon. I have already looked at it on wikipedia, but I was hoping to get some answers from people with experience.
Note: I know some QML, I don't know any Javascript.
QML is a declarative language describing a tree of objects (in the QtQuick case a tree of visual items). The documentation has a fairly comprehensive documentation of the language. QML is used in the Qt framework only.
Javascript is an imperative language. Javascript is a very popular language used in many different places, for example embeddded in HTML sites or as part of node.js servers.
QML can actually include Javascript snippets, for example for bindings and signal handlers.
QML and Javascript serve very different purposes, so I don't see how to provide a list of similarities and differences.
Getting some downvotes there, my guess is that it is because you didn't research enough before coming here. And possibly because it doesn't sound like you are quite ready for a presentation on these languages.
But I'll see if I can at least point you in the right direction; QML is what is called a "markup language", not unlike XML, whereas Javascript is an "imperative language", like many others such as Python, C and Rust. More similar to Python, as it is also an "interpreted" language, whereas the others mentioned are "compiled" languages.
Hope it helps!
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 9 years ago.
Improve this question
Javascript : What are the different conditions when javascript work in IE but not in Firefox or some other browser?
one that i know of is that while using certain window events..
What other scenarios can cause javascript to not work properly?
The answer is too complex to fully list here. Use sites like http://caniuse.com that will tell you which JavaScript is available in which browser.
Generally speaking, all browsers implement JavaScript differently. Microsoft have long been stuck in their own world, implementing their own ways to do things, whereas everyone else seems to try and conform to the standards as much as possible. Microsoft are coming around to the "standards" way of doing things, and from what I hear, IE11 will be a massive step in this direction.
As already mentioned, you can use http://caniuse.com/ to find what you can and can't do in different browsers, but then you'll likely end up doing what many others have done...write your own API which works around these to achieve a task...which is a bit unnecessary, unless you can find a ground-breaking way to implement your API that will be beneficial to other developers.
APIs like jQuery already work around these differences. The aim with these libraries is to provide clean JavaScript, whilst being completely transparent from the underlying JavaScript implementation.
Also, look into "shim"/"polyfill" implementations. These are used when a core feature that is recognised as part of an ECMAScript version has not been implemented in the browser. These provide the implementation for you, if it is not natively supported.
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 8 years ago.
Improve this question
Where I was working as an intern, working on a JavaScript front end project with Backbone.JS, I was using those getters and setters as provided by the framework (Backbone) but was asked to define my own to make it clear whats public/private. I was more for using those provided by the backbone. Whats the better practice or recommended method here?
Then recently, I was developing my own ExpressJS/Mongoose app, I started off thinking I define a Todo model then a Todos collection that exposes functions like byId, byList etc, but then I was thinking perhaps I should just use those provided by Mongoose?
The advantage of using the provided getters/setters will be
Less code, less bugs
standard way of getting/setting. Instead of 2 (from framework + custom)
Another developer will just need to learn the framework instead of my custom code to understand whats happening
Cons:
a little longer code
less sense of whats private whats not, but I think this is not very important ... esp in a dynamic language
Again, whats recommended here?
If the framework allows it to you, write your own getters/setters only when you have to modify the behaviour of the default getters/setters.
There's no reason to write them if not needed, IMHO.