CSS and JavaScript Live Editing


As planned we're continuing our tradition to present JavaScript Developer Toolkit. Last time we've talked about Emmet and today's article I'd like to devote to HTML/CSS/JavaScript editing.

How often do you change your CSS rules and JavaScript within your browser? How often do copy/paste the changes made into appropriate resource files? It's time to do this Zen style.

IDE integration


This is my preferable way to develop and live-editing the changes. Let me show you why. Wouldn't it be cool if you could develop using your beloved IDE with all the neat plugins it offers and see the changes reflected live in the browser? Well - you can, with both Sublime Text and Webstorm we've talked about during our previous JavaScript toolkit article. You do this by installing JetBrains IDE Chrome extension for Webstorm:


or Emmet LiveStyle for Sumblime Text:


Look into their sites and see how properly things should to be configured. Both tools only offer support for Chrome, so Firefox fans will have to wait for now...

Browser Extensions


As time passed, passionate developers have been creating bunch of extensions both for Chrome and Firefox to enable this functionality. The most prominent ones are Chrome DevTools Autosave and EditCSS. However this work has not only inspired the developer community, but also the creators of both most commonly used browsers. As a result as of Firefox 11 and Chrome 28 the functionality has been bundled with the browsers, making the extensions obsolete.

Browser built-in capabilities


While Firefox has done some progress and enabled the live editing of CSS using it's Style Editor, the real advancement came from Google camp with the introduction of workspaces. It allows one to save both CSS rules and JavaScript code and even supports Sass debugging of Sass (.scss) files in the Sources panel, and view the results without having to leave DevTools or refresh the page. When you inspect an element whose styles are provided by a Sass-generated CSS file, the Elements panel displays a link to the .scss file, not the generated .css file. We'll talk more about Sass and Compass in the future. Find the time to watch the whole presentation about this feature:

Comments

Post a Comment

Popular posts from this blog

Rust Static Analysis and Blockchain Licensing

Image
What is static analysis? Static analysis is an analysis of software artifacts. For example requirements or code, carried out without execution of these software development artifacts. Static analysis is usually carried out using supporting tools. In other words, we can say that static analysis is an examination of requirements, design, and code that differ from more traditional dynamic testing in several important ways. The main goal behind this analysis is to find the bugs, whether or not they may cause failures. As with reviews, static analysis finds bugs rather than failures. The general name for static analysis is linting. lint, or a linter, is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs. Simply put, a linter is a tool that programmatically scans your code with the goal of finding issues that can lead to bugs or inconsistencies with code health and style. Some can even help fix them for you! How to analyse
Read more

Length extension attack

Image
What is length extension? When a Merkle–Damgård based hash is misused as a message authentication code with construction H(secret ‖ message), and message and the length of secret is known, a length extension attack allows anyone to include extra information at the end of the message and produce a valid hash without knowing the secret. Quick sidebar, before you freak out: Since HMAC does not use this construction, HMAC hashes are not prone to length extension attacks. So, a length extension attack is a type of attack where an attacker can use Hash(message1) and the length of message1 to calculate Hash(message1 ‖ message2) for an attacker-controlled message2, without needing to know the content of message1. Algorithms like MD5, SHA-1 and most of SHA-2 that are based on the Merkle–Damgård construction are susceptible to this kind of attack. Truncated versions of SHA-2, including SHA-384 and SHA-512/256 are not susceptible, nor is the SHA-3 algorithm. A bit more details
Read more

CAP Theorem and blockchain

Image
In theoretical computer science, the CAP theorem states that it is impossible for a distributed data store (such as a blockchain network) to simultaneously provide more than two out of the three guarantees: Consistency, Availability & Partition tolerance. CAP Theorem – the parts C: Consistency – At any given time, all nodes in the network have exactly the same (most recent) value. A: Availability – Every request to the network receives a response, though without any guarantee that returned data is the most recent. P: Partition tolerance – The network continues to operate, even if an arbitrary number of nodes are failing. Due to the nature of distributed data stores (such as blockchain), Partition tolerance is a given fact; there will always be failing/unreachable nodes in the network (not least because of the unstable nature of the internet). CAP Theorem states that one has to choose between C (Consistency) or A (Availability) when in the presence of P (Partition): Av
Read more