jQuery has released two new Alpha versions: 3.0 (for IE9+) and 3.0 Compat (for IE<9). There are several updates that could break existing code, but as usual, they are well documented, and jQuery Migrate should help you find any potential stress points.
Styling SVG<use> Content with CSS, by who else but SaraSoueidan, is much more than the title indicates, getting into how you should structure your code, how the browser creates the Shadow DOM, dealing with cascades and overrides, using tricks like all and currentColor, and even getting into what’s coming down the pipe, like CSS variables… Oh yeah, Sara also talks about styling SVG <use> content with CSS… :-)
The Front-End Developer’s Dilemma by GeoffGraham is very dear to my heart. I used to just tell people I do “computer crap” and would then expand on that incrementally until I felt they realized enough about technology that I could really explain what I do without making their eyes roll into the back of their heads: “I do web stuff.” “I’m a web developer.” “I do front-end development.” “I specialize in HTML, CSS, and JS, but work with WP and even SVG a good bit too, but I also think about and push-back a lot when it comes to UI and UX.” Having to explain the difference between web design and web development always surprises me, but I am the first to admit that I am not, and correct others when they wrongly label me as, a programmer; I know dudes that are computer programmers, and that is not me… :-)
And finally, JoshWorth‘s “Tediously Accurate Map of the Solar System is mind-bogglingly, brain-numbingly, cortex-meltingly amazing… I admit I did not make it all the way to Pluto… After an insane amount of scrolling, I had passed Saturn (no, I did not make it to Uranus, snarf! ;-), yet my horizontal scroll bar said I was still only halfway… I got new respect for you, New Horizons…
As fairly-new web technologies, Service Workers, Web Workers and WebSockets all started, stalled, and then sort of made a resurgence. And so I find myself somewhat confused by exactly what each does, what the differences between them are, and what purpose each ideally serves.
I tried searching for some comparison articles, but was surprised by the lack of search results comparing all three of these technologies. I found two that come close…
…but neither compares the three I was curious about… So I decided to get to know them all a little better and document my findings here (so I could come back and remind myself again later…).
Background service that handles network requests. Ideal for dealing with offline situations and background syncs or push notifications. Cannot directly interact with the DOM. Communication must go through the Service Worker’s postMessage method.
Mimics multithreading, allowing intensive scripts to be run in the background so they do not block other scripts from running. Ideal for keeping your UI responsive while also performing processor-intensive functions. Cannot directly interact with the DOM. Communication must go through the Web Worker’s postMessage method.
Creates an open connection between a client and a server, allowing persistent two-way communication over a single connection. Ideal for any situation where you currently use long-polling such as chat apps, online games, or sports tickers. Can directly interact with the DOM. Communication is handled through the WebSocket’s send method.
Service worker is a programmable network proxy, allowing you to control how network requests from your page are handled.
Service Workers are pretty perfect for creating offline-first web apps. They let you interact with the server when you can (to fetch new data from the server, or push updated info back to the server), so your app can work regardless of your user’s connectivity.
For example, an email client could fetch emails when the app loads, then, if the user loses connectivity for a brief period, the app could still continue to register read/unread and deleted states and store new emails to send until connectivity is restored, then send those updates back to the server via a Service Worker. To the user, all the time they were offline, the app continued to work, so they “got stuff done”, and your app just did its job, by collecting changes and updating the server as soon as it could.
While Service Workers cannot directly interact with the DOM, your main JS code can do that based on the messages you receive back from a Service Worker. Service workers also stop when not being used and restart when needed, so there is no persistent “state”; you would need to rely on some form of local storage (localStorage, IndexedDB, etc.) for such persistence. It is important to remember that a Service Worker’s life cycle is completely separate from your webpage.
Workers utilize thread-like message passing to achieve parallelism.
Web Workers are pretty perfect for any web app that has intense functions to perform. They let you push the intense functions into a background thread so your main JS can keep on rocking, like maybe setting up event listeners and other UI interactions. Then, when the intense functions are done, they report back with their results, letting the main JS update the web app.
For example, a site that fetches and displays data in a series of dynamic charts could have each chart fetch its own data via a separate Web Worker. While the Web Workers are fetching, processing, and calculating their data, the main JS could be setting up menus, event listeners, initializing date pickers and custom UI elements, etc. And when each Web Worker is done with its process, it can report back to the main JS with its resulting data to be used to create its respective chart.
While Web Workers cannot directly interact with the DOM, your main JS code can do that based on the messages you receive back from a Web Worker. And as they are completely separate threads, Web Worker code must exist in a separate file and does not have access to your main JS. Workers can also spawn subworkers, to create additional background threads.
There is an [sic] persistent connection between the client and the server and both parties can start sending data at any time.
WebSockets are pretty perfect for any web app that needs to communicate frequently with a server, and could benefit from the server being able to communicate directly with the client.
For example, a chat app could create a WebSocket connection so that as each person types, their message is pushed to the server and the server can then send that message directly to the other person(s) in that chat. The previous methods for doing this would be using setTimeout, setInterval and Ajax requests. But these approaches created intensive loops that have to keep asking the server: “Do you have anything yet?” No. “Do you have anything yet?” No. “Do you have anything yet?” No…
So, with WebSockets we finally can directly affect the DOM and, as they are part of the main thread, WebSockets do have access to your main JS.
So, while WebSockets and Service Workers kind of overlap, both being used for client-server communications, WebSockets would be used more for continuous communication so both the client and the server can send messages to each other without having to create new connections, and Service Workers would be used more for one-off client-server communications like syncing an app and the database after the app was offline for some time, like a burst that can then be dropped when the sync is completed.
And Web Workers are something completely different, allowing processor-intensive functions to run in a separate, background thread, while allowing the main JS to run and the UI to setup and operate more smoothly while those intensive functions are still running in the background.
Well, I hope this quick look at Service Workers, Web Workers and WebSockets helped clear up the similarities, differences, and purposes of these great new web technologies for you, as much as it did for me! As always, please feel free to drop any questions/thoughts into the comments below; discussion is always fun. :-)
ZOMG!!! A Bluetooth-connected Star Trek communicator… Too bad (or maybe Thank God!) the pre-order link in the article is busted, and the company’s own website is rather junky… I have been saying since the very first flip-phone came out, that someone needs to make one that makes the communicator sound when it opens, but this is SO much better!
Here are a couple Interactions for Draggable Elements. While I am inspired by the tech, I find the interactions completely unintuitive, and could not suggest using either in a production site. But again, nice animation, and good inspiration for a better interface.
The Web’s Cruft Problem. Certainly not news to anyone, and a hard battle to fight. Not technologically, as developers we can pull bullshit out, push the remains together to reduce requests, minify those requests, then distribute it all around the world via CDNs for nice, fast, reliable content delivery. The hard part is that our bosses always want to make money, so we can all get paid. The examples of “solving” this problem (Flipboard and Facebook’s Instant Articles) aren’t doing it for free, but businesses should realize that the faster people can get things, the more they will consume, and the more they will return, and the more they will consume.·. And they won’t have to pay Flipboard or split ad revenue with Facebook…
Code reviews are smart business. Not only do they ensure that you are about to launch the most efficient way to do something, but they also ensure that all internal standards have been met, that team members understand how something new works, and they are a great way for team members to knowledge-share! But it’s also incredibly rare for teams to be allotted time to perform this task. Time, money, etc. But even when it is done, I have never seen anyone do it with CSS! Which is crazy, because that mess can become a far worse pile of spaghetti in no time at all! Anyhow, here is an example of what a CSS code review might look like. Enticing…