The ability to render any React component over a map means you make dynamic map features that feel very fast -- Ivan's library calculates the co-ordinates independently of Google Maps, so you can treat your React code separately instead of worrying too much about how it relates to Google Maps.
Now every object on the map can be hovered (however, you can still use css hover selectors if you want). If you try zooming out here example, you will still be able to hover on almost every map marker.
This algorithm allows you to tweak hover probability of map objects, for example making some objects "more hoverable". distance_hover example with different hover probabilities
The main example shows a map combined with fast infinite scrolling, SVG icons, and balloons made with React.
MyScript is a service for handwriting and handwritten shape recognition. Gregory Pakosz sent in some Polymer MyScript components for interacting with the service. The components are built with MyScriptJS, and they cover things like mathematical expression and text recognition.
The demos on the MyScript Web Components homepage are interactive, so if you select the <myscript-math> example and press play you should be able to draw some equations and see the results.
Normally when I think of Google I think Java and Python. Other services including Heroku and Azure support a wide range of platforms, including Node, so it's exciting to see Google offering MEAN.
The developer guide is here: MEAN development stack on Google Compute Engine, but it's worth noting that the MEAN stack can be brought up with click-to-deploy. That means you can get MongoDB, Express, and Angular running in minutes, using a web-based wizard.
I'm not exactly sure how the pricing works with MongoDB, because SQL database pricing is different from Compute Engine. I created a click-to-deploy MEAN project and it seemed to show all the resources under Compute Engine, so I think that means all prices are based on CPU/disk usage.
I make a lot of Express apps, and Google's developer tools (including the web console) seem compelling even next to Heroku and Azure, so I'd definitely like to try this for a real project soon!
Sponsored Content This post is about a commercial product that we think will appeal to DailyJS readers.
Despite that, optimized code is often confused with obfuscated code. For example, compressed code is completely encoded, which at first glance may seem to be highly obfuscated, but a simple run is often enough to retrieve something very similar to the original code. In short, these tools do a good job optimizing your code, but they don't protect it. (fiddle: demo, Google Compiler optimized demo and beautified optimized demo).
JScrambler goes beyond these libraries by offering advanced obfuscation (JScrambler obfuscated version) that can protect your code. It leverages obfuscation by inserting a number of different code traps to control execution and to enforce licensing. For example, you can lock the code to a list of predefined domains. If someone tries to execute the code elsewhere, the code breaks.
As expected, these techniques have a cost in file size and execution, but because JScrambler also has optimization features, this extra cost can be controlled -- as proven by running the two protected demos. You don't have to give up performance to get protection.
Ray Wang sent in JellyReader (GitHub: NimbusBase / jellyreader, License: MIT), an entirely client-side feed reader that is powered by Google Drive and Dropbox. NimbusBase has been used to unify access to Google Drive and Dropbox, so the data is ultimately stored as flat files.
JellyReader itself is implemented with jQuery and AngularJS. It allows you to add feeds, view entries, toggle the read state, and you can also star your favourite items. I tried it out with my Dropbox account, and Dropbox states that the application only has access to an "app" folder:
I added DailyJS to it:
And the stories are rendered as you might expect:
After playing around with the web interface for a while, I wondered what the files on Dropbox looked like. Each data collection is serialised in a directory, and there is a file per item. So feeds have a directory, and stories do as well. UUIDs are used to ensure the filenames don't clash.
Presumably NimbusBase data has the same structure on Google Drive.
The JellyReader source uses lots of third party components, including jFeed which I haven't seen for a few years. I actually like the flat file approach for personal, self-hosted applications like this, although it would be interesting to see a comparison with a Dropbox Datastore implementation.
Although tools like Chrome DevTools are excellent, the advantage of spy-js is it can work with any browser. It also allows performance between browsers to be compared more easily.