So I have a fancy GUI in jQuery, which has gotten relatively complex. I would like to write tests for it, e.g. using assert(). However, it seems that writing such tests is difficult because GUIs don't manipulate data or make computations: they are just superficial interfaces to please the user.
So how does one generally write tests for GUIs?
assuming your code is fairly clean (modular and loosely coupled pieces of functionality that work together rather then a few uber functions), the first thing to do is choose a test framework. I recommend jasmine, because it fits the way I like to write tests, but if you are looking for more of an xUnit clone, qunit is also very well made.
If your code is not pulled apart (like 99.99% of javascript in the wild), I would first look at how to make jquery plugins, and extract as much as you can into them. Testing uber-functions that do loads of things is a scary proposition, but when you are talking about a module that does a single thing, testing gets much easier.
Finally, there is a bit of a learning curve with both how to structure complex javascript, and how to test it. Don't give up! Contrary to what some people would have you believe, javascript is very testable nowadays with very solid libraries and there are many people doing it (I just spent all day working on complex functionality, was practicing TDD the entire time, and it never felt clunky or unnatural)
Good luck, and feel free to ask for clarification if something here is unclear :)
EDIT:
By "pull apart" I mean move to a more modular approach rather then gigantic functions. In jQuery, the first step is with plugins, which will take you pretty far. If you are making a javascript "application", where most of your logic is in the front end and the back end is mostly for persistance, I would look at stuff like Backbone.js, which will help manage a very high level of complexity, but is totally overkill if you don't need it.
Going back to extracting plugins, try to find pieces of functionality that are sort of contained. I wrote a quick plugin today to remember the state of checkboxes in a table with paging, where the contents of the table get swapped out programmatically, but if a user checks a box on page one (but doesn't save), goes to page two, then back to page one they should still see that box checked.
If that checkbox code was inline in the paging code, it would make the paging code WAY more complicated. By pulling it into a plugin, it only complicates the paging code a little bit (calling $(table).saveCheckState() when a page unloads, and $(table).loadCheckState() when a new page loads) It also makes the testing very straightforward, all I need is a div with a few checkboxes to test the checkbox code, rather then needing to add more to the paging tests which are already pretty complex.
Not knowing your background or level of experience I would hesitantly recommend reading clean code if you want to learn more about this sort of stuff. Unfortunately is it java oriented rather then javascript, but most of it is universally applicable in any object oriented language (which javascript can be), and is probably the best intro level book into this topic. If you do full stack development (rather then just front end), have at least a working knowledge of java, are a junior/intermediate dev who wants to improve their craft, its one of those books everyone should read. If those things aren't true, it may end up just being confusing, or just not really be much use to you. So take the recommendation with a grain of salt :)
Your answer is in GUI itself - User interface.
GUI's are best tested with people. You should check out http://ux.stackexchange.com which is dedicated entirely to the user experience.
I think this is important, because I'm sure your GUI is to the point where it is solid, as you've done the unit testing on non-graphical elements. Through your own testing you've made it this way - now, you should see how other people interact with it, how they break it, and what they like or don't like about it. Then you make changes and do it all over again.
(Ok, I know this isn't unit testing. But seriously, the options out there for heavy testing of jQuery stuff are not that fun to deal with!)
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 9 years ago.
Improve this question
I want to create a custom UI framework in JavaScript for web applications (like Google Docs ui) (do not confuse with web application that deploy using languages like PHP, Python, etc.). However, after reading several books about web development, I understand that the best website is layered as follows:
Structure in HTML
Presentation in CSS
Behaviour in JavaScript
So there are several approaches to creating my own HTML document and control it in JavaScript. However in this approach HTML and CSS will be mixed, like in case of extJS UI. I am confused now, and I need some answers from experienced developers on how to write this kind of framework.
If HTML, CSS, and JavaScript is mixed.
What was advantages?
What was disadvantages?
Is there are other methods?
What was the usual type of creating UI frameworks?
I apologize that this answer is extremely long and at times may seem somewhat off-topic, but please keep in mind that the question was not very specific. If it is improved, or made less general, then I will gladly remove the superfluous parts, but until then, just bear with me. This is somewhat of a compilation of the other answers here, in addition to my own thoughts and research. Hopefully my ramblings will be at least somewhat helpful for answering this question.
General Tips for Frameworks
Frameworks are a ton of work, so don't spend all of that time for nothing. Work Smarter, Not Harder. In general, you should remember these things when creating a framework:
Don't Reinvent the wheel: There are tons of great frameworks out there, and if you create a framework that does the exact same thing as another framework, you've wasted a ton of your time. Of course, understanding what goes on inside another library is a great way to make your own library better. Quoting #ShadowScripter, "knowledge -> innovation." However, don't try to rewrite jQuery by yourself. :)
Solve a Problem: All good frameworks (and programs) start with a problem they are trying to solve, then design an elegant solution to solve this problem. So don't just start writing code to "create a custom UI framework," but rather come up with a specific problem you want to solve, or something you want to make easier. jQuery makes selecting and manipulating the DOM easier. Modernizr helps developers identify the features supported by a browser. Knowing the purpose of your framework will make it more worthwhile, and may even give it a chance of becoming popular.
Fork, don't rewrite: If the problem you aim to solve is already partially solved by another framework, then fork that framework and modify it to fully fit your needs. There's no shame in building of the work of others.
Optimize and Test: This is kind of a no-brainer, but before publishing version 1.0 on your website, test every single part of the function, under every single possible scenario, to make sure it won't crash and burn in production. Also, another no-brainer, minify your code (after testing) for performance benefits.
DRY and KISS: Don't repeat yourself, and keep it simple, stupid. Pretty self-explanatory.
Stick to Stable: (This is mostly my personal opinion) Unless you're trying to create a framework specifically targetted to HTML5 in Chrome 31, using experimental features and unstable code will make your framework slower, uncompatible with older browsers, and harder to develop with.
Open Source: (Another of my opinions) It takes years for huge companies like Google with thousands of dollars invested to create frameworks (e.g. AngularJS) so it is an excellent idea to make your source openly available. Having a community of developers contributing to your project will make development faster, and will make the end product faster, bug-free, and better all around. Of course, if you're going to sell it, that's another story...
For more information about best practices when making libraries, take a look at these links:
Javascript Library Design
Javascript Module Pattern: In Depth
Best Practices in Javascript Library Design
Building a Javascript Library
Types of Frameworks
The first thing you need to think about, as mentioned above, is what functionality you want your framework to provide. Here are is the list of types of frameworks/libraries (thanks to #prong for the link). For a much more comprehensive list, see jster, which has 1478 libraries, put into 8 categories, each with several subcategories.
DOM (manipulation) related
GUI-related (Widget libraries)
Graphical/Visualization (Canvas or SVG related)
Web-application related (MVC, MVVM, or otherwise)
Pure Javascript/AJAX
Template Systems
Unit Testing
Other
As you can see from the link, there are already dozens of libraries and frameworks in each of these categories, so there's not exactly much room for something new. That being said, I don't want to discourage you- who knows, you could create the next bootstrap or jQuery. So, here are some resources about each type of framework.
Note: you can't say that any type is better than the others, they simply are designed for different goals. It's like comparing apples and oranges.
DOM (manipulation) related
These types of libraries are designed to interact with, modify, and control the DOM of a website. Here are just a few of the things they do:
Select Elements in the DOM ($("div#id .class"))
Add/Remove Elements in the DOM ($("div#id .class").remove())
Edit Attributes of Elements in the DOM ($(div#id .class).height("30px"))
Edit CSS of Elements in the DOM ($(div#id .class).css("property","value"))
Add listeners for various events taking place in the DOM ($(div#id .class).click(callback))
The most notable of these, of course, is jQuery, and it has one of the largest user bases of any Javascript library. However, it is by no means perfect, and if your library wants to compete, the best thing to do would be to make it excel in the areas that jQuery fails- speed, fragmentation, and "spaghetti" code. (The last two aren't completely in your control, but there are certainly things that you can do to make it easier for users to use the most update version, and keep their code maintainable)
GUI-related (Widget libraries)
I think that this may be the type of framework you're looking to create. These types of libraries provide widgets (datepickers, accordians, sliders, tabs, etc.), interactions (drag, drop, sort, etc.) and effects (show, hide, animations, etc.). For these, people are looking for quantity- the best frameworks out there have several useful widgets/effects that work well. This is one case where it's "the more, the merrier," of course, if it works properly.
Graphical/Visualization (Canvas or SVG related)
The purpose of these libraries is to control animations on the page, specifically on an HTML5 Canvas. These feature animations and sprites for games, interactive charts, and other animations. Again, successful graphical libraries have many, many sprites/animations. For example kineticjs has over 20 different sprites available. However, make sure that quantity does not compromise performance and overall quality.
Web-application related (MVC, MVVM, or otherwise)
Basically, the idea is to provide a layout for the users to put their code in, typically separating the model (data) from the view(what the user sees), with a small controller to provide an interface between these two. This is known as MVC. While it is by no means the only software pattern to base a framework off of, it has become quite popular recently, as it makes development much easier (that's why Rails is so popular).
Pure Javascript- AJAX
This should really be two categories. The first, AJAX libraries, are often paired with a server side library and/or database (though not always) and are designed to make connections with a server and get data asynchronously. The second, "Pure Javascript" are designed to make Javascript easier to program in, as a language, provide helpful functions and programming constructs.
Template Systems
This might also be the type of framework you're looking to create. The idea is to provide components that developers can use. There's a thin line between Template Frameworks and Widget Frameworks (which twitter bootstrap, one of the most popular template frameworks, crosses a lot). While widget frameworks just give a bunch of little elements that can be put in a site, template frameworks give structure to a website (e.g. responsive columns), in addition to making it look good.
Unit Testing
This type of framework is designed to let developers test, or systematically ensure the correctness, of their code. Pretty boring, but also really useful.
Other
This type of framework is for really specific purposes that don't really fit into any of these other categories. For example, MathQuill is designed for rendering math interactively in web pages. It doesn't really fit into any other category. However, these types of frameworks aren't bad or useless, they're just unique. A perfect example is Modernizr, a library for detecting a browser's support for features. While it doesn't really have any direct competitors, can't be put into any of the other categories, and does a very small task, it works very well, and is very popular as a result.
More Types
There are a bunch of other types of libraries. Below are the categories (I'm not listing subcategories because that would take half an hour to copy down) that JSter puts their 1478 libraries into:
Essentials
UI
Multimedia
Graphics
Data
Development
Utilities
Applications
It depends on what you really want. The first distinction that needs to be made is between a Javascript UI framework (which provides structure to the app), an HTML UI Framework (Presentation) and Widget Libs.
Javascript Frameworks such as backbone, angular, ember, and knockout provide MVC-like structure to the app.
UI frameworks such as YUI, bootstrap, and Foundation provide a consistent HTML and CSS base.
Widget Libraries such as jQuery UI, Fuel UX, and Kendo UI provide ready made widgets.
There are also fully-fledged frameworks which provide things across the board, such as Google Closure tools, Dojo with Dijit.
This Wikipedia list pretty much sums it up, and here is the comparison.
In order to find the best way to create a framework, first ask this question: Can any of the above frameworks/libraries solve all or some of the problems/requirements I have?
If something solves all the problems, you can use it right away.
If something solves your problem partially, you can start by extending/forking that project/framework.
Follow DRY and KISS rules. Only solve a problem which nobody has solved as of now.
Fortunately, there is already a good solution: Google Closure Library. This is what Google uses. It shows the approach of mixing HTML, CSS and JS. I wouldn't say it's perfect, but I believe it's one of the best ones at this moment. Its architectural principles rely on proven component based and OOP concepts, and it's accompanied with a static compiler for Javascript. It's definitely worth of studying before baking your own solution.
I'd like to say that cloudcoder2000's answer sums it up nicely. I'm just writing this answer because it didn't seem right in the comment section :P
If you are thinking of making another framework, my suggesting is to stop thinking.
First find the thing in current implementations which troubles you the most, and try to find how you can improve it. Contribute to existing projects, nearly all of them are open source anyways. Also, you don't really need to be a JS-ninja to get into their midst. Take a fork, and get started. Once you're done, and feel that you're code is good enough, make it known to the original repo's maintainers that you have done improvements, and are looking for it to be merged into the project.
Keep in mind here that I'm not discouraging you from solving the problem at all.
I'm just pointing out that there are so MANY frameworks out there, wouldn't it be better if you went ahead and contributed to one of them instead of going for complete glory and implementing a full framework yourself? Making a framework is hard, but getting people interested in your framework is HARD. Really Really HARD, even for Google! Only once Angular got a very good documentation (which itself took quite some time, and resources, of Angular evangelists), that it has gathered so much steam. So, I'm just saying that instead of creating your own monument, perhaps lending a hand to others would be a more worthwhile exercise.
Most importantly though, is the fact that since you are just starting out, I presume you wouldn't have much experience designing frameworks, or thinking in those design terms even. It would of immense value if you contribute to existing projects. Then you will be gathering knowledge and experience of how things are built. Then, you'll be more confident. Then, you can go ahead and make your own framework! Then you'll be more equipped to tackle mammoth projects such as designing a framework. And Then, my friend, will you make something which would be worth the time of countless developers.
Short answer
Build a skinny DOM and only focus on JS code to make it more efficient.
Long answer
A good architect always replies with "it depends." You can't have one single framework that enjoys all others' benefits and suffers from no disadvantages, all at once. There's always a trade-off.
In order to create a framework that is really lightweight, you would probably want the lightest DOM (HTML) structure. However, having a skinny DOM might have the cost of more JS code. So you would probably try to write the most efficient code. You can start here.
Needless to say, you should be keeping the open-close principle, and have the stylesheets separated from HTML, using only classes and never inline styling. I would suggest using less. It makes the implementation faster, and the result is pure css so you suffer from no performance issues around it.
I must respectfully disagree with cloudcoder2000,
From a young age I have been being told don't re-invent the wheel, but why?
During the last 3.5 years, I have re-invented almost all of my web controls using javascript/html/css. From the extremely complex; for example a grid, rich text editor, tree view, dialog. To the very simple, like a progress bar, dropdown. What I gained is a better understanding of html/js/css.
No pain, no gain. I'm so happy with what I was doing these years as I learned more than others.
Some of the controls I re-invented, I think, are much better than the popular ones, like telerik, jquery mobile, extJS. For example, my tree view is fully customizable, with it one can build very complex trees.
So, I encourage you re-invent the wheels, and you will definitely get more than you expected. But also, from the beginning, you need to learn the source code of the popular controls, and re-invent them. You will be very happy when you find yourself be able to make the controls better.
Then the tips on creating HTML controls:
1. use jquery;
2. write jquery plugins(jQuery.prototype...) for simple controls, while define classes for complex controls;
3. separate css from html and js files. Define the html template in js, don't use html files, which make using the controls hard.
Regards,
Leo
For best performance in your UI design, you need to use a lightweight JavaScript framework like angular or backbone, Twitter Bootstrap for the UI, AJAX for base script load and use gzip compression in your app to make it lightweight and help the UI render faster.
When would one go for using Javascript MVC ? I mean why there was a
need for JS-MVC ?
Is it only because this design pattern was famous in other languages, for code maintenance,readability and many web apps are shipping client side ?
How does it helps a developer, tester and end-user easing their
tasks ?
Any use-case where JS-MVC is suited best and any case where it is
not at all required ?
Question 1,2,4
My view is that you should apply any kind of design pattern only and only if you really need it. Simply because design patterns aren't easy after all. They will add complexity to your solution, but they'll also provide you the benefit of (normally) being established and working solutions for specific kind of problems.
Whether to use or not use them really depends on what you are going to construct and how complex it is. That said, I'm probably not going to structure my 200 lines jQuery plugin using the MVC pattern, maybe...
But at work we create single page applications where we have 2-5 devs working on a project the same time, projects of the amount of 500 days. In such environments things can get complex very quickly and if you don't follow any kind of proper structuring you're lost.
I hope that should answer your question 1 and 2.
For question 3:
The end-user hopefully gets a better quality app with less bugs, but usually he shouldn't even notice (nor does he care) about the underlying architecture of an app.
MVC helps the developer
as an orientation when navigating in the app's source code. Consider an app of 3000 lines of code in a single source file and then when having 4 devs working on it at the same time. A mess, right? When having an MVC app which normally also use routings etc...you normally already know by looking at the route in the url where the corresponding controller lies in the source code and where you should put your hands on
for easier testing. Separation of concerns is always beneficial when applying unit testing practices because you can much easier test your controller because it isn't directly couple to data or presentational stuff (like HTML code etc). And just as a side note, you should definitely unit-test your JavaScript code, definitely!!
maintenance: which is the result of the previous points somehow
I'm not sure which kind of figure you intend by "tester". If he writes automated tests at the unit or acceptance level, then the benefits from before pretty much hold as well. If he's testing the app as a whole in the sense of navigating around, taking the app as a black box by testing its reaction to different kind of inputs, then MVC doesn't really play a big role for him. It's like for the end-user.
So I hope I was able to clarify some things for you. But as said, never just follow a pattern because people follow it but only 'cause it gives you any kind of benefits.
MVC is used to structure your code especially if you are working a lot with client side rendering. Without structure your code gets complex very fast.
User experience for end user is much better when you don't have to wait for the whole page refresh if you only need partial update.
It helps to navigate through the code much faster if you have well defined structure of your code.
JS MVC frameworks are best used where you have complex systems and you want to provide better user experience by using AJAX and partial page reloads or updates. Usually you would not use MVC for Personal website, blogs or stuff like that...
I have a very large website that I need to refactor the front-end of due to maintainability concerns and performance issues:
What's tricky:
Lots of overcomplicated scripts
Over-complicated CSS with a whopping filesize
No selenium tests in place
No js tests in place
Back end developers concerned anything breaking
The site has been live for a while and the client is happy
Tools available:
Multiple servers for testing versions on
Continuos integration setup
Version control
Some thoughts (after having done also bigger refactorings though more on backend side):
create a play-branch where you start to "scribble" refactor. there you can see how the refactoring feels. I often find that especially big refactorings are like starting design/programming. You have to get hands on and see how your refactoring target feels like. This also has great to better estimate the overall effort.
as your client is happy and it is more an investment for future take the incremental approach. Do not do a big-bang refactoring. Try to partition several refactoring areas (e.g. javascript vs. CSS) and also by pages.
start with the easier refactorings steps. They help to get you "fit" with the harder ones.
the scm is one of your biggest friends. It is vital to revert quickly and feel safe when refactoring. Even on your refactoring branch for bigger works you can create further "minor-branches" to go on with bigger refactoring steps.
regression tests are vital. Get tests in place first. 100% test automation is hardly possible, so get one of your QA/Test team-members to help you along the refactoring and regression-test after each bigger refactoring-step. The 'it doesn't work anymore' after 3 months of refactoring would just smash you.
for more difficult refactorings (hard to test) and flaky code structure do 'pair programming'.
The fear backend developers not trusting big refactoring is correct, take them serious and ask for help (especially for the regression testing requirements).
Well, it seems to me that the main problem you're facing is a lack of exiting JavaScript/Selenium tests. Once you've got those in place, you can start the real work of refactoring, taking small steps - confident that mistakes will be picked up.
Never refactor without having tests in place first.
Well I would start out copying the project to a new workspace and creating a place for your version control. This way your back end developers don't need to be scared anymore. Next I would look at the css files because you can change those and see the difference right away. When you like the css you have then you can go on to the script part.
Here you definitely need tests because else there will certainly be some errors or changes which are not wanted. I personaly would migrate the script in very(!) small junks so you are able to find errors very fast and run tests for every little thing you changed. This will lead to the most persistent outcome in my experience.
Another thing you need to think of is the deployment. I mean there are always some requirements or dependencies (I don't know if that's the case in your problem but you should really check that and work with your back end guys so they can give you some hints where the problems could be).
Here are some ideas:
Spend a few hours going over the site, clicking through, getting a sense of functionality
Zero into the core page, or pages you want to focus your main improvements on. Spend an hour on that
Start looking at what's more important:
A) maintainability / quick ability for you or someone else to come in and extend functionality
B) page load performance - how you might reduced it by 100kb plus, and consider if its really worth it based on the type of site it is
C) ui latency. How sticky, intermittent transitions, how slow the site feels once loaded.
Come up with a figure in your head. Is it a two day job for you? 2 weeks? What benefit will it have for all of the above? Now consider how long it might take some new developer you have hired who will now have to go through the same process as you and be at your level.
Once you feel you know all the possible user journeys and variations of a particular component you have singled out, consider how long it would take you to do the following:
recreating the same file hierarchy of a single page onto your own server, outside of the existing slow/unreliable/changing environment/live site or whatever so you can accelerate the speed in which you are about to work on this (approx 3/4 day)
switching headspace between development/research/documenting anything as you go/ interruptions, managing other projects etc (approx 1hr)
create whatever tests you want and develop from scratch and emulating an existing piece of fe architecture, written exactly how you would have wanted it. (1 day per component - html, accessibility, sass, js etc)
consider how you could integrate this single component into the existing architecture/environment and remove the existing piece without breaking anything around it.
integrate it back into the environment. Time is money, but thorough investigation before embarking on a project will protect and prepare you for that important discussion with the business owner.
I want to use a javascript framework with MVC for a complex web application (which will be one of a set of related apps and pages) for an intranet in a digital archives. I have been looking at SproutCore and JavascriptMVC. I want to choose one framework and stick with it.
Does anybody know what the distinguishing features are when comparing these two?
I want something that is simple, straightforward that I can customize/hack easily, and that doesn't get in my way too much, but that at the same time gives me a basis for keeping my code nicely organized, and event-driven. I also plan on using jquery substantially.
I know sproutcore is backed by Apple, and looks like it is getting more popular by the day, and it has a nice green website :), whereas JavascriptMVC looks less professional, with less of a following and less momentum behind it.
I've done the tutorials for both and I was impressed by SproutCore more (in the JMVC tutorial you don't really do anything substantial) - but somewhere in the back of my mind I feel that JMVC might just be better because it doesn't try and do too much - it just gives you MVC functionality based on a couple of jquery plugins, and you can use jquery for everything else, so its flexible. Whereas SproutCore seems to have more of its own API etc... which is also nice in a way... but then you're kind of stuck within that.... hmmm I'm confused :).
Any thoughts would be much appreciated.
Being a JavaScriptMVC contributor, I'm extremely biased. But I'll try to give the best answer I can.
JavaScriptMVC has also taken years to develop. But instead of focusing on ui functionality, it focused on the layers just below that. There are a few reasons for this:
You can find a jQuery widget to meet almost every need. There's no reason to compete these plugins. Instead, JavaScriptMVC tries to work with them.
Most people need one or two custom widgets / controls. JavaScriptMVC wants to make building and maintaining these pieces as easy as possible.'
Flexibility+API. I'm not sure exactly how to say this one ... but here's my best shot ... With JavaScriptMVC, we wanted every layer of the application to be as easy to understand and maintain as possible. This is why we picked jQuery as our low-level library. It's API is about the best abstraction for the dom possible. People typically go directly from the low-level API to build the Widget/Control. This is why most jQuery widgets' code look very dissimilar. We wanted a middle layer that organize our code and promote best practices, while providing enough flexibility to meet almost any requirement. So with JavaScriptMVC, you get very solid low and middle-level layers. But, you don't get widgets.
JavaScriptMVC has testing, error reporting, and documentation baked into the framework. The testing is the most impressive part. It has integrated selenium and envjs testing.
My recommendation would be to go with SproutCoreif your requirements can be built pretty straightforward with SproutCore. But if you know jQuery, have to build a lot of custom controls, or need really awesome testing, use JavaScriptMVC.
Funny, because just a month back or so, our team evaluated exactly these 2 frameworks head to head. We ended up choosing JavaScriptMVC, and I've been working hands-on with it for about a month.
I like it ... but, I was a HUGE proponent of SproutCore. I had never heard of either framework before we eval'd them, but once I saw SproutCore and looked under the hood, I was very, very impressed. Honestly, I don't think there's anything out there that can give you the kind of power it gives. Yes, you'll have a learning curve, but it's the kind of thing that lets one person accomplish the work of 5 or 10 once you know it.
So I'd use SproutCore in a heartbeat.
That being said, JavascriptMVC (aka "JMVC") is nice. It doesn't really give you a ton on top of jQuery itself. You will still have some infrastructure to build yourself (depending on how complicated your requirements are). This is both a pro and a con. One nice thing about it is that, if you need to dig into the details of some piece of JMVC, you can ... it is not so incredibly huge that it is impenetrable.
In summary, there's not a thing wrong with JMVC. But there is, in my opinion, nothing even in the ballpark with SproutCore.
I think that the main difference between them is that SproutCore includes a GUI while the JMVC is something low-level without any graphic, so if you need a GUI you can't use JMVC without including other scripts like the jQuery UI or jQuery plugins.
You said that "JMVC might just be better because it doesn't try and do too much" i don't agree with this, it took years before SproutCore 1.0 was released, so developers had the time to make a great product.
I suggest you to use SproutCore, maybe you'll have to learn more things, you'll spend more time to practice and understand everything, but you'll learn how to use a very good framework that can be usefull also for future projects.
Sproutcore-2.0 eliminates the ui-constraints and plays nice with completely custom app-uis.
http://blog.sproutcore.com/announcing-sproutcore-2-0/
http://blog.sproutcore.com/dispatches-from-the-edge-dropping-in-a-sproutcore-2-0-application/
I code CSS/XHTML like it should be my mother language, and I do write valid, semantic code following guidelines of accessibility and such.
But I want to learn Unobtrusive JavaScripting, but with a total non-programmer brain I need some motivation / tips / etc., like what's the best way to learn it, and how long does it take/did it take you before you could feel the power of knowledge? :)
PS: I do have an understanding on how JavaScript works and changes the DOM etc.. I think it's more about learning the syntax by head instead of having to look it up.
See also:
Suggestions for someone starting javascript programming.
Just use it. Really, the more time you spend reading and writing the language, the more natural it becomes. Use Firebug or an equivalent console to test short ideas; take an existing web page and wire up events interactively from the command line, get used to the idea of writing behavioral code as a separate process from writing markup.
If you want a good book, i can recommend the excellent jQuery in Action - yes, it's targeted at jQuery users, but the concepts apply regardless of your choice in libraries.
Motivation, sorry can't help there.
Syntax is learned by rote. The rules are simple, and reasonably consistent, so in truth syntax isn't that hard.
What you conflate with syntax are likely the other aspects like what properties are available on what objects, what functions to call, what does your framework provide. That, again, is basically rote memorization.
Many frameworks add a little bit of syntax through clever use of the JavaScript syntax, and you'll need to learn those as well.
But when it all comes down to it, the only way to learn this stuff is to use it.
You can't read about it, you have to do it.
Find an issue that you want to work on, a feature for your site or whatever, and attack that.
If you find a tutorial or whatever on line that does what you want, TYPE IN THE CODE, don't cut and paste it. As you type it in, question every symbol or character, try to understand why you're typing what you are typing.
Make an effort to change things, even if it's just variable names, because then you get a better idea of what things are being used for, and how they're referenced. It also lets you focus on a small part of the larger program.
If you're changing the "window1" variable to "myWindow", then at least you can look at the code as "blah blah blah window1 blah blah window1" without having to understand all of it.
Start small, don't worry about "doing it right", etc. so much as just being successful. If the way it's done doesn't bother you, then you're good. If you look at it and go "That's not quite right" because you learned something later after you started, then go back and clean it up.
At this stage, function is greater than form. Much of the form simply comes from experience.
Depends on what you want to do. Are you a successful web designer who's considering getting into the development side? Forge ahead, but tread cautiously. JavaScript can be easy to start with, but it can get ugly very quickly. And it's very different from any server-side language (including Java). Some of your JavaScript skills will translate to other languages, (conditional and control-flow operators, for example). But some things are unique to JavaScript and will require some relearning if you move to another language.
Also, some things in JavaScript won't completely make sense unless you've done object-oriented development; even though JavaScript is "prototype-based" rather than strictly object-oriented, without the OO concepts to relate to, the prototyping system may be difficult to understand. The typing system also may not make much sense if you don't have a lot of experience with different typing systems (static vs. dynamic, explicit vs. implicit).
Use a good framework like jQuery or YUI, but be sure to understand what's going on behind the scenes. Shog9's suggestion to use FireBug is a good one, too. It will show you what's going on (without having to do a lot of alert() statements in your code).
Your HTML DOM and CSS experience will help some, but only in the sense of understanding what the JavaScript is trying to do. Having written HTML and CSS by hand won't help you learn to write JavaScript; HTML and CSS are document markup languages, not imperative programming languages.
So go for it, but don't expect it to be easy. You may make a lot of quick progress, only to find that you're not as far along as you think, and that things don't work the way the appear to. But with enough effort and research you'll probably get there.
I think learning Javascript is a great idea if you are all ready doing HTML and CSS. Javascript is a cool, but quirky language. Most people that use don't really know how to write good JS code. I highly recommend watching Douglas Crockford video, see http://video.yahoo.com/watch/111593
They will give the real scoop on Javascript.
I've recommended JavaScript: The Good Parts before (and can't recommend it highly enough), but if you're new to programming I suggest starting with Head First JavaScript.
(source: oreilly.com)
I think you've got an abundance of great answers and resources already, but I'd like to chime in, too, since I've seen a couple of jQuery recommendations:
I love jQuery, too, and use it nearly daily. That said, for a beginner, I would recommend that you be comfortable with javascript proper first before diving into jQuery. Being comfortable with the syntax, variables, scope, and at least some DOM concepts will greatly improve your understanding of how to do what you want with jQuery. If you try to speed too quickly past the fundamentals, you'll definitely get stuck on some common misunderstanding that jQuery won't be able to help you with.
http://codeavengers.com level 1 JavaScript is great for the complete beginner. I created the courses and have had lots of great feedback from beginners who have found my course a fun and effective way to learn JavaScript.