Thanks for highlighting my paper. I agree htmx is an interesting one to cover in future work and I have listed it as a reference on my state manager (https://sidewind.js.org/) as a related approach. It would be highly interesting to rewrite Sidewind as a compiler so I can do more granular bundle per page (or for the entire site if I capture from all the pages as that's enough for many use cases).
For the next paper, I plan to have a look at a couple of disappearing frameworks in detail. Let me know if you have special requests on what to research. :)
I just self-published my first book (http://survivejs.com/). Writing books is way harder than people think. Writing isn't enough as you need to tackle other aspects, such as marketing and sales, as well. If you are not native, you have the extra challenge of learning to write.
In short, it's definitely possible to earn a living out of technical writing. Getting started is the hardest part. If you don't have a reputation, you will need to build one. Growing audience will take time, but it will pay dividends.
To keep this comment short, I'll just link to a series of articles (and presentation slides) I've written about my experiences. Hopefully these help! Here we go:
Yeah, it's bit of a stab. I'm really curious to see how GitHub responds (if they respond). A lot of good could come out of this even if it takes some competition to force some of that.
I see view (or screen) as something that maps to a route. It's true it's definitely a component.
I feel adding vocabulary like this to a system can help with understandability. That's the point I made with a "feature". It's something that could fit between views and components.
That might give you alternative ways to think about contracts. In short, because we aren't contracting right, all parties end up disappointed. I would say this is one of the main reasons why software projects fail. We sell too big projects (more likely to fail), buyers don't know how to buy (or what they need), we specify too much beforehand (and then stick with that...). There are so many traps.
Speaking of outsourcing it all depends on what kind of a relationship you want to build. I think some of this depends on legislation (ie. hire vs. buy). Construct incentives so that they are win-win.
Why not let website visitors make your measurements by loading the JavaScript files from the CDNs in the background?
Something like (untested):
var i = 0;
var urls = [
"http://cdn.jsdelivr.net/jquery/2.0.3/jquery-2.0.3.min.js",
"http://code.jquery.com/jquery-2.0.3.min.js",
...
];
function measureRemaining() {
if(i >= urls.length) return;
var url = urls[i++];
measureLatency(url, function(latency) {
// TODO: post (url,latency) to back-end
measureRemaining();
});
}
function measureLatency(url,responseFn) {
var script = document.createElement("script");
// Bust through browser cache
script.src = url + "?bust=" + Math.random():
var start = new Date().getTime();
script.onload = function() {
var end = new Date().getTime();
var latency = end - start;
responseFn(latency);
};
document.getElementsByTagName("head")[0].appendChild(script);
}
measureRemaining();
In this way, you'll get actual end-user performance from a (hopefully) large number of different network locations. You will probably want to do this in a separate iframe to avoid changing the behaviour of your webpage.
In the context of full web pages how I've seen this done is by embedding a Javascript call that occurs after the page is loaded to your site. I suspect you could do something similar with this resource.
Alternatively you can look at what CDNs are hosting the resources and then just use the existing tools to compare the expected performance of each CDN. Of course this comes with a few caveats:
1/ Performance may be different on a given CDN depending on which "package" the customer has purchased. I know was the case ~1-2 years ago for Akamai.
2/ A CDN may perform well for small objects but not for larger objects, make sure you look at representative benchmarks.
3/ JS CDNs using CDN load balancing services like Cedexis mean more work to find all the CDNs that are being load balanced across (jsDelivr uses Cedexis)
Looks more mature than JSDB.io - particularly with the larger collection of libraries and tagging system etc. But honestly your site is cluttered and ugly, JSDB is winning there. A twitter feed, really? I think your site needs some clear direction. Just saying.
Ok, I'll give some suggestions, I'll be blunt. But first you should know that I'm not a web designer - so take them with salt. It might also be worth asking for suggestions as a Hacker News thread? Or perhaps a web-design specific forum.
I'm taking an interest because I think the web development world really needs a good site to serve as a list/index/catalog of open-source javascript (and css) libraries, with user ratings and comments etc.
Fundamentally, I think the intent of your design is wrong. Its cluttered and all about the bells and whistles rather than focusing on use-cases and the problems your site should be trying to solve.
(1) Home page
Editor's Choice Part
Get rid of this, I don't think users care about your editors picks. User's care more what the user base / crowd thinks. So you could perhaps put trending libraries (those receiving a lot of up-votes recently) here instead. Or otherwise just remove it all-together.
Blog Part
Also get rid of this. The foremost parts of your homepage should be the Category list and a search box. Also get rid of the tag cloud - doesn't add anything IMO.
Layout and Color Scheme
All wrong, too many different colors and shades, jagged lines and shadows everywhere. Less is more here I think.
(2) Category Page
Layout
Change to a list-view instead of a grid-view. The grid looks too squashed, and users don't mind scrolling - list view is better for responsive design / mobile devices. Also sort the list by rating.
Each Library
Increase the font size of the description <- will work better when you change to a list view instead of a grid. Show the rating larger as well, and then to a lesser extent the GitHub stars etc. Take some design pointers from the StackOverflow question list (http://stackoverflow.com/unanswered).
(3) Library Page
Comments
Shift the DISQUS comments above the 'ALSO ON JSTER' part, put that stuff at the bottom, users care more about comments. Remove the 'RECOMMENDED CONTENT' - its irrelevant and your site is too immature for advertising yet.
Rating System
Light bulbs? I honestly think you would be better off with an up/down vote rating system like StackOverflow. A library having a 5/5 rating doesn't mean anything when there is only one vote (probably from the developer who wrote it and submitted the library).
If you wanted to make it really smart, you could allow users to up/down vote a library for specific category. For example, users could up-vote the D3.js library within the 'Charting' tag/category only if they wish to - which means the user thinks D3.js is good for charts.
For the next paper, I plan to have a look at a couple of disappearing frameworks in detail. Let me know if you have special requests on what to research. :)