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 6 years ago.
Improve this question
I am sorry to ask this type of question.
but i am extremely confused here,i have gone through another sites to find the answer .
but not getting any proper answer .
Please explain me.
Thank you
I do find this answer from #Elisabeth Robson on CodeRanch pretty informative..
I think this is one of those questions which doesn't have a definitive answer and you're likely to get different answers from different people depending on what they think of as "lightweight".
Here's my answer: I think JavaScript can be thought of as lightweight because (at least up to ECMAScript 5) it isn't a particularly "big" language with many many constructs. It's actually a fairly simple language for the most part. Now, each new release of the language inevitably adds more "stuff" to it, which makes it less lightweight. Personally, I don't like that inevitable march towards more "stuff". I like when languages are lightweight: that makes the language easier to learn and understand.
A related way to think about whether a language is lightweight is: is the interpreter/compiler/execution environment for that language simple and fast? Which is really only possible if the language itself is simple. JavaScript engines have become a lot more complex in the past few years, but the tradeoff is that executing JavaScript code has become a LOT faster. I really have no idea how a JavaScript engine compares in complexity to, say, a Java compiler/runtime so I don't feel qualified to really comment on that end of it.
Another way to think of this is to consider the language "ecosystem": how many libraries and frameworks are built for it? While libraries and frameworks are useful, they can make a language feel less lightweight, because if using those libraries and frameworks becomes a necessary part of working with the language (your employer requires it, or your co-workers, or "everyone is using library X"), then again, it's more "stuff" to wrap your head around. In that sense, JavaScript becomes less lightweight by the day as more and more libraries and frameworks are released.
In conclusion, I'd say that I think the core JavaScript language is still fairly lightweight, but the JavaScript ecosystem is becoming a lot heavier by the day.
There are a few things this could refer to. Could be the fact javascript is fairly high level, weakly typed, or not very complex to write. Either way, it does seem to be a slightly subjective and vague term.
The fact is is high level simply means it has quite a few abstraction layers that differ it from machine code. C++, for example, is more low level, and getting something done in C++ takes more lines of code, but executes quicker.
Javascript is also weakly typed, meaning you do not need to specify data types, return types, etc. This is good and bad. It ends up making development quicker, but can cause more bugs that are not immediately recognised by the compiler. Also, it can remove reading clarity.
Finally, Javascript is arguably easier to write, and understand, then languages such as Java, C++, etc. It is has less methodologies to go about a given task.
Javascript is considered as light weight programming language .One of the reasons, is because it does not have any variable types unlike other languages. In javascript everything is considered to be as an object.
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 6 years ago.
Improve this question
I'm stepping onto the path of coding, for web services (full stack), after being a generalist in IT ops for many years. Ruby, Python, C# and JavaScript are interesting and Launch School looks like it has an excellent approach and curriculum for learning full stack, starting with Ruby on the back-end.
What about C# and .net Core?
However, a friend recently got me interested in C#, which is apparently a beautiful language to work with. The release of .net Core last month made this even more attractive. However, it's not a bad idea to start simple and to learn to program first and, unfortunately, C# is inseparable from .net. All the code examples appear to have .net throughout and maybe this makes it not so good for beginners to learn programming concepts.
The structure and strict typing of C# is attractive to me, but so is the 'simplicity' of Ruby and other dynamic languages. Ruby's OOP and the opinionatedness of the language is also attractive. Actually, there appear to be compelling reasons for each language.
On to JavaScript
So, continuing research shows that there is a strong case for JavaScript as a great first language, which will extend into many areas (web front and back end, DevOps, etc) and create, as Jeffrey Snover puts it, 'a virtuous cycle'.
JavaScript looks good, too. It seems to be less verbose than C#. However, it has the disadvantage of not having C#'s strict typing, nor Ruby's opinionatedness, to help the programmer write better code. It's so loose. ES6 and TypeScript go a way towards resolving this problem and initially I wanted to just learn TypeScript. But, I'm a fundamentalist and so this just doesn't feel like the right way to go.
Possible path
This leads me to a path more or less based on:
learn to code, using ES5 (lots of available resources starting
with Eloquent JavaScript, adding Speaking JavaScript, JavaScript:The Good Parts, etc);
add Smalltalk into the mix, as this sounds like a great baseline and is, by all accounts, a beautiful, simple/direct language with a pure OOP focus;
learn CSS and HTML, JSON, ReST;
learn TypeScript, ES6 once I am comfortable with ES5, including having avoided many of its pitfalls;
learn Node.js, and other JS variants, as required;
add frameworks, as required.
Anyway, JavaScript makes sense for full-stack, 'everything' web services. Great to learn a non-Microsoft stack, too.
Thanks,
nick
EDIT:
I have listened to a podcast, in which Kyle Simpson, Ashley Williams, et al, are talking about beginners using JavaScript to learn programming concepts. And, they are praising the lack of abstractions and sugar in ES5 and comparing this with the introduction of abstractions in ES6, some of which obscure aspects of the language from beginners.
In the context of ES6 making it harder for beginners they seem to point pretty strongly at Classes and that the implementation appears to be an odd fit for the language. But, they also mention how awesome Destructuring is and how this makes it easier to learn. It's an interesting discussion.
Ashley also gave a talk at jsconf2015 (link on the page linked to above) in which she looks at ES6 in the context of using it to learn programming concepts.
Javascript is a great language but it is also very confusing and there is a lot of bad articles out there. Unlike the other answer, I suggest you learn ES5 first because all the books you have mentioned are written in ES5. You don't want to confuse yourself with arrow syntax and other syntactic sugar. You will also appreciate ES6 more once you suffer a bit with ES5 but I believe that is the necessary part of learning. It would also give you a better perspective on to why these new features where added to ES6.
When it comes to learning Javascript, my opinion is to choose multiple sources, like videos, following the right people on twitter, listening to podcasts, articles etc. Here is a good place to guide you on your journey: http://jstherightway.org/
The books you have mentioned are great but I would add two more books to it. Javascript the definitive guide and you don't know JS.
I have read Eloquent JS, The Definitive Guide and Javascript the good parts but I felt that I truly started to grasp JS after I read "You don't know JS - by Kyle Simpson" https://github.com/getify/You-Dont-Know-JS
I highly suggest his video course "Advanced Javascript for serious Programmers". It really opened my eyes to the javascript paradigm.
Don't jump on frameworks because you will wasted a lot of time on configuration instead of learning actual javascript.
At the time you are proficient in JavaScript, ES6 will most likely be fully supported. I would go straight to ES6. Then, I would learn JavaScript framework, like Angular 2.
ES6 includes almost all features of ES5, they are not entirely different. There is a very good ES6 description available.
When you see :
ES5
[{lb:'Email',val:'ab#kg.co.sa'}].map(function(e){
return '<div><label>'+e.lb+'</label>'+'<input value="'+e.val+'" />'+'</div>'
})
Can be written in ES6 :
[{lb:'Email',val:'ab#kg.co.sa'}].map(({lb,val})=>`<div><label>${lb}</label> <input value="${val}" /></div>`)
You will take the decision by yourself.
==> The elegance & the productivity are with ES6.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have a plain javascript code that does not rely on external library. But given the popularity of jQuery and the fact that jQuery has become a de facto standard, I am wondering if it makes sense to rewrite the whole code for the sake of maintenance and extension in the future. Does it make sense to do so even if there is no particular problem with my plain javascript code at the moment?
Depends on the size of the codebase. If it's a very large job then 'if it ain't broke, don't fix it' applies. If it's quite small then it may help keep things more consistent.
There's no harm in itself however in mixing jquery and standard javascript, so anything new can be just written using jquery.
I would do it only if i can take advantage of jQuery to make my code smaller and easier to maintain.
jQuery is simply functions written in vanilla JavaScript so we don't have to write them ourselves.
I don't think there is an easy answer for this one.
My thoughts: It depends. Jquery may help you develop new functionality more rapidly so maybe it would be good to use for future functions. If your application is big it may cause instability if you rewrite large parts of it at one time. Maybe you find some parts that would especially benefit from being written in jquery and refactor these pieces one by one over time? Since javascript is the foundation of Jquery javascript will be there even if Jquery goes out of fashion so it can't be that bad to keep. Your main focus should be with the users; To keep them interested in you application and deliver new features that will keep them using your application. Very few users will care or even notice if you introduce a new library or not, but if your application breaks they will know. (It may however be very satisfying to introduce a library into your application that makes the code look good and easier to maintain).
Sidenote: These days I wonder if anyone knows what language / library they will be useing next year?
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 10 years ago.
I'd like to use a "javascript derived language" in order to learn and use some of the usual web technologies today like node.js, jquery, etc.
After toying for a while with functional concepts and languages, mostly F#, I'm looking if there's any similar thing in the Javascript world. So far what I've found and considered is:
Javascript the functional way: use javascript's functional parts as extensively as I can, making use of Underscore or other functional libraries. The pros to this approach would be to learn the "mother language". The cons for me are that I really don't like its syntax and doesn't feel very natural to program "functional first" in Javascript.
CoffeeScript + Underscore: I've seen some examples using CoffeScript + Underscore which seem appealing. For example: http://autotelicum.github.com/Smooth-CoffeeScript/SmoothCoffeeScript.html#toc-Chapter-7
The pros to this would be that CoffeScript is spreading wildly and seems the defacto standard of languages designed for its use with a javascript VM. It syntax feels more natural to me and I could program some things the functional way in an easier manner.
The cons would be getting far away from javascript itself (which really isn't too much of a problem to me) and to be in middle ground of non truly functional.
Livescript: Derived from Coco (which itself was derived from CoffeScript), it has the more appealing syntax to me (it even has my beloved pipeline '|>' operator from F#). The pros are that it is the most functional like approach. The cons would be that it isn't very spread (I made a search in SO and there's really NOTHING regarding it) and all that implies (not much community, support, tutorials, etc).
After thinking for a while on all this, I have no real conclusión so it'd be great if people used to working with javascript, CoffeeScript, etc could guide me on the real importance of this concerns.
Just in case... I haven't really considered using Pit (and so continue using F#) because although it compiles to javascript, I think it doesn't integrate with any javascript library like the above and doesn't follow the same workflow or integrate with the javascript ecosystem as well as those options listed.
Thanks a lot!
I'm probably a bit biased (I am the creator of LiveScript), but you should try LiveScript! I'm currently working on a standard library for it that will integrate better than underscore. As you say, there aren't that many people using it yet, but a community has to start somewhere! As you've pointed out, it seems like the best option all other things being equal - so take a dive and try it!
You basically have two options:
Use a JS-derived language like CoffeeScript
Use a functional language to JS compiler
For option 1, well, it's probably your best option for interoperability with other JS code. It's also your best option if you actually want to work with other JS developers who may not be familiar with <insert functional language>.
If you aren't actually very familiar with JS, I would suggest option 1. It may be tricky to understand how things work especially if you run into bugs in the language/tool of your choice if you don't understand the JS underpinnings.
Option 2 can be more interesting to use as you would probably get the benefits of your favorite language into JS. In addition to the Pit project you mention, there are some attempts at making Haskell compile into JS which could also be an option.
Option 2's downsides are probably the fact the projects aren't (afaik) very advanced to this day yet and that it may compile into not very efficient JS code.
Lastly, there was some Haskell-style language which was based on JS, similar to CoffeeScript, but I seem to have forgotten its name. It might be worth a shot, if someone can figure out what it was called :D
And what about just a library of ""FUNCTIONAL"" functions , + coffeescript + underscore ;) !
http://osteele.com/sources/javascript/functional/
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.
I've always been dabbling in javascript, but never really got hugely into writing a lot of javascript until last year or so. One thing I noticed is that my javascript started to grow so complex, that parts of it were more complex than the server's application code (minus all the framework code of course, such as Spring or Hibernate).
This caused me to realize that if you want to write a complex javascript application, in the same way you've been writing complex web applications on the server, you have to start thinking about best practices, architecture, how you structure your files, how you test your code, what abstractions do you use to create smaller, more reusable components, what is the best way to pass parameters and send messages, should i pass parameters or object literals, and just best practices all around. None of this provided or encouraged by Javascript itself, and everyone seems to have its own way of going about everything.
And of course, because Javascript offers such very poor api out of the box, I often spend a countless amount of time researching what the best tools for the job are. Facilities like importing files and dependencies, or even a basic collection library, are things NOT handled by the language. Let's not forget that IDE support, even in something like Idea 10.5, is actually pretty bad and nowhere near as rich as say Java due to its dynamic nature and the lack of these hard-bindings for packages and imports.
Outside of jquery, which I really like and feel comfortable with, I still haven't made any decisions as to the "right" way to do things either. This is odd to me.
Everyone seems to have their own coding idioms too - they either write in a pure functional style, or they try and create a whole classical programming model and then use that. People's coding standards and idioms vary from library to library and person to person. All of this makes knowing what the "right" thing to do an incredible task.
Even worse, there doesn't seem to be books on this sort of thing. It's like nobody has bothered to tackle it - which is totally contrary to what we have in the Java space, or many other spaces for that matter.
What is the right/successful path to having a refined way to successfully write nice-looking and robust javascript for complex web applications?
I feel like my knowledge of Javascript expanded and became more complete after reading Douglas Crockford's Javascript: The Good Parts. He really clarifies the most difficult and important parts of the language.
Reading it made clear the different types of inheritance: neoclassical, functional, prototypal. And the different ways to invoke a function: constructor invocation, apply invocation, function invocation, and method invocation.
I would start there.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I often see articles, posts and comments something like:
globals are bad in javascript
script tags should be at bottom of page
CSS should be in external files and at the top of page
scripts should be in external files, not plain script-tags.
etc.
I've looked up the HTML source of some big sites and have noticed that they have a lot of plain javascript and CSS inside HTML markup. JavaScript and HTML are note always obfuscated, and so on.
There are quite a few separate issues here.
What you see when you "view source" is not usually what they develop with. It's usually a compressed / optimised form generated from "source" code.
Claims about what is "best practice" are necessarily generic, and don't apply to all scenarios (especially if you're a big site and need specialised optimisation). These guidelines should be considered individually for each project.
Best practice, or even clean code, doesn't directly translate to return on investment. It may be nice to have consistent naming schemes, but is it worth the time developing and enforcing the scheme across 100s of developers?
Laziness, incompetence, or Friday nights.
Just because a site is big makes no guarantees about the quality of the code.
Have you ever viewed the source of Google's page? Is it pretty? No. Does it work? Yes!
Some possible reasons:
Some Web code simply isn't very big or complicated and it really makes no difference in maintainability whether it follows best practices or not, and it works fine the way it is.
Code is often written by inexperienced programmers, even on big, popular sites, and is never improved because it works fine the way it is.
Best practices change from time to time and it's seen as wasteful to spend time redoing your code just to adhere to the latest, when it works fine the way it is.
Adding new features is deemed more important than cleaning up old code, especially when, again, the old code works fine the way it is.
You may sense a recurring theme here. Rarely do programmers feel the need to fix what isn't broken.
Edit: If I were writing this now, more than two years later, I'd reword that final sentence to say "Rarely does management feel the need to fix what isn't broken." Most programmers love to revamp inelegant things, to the extent that they must sometimes be restrained by management in order to ship a product. I'd also throw in a mention of the concept of technical debt.