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 1 year ago.
Improve this question
Is there a standard way (or ways) of packaging a Javascript GUI control such that it is easy for others to use and evaluate?
For example - should classes be named a certain way, should certain methods always be implemented?
Is a raw Javascript GUI control easy to use, or should it have a wrapper to make it usable in a framework? Currently, the code is not written for any framework.
Some background: I am a long time C# (WinForms) developer. To learn Javascript/HTML5, I ported one of my C# GUI projects, a spiral-shaped slider/track-bar, to Javascript and implemented a test harness using a HTML page. My plan is to use JSDoc to generate documentation once the classes/methods are stable.
Thanks in advance for any guidance.
There are a few best practices:
Use as few dependencies as possible.
Dependencies increase the package size and add the possibility that someone up the chain will insert a vulnerability. One dependency may be including a dozen more.
Don't put things in the global scope.
You can't trust other modules not to collide with you. If you must, pick a unique name.
Set "use-strict".
Use strict forces the browser to use more precise interpretation of your code. It can reduce errors and boost performance.
Don't eval.
While not necessarily evil, it's dangerous and often is a shortcut to doing something right.
As with all best practices, there are cases to ignore each of these.
There are some common patterns that js elements use when attaching to a page. Most typical is for an element that most closely matches the behavior is added to the document with a class that the script recognizes. For example <input type="number" class="praise-helix"></input>. HTML5 also supports custom data attributes, meaning that this is valid <input type="number" data-helix></input>.
Related
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 4 years ago.
Improve this question
If I understand Google encourages to put the css and javascript in the same page that the html. Internal css but not inline. On the other side, all the manuals and tutorials I have read say that I should use an external document.
Where should I put the css and javascript?
Note: in the design o my page there it makes no difference to use the css and javascript of the "above the folder" internal and the rest external. 90% or more of the css and javascript is for the content above the folder. In my case, it makes no sense make a distinction.
https://developers.google.com/speed/pagespeed/insights/
Resources are blocking the first paint of your page. Consider delivering critical JS/CSS inline and deferring all non-critical JS/styles
https://developers.google.com/web/tools/lighthouse/audits/critical-request-chains
There is marginal performance improvement in combining html, css, and javascript in a single document. This theoretical performance boost is outweighed by the many complicating factors that come from trying to do this. You might be saving 20-40ms by combining documents, which is generally not something the end user can detect. You will find more important performance improvements in many other ways.
Merging documents, when done at all, should be acccomplished by using a server-side assembly process so that your code can be well partitioned and well maintained. An example of this is webpack.
But again, unless there is some specialized use case that makes this important, it is not standard practice.
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 7 years ago.
Improve this question
In relation to this stack overflow question, I'm wondering what the typical use-cases are for compile-to-JavaScript tools. I've done some research and I've found a list of programming languages that compile to JavaScript, many of which are strongly-typed.
Emscripted and ASM.JS are typically used for for processor intensive tasks. Is this the primary use case of such tools, or is this dependent on the tool?
For the most part it is dependent on the tool. Libraries such as asm.js offer low-level complex functionality and enhancements that most people would not be able to implement themselves. This is the basis for most libraries, it brings the saying "Standing on the shoulders of giants" to mind.
CoffeeScript and TypeScript are dialects of JavaScript that offer people the option of writing in a language that has features they are accustomed to in other languages (like static typing). They can then compile their CoffeeScript code to JavaScript for use in a web browser.
I hope this gave some insight into your question.
Can compile-to-JavaScript tools be used for “regular” client-side development?
Coffeescript / TypeScript -> Yes. In fact that is on of their main
target audience.
Asm.js -> Depends on how you define regular. If creating a quake clone in the browser is regular for you then yes. If creating a standard SPA (angular/react/ember etc) is regular then no, asm.js is not targetted at you
I think most or all of those "languages that compile to JS" don't have anything to do with ASM.JS. ASM.JS is a very limited subset of JS that only runs assembly-style commands on a block of memory.
The main reason for doing so is performance, yes, since you can't directly access DOM and other handy browser objects directly.
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
I recently included Handlebars.js in a rails project, and a coworker balked at the notion. What are the realistic technical considerations when including an extra javascript library into a rails project?
Does the addition of an extraneous library significantly slow down the site delivery and user experience? Is this an example of engineering drama?
Has this been measured?
Adding additional libraries slows down the site delivery by several hundred milliseconds. It also requires some client time to parse and run its onload()-type functionality. From a human standpoint, it requires a bit of time to get used to using the new library. Depending on the level of complexity, usefulness, and time-saving of the library, this may be an acceptable tradeoff.
Handlebars is a great tool for templating, but you really need everybody on your team to be on board to use it. It's not very nice to simply introduce a brand new way of doing things without really discussing things. Handlebars is a big enough change to warrant at least a discussion, if not a vote.
If you were just wanting to put it there to see if it would work in the future, or maybe just convert over a page or two, then you should do that in a separate branch and do a quick prototype and demo for the team.
Depending on whether there is a valid business case and legitimate usefulness, you and the team can decide whether to convert your application to use it.
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
This might seem like an odd question, but I find that javascript is either easy or hard, depending on how you've coded the HTML. Is there a book or website that goes into detail about successful patterns and guidelines for coding HTML, so that it's very workable with jQuery, css and complex ajax applications? Like solid rules to live by.
Again, seems like a weird question maybe, but I don't know a better way to ask it. I just find myself always having to change the markup as new things come up - like switching between a hidden input element to a data attribute... or putting more ids or taking away ids - and I guess I arrive at the right way to do it, but I'm curious if someone has bothered to analyze this and came up with some great guidelines, standards and patterns so that the resultant HTML is right the first time.
Thanks
The first thing if you want to code some clean HTML that will be easy to work with is to make sure that your code is valid against an official DTD, HTML4 (here) or XHTML (here).
Then use id and class in a proper way (id only for unique section and class for repeatable ones) and name them correctly according to the context so they are easily reachable.
From my experience, I would actually suggest that, when it comes to large projects and professional JavaScript coding, the goal actually becomes to decouple the JavaScript code from whatever HTML it lives in.
As mentioned already, as long as you are using well formed HTML (DTD compliant), a library like jQuery shouldn't have any trouble operating on it. However, as best practice, I would recommend striving to isolate and encapsulate dependencies, whether they be because of HTML structure or just other chunks of JavaScript code.
the best way is to develop the html and javascript together. That way you can adjust the document structure to whatever you need.
This article seems to answer my question:
http://www.viget.com/inspire/extending-paul-irishs-comprehensive-dom-ready-execution/
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
I have a JS script (widget) which is added to other websites. Technically its similar to Google analytics. My question is: what are your advices for ensuring robustness, keeping the code from interfering with other code on the site, avoiding errors for users etc. In general, what should I know to write a professional grade widget.
Notes:
I can't use any JS library such as jquery etc..
I am a big fan of Peter Michaux's guide on how he writes javascript widgets
Also useful are Christian Heilmann's script configuration and the module pattern
Those are generic javascript articles and aren't specific to a single library
Other useful tricks are things like wrapping your code in an anonymous function to stop it interfering with other global libraries.
(function() {
//Your code goes in here
})();
Regarding errors and best practice, John Resig has an interesting article on javascript strict that isn't in yet, but does have some handy information on the sort of things you should be avoiding.
If you're still coming to terms with scoping within your objects, then you might find this article on private and public variables useful as well a a bit more technical definition by Douglas Crockford
Finally, remember to run your completed code through a code quality tool