Skip to main content

Home/ Future of the Web/ Group items tagged Javascript

Rss Feed Group items tagged

Gonzalo San Gil, PhD.

Turn an old smartphone into a home automation gizmo - 1 views

  •  
    "At the recent Embedded Linux Conference and OpenIoT Summit, Mozilla Technical Evangelist Dietrich Ayala proposed a simple and affordable solution to home automation: A discarded smartphone can handle some of the most useful home automation tasks without requiring expensive hubs and sensors - or risking data security in the cloud."
  •  
    "At the recent Embedded Linux Conference and OpenIoT Summit, Mozilla Technical Evangelist Dietrich Ayala proposed a simple and affordable solution to home automation: A discarded smartphone can handle some of the most useful home automation tasks without requiring expensive hubs and sensors - or risking data security in the cloud."
Gonzalo San Gil, PhD.

No one should have to use proprietary software to communicate with their government - F... - 0 views

  •  
    "by Donald Robertson - Published on May 04, 2016 12:36 PM The Free Software Foundation (FSF) submitted a comment to the U.S. Copyright Office calling for a method to submit comments that do not require the use of proprietary JavaScript. Proprietary JavaScript is a threat to all users on the Web. When minified, the code can hide all sorts of nasty items, like spyware and other security risks. Savvy users can protect themselves by blocking scripts in their browser, or by installing the LibreJS browser extension and avoiding sites that require proprietary JavaScript in order to function. B"
  •  
    "by Donald Robertson - Published on May 04, 2016 12:36 PM The Free Software Foundation (FSF) submitted a comment to the U.S. Copyright Office calling for a method to submit comments that do not require the use of proprietary JavaScript. Proprietary JavaScript is a threat to all users on the Web. When minified, the code can hide all sorts of nasty items, like spyware and other security risks. Savvy users can protect themselves by blocking scripts in their browser, or by installing the LibreJS browser extension and avoiding sites that require proprietary JavaScript in order to function. B"
Gonzalo San Gil, PhD.

OS.js Is A New Javascript Based Open Source Operating System Running In Your Browser - 2 views

  •  
    "hort Bytes: OS.js is a free and open source operating system that runs in your web browser. Based on Javascript, this operating system comes with a fully-fledged window manager, ability to install applications, access to virtual filesystems and a lot more. Read more to know about the OS in detail."
Gary Edwards

Developer: Dump JavaScript for faster Web loading | CIO - 0 views

  • Accomplishing the goal of a high-speed, responsive Web experience without loading JavaScript "could probably be done by linking anchor elements to JSON/XML (or a new definition) API endpoints [and] having the browser internally load the data into a new data structure," the proposal states.
  • The browser "then replaces DOM elements with whatever data that was loaded as needed.
  • The initial data and standard error responses could be in header fixtures, which could be replaced later if so desired. "The HTML body thus becomes a templating language with all the content residing in the fixtures that can be dynamically reloaded without JavaScript."
  •  
    "A W3C (World Wide Web Consortium) mailing list post entitled "HTML6 proposal for single-page Web apps without JavaScript" details the proposal, dated March 20. "The overall purpose [of the plan] is to reduce response times when loading Web pages," said Web developer Bobby Mozumder, editor in chief of FutureClaw magazine, in an email. "This is the difference between a 300ms page load vs 10ms. The faster you are, the better people are going to feel about using your Website." The proposal cites a standard design pattern emerging via front-end JavaScript frameworks where content is loaded dynamically via JSON APIs. "This is the single-page app Web design pattern," said Mozumder. "Everyone's into it because the responsiveness is so much better than loading a full page -- 10-50ms with a clean API load vs. 300-1500ms for a full HTML page load. Since this is so common now, can we implement this directly in the browsers via HTML so users can dynamically run single-page apps without JavaScript?" Accomplishing the goal of a high-speed, responsive Web experience without loading JavaScript "could probably be done by linking anchor elements to JSON/XML (or a new definition) API endpoints [and] having the browser internally load the data into a new data structure," the proposal states. The browser "then replaces DOM elements with whatever data that was loaded as needed." The initial data and standard error responses could be in header fixtures, which could be replaced later if so desired. "The HTML body thus becomes a templating language with all the content residing in the fixtures that can be dynamically reloaded without JavaScript." JavaScript frameworks and JavaScript are leveraged for loading now, but there are issues with these, Mozumder explained. "Should we force millions of Web developers to learn JavaScript, a framework, and an associated templating language if they want a speedy, responsive Web site out-of-the-box? This is a huge barrier for beginners, and right n
Gonzalo San Gil, PhD.

NoScript - JavaScript/Java/Flash blocker for a safer Firefox experience! - NoScript Rel... - 0 views

  •  
    "Congratulations, you've got the latest version. If you find any bug or you'd like an enhancement, please report here or here. Many thanks! Main good news Script Surrogate replacement for googletagservices.com (thanks Guest and barbaz). Fixed XSS false positive in the new gmx.com webmail login and in other services (e.g. mail.com) using the same back-end. Better compatibility with script inclusion enforcers such as Require.js. Safer toStaticHTML() implementation (thanks .mario for reporting). Several XSS filter improvements (thanks Masato Kinugawa for reporting). CAPS-independent, finer-tuned version of the "Allow local links" feature."
  •  
    "Congratulations, you've got the latest version. If you find any bug or you'd like an enhancement, please report here or here. Many thanks! Main good news Script Surrogate replacement for googletagservices.com (thanks Guest and barbaz). Fixed XSS false positive in the new gmx.com webmail login and in other services (e.g. mail.com) using the same back-end. Better compatibility with script inclusion enforcers such as Require.js. Safer toStaticHTML() implementation (thanks .mario for reporting). Several XSS filter improvements (thanks Masato Kinugawa for reporting). CAPS-independent, finer-tuned version of the "Allow local links" feature."
  •  
    "Congratulations, you've got the latest version. If you find any bug or you'd like an enhancement, please report here or here. Many thanks! Main good news Script Surrogate replacement for googletagservices.com (thanks Guest and barbaz). Fixed XSS false positive in the new gmx.com webmail login and in other services (e.g. mail.com) using the same back-end. Better compatibility with script inclusion enforcers such as Require.js. Safer toStaticHTML() implementation (thanks .mario for reporting). Several XSS filter improvements (thanks Masato Kinugawa for reporting). CAPS-independent, finer-tuned version of the "Allow local links" feature."
Gonzalo San Gil, PhD.

Whitepapers - www.technicalinfo.net - 0 views

  •  
    "Understanding the cause and effect of CSS (XSS) Vulnerabilities"
Gonzalo San Gil, PhD.

The JavaScript Trap - 1 views

  •  
    "by Richard Stallman You may be running nonfree programs on your computer every day without realizing it-through your web browse"
Gary Edwards

Red 4.0 - A Full Ruby Runtime in Your Browser « Trek - 0 views

  •  
    Javascript has a major advantage of being (likely) the most installed programming language in history. It's experiencing a renaissance lately where people actually learning it, not just copying code found on someone's website. ECMAScript Harmony will bring some much needed fixes to the language (although I think ECMAScript 4 would have been a true game-changer for the web). Regardless, until we have more mature tools for sever- and DB-side javascript, Javascript is really a browser language (and faces an army of entrenched programmers who'd rather use some other language). To the second argument, I say: Javascript is an amazing language, but you can't declare it off limits to people who prefer other languages. Programming is about choice. On the server we get to use whatever combinations of web server, database, programming language, and development environment we like. Not so for the browser. We're stuck with Javascript whether we like it or not. We can't stay away from it, we can't use something else. Everyone who dislikes working in Javascript is perfectly justified because he has no other avenue. When all browsers support and are prepackaged with VMs for many languages, I'll be the first to sound the clarion: if you don't like JS, get the hell away from it. Until then, you're stuck with us and we're stuck with you. To the third: again, it's really all about to choice. If you prefer Javascript keep using it, make it better, steal ideas from other languages, and seed the community with new ideas of your own. Nobody will complain about a better overall development community. If you'd like to see Red in Python, PHP, C#, or language X then steal Jesse's code. Red was a herculean effort on Jesse's part. I know he's worked on nothing else for two months and future ports of Red to other languages will benefit from this effort.
Gary Edwards

More WebKit Goodies - CSS Transforms and Transitions - the OSX Dock example | theChrisW... - 0 views

  •  
    Chris Walker provides some interactive demonstrations of the powerful webkit-transforms that are placed in CSS. So, what can we do with all this magic? Well, the culmination of the Chris Walker demo is a Mac OSX style Dock menu, using no Javascript...

    ".....Yes, that's right a bulging docked menu, with no javascript. Just so you remember, there no javascript in the demo. Check out the Javascript free OSX Dock Menu Demo.

    This demo actually proves an important point Tom Yager made earlier about Ajax; Will JavaScript inconsistencies break the Web?

    Taking AJAX literally makes lousy Web apps: "As little as possible should be the rule for JavaScript, which must play a supporting role to CSS and HTML". Tom concludes that it's best to follow the WebKit model, putting everything possible into first CSS4, then HTML5, and then JavaScript. I would argue that the proliferation of JavaScript libraries is a good hedge against the non interoperable future Yager warns of. But hey, why stop the guy when he's on a roll. CSS4! I guess the webkit-transforms have been officially christened. Thanks Tom.

    ~ge~
Gary Edwards

When You're a WebKit Hammer, Everything Looks Like an Open Web Nail ... As it should! - 0 views

  • You’re still waiting for me to explain what I meant when I referred to JavaScript as a last resort. I hinted at it in the preceding paragraph. Not the part on JavaScript debugging, but my reference to CSS and HTML. These do a lot more than paint screens. They are a browser's client-side framework. Everything they do is handled as native code. In other words, they're fast. CSS3 and HTML5 are too inconsistently implemented (if at all) across browsers to design to unless you're specifically targeting Safari, iPhone, or other WebKit-based browsers.
    • Gary Edwards
       
      Tom makes the point that the use of AJAX JavaScript breaks Web interoperability. He further points out that HTML is a static layout language, where CSS is dynamic and adaptive. (Use HTML5/DOM for document structure, and CSS4 for presentation - layout, formatting and visual interface).

      It is the consistency of the WebKit document model across all WebKit browsers that makes for an interoperable Open Web future. I would not however discount the importance of Firefox and Opera embracing the WebKit document model (HTML5, CSS4, SVG/Canvas, JavaScript, DOM2). That's our guarantee that the future of the Open Web will actually be open.

      Tom goes on to suggest that instead of "AJAX", developers would be better off thinking in terms of "ACHJAX": Asynchronous CSS4 - HTML5 - JavaScript and XML ..... with the focus on getting as much done in CSS4 as possible.
  •  
    InfoWorld's Tom Yager makes the case for the WebKit visual document model over AJAX. The problem with AJAX as he sees it is that it's JavaScript heavy. And that breaks precious Web interoperability. He makes the point that if something can be done in CSS, it should. He also argues that WebKit is the best tool because the document model is that of advanced HTML5 and CSS3.

    "... These [WebKit] browsers also share a stellar accelerated JavaScript interpreter that makes the edit/run/debug cycle go faster. They are also the only browsers that deliver on CSS4 and HTML5 standards (with some elements that are proposed to the W3C standards body). Sites that are visually rich may start sprouting "best viewed with Safari" banners until other browsers catch up. The banner would also let users know that your site is optimized for iPhone....."

    Humm. Did you catch that? CSS4!!! I guess he's referring to the WebKit penchant for putting advanced graphical transitions and animations into CSS instead of relying on a device specific or OS specific API.

    Placing the visual interface instructions in the documents presentation layer (CSS4) is a revolutionary idea. The WebKit model will go a long way towards creating a global interoperability layer that rides above lower device, OS, browser and application specifics. So yes, by all means let's go with CSS4 :)

Gary Edwards

Mozilla's Bespin project encourages experimentation - Ars Technica, Paul Ryan - 0 views

  •  
    "The Bespin project, which aims to develop a browser-based IDE, has attracted significant attention in the Web development community. Ars looks at some of the buzz around Bespin and the project's innovative use of the HTML canvas element.........." Good stuff here. The Bespin project started off as a JavaScript code editor written in JavaScript, but the really exciting part looks to be the innovative use of the canvas element and the JavaScript API for drawing. There is also the development of using Bespin as a Web page editor using the new canvas text rendering API! One of the advantages Flash has over WebKit is the proliferation of SWF based IDE's. Silverlight will similarly have an excellent collection of IDE's. There are no WebKit - Canvas based IDE's today, but Bespin will perhaps change that. I can also imagine that many of the Flash based IDE's like Swifft tools and my favorite, "SwishMAX", could provide multiple vector graphics; including Canvas! Note that Adobe is scheduled to discontinue all support for SVG this coming March of 2009, moving everything to the proprietary SWF.
Gary Edwards

Desktop Web Applications using Sproutcore | rapid apps group - low cost, ethical web de... - 0 views

  •  
    Good article discussing the rapid advance of a WebOS for Web Applications based on the WebKit JavaScript model. Author focuses on Apple's SproutCore - Object C framework, but provides a very broad scope of discussion. Interesting stuff concerning the relationship between JavaScript, the SproutCore Framework, and Ruby. I found the link to this at the ReadWriteWeb story, "The Future of the Desktop" ........ "Desktop web applications offer the convenience of desktop applications and the interconnected power of web applications. This article looks at what they are, how they may evolve and focuses on Sproutcore, an open source framework for building them: The Internet is still evolving and the familiar struggle over who will control the platform of future web applications is still ongoing. Companies like Microsoft and Adobe provide platforms that build slick web applications but their aim is to dominate with proprietary systems that will effectively replace the browser. On the other side you have Google and Apple who have developed or support open web standards for developing web applications. If the proprietary companies win, future web applications could be locked into their systems and the incredible innovation that has driven the web to date may begin to falter.
Paul Merrell

Firefox, Google's Chrome speed past IE, Opera | The Open Road - CNET News - 0 views

  • ZDNet Australia on Tuesday released updated browser speeds, as measured by the industry-standard SunSpider JavaScript test, and the results should give pause to proprietary-browser makers Microsoft and Opera Software: Every open-source browser completely obliterated the proprietary browsers in terms of performance, and by a huge margin. The test compared Microsoft's Internet Explorer 8 Release Candidate 1, Opera 10.00 Alpha, Firefox 3.1b1, Chrome 2.0.158.0, and the WebKit r40220 developer project included in Chrome and Apple's Safari. Google Chrome and Mozilla Firefox (along with WebKit) left the proprietary competition in the dust:
Paul Merrell

Carakan - By Opera Core Concerns - 0 views

  • Over the past few months, a small team of developers and testers have been working on implementing a new ECMAScript/JavaScript engine for Opera. When Opera's current ECMAScript engine, called Futhark, was first released in a public version, it was the fastest engine on the market. That engine was developed to minimize code footprint and memory usage, rather than to achieve maximum execution speed. This has traditionally been a correct trade-off on many of the platforms Opera runs on. The Web is a changing environment however, and tomorrow's advanced web applications will require faster ECMAScript execution, so we have now taken on the challenge to once again develop the fastest ECMAScript engine on the market.
  • So how fast is Carakan? Using a regular cross-platform switch dispatch mechanism (without any generated native code) Carakan is currently about two and a half times faster at the SunSpider benchmark than the ECMAScript engine in Presto 2.2 (Opera 10 Alpha). Since Opera is ported to many different hardware architectures, this cross-platform improvement is on its own very important. The native code generation in Carakan is not yet ready for full-scale testing, but the few individual benchmark tests that it is already compatible with runs between 5 and 50 times faster, so it is looking promising so far.
Gary Edwards

Adamac Attack!: Evolution Revolution - 0 views

  • HTTP as a universal calling convention is pretty interesting. We already have tons of web services in the cloud using HTTP to communicate with one another - why not extend this to include local code talking with other components. The iPhone already supports a form of this IPC using the URL handlers, basically turning your application into a web server. BugLabs exposes interfaces to its various embedded device modules through web services. It has even been suggested in the literature that every object could embed a web server. Why not use this mechanism for calling that object's methods?
  •  
    Given the increasing number of platforms supporting Javascript + HTTP + HTML5, it's not inconceivable that "write-once, run anywhere" might come closer to fruition with this combo than Java ever achieved. Here's how this architecture plays out in my mind. Javascript is the core programming language. Using a HTTP transport and JSON data format, components in different processes can perform RPCs to one another. HTML5 features like local storage and the application cache allow for an offline story (the latest build of Safari on iPhone supports this). And of course, HTML + CSS allows for a common UI platform.
Gary Edwards

Brendan's Roadmap Updates: Open letter to Microsoft's Chris Wilson and their fight to s... - 0 views

  • The history of ECMAScript since its beginnings in November 1996 shows that when Microsoft was behind in the market (against Netscape in 1996-1997), it moved aggressively in the standards body to evolve standards starting with ES1 through ES3. Once Microsoft dominated the market, the last edition of the standard was left to rot -- ES3 was finished in 1999 -- and even easy-to-fix standards conformance bugs in IE JScript went unfixed for eight years (so three years to go from Edition 1 to 3, then over eight to approach Edition 4). Now that the proposed 4th edition looks like a competitive threat, the world suddenly hears in detail about all those bugs, spun as differences afflicting "JavaScript" that should inform a new standard.
  • In my opinion the notion that we need to add features so that ajax programming would be easier is plain wrong. ajax is a hack and also the notion of a webapp is a hack. the web was created in a document centric view. All w3c standards are also based on the same document notion. The heart of the web, the HTTP protocol is designed to support a web of documents and as such is stateless. the proper solution, IMO, is not to evolve ES for the benefit of ajax and webapps, but rather generalize the notion of a document browser that connects to a web of documents to a general purpose client engine that connects to a network of internet applications. thus the current web (document) browser just becomes one such internet application.
  •  
    the obvious conflict of interest between the standards-based web and proprietary platforms advanced by Microsoft, and the rationales for keeping the web's client-side programming language small while the proprietary platforms rapidly evolve support for large languages, does not help maintain the fiction that only clashing high-level philosophies are involved here. Readers may not know that Ecma has no provision for "minor releases" of its standards, so any ES3.1 that was approved by TG1 would inevitably be given a whole edition number, presumably becoming the 4th Edition of ECMAScript. This is obviously contentious given all the years that the majority of TG1, sometimes even apparently including Microsoft representatives, has worked on ES4, and the developer expectations set by this long-standing effort. A history of Microsoft's post-ES3 involvement in the ECMAScript standard group, leading up to the overt split in TG1 in March, is summarized here. The history of ECMAScript since its beginnings in November 1996 shows that when Microsoft was behind in the market (against Netscape in 1996-1997), it moved aggressively in the standards body to evolve standards starting with ES1 through ES3. Once Microsoft dominated the market, the last edition of the standard was left to rot -- ES3 was finished in 1999 -- and even easy-to-fix standards conformance bugs in IE JScript went unfixed for eight years (so three years to go from Edition 1 to 3, then over eight to approach Edition 4). Now that the proposed 4th edition looks like a competitive threat, the world suddenly hears in detail about all those bugs, spun as differences afflicting "JavaScript" that should inform a new standard.
Gary Edwards

ES4 and the fight for the future of the Open Web - By Haavard - 0 views

  • Here, we have no better theory to explain why Microsoft is enthusiastic to spread C# onto the web via Silverlight, but not to give C# a run for its money in the open web standards by supporting ES4 in IE.The fact is, and we've heard this over late night truth-telling meetings between Mozilla principals and friends at Microsoft, that Microsoft does not think the web needs to change much. Or as one insider said to a Mozilla figure earlier this year: "we could improve the web standards, but what's in it for us?"
  •  
    Microsoft opposes the stunning collection of EcmaScript standards improvements to JavaScript ES3 known as "ES4". Brendan Eich, author of JavaScript and lead Mozilla developer claims that Microsoft is stalling the advance of JavaScript to protect their proprietary advantages with Silverlight - WPF technologies. Opera developer "Haavard" asks the question, "Why would Microsoft do this?" Brendan Eich explains: Indeed Microsoft does not desire serious change to ES3, and we heard this inside TG1 in April. The words were (from my notes) more like this: "Microsoft does not think the web needs to change much". Except, of course, via Silverlight and WPF, which if not matched by evolution of the open web standards, will spread far and wide on the Web, as Flash already has. And that change to the Web is apparently just fine and dandy according to Microsoft. First, Microsoft does not think the Web needs to change much, but then they give us Silverlight and WPF? An amazing contradiction if I ever saw one. It is obvious that Microsoft wants to lock the Web to their proprietary technologies again. They want Silverlight, not some new open standard which further threatens their locked-in position. They will use dirty tricks - lies and deception - to convince people that they are in the right. Excellent discussion on how Microsoft participates in open standards groups to delay, stall and dumb down the Open Web formats, protocols and interfaces their competitors use. With their applications and services, Microsoft offers users a Hobbsian choice; use the stalled, limited and dumbed down Open Web standards, or, use rich, fully featured and advanced but proprietary Silverlight-WPF technologies. Some choice.
Gary Edwards

John Resig - JavaScript iPhone Apps - 0 views

  •  
    Review of JavaScript Apps and developer approaches for the iPhone. JiggyApp, WebTouch, JSCocoa, and PhoneGap are mentioned. WebTouch is very interesting in that it involves a WebKit instance such as that used by wiki-WORD. It's really simple and gives you a good entry point into the world of hybrid HTML/CSS/JavaScript/Objective-C/Cocoa development.
1 - 20 of 42 Next › Last »
Showing 20 items per page