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/
Related
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.
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'm trying to learn JavaScript, but seem to be going around in circles regarding primitives, objects, functions, etc. I can code fairly well in Python, so the JavaScript part is now mostly about syntax and idioms.
I am overwhelmed by the choices and I'm not sure how to choose: Prototype, jQuery, Dojo, Node.js, Backbone.js, etc.
What would be good JavaScript framework/s to pick up after mastering the basics? At the risk of betraying my JavaScript naivete, I'd like one (or a combination of) framework wherein I can do asynchronous requests, data visualization, and UI implementation.
I can do asynchronous requests, data visualization, and UI implementation.
async requests means XHR2
data visualization and UI means HTML, DOM4 or <canvas>
If you want to learn and really learn stick with the low level basics and don't use bloated abstractions.
Sure when you use jQuery you might finish it faster, but you won't learn anything other then how to hack together spaghetti code using jQuery. Your code wouldn't be anywhere near as maintainable, stable or performant if you had just learned how to do it right with plain old javascript.
I wouldn't be right to not first say to make sure you understand JavaScript itself first. It's a rather unique language with both good parts and bad parts. If you take the time to understand closure, prototypal inheritance, this keyword, constructor functions, etc, you will thank yourself. JavaScript, The Good Parts is an excellent place to start. Anyways...
For basic DOM manipulation, event handling, ajax, etc jQuery is the clear winner. In the past, Prototype/Scriptaculous was a common alternative.
For more advanced browser-based applications, Backbone.js, Angular.js, and Ember.js are the winners.
Dojo, Mootools, ExtJS, and Knockout.js are some alternatives to Angular and friends... all with varying strengths and focuses.
There are countless libraries for charting. HighCharts is a popular one. For more advanced visualizations, check out D3.js and Raphael.
Node.js is different beast. It's a server-side, network IO platform. It's competitors are things like Python's Twisted and Ruby's EventMachine.
Of course this topic has been covered in great length here:
https://stackoverflow.com/questions/394601/which-javascript-framework-jquery-vs-dojo-vs
For the first steps I'll recommend jQuery, with it's intuitive syntax and ability to be extended with bunch of plugins, and for it's strong community and huge amount of articles, tutorials, etc. on the internet.
jQuery is a cross-browser JavaScript library that provides
abstractions for DOM traversal, event handling, animation, and AJAX
Try it at first, then you can go with other frameworks based on the task requirements like Raphaël JS for vector graphics,Processing.js for animations, etc.
I would suggest 3 main/major frameworks to consider. The reason I choose the following 3 is because they are fairly well supported, document and used, but more importantly - they all suggest a different coding style/convention.
Dojo
ExtJS (Sencha)
jQuery (UI/core)
Should be noted that any one of them can be fit to almost any coding style/preference, but if I were to create the perfect (from working with it standpoint) framework, I would do a hybrid:
Dojo's widget creation and styling + ExtJS layouting capabilities and stores-based data managemenet + jQuery DOM manipulation and AJAX support.
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.
The basic idea for writing good code is that the code must be readable, well-commented and documented.
Other basic facts for writing good code regarding all the program languages are structuring the code in directories and files and indentation of course.
In the case of javascript the things could be more complicated,
because the language allows you to use different style to accomplish similar task.
For example there are three different ways to define a JavaScript class.
Said that, which are the best resource (books/sites) or suggestion for writing good code (library) in javascript?
I'd highly recommend reading JavaScript: The Good Parts by Douglas Crockford to get you started on writing quality JavaScript code.
If you're working for a company, is there a standards manual, or something jotted up saying "this is how we want things to be coded"? Yes, it's kinda Dictatorial, but it helps keep things "neat". ---Now, if you do not have one at your company, be proactive, talk to a few higher ups if they think it'd be useful, tactfully get them to delegate it to yourself and then make it. Get some brownie points and a good thing for your resume ---
There's ton's of books on the subject, blogs, pod casts, and probably a radio station somewhere.... that all talk about this subject.
But the #1 thing you will get from people is: Do not put many operations on the same line!
How many times do you look at a script and see a kerfuffle of statements/commands/initiators/setters/getters on one line. Or 4 nested ternary statements.
Sure, it "looks" cool if you're 15, but it is counter productive, not intuitive and not helpful. (yes this is a sour point). Code/Script is supposed to be maintainable. The biggest cost to some companies is maintenance on a product. When you go back to something years/months/days/hours after something is written, you want to be able to understand it without having to tape your eye lids open.
Here's a couple good articles I've read about this. They're not the most up-to-date but the information in them is still strong.
http://amix.dk/blog/post/19496
http://www.codinghorror.com/blog/2008/08/secrets-of-the-javascript-ninjas.html (yes from SO's very own Jeff)
http://www.bobbyvandersluis.com/articles/javascript_good_practices/index.html
Javascript - The Definitive Guide by David Flanagan (O'Reilly)
Pro Javascript Techniques by John Resig (APress)
http://jquery.com/
http://www.crockford.com/
http://developer.yahoo.com/yui/
This list will probably get fairly long, but don't forget you can study most of the code that is out there & you will soon learn what is good and bad - that's one big, great resource.
At the first place i would suggest you to get more familiar with JS object model
I would suggest you to take Douglas Crockford's article on prototypal inheritance:
http://javascript.crockford.com/prototypal.html
and make comparison with classical inheritance model
http://javascript.crockford.com/inheritance.html
More systematic approach of pros and cons of JavaScript can be found in his book
JavaScript: The Good Parts
http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742
If you search for more broader architectural approach
JQuery, ExtJs (a.k.a. Sencha), MooTools are great java script libraries/frameworks to start looking at their design principles.
I would start with JSLint
I would recommend coffee script as a good tool to help write good javascript. It is very readable, and includes some very clever improvements to vanilla javascript, including a very well thought out class declaration system (not trivial in javascript, which is prototype based rather than class based in it's language definition).
For comments, I would recommend JSDoc, which is a javascript version of JavaDoc. I find it to be very easy to maintain comments in the code, and the output is in a standard format that many editors/tools are able to utalise - so not only for people to read. Google have also provided a good set of guidelines of how best to write comments using JSDoc in a standardised manner.
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 have started a new web application and have decided to use jquery as my primary javascript library... But still i want to get some pros and cons tips from SO users who used jquery ...
Pro's
Eliminates a lot of cross browser javascript issues
Can perform complicated Javascript operations in little code
Can easily add Ajax functionality to app
Has built in UI and effects libraries
Con's
Overhead of adding extra javascript to page
Learning curve may not be short for some developers
All pros, no cons.
The only thing will be the execution time overhead that jQuery adds to load its files and execute its functions, but compared to the Pro of coding cross browser compatible JavaScript it is nothing.
Also compared to other JavaScript libraries jQuery is one of the fastest and smallest out there. Their community is huge and you can easily find support and good documentation.
Pros:
Large community
Useful for selecting and iterating over sets of DOM nodes
Eliminates some inconsistencies between browsers
Makes it easy for inexperienced JavaScript developers to do relatively complex scripting tasks
Cons:
Regular updates that change existing behaviour
Some confusing fundamental API methods (e.g. attr() method: what exactly does it do? It certainly blurs the line between attributes and properties)
Encourages "chaining", which leads to code that is difficult to debug: in a long chain of jQuery method calls, there's nowhere to put logging statements, so you need a full-on debugger
Short list of supported browsers
A general point about general purpose libraries: they encourage developers not to attempt to understand the underlying problems that the libraries try to solve, leading to a tendency to think of the library as being magical and to use it for absolutely everything
Adds 70K of JavaScript to every page where it's used when often a few bytes of non-jQuery code would do
Performance is generally much slower than the equivalent (well thought-through) non-jQuery code
Quality of plug-ins is very variable
You've made a good choice, don't worry. jQuery is a very well designed library - it is powerful, clean, well documented, and extremely popular. Learn it well, and it will be a powerful tool in your arsenal.
That said, I think that to be really aware of its pros and cons versus other frameworks, you should first learn it well. Only a deeper understanding of a tool enables you real comparison with other tools.
The only con I can think of is the occasional memory leaks. It is a great framework on top of javascript and is not restrictive.
That said, jQuery UI is terrible to my taste and if your application requires highly interactive UI try Ext JS.
The pros and cons are really relative to what your new web application will be doing. If it is going to be JavaScript/Ajax-rich and requires cross-browser support then jQuery is the way to go - no doubt. However, if you are only going to use JavaScript very sparingly, then it may be over-kill to include a large-ish framework, and it would be more efficient (in terms of performance and page size) to code the JavaScript directly.
Pros: Lightweight, easy to use, good documentation, gets rid of nearly all cross-browser issues and normalizes the event model.
Cons: jQuery UI doesn't have much to offer, and the plugins are hit or miss.
If you're doing a very JavaScript-heavy Rich Internet Application, go with YUI or ExtJS. jQuery is an excellent DOM manipulation library, and is the best for highly custom UI work. But if you need lots of stock UI and a robust data management system behind it, you need a bigger framework to tie it all together.
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 9 years ago.
I noticed most questions related to client-side script on SO are jQuery related and that got me thinking. I'm wondering what the ease of these libraries is doing to actual KNOWLEDGE of JavaScript and the DOM.
So much is done for you that my fear is there is a growing number of web developers that actually know very little about JavaScript besides how to include the jQuery library and use the plug-ins they download. It's the "fast food" approach to software development and, based on nothing more than anecdotal evidence, I think a lot of web "developers" would be in the dark when it comes to client script if they were suddenly unable to use the jQuery library.
My question: are these libraries helping or hurting REAL knowledge of client-side scripting?
In my opinion jQuery is to DOM as the .NET Framework is to the Win32 API, or GTK+ is to X11 programming. It's another layer on top of the "raw" API. It makes things a lot easier to work with, at the "cost" of abstracting the lower level details. Usually this is OK, but sometimes these details are important. It can help at times to be familiar with the underlying API (I think moreso in the jQuery/DOM case than .NET/Win32), but I wouldn't worry overmuch if someone has to hit a reference site or two before coding a pure DOM solution.
It's also important to recognize the difference between "JavaScript" and "the DOM". The DOM is not part of the JavaScript language; it is merely an API exposed by to the JavaScript engines in the major browsers. So while using jQuery might hinder one's knowledge of the DOM, it won't hurt their knowledge of the JavaScript language itself.
This is common question in programming.
Libraries and high levels of abstractions, in general, make things that were once difficult, much simpler. This tends to make the number of people who understand low-level internals smaller, but also increases the overall productivity of the industry.
jQuery have hurt my knowledge of DOM: I forget this **** DOM as a nightmare.
jQuery will never hurt my knowledge of JavaScript. You can't forget JavaScript after Crockford's texts
I started by learning Javascript as a child - HTML + Javascript was the easiest thing to deploy without having to actually know much about how computers worked. Since then, I feel that I know more about Javascript than I ever would have to.
However, there are very few projects now for which I use Javascript without jQuery. In fact, before I knew about jQuery, I made my own libraries. They weren't great, but they worked, and saved me loads of time and repeated code.
I guess my point is that the Javascript pros would have produced great libraries for themselves, no matter how many n00bs ended up grabbing onto them. Even if we're hurting beginners' knowledge of Javascript (an assertion which I'm not even going to make), jQuery is still definitely a good thing. What it does to beginners is a question of the learning process we offer beginners, rather than the tool itself.
I think that jQuery and its peers are probably greatly increasing general knowledge of Javascript. When I discovered jQuery I went from disliking Javascript and using it as little as possible to thinking it was a wonderful and beautiful language. Indeed, it might now be my favourite language in which to program, and I've learned an awful lot by reading the source code of the jQuery library. I can't believe that my experience is in any way unusual.
Why do you care about the "real" knowledge? The end result is all that matters.
If a developer can make a website that loads really fast with a great interface and layout, then he or she is a successful developer. How (s)he did it is irrelevant.