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
How does generating HTML/CSS directly in HTML/CSS files, compare with generating HTML/CSS in Javascript?
I have written some code in HTML and CSS, but feel I have much more control over what I am doing when writing Javascript, as it is a fully fledged programming language. Then I have one type of file for the system and can control the structure of the system much better etc.
It has therefore become tempting to simply write everything in Javascript directly.
But what are the downsides of writing HTML/CSS directly in Javascript?
1- People who disable javascript can't see your content
2- It takes longer to render everything, since javascript is ran after DOM loads.
3- Search engines can't see what content is on you page
JavaScript is a client-side language — therefore, writing HTML with JS onto a blank page (I guess that is what you are referring to) will be performed on the client side. This makes you lose some degree of control over how HTML and CSS are written to the page, e.g. when the end-user does not have JS-enabled. Most search engine bots also do not have JS enabled, which means your page will be blind to search engines in general.
However, serving HTML and CSS files instead of writing them using JS will allow you to serve files from the server-side. You can insert information into HTML and CSS files from the server side, e.g. using PHP, before they are sent to the user.
In addition, by using JS, you will be losing this control unless you bridge that gap using AJAX.
Before thinking of doing this you need to ask Why are you willing to do it? If it is for practicing and/or developing your JS skills, I understand but it has little practical use.
Javascript is a programming language. Although it does have many applications (including in AJAX), it gives you the ability to modify client-side code dynamically. So, the standard practice is to write static HTML/CSS files as HTML/CSS respectively and then when you need to trigger something dynamically to modify HTML (or text) or styling (CSS) of the elements, you can use Javascript.
As someone else pointed out, search engines / spiders can only access server-sided pages and JS works on client-side so none of your content would be "crawlable" by the search engine spiders.
Even though, CSS or rather CSS3 does give you some limited ability to perform dynamically alter client-side styling, for example the :hover selector or CSS Animations, for more advanced applications, Javascript is used.
It is crucial to think by the way, on devices where Javascript is disabled, none of your site pages would load if your site was rendering all the HTML/CSS in Js, purely.
Therefore, it is best to use HTML/CSS for static text/code/styling and JS for dynamically updating your page.
Hope it helps!
No current answer adequately address both the advantages and disadvantages to writing HTML or CSS through JavaScript, so I will attempt to address both sides of the issue.
Advantages:
JavaScript is reusable. Elements common to many pages can be shared, and as JavaScript is a language, these common elements can be manipulated to suit the requirements of the page.
JavaScript can be consumed by external sites, allowing a developer to create dynamic content that can be compiled and rendered externally.
JavaScript can handle robust data through JSON objects, which allows for manipulation of data on the client while writing the visual markup.
JavaScript developers have created many frameworks, such as jQuery, that help avoid re-inventing the wheel.
Disadvantages:
JavaScript must be executed by the client, which can take time and impact the performance of your application.
JavaScript cannot be crawled by search engines, which will negatively impact your search engine optimization strategy.
While rare, JavaScript cannot be used by browsers that do not support it. Users attempting to access your application will see only the HTML markup if they cannot execute JavaScript.
Incorrect use of JavaScript opens your application to malicious threats, such as cross-site scripting, where static HTML may have never introduced the threat.
As mentioned by Djizeus, frameworks exist that use JavaScript extensively in developing web applications. AngularJS is an example of a framework that aims to assist in creating single-page applications through JavaScript (though static HTML and CSS is also utilized).
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 5 years ago.
Improve this question
So I have been wondering how can I manipulate DOM in languages other than Javascript and PHP. I can always use Javascript and PHP in one HTML file with other HTML and CSS code.
Similarly, in Javascript there are multiple methods such as document.getElemenyById() etc. In PHP, basically it is a hypertext pre-processor and thus it automatically renders HTML through the server which again can be used for DOM Manipulation.
What about other languages? Can we use them to build the web? Or specifically, do things like HTML and CSS Manipulation. Let's say for example, Python or C#. How can I use them like JS and PHP?
There are two stages of "working" with DOM.
The first stage is the server render. When PHP engine receives template (mix of HTML, PHP) plus data and outputs valid HTML to a browser. In this stage, you can build HTML that will be parsed by a browser to DOM tree. You don't work with DOM, but rather with a plain text of your template.
The second stage is the Javascript evaluation. A browser parses and runs JS, and this JS has access to DOM tree.
The first stage can be done in any language that runs on a server. You can use c# templates, python templates, go templates, even javascript. All template engines just proceed template (text) and data and give text output which can be valid HTML.
The second stage works only with JS because browsers work with JS only. There were some attempts to bring other languages to a frontend (like Dart), and all failed. But you have some options. There are many compilers for existing languages that can target JS. For example, clojruescript for clojure, bucklescript for ocaml, gopherjs for go and others. Also, there are bunch of languages which created for this purpose (compile to JS): purescript, elm, typescript, etc.
Modern browsers can use webassembly binary packages. It differs from JS, but also don't have access to DOM.
The real question you have raised here is:
Whether we can use languages like C# or python for DOM manipulation like JS?
In simple words, the answer is no. But if you are using any kind of parser, you will get a feeling that you are doing something in python like HTML but again on browser it will be HTML only.
Rather I will say... there is very big difference between mark up language (front end language) and server side language.
HTML is used as a markup to show some content on web page. You can use some templating though but that will again finally be compiled into HTML only.
Now comes the role of JS, whatever elements have been created on web page, Javascript has power to perform operation/manipulation on them. This is called DOM manipulation which is only possible through some front end language. And currently we have only Javascript as per my knowledge (Please somebody correct me if I am wrong)
Now comes the role of C#, python or PHP. These languages are for back end jobs. Anything you are sending from front end, will be processed at backend and these languages are used for those purpose so, DOM manipulation thru C# is a big NO. You need javascript (jQuery or other library) for that.
Thanks,
Hope it helps.
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
Most traditional MVC frameworks include their own templating solution (Jinja2, Mako, etc). If one decides to use one of those new ui frameworks such as angular or backbone, they seem to encourage the use of front end templating solutions.
Is there any difference in performance? What are the pros and cons of going either way? Are there issues in ie or other browsers when using some of theses js templating solutions?
My take on this is simple, really.
Use a server side templating engine when you want to template the structure of a site. Use a client side templating engine when you want to template the data of the site. And there is nothing wrong at all with using both, as long as they don't have a large amount of competing tokens.
A VERY common example of this is using ASP.Net MVC to manage the bulk of a site structure using the razor template engine, and using a JavaScript client library such as Angular.js to simplify the data structures on the individual pages.
Depending on the situation, one major factor can be a significant change in bandwidth usage.
For example, my newest project includes the ability to have colour codes in chat (and other places). These codes look like:
`1blue `2green `3yellow `4red `bbold on `Bbold off `b`iBold Italic...
I could parse this server-side and return:
<span style="color:blue">blue </span><span style="color:green">green</span>...
But see how I only did two words and I'm already going longer than the source text! Instead, I chose to implement the parser in JavaScript, on the front-end. This takes a lot of processing off of the server (which would otherwise have to parse this stuff for every single user) to the client (where only one user is being dealt with).
It also had the advantage that I could implement a live preview just by plugging in to the same parser, but that's irrelevant here.
Additionally, client-side templates can be cached, further reducing the amount of data that needs to be sent. This can be particularly beneficial to mobile users, who may not have unlimited data (those poor people... I weep for them... not really)
Personally, given the choice, I'd strongly recommend client-side templating (although in my usual style, I would shun all pre-made solutions and make my own XD I'm weird like that) for a variety of performance reasons. Obviously, the major downside is "no JavaScript = no website", but I'm fine with that since the entire site relies on JS...
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
All of the answers to this question so far as I can see are confusing... can someone give me a detailed way to make EXE apps with HTML?
No. In the strict sense you can't. HTML was mainly invented to design and exchange documents written for a browser (and CSS provides layout information for such a document).
Although, that is not the case anymore. There are many possibilities, where HTML and CSS is used outside of the browser (e.g Gnome Shell is developed with the help of CSS and Javascript or think of Modern UI apps for Windows 8).
So if you consider Windows 8, there is the possibility of creating an app outside of the browser; but technically it is not an .exe It is not an executable.
Another possibility is to make use of the WebBrowser Class, which allows you to write an .exe which makes use of your HTML and CSS.
So there are ways to stuff HTML into an executable, but you can not make it executable by itself, since it is a document/markup language and not a programming language and can not be converted to running code.
There are several possible directions here, and I can't be sure what you really want.
If you have a static HTML site, you can load it into any web browser from a local disk. This is exactly how "Save as complete web page" functionality works in all major browsers. You can even put this on a CD/DVD and cause Window's autorun feature to automatically load it in a web browser. This method (or some variation) is probably what you want.
If it is a non-trivial web app, then it is already an executable, albeit on the server, not the client. (I assume this is not the case). This cannot easily be converted to a desktop app, for reasons obvious to anyone with the skill to do so.
If you want to make the UI of an application via HTML/CSS, that's a whole different story. Its a means to an end; the app is the actual product. But this involves making a real exe: still no cheating.
So, okay. Despite the "no-cheating" claim above, it is possible to build an application using Javascript as the programming language. In this case it is an "executable", but not really an .exe: it's a .js file. You would need a standalone Javascript interpreter for this. But this doesn't necessarily involve any HTML or CSS at all: Javascript is a programming language in its own right, just like the ones other apps are build with.
So no, HTML is not put into executables strictly for viewing pleasure. Its technically possible, but also infeasible: far better solutions already exist. E.g. how do you justify choosing which browser to integrate? Will you force every user to use your exe browser instead of their favorite?
HTML is a language similar to XML - it is interpreted, not compiled. Thus, you cannot make MS Windows executable files (*.exe) with HTML.
This is a common misconception. HTML is a markup language, which means it must be interpreted by an engine that can display the actual visuals that HTML encodes.
One cannot simply compile HTML, CSS, and JavaScript into an executable file. These are all merely scripting, styling, and markup languages that must be interpreted by an engine (which in many cases is executable).
In Visual Studio 2010 you can create a simple window with a WebView element, and you can populate this element with custom HTML, and inject JS, and so forth. This is described more in depth here: http://blogs.msdn.com/b/wsdevsol/archive/2012/10/18/nine-things-you-need-to-know-about-webview.aspx
Finally, you may be thinking about Visual Studio 2013, which allows you to use JavaScript.
JavaScript is a first-class language in Visual Studio 2013. You can
use most or all of the standard editing aids (code snippets,
IntelliSense, and so on) when you write JavaScript code in the Visual
Studio IDE. You can write JavaScript code for Windows Store apps and
Web apps in Visual Studio.
However, keep in mind that all of your JavaScript gets compiled down into the CLR (Common Language Runtime) which can be read about more here: http://en.wikipedia.org/wiki/Common_Language_Runtime
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
Similar to this question; When to use JavaScript template engines? but not quite.
Is it practical to make full sites (e.g. skip static HTML and PHP processing and just send JavaScript with HTML templates for client side rendering) in client-side JavaScript with a template engine such as handlebars? Or, are template engines only useful when it comes to re-usable template sections?
You have half of the the answer, which is re-use, but you can get that on the server-side. To me the other half is as follows:
Allow front-end developers to handle all the interactive development in JS and HTML, almost without knowing JS for simple templating needs.
For web applications the UI rendering on the server slows or limits the interactions/experiences one can design, or at least limit performance. Why does the server have to know and understand the User button clicks? The browser is powerful enough to handle the button clicks.
It pairs nicely with REST services. The browser knows how to request the data and determine the user context.
More complex web server side design. State is a very complex thing to manage across clusters and nodes. Not that you can't but why should you? Especially as for most modern web applications (web 2.0 and all that jazz) the whole point is the browser doing more, handling button clicks, sorting data, etc. Guess what all that is user state. So the browser already has a lot. So why distribute that state across a cluster of servers adding latency, dependencies, etc. I have a no HTML in the application server policy.
Change control. When you write PHP and embed HTML snips in everything things end up tightly coupled. It reduces flexibility of use case changes.
Separation of concerns, forcefully. Many developers are tempted to do business logic in the view. Simple templates help reduce the likelihood of this. One could easily construct an argument against all non-templating based approaches, JS or server-side but that is not the question at hand.
If you are going to build a mobile app you want and need services that avoid presentation markup. So never generate HTML in the application server or else your app will only speak one language. People might shout server side MVC will help, but not for off-line, different access patterns, etc.
There are some performance, device detection, 'dumb phone' reasons to generate html server-side, but then write it off of the services which your JS web app use. Let that be the exception. Even better write it in JS on the server-side and re-use the business functions and logic on both.
I use a JavaScript template engine when I make one-page web-apps (with backbone.js for example).
In any other case, I would not use a JavaScript template engine.
The reason for this is, that if I create an application in anything other than JavaScript-only (PHP, Rails etc.), I like having the templates done on the server rather than at the client.
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 5 years ago.
Improve this question
I'm a student and also new to JQuery. I want to know the difference between JQuery vs JScript. How we decide what to use and when to use those two technology.
Considering
Performance
Technology
jQuery is JavaScript. It is a JavaScript library, so it operates on top of JavaScript. It cannot exist on its own, so you can't use one over the other. You can use just JavaScript or JavaScript and jQuery.
jQuery is designed to make many JavaScript development tasks much easier.
Use jQuery when it will significantly reduce your development time, and you can afford the extra overhead of downloading the library.
A lot of people automatically include jQuery without considering the fact that it might not make the particular development task at hand much easier. This is a bad habit to get into...
Personally my most common uses are:
Complex element selection
Animation
Event handling
There is a humorous Photoshopped screen shot of a "Stack Overflow" post that pokes some fun at the overuse of jQuery. Enjoy:
I was initially against jQuery and, for new programmers, I still am. It is a pure JavaScript framework that has several benefits; here are some of the major ones:
crossbrowser support
easy element selection
customizable plugins
large support community
very popular
Some would argue that it is large, which could affect your web performance... and they would be right. However, because of its popularity, it is likely to have already been used on some site you've visited before. Most browsers these days are good about caching scripts/images, so that download hit is reduced over time.
On the other hand, many new programmers that rely on the framework become very dependent on it, so much so that they lose their ability to evaluate the best tool for the job, and use the most familiar tool that they're used to. These same programmers lose their ability to properly debug and become reliant on an API that has no standard.
What I like using it for is it's cross browser support, which is great for event handling; and whenever you apply dynamic styling to elements on the page (or really anything that requires you needing a more advanced set of elements). Element selection is it's #1 tool, where you can select elements by id, type, attribute, classname, tagname, hierarchical relationship,... all sorts of ways.
I want to know the difference between JQuery vs JScript.
JavaScript is a scripting language for the web. Microsoft refers to their implementation of it as "JScript" but in terms of syntax it's pretty much the same.
jQuery is a software library, written in JavaScript, whose intention is to help JavaScript developers when writing code that is to be run in a web page.
How we decide what to use and when to use those two technology.
JavaScript (including jQuery) can be used to add interactivity to a web page beyond that which is possible merely with HTML and CSS. This allows for a more "application-like" experience for the user. Many see it as a bad idea to make a web page which depends on JavaScript, and won't run without it, and insist that JavaScript should only enhance the user experience. However, websites which won't work without JavaScript do exist and are becoming more common.
jQuery runs in JavaScript, and is written in JavaScript. If you are writing JavaScript for a web page, it is often a good idea to also use a library (or framework) like jQuery to make the task of browser-compatibility that much easier. It is like a pre-packaged set of JavaScript routines that you may have otherwise needed to write yourself, packaged in an easy-to-use way.
A drawback of using jQuery is that it is a relatively large file size, which does matter on the web. Some would argue that if you are not using enough of jQuery to justify its file size on your site, you should consider something else (such as a more modular framework, or not using a library/framework at all).
It's perhaps a little redundant now but 'JScript' was originally the name of the Microsoft implementation of Javascript in old versions of Internet Explorer. Thankfully it's long since disappeared although if you find references to it in older literature just replace with 'Javascript'.
Back to the questions, if you're new to this, I'd strongly recommend going for JQuery (or another Javascript library) instead of raw Javascript. You can do very complex things with one line of JQuery that would take a lot of coding and debugging if you were to use raw Javascript. Ultimately you will need an understanding of the underlying language to take full advantage of JQuery but if you want something you can deploy today, start with JQuery rather than Javascript.
I have been recently struggling with the same question, jQuery or JavaScript. Coming from a coding background that includes several old school programming languages (C, perl, ksh, and more recently Java and C#), I am finding that JavaScript is MUCH easier to quickly understand than jQuery. From a support perspective, the ease of understanding the code is more important than less typing when creating the code. The one answer here, that does have me reconsidering the use of jQuery, is browser compatibility. This one significantly impacts future application support. Based on my experience (over 20 years as a software engineer) the application life cycle spends a lot more time in support than it does in development.