Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have a task which requires me to create rows of tables using MSXML ActiveXObjects. I don't understand what an ActiveXObject has to do with anything. How could I create a table with that? Why wouldn't I just create the table in the HTML DOM?
I read various threads and concluded that there seems to be a layer within the browser that is responsible for data transport of non-html related data. Is this essentially the point of ActiveXObjects?
This is essentially what I am trying to make:
I just don't understand what roll the ActiveXObject plays here
It is actually pretty straight forward: the ActiveXObject is a Microsoft extension to JavaScript that provides you with an interface to Microsoft's software framework ActiveX. ActiveX basically is a set of modular software components which are used to build Microsoft's software products (which are in turn also available as ActiveX components, e.g. Excel).
Wikiped Article
You can find some examples on the use of the ActiveXObject in the link below.
MSDN Documentation
I can only guess what your task is, but if it involves at any point the use of a proprietary Microsoft specific software component, that would be the reason for using the ActiveXObject. Some functionalities provided by the ActiveXObject are however redundant (e.g. Microsoft.XMLHTTP since newer versions of Internet Explorer implement the standardized XMLHttpRequest interface).
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 3 years ago.
Improve this question
Recently I started learning web development. I tried to read the HTML and CSS codes of some famous websites in my web browser. But I observed that they intentionally mess everything such as changing the real names of the bootstrap classes, while looking at the design architecture and page layout anyone could guess what kinds of technologies are used.
What would be the possible reasons?
I think it's not about security because any average programmer can still know everything about their front-end technologies if he puts some efforts.
There are multiple reasons.
Some companies, indeed, try to obfuscate some of all of the code to hinder some of the attacks. That is not 100% proof, of course, because a sophisticated actor can still reverse engineer almost any code that's out in the open.
However, most of the times it's simply how modern frontend development is done nowadays. The trend has been moving more and more towards using various build, bundle, code-minification and packaging tools. Like Webpack, for example.
What you see simply is a result of source code being processed packaged for optimal delivery and running in the browser.
The days when we could view web-page source and inspect pure HTML/JS/CSS, as it was written by the original developer, are long gone.
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 7 years ago.
Improve this question
I have a Dutch Radio Station called FinioxFM and I would like to get information from my ICEcast server to my website. I'm using Airtime, I've searched all over the internet and I couldn't find a answer. I saw a lot op options but they were all from 2007 or 2010 and I didn't know if they would still work now. My question is how do I get this information from my ICEcast server. Or is there a simple way with Airtime? Do I use HTML, Java Script or PHP? What are my options?
Using Airtime V2.5.1 and a direct link to my stream is http://radio.finiox.com:8000/live - My website is http://www.finiox.com
Thanks for helping me out!
You're using a rather old version of Icecast, that leads to three options:
Upgrade to latest version (2.4.1) and use the JSON API. (Official packages for many distributions available at http://icecast.org/download/)
Retrofit the JSON API files (status-json.xsl and xml2json.xslt) and put them in your webroot
Write custom XSLT and access that. Some old examples are here: http://ruecker.fi/foss/icecast/xslt/
Please note that both option 2 and 3 mean that you need to do the query and inclusion on the server side. While on Icecast 2.4.1 or newer you also query that data directly from the client web browser, as Icecast supports sending CORS ACAO headers. (See default config and documentation)
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 have a question about the design of a web application with JavaScript: Should a web application be designed to work without JavaScript, and then later add JavaScript for users that have it? Or should I design a web application with JavaScript in mind and then add fallback functionality for user that do not have JavaScript.
I hope this question makes sense. Let me know if you need me to clarify something.
Thanks.
The terms, that describe what you are looking for are "Progressive Enhancement" and "Graceful Degradation".
Here is good article describing what you already have in your question in more detail:
A List Apart: Understanding Progressive Enhancement
An article that could help you on your decision:
Dev.Opera: Graceful degradation versus progressive enhancement (The named reasons are still valid, despite the fact that the article is marked as outdated)
I favor progressive enhancement in most cases, since it is more accessible when it comes to different output devices, software and the capabilities of the user using that website.
Answers like "there are so few people with JavaScript disabled" are just one side of the medal. Not relying on JS also could improve your site experience to non-graphical clients like search engine robots (how should they load AJAX content, when that is only accessible via JS?) or screen reader software. In fact there are many more good reasons not to rely on on JS.
At this time of age there are so few people with javascript disabled, that there is no signifcant benefit for creating a static version. Try to imagine who is your visitor and if he/she would even know how to disable it.
I suggest you to design a web application with JavaScript in mind and then add fallback functionality for user that do not have JavaScript.
Now a days everything runs on JS only. You should create some kind of services/API on server side and a separate project for UI, this is the trend being followed these days.
UI project can be based on any JS framework or it can even be a simple MVC/.net project. This approach can decouple stuff, and thereafter you can create 2 UI projects one for JS users and one for the users who do not have JS.
seems a bit of a work but, it will pay in the long run.
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
Javascript : What are the different conditions when javascript work in IE but not in Firefox or some other browser?
one that i know of is that while using certain window events..
What other scenarios can cause javascript to not work properly?
The answer is too complex to fully list here. Use sites like http://caniuse.com that will tell you which JavaScript is available in which browser.
Generally speaking, all browsers implement JavaScript differently. Microsoft have long been stuck in their own world, implementing their own ways to do things, whereas everyone else seems to try and conform to the standards as much as possible. Microsoft are coming around to the "standards" way of doing things, and from what I hear, IE11 will be a massive step in this direction.
As already mentioned, you can use http://caniuse.com/ to find what you can and can't do in different browsers, but then you'll likely end up doing what many others have done...write your own API which works around these to achieve a task...which is a bit unnecessary, unless you can find a ground-breaking way to implement your API that will be beneficial to other developers.
APIs like jQuery already work around these differences. The aim with these libraries is to provide clean JavaScript, whilst being completely transparent from the underlying JavaScript implementation.
Also, look into "shim"/"polyfill" implementations. These are used when a core feature that is recognised as part of an ECMAScript version has not been implemented in the browser. These provide the implementation for you, if it is not natively supported.
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 4 months ago.
Improve this question
Does anyone know or have an opinion on whether AppEngine will add javascript as a supported language/framework and in what timeframe?
See this: http://helma.org/wiki/Helma+NG/Running%20Rhino%20and%20Helma%20NG%20on%20Google%20App%20Engine/
Because Java now supports JavaScript as part of its standard runtime, you can do all sorts of cool stuff.
I spoke to the Google team at Google I/O and native JavaScript on the server side is not on their near-term roadmap.
Given that JavaScript is rarely used as a server-side language, that seems very unlikely to me. It's not like doing so would add a lot of potential users.
(Disclaimer: I work for Google, but nothing I write here should be taken as Google's stance on things, and I don't know anything about the AppEngine team's plans :)
EDIT: To answer Pointy's point, I think there's a big difference between JavaScript being supported and it being something you can get working if you try hard enough via Rhino and Java. Put it this way: if some obscure change to the Java support made life better for most Java users but broke a bit of JavaScript via Rhino, I'd expect that to have a relatively low priority for the team.
Appengine now supports Node.js using the flexible environment. It's taken a while, but see https://cloud.google.com/appengine/docs/flexible/ for info.
Recently, Google released/improved Google Apps Script which allows you to script the cloud using JavaScript.
My old answer for your reference is no longer applicable:
You might want to check out:
http://www.appenginejs.org/
I believe the short answer to direct JavaScript support by Google Apps Engine would be no.