It would be so helpful if the author would make a simple statement at the beginning of the video about what this does and why it is useful. Over ten minutes into the video, we have no idea. Read the project description on Github, still no idea.
Why not start with, "This project creates a virtual printer that advertises itself with Bonjour and writes a postscript file to local storage." Follow that with a simple statement about why that is cool and what you can do with the file, which is still not apparent.
Save to PDF would just give you a PDF. The idea here is that you can do whatever you like with the print-job as long as you can program it. So print to PDF is just the most simple example.
I mention a few low hanging fruits in the talk like "print to bookkeeping" - but that's just one use-case. Consider that you can use it as a printing proxy and divert jobs to different printers or implement an authentication system or a payment system before printing. There are a lot of options...
Print to bookkeeping is actually a pretty brilliant idea... I'm planning to start doing itemized taxes for the coming year, and this could be useful as a basis for capturing receipts... Combined with cloud print... snap a photo of the receipt on my phone, print to bookkeeping, sort it out later.
Might even be able to combine with GPS info in the image to log where the receipt is from, etc.
This could be a pretty decent idea for adding to online bookkeeping services... so that you can tag receipts, for tracking the taxable portion of them, etc.
Advance print queues for printing services could be another thing...
I've just recently discovered NodeJS -- heard about it for years, of course. I was able to create a web server for one of my group's web apps in about 5 lines of code. It's a bit weird to wrap one's mind around it at first, but then it starts to make a lot of sense.
This IPP server is cool, though I'm not sure what uses it has yet. Maybe just a handy way to print to disk without having to choose a folder and file name. Or use as a proxy to redirect print requests to different printers depending on size or type of print job. Or a way to queue up print requests until off-hours. This is just off the top of my head and I'll bet there are other cool uses as well.
JavaScript is great. I do enjoy all the posts about how it sucks. First it was a toy language. Now people complain that it's a weakly typed language replacing strongly-typed languages they prefer... I'm interested to see the next iteration of this phenomenon.
Meanwhile I just enjoy developing in it every day. Other than having to maintain the odd ExtJS app, it's simply the best. cue triumphant sax
Can we just use the term "duck-typed" already? There's a significant difference between weakly-typed C, strongly-typed rust, and "strongly"-typed JavaScript/Ruby. Besides, weak-typing is relative. Javascript does some type conversion, but because it does less than C, it is more strongly typed than C, but it is more weakly typed than some other languages.
No, duck typing is not a very good distinguishing characteristic anymore. "Interfaces", "traits", and "concepts", to say nothing of other things, all in various ways make static languages have something that looks something like statically-checked duck typing. Duck typing isn't unique to dynamic languages.
The syntax could be a lot cleaner... the Universal Module Definition (UMD) pattern at the top makes it a bit quirky... A lot of people have moved towards using CommonJS (cjs/node-style) exports with tooling such as browserift/webpack and/or babel (for es6 modules) in order to clean up the source syntax.
What you're looking at is a relatively poor example. In es6, that could be ...
exports default function...
without all the cruft around it, also the module itself could be cleaner. Similar to:
var cookies = parse();
export function set({key, value, days=null}) {
...
}
export function get(key) {
...
}
export const remove = (key) => set({key, value:null});
export function parse(values = document && document.cookie || '') {
...
}
Classes and modules in almost any other modern language are much easier to read and write. Ruby, python, heck even php are better than JS. That's my real issue with JS. If we had a browser that had lots of languages baked into it, none of use would choose to use JS ;) node.js would never have been invented...
>Now people complain that it's a weakly typed language replacing strongly-typed languages they prefer
Firstly, that's a strawman. I prefer strongly-typed dynamic languages and I still think JavaScript sucks.
Secondly, I think you're confusing strong vs. weak with dynamic vs. static. JavaScript's weak typing is unequivocally one of the worst things about the language.
I'm not Javascript's biggest fan, but the weak typing argument is a little... weak. You never run into problems with weak typing as long as you follow a few rules like using === over ==. Javascript is poorly designed because there are these rules you need to learn and because there are some language features that you just don't use. Some other reasons too, but the way people write it, Javascript may as well be strongly typed.
I think you contradict this in the rest of your comment:
>Javascript is poorly designed because there are these rules you need to learn and because there are some language features that you just don't use.
One rule you've mentioned:
>using === over ==
Which is a result of weak typing. So maybe weak typing is a language feature "that you just don't use"? Which, according to you, makes weak typing a reason why JavaScript is poorly designed.
It was not my intention to imply that javascript is not weakly typed. And I think we have collectively determined (correctly) that weak typing is a burden in a general-purpose language. So yes, your conclusion is correct, weak typing is "a reason" that javascript is poorly designed.
But your claim wasn't "weak typing was a bad design decision", it was "JavaScript's weak typing is unequivocally one of the worst things about the language". I think it's silly to call a mis-feature "unequivocally one of the worst things" when people who write javascript basically never run into, and when it can be completely avoided by using unintrusive tooling like a linter.
I started off developing in C, then C++. Then I did Java (late 90's till 2010 or so). I toyed around with PHP and perl somewhere in between. I love modern Javascript, and would be hard pressed to go back to something else.
I remember having to debug the printing system (lpq, converters etc.) on my first Slackware system back in the early years of the second age, with plenty of shell scripts and literal postscript output. So I regard this with a certain amount of schadenfreude.
(Although the "printer" part of the headline makes this sound much more fancy and hardware-oriented than what it is, yet another HTTP-based protocol that's parsed enough to work for a few use cases).
Funny you mention that :) I was actually thinking of creating a version of the printer where all print jobs would have the typeface swapped for Comic Sans.
It's been pretty hard so far though to figure out how to do this replacement in PostScript :(
That had absolutely nothing to do with making printers great (again).
Printers suck a putting stuff on paper, doing a digital copy via a printer protocol doesn't fix that. It's neat and there might be some interesting use cases, but it doesn't fix what's wrong with printers.
I'm not even sure that printers where ever that great. Printers seems like devices that sort of peaked 40 years ago. Since then they have gradually decreased in quality. Printing 1000+ pages a day seems to be a little much to ask from many printers, they simply wear out to quickly. The whole process of looping paper around inside something that fits on a desk (sort of), combined with cheap plastic parts is a receipt for disaster.
Software-wise the manufacture should stop trying to add more feature that no one while ever use and instead work on making "cancel print job" actually work. The number of times a printer (driver?) has chosen to pick the wrong paper-tray is mind boggling. Why are there even multiple trays, we only ever need to print on standard A4 paper? Sadly picking a printer where the hardware quality will support the volume also result in feature bloat.
I really hate printers, and no amount of Javascript will make them any better.
> I'm not even sure that printers where ever that great. Printers seems like devices that sort of peaked 40 years ago. Since then they have gradually decreased in quality. Printing 1000+ pages a day seems to be a little much to ask from many printers, they simply wear out to quickly. The whole process of looping paper around inside something that fits on a desk (sort of), combined with cheap plastic parts is a receipt for disaster.
If you get an old LaserJet they're industrial beasts. But no-one wants to pay money for a printer, so we end up with two markets: the very expensive, but good, professional printers, and the domestic horrible printers.
If you're printing 2 reams a day you can afford to invest in a decent printer.
> Why are there even multiple trays, we only ever need to print on standard A4 paper?
You only need that. A bunch of offices need to print on A4, and C5 envelopes, and sometimes A5 and sometimes on labels.
I would pay for a quality printer. Something along the lines of Epson EcoTank, but it's going to take some time to heal my printer wounds.
The printer needs to be well built. The printer needs cheap ink, and no chipped cartridges, the ability to use generic ink, and ink cartridges that don't dry out. Then, and only then will I spend a lot on a printer.
The printer industry seems to have shot themselfs in the foot while being clever with chipped cartridges. People realized they don't need to print? I have a Epson r2400 collecting dust. I just got tired of paying over a hundred dollars for their pricy ink.
I am now so used to not printing; maybe I'll never return?
>You only need that. A bunch of offices need to print on A4, and C5 envelopes, and sometimes A5 and sometimes on labels.
I understand that. My point was that perhaps it would easier to build high quality printer dedicated to specific tasks. I would guess that the majority of printers in something like financial departs won't ever print on more than one type of paper.
Honestly I don't even feel that paying for the expensive printer, like high-end HPs, will get you above "okay". They still do weird stuff and the internal plastic parts will break easily.
I have an HP LaserJet Color 400 series, and generally never use the manual feed, only the tray with US Letter size paper... I had an HP 4000 for a long time, that I bought used at a school auction, that beast lasted me 6-7 years after it had already been in heavy use for 5...
I don't print much, but I'm not sure where your problem lay. A typical low-end B&W LaserJet with a single tray is pretty damned close to what you are asking for, and they aren't that expensive.
Why not start with, "This project creates a virtual printer that advertises itself with Bonjour and writes a postscript file to local storage." Follow that with a simple statement about why that is cool and what you can do with the file, which is still not apparent.
Obfuscation has become the norm.