Build a toy quantum computer at home - <AUTHOR> https://www.dhruvonmath.com/2020/07/19/quantum-computers/# <comment><USER2> While this is a nice demonstration of the polarization of light, this is not a demonstration of quantum mechanics, or quantum computing (though it does have pedagogical value, if qualified properly).

Polarizers essentially just project the electric field of the wave onto some axis, zeroing out the perpendicular component. Keeping in mind that light intensity is the square of the electric field strength, all of this can be explained through straightforward classical electrodynamics.

An analogous statement would be that interference of light (say through a pair of slits) is also quantum mechanical in nature. This isn't strictly wrong (since basically everything is quantum mechanical in nature when you get down to it) but is a misleading way to present something that can (and was) understood perfectly well before quantum mechanics came along.

Note: These kind of experiments for a single particle (e.g. photons, electrons, etc) are a different story and do provide a demonstration of quantum mechanics (and the combination of wave-like and particle-like properties intrinsic to it).

<comment><USER3> This is incorrect [edit: it isn't] - see the standard "three polarizing filter" experiment [0] which is impossible to explain with classical mechanics [edit: it can actually be explained, see coolgod's comment below]. Polarizing filters don't just zero out the perpendicular component of an electric wave, they measure each individual photon that passes through and either blocks it or permits it to pass with some probability proportional to the angle between the photon's polarization and the filter's polarization.

[0] [https://youtu.be/zcqZHYo7ONs](https://youtu.be/zcqZHYo7ONs)

<comment><USER4> The three polarizing filter experiment using common sources of light can be explained perfectly without using quantum mechanics [0]. These effects only need QM to explain in the single photon regime. The polarized light from the LED display is definitely not in the single photon regime thus this experiment does not demonstrate any quantum effects. Without any quantum effects, it is much more difficult to justify the quantumness of this supposed quantum computer.

[0] [http://alienryderflex.com/polarizer/](http://alienryderflex.com/polarizer/)

<comment><USER3> I was going to say, this wouldn't explain it because the electric field strength is projected to the polarization axis (with strength 0.707 at 45 degrees) but to match quantum measurement it should be 0.5 strength (0.707 squared). But as the grandparent comment stresses, light intensity is the square of electric field strength... so the measurement matches. Makes sense! I will amend my above comment.

</comment></comment></comment></comment><comment><USER5> This is a real-valued computer, not a quantum computer. In the described algorithm the state is the real-valued angle of the polarizer. One could very well implement this algorithm using the charge on a capacitor. Also the algorithm has bugs, it can overshoot the vertical. The author does acknowledge these shortcomings in the "caveats" section. But with all those caveats, you are not building a quantum computer at home.

<comment> jerome-jh The proper term would be "analog computer", but I agree with you. Really this is not even a computer.

<comment><USER5> Indeed, I should have called it "analog computation" instead.

</comment></comment></comment><comment><USER6> Nice article, but not really a quantum computer or even a system that needs quantum mechanics to explain it. You could do the same calculation with an analog system (e.g. a capacitor that you add/remove charges to/from). The argument from Scott Aaronson about quantum advantage that the author refers to is really not very relevant, as a single qubit doesn't have any information encoding advantage over an analog system. A quantum computer simply cannot produce a speed advantage without relying on entanglement at some point during the quantum computation. So: no entanglement = no speed advantage.

</comment><comment><AUTHOR> Hi! Author here - If you have any feedback on what can improve please let me know! Thanks for reading and feel free to shoot me a note at email@example.com if you'd like to see something edited.

<comment><USER7> It is a very nice article, and very well articulated.

However, this article falls into a pet peeve of mine which is that the behavior exhibited here can also be completely explained classically -- this is also a standard demo when explaining how polarization works classically. I feel that it is worth it to at least include a footnote to that effect. The reason that I bring it up is that I (as someone who first learned classical optics, but is now learning quantum optics) personally suffered from some deep rooted misunderstandings about quantum mechanics due to having seen so many of these simplified demos which do not actually capture the quantum nature of light.

The way this article is presented it implies that one can also model quantum phenomenon using maxwells equations -- which is obviously not true. In this specific case you get the same answer, but as soon as you start looking at the individual photon statistics your answers will start to diverge. This is where the actually quantum things like Bells inequality and the Hong–Ou–Mandel effect come into play. If people had just been up front with their descriptions 'oh by the way, when you look at the aggregate behavior of photons they look perfectly classical, it is only when you look at the statistics do they behave any different' it would have saved me a lot of soul searching and misguided contempt for the quantum community.

<comment><AUTHOR> Hey - this is perfectly reasonable and constructive feedback - thank you! I see your point that the polarization example can be explained using classical approaches. I wanted to explain it in terms of individual photons as I wanted to use this to help provide some visual intuition for qubits. Photon polarization is a nice, visual way of interpreting qubits and as such lent itself well to the task.

EDIT: I've gone ahead and added the footnote. Thanks for the suggestion!

</comment></comment></comment><comment><USER8> The 3-polarizer experiment is a very cool way to demonstrate the weirdness of light.

And the idea of using sequential rotation to keep track of cumulative bias in coin flips is an interesting concept.

But ultimately I think neither one of those concepts really depends on the other in this experiment. Checking for light through polarizers is neat, but keeping track of any other rotating macro-scale object would work just as well. You can do the same thing by rotating a stick on a piece of graph paper. If it goes beyond your pre-determined test angle, you declare a bias.

As I understand it, the crazy thing about quantum computing is that you _don 't_ need to go sequentially; you can simultaneously compute every test flip in one step with qubits. That's why quantum computing could speed up certain calculations. (Note: please don't ask me to explain how.)

<comment><AUTHOR> Hey, you're right you could use a stick on a piece of paper etc. Totally fair. That being said this is in fact a real application where a qubit can model things a standard bit can't. Professor Aaronson describes it in this paper: [https://www.scottaaronson.com/papers/qcoin13.pdf](https://www.scottaaronson.com/papers/qcoin13.pdf). Additionally, it's described in his lecture notes here: [https://www.scottaaronson.com/qclec/5.pdf](https://www.scottaaronson.com/qclec/5.pdf)

<comment><USER8> Thanks for the links. It doesn't seem like your experiment captures the interesting part, which is that you don't need more qubits to measure a more subtle bias.

As I understand the experiment now, it seems like the more subtle the bias in the coin, the more times you would need to rotate the polarizer to detect the bias.

If there is something about using the polarizing filters to keep track of tries that is more efficient than using something like a stick, then I would emphasize that in your write-up.

<comment><USER9> Yup. As greek to me as the paper is at least it makes very clear what it sets out to achieve and why (and when) it differs. I suppose it's implicit but I feel article really ought to explain that in the demonstrated case of heavy bias, few attempts and fixed, coarse steps there is of course no advantage - apart from the stick in ground one could also best its resolution off 0b1000000 and ++/\--.

It's a nice explainer on polarization but tries to be more than that and doesn't achieve it - but with further work (not in form of added caveats but rather a new approach to tying the two concepts together) I'm sure it could.

</comment></comment></comment></comment><comment><USER10> maybe i'm missing something here, but could we not have just used a stick on the ground and rotated it accordingly, and still end up with the same result - if the stick ends up perpendicular to the plane, i.e. you? Why do we need the light polarization setup?

<comment><AUTHOR> Hey - you totally could to mock this exact setup like you're suggesting. However, in a real quantum computer setup you would take one qubit and apply either the positive or negative rotation gate to it again and again and rotate the state of that qubit. The "stick" in the quantum computer would be the qubit (or photon in this case). So the post is meant to show what would happen in a real setup. Hope that makes sense.

</comment></comment><comment><USER11> It's more of a quantum demonstration than a computer, no?

<comment><AUTHOR> Yes - I used the term computer because it really does allow you to mock this quantum algorithm: [https://www.scottaaronson.com/papers/qcoin13.pdf](https://www.scottaaronson.com/papers/qcoin13.pdf). It's described in Professor Aaronson's lecture notes here: [https://www.scottaaronson.com/qclec/5.pdf](https://www.scottaaronson.com/qclec/5.pdf)

</comment></comment><comment><USER12> Analogous statement would be that interference of light (say through a pair of slits) is also quantum mechanical in nature. This isn't strictly wrong (since basically everything is quantum mechanical in nature when you get down to it) but is a misleading way to present something that can (and was) understood perfectly well before quantum mechanics came along Thatis.

</comment><comment><USER13> Is it possible / are there virtual or emulated quantum computers?

I read about the Kyndi model but could not find any implementation.

<comment><USER14> Yes, it is possible to emulate a quantum computer, and this is done quite often for research and to try out quantum programs.

The problem is it takes O(2^n) classical computer resources to emulate a general purpose n-qubit quantum computer. In other words, exponential time or size.

(We can simulate some larger quantum chemistry systems on a classical computer, but those aren't general purpose. The simulations are quite restricted in what they can measure, and there's still a significant practical size limit.)

So we can only emulate very small general purpose quantum computers or other quantum systems. For larger quantum computers, in principle those can be emulated too, except you would need an impossibly fast and large classical computer to do it. So we can't do so in practice.

This is actually the motivation for building real quantum computers of significant capacity.

If a real quantum computer can be built with a large number of high quality, fully coherent qubits, it will be able to do calculations that can't be emulated on any classical computer we can actually build and run, just because of the O(2^n) practical limit.

Right now, there are no quantum computers like that. There are some dubious marketing claims around, and there are also some genuine, but smaller, devices.

Because we can't even simulate a large quantum computer, we don't know for certain whether such a device can even be built in the physical world. The abstracted maths of quantum mechanics, which has proven to be extremely accurate and correct for everything it's been used on, says it can (subject to practical engineering details), but the physical world may have a subtle limitation which we can't detect in smaller systems, that only happens with larger quantum computers and prevents it from being possible. The maths itself might even have a subtle reason (such as stability or entropy) why the system cannot work, but no such reason is known at the moment. We can't "run" the maths to find out its behaviour on a large system, for the same reason we can't simulate a large quantum computer without a large quantum computer in the first place. We can only reason about it in the abstract.

</comment></comment><comment><USER15> I liked the article, but this is not a quantum computer. Please do not take away the credibility of what a real quantum computer could achieve. This is at best an algorithm to reveal the angle of polarizer, and also the nature of light.

Although, appreciate the efforts.

</comment><comment><USER16> Not sure what's up, but this website refuses to scroll on any Chrome based browser on my phone. Works fine in Firefox though.

Edit: Weird. Now it works. Though there still some initial "resistance" when I start scrolling...

</comment><comment><USER17> I like it.

</comment><comment><USER18> Has anyone cracked SHA with this?

<comment><USER19> SHA is not crackable with quantum computers. RSA and Diffie-Hellman are though and nobody has done it yet (or come close).</comment></comment>


Strange google image search that yields tons of gravestones - <AUTHOR> http://www.google.com/images?um=1&hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&biw=1374&bih=854&tbs=isch%3A1&sa=1&q=1924%2F17&aq=f&aqi=&aql=&oq=

<comment><USER2> You don't ned the / just use space. Sometimes you will hit a product model, giving more results, than birth and death dates.

</comment><comment><AUTHOR> It works with 1924/15, 1924/16, etc too.

Looks like sometimes you get a lot of coins as well.</comment>


Google licenses VP8 patents from MPEG-LA - <AUTHOR> http://www.businesswire.com/news/home/20130307006192/en/Google-MPEG-LA-Announce-Agreement-Covering-VP8

<comment><USER2> This shows that VP8 wasn't as patent-free as On2/Google claimed. OTOH, there's probably nothing to worry about now since Google has licensed the patents on behalf of everyone.

Original context from 2010: <http://x264dev.multimedia.cx/archives/377>

<comment><USER3> Precisely the opposite. If MPEG-LA thought they had VP8 dead to rights, they would never have agreed to this deal -- they would have litigated to the bitter end.

This is actually a huge badge of honor for VP8, and a repudiation of the meme that somehow it's just an H.264 knock-off. It's always stunned me that the same community that hates on patent trolls is in love with H264 (aka MPEG4++). MPEG-LA are IMSHO the very definition of trolls -- patenting (and charging royalties for) techniques that were obvious and known art in the video compression community for ages.

<comment><USER4> There is no such thing as "dead to rights" in a patent war over algorithms. It would come down to the jury, and it would be a gamble (as the disagreement amongst people _who should know_ about whether VP8 infringes or not shows).

The risk for MPEG-LA in _not_ agreeing is that the patent pool would collapse - if Google isn't in then why should anyone else remain in the pool?

I do agree that this agreement seems to be pretty good for Google though. Their ability to sub license VP8 has the potential to undermine royalties for H264 to the patent pool.

BTW, MPEG-LA isn't a patent troll by any conventional definition.

Firstly, MPEG-LA _doesn't_ patent anything itself, they are merely an organisation to pool related patents amongst member organisations.

Secondly, the member organisations are mostly (all?) the opposite of patent trolls, too: they hold patents in the field because they are _actively producing software in the field_. That is the opposite of the typical non- practising-entity patent troll model.

Thirdly, if you do accept software patents then the patent pool model is actually quite a nice way to manage them. It means people who want to work in the field only have to deal with one entity and gain protection from patent claims from any other company in the field. (Note: I _don't_ accept software patents at all - just pointing out that while they exist this isn't a bad way to do them).

I have no real opinion on VP8 vs H264, but I do know that the patent situation is much more complex than you seem to believe.

<comment><USER5> >The risk for MPEG-LA in _not_ agreeing is that the patent pool would collapse - if Google isn't in then why should anyone else remain in the pool?

I think you have it kind of backwards. This whole thing is inside baseball.

Start with the patent system. It's really easy to get a narrow patent. It's far too easy to get an overly broad and totally obvious patent. It's _really easy_ to get a narrow patent.

So what happens when all the industry players come together to create a standard for a video codec? They all offer up their "technologies" for inclusion in the standard, because if it gets included and they have a patent then they get royalties. Some of these are the ridiculously overbroad and obvious patents everyone is accustomed to complaining about. But here's where the narrow patents come in: Narrower patents tend to be stronger. It's harder to find invalidating prior art if the claims are more specific. Plus, more is better, and narrow patents are easier to get. So what they do is they all file for specific patents on exactly what they intend to put in the standard, so that all the major industry players each have several strong patents that cover the standard they're creating. The incentive that they each have individually to do this is obvious, and the others allow it because they want to do it too and they implicitly expect reciprocity.

It's basically a method for implicit collusion. They each include a bunch of patented stuff in the standard primarily for the purpose of increasing the amount of royalties they get from anyone who uses it. Since each of the major players does the same thing, the royalties between one another largely cancel out, but if there are any minor players or any new competitor attempts to enter the market, now they've got to pay a bunch of royalties to all the incumbents to use the standard whereas the incumbents don't have to pay any royalties to them because the newcomer wasn't around at the time to have put their patented technologies in the standard. It serves as a pretty effective method to thwart competition, and it's really hard for the antitrust authorities to prove anything illegal is going on.

So enter Google/On2 and VP8. They don't like all this. "Promote competition in markets complementary to your own" is business 101. So they specifically design a codec that doesn't infringe the H.264 patents and release it free to the world. Obviously this means one less barrier to competition in those markets -- it's exactly the same strategy as giving away Android for free. You can't allow a cartel to form in a complementary market or eventually they'll find a way to lock up all your customers behind a toll booth and squeeze all the margins out of your market.

This doesn't make MPEG-LA happy. They're in the toll booth business. If people start using VP8 or its successors then the whole antitrust-resistant implicit collusion scheme is going to fall apart. So they try to figure out how to stop it, but what can they do? When you sell hammers, you start seeing nails everywhere. So they threaten to create a patent pool for VP8. The point of the pool was never to actually license patents to people who wanted to use VP8. VP8 is somewhat worse than H.264 on account of having to avoid some of the ridiculously broad and obvious patents. If you have to license patents then you might as well just use H.264. Which was the real point of the pool for VP8. Make sure there doesn't exist a decent royalty-free codec so that people can't use it instead of H.264.

But VP8 was specifically designed to avoid all known patents, so setting up a pool for it turns out to be harder than it sounds. On the other hand, software patents are so broken that you can generally find a few bad ones that maybe possibly read on any given thing, at least to the point that you can tie it up in litigation for years. So that's what I imagine happened here: MPEG-LA probably knew they wouldn't be able to win in the end, but they had the ability to cause trouble, which can be leveraged into a tidy settlement.

<comment><USER4> I'm not sure why you think I have it backwards. That's precisely the point - if MPEG-LA couldn't get Google to license the patent pool then other patent holders in the pool might jump ship too.

Imagine if you are patent-holder-X, present scenario: We want to transpose the MacGuffin, but that is covered by the patents held by ZZZ Corp. But that's ok, because ZZZ Corp is in the MPEG-LA patent pool, and the patent is covered by our license so we'll just do it. Happy days at ZZZ Corp

Scenario if Google didn't pay the license: We want to transpose the MacGuffin, but that is covered by the patents held by ZZZ Corp. So lets see what VP8 does instead... hmm.. we can do that. And now we don't need out MPEG-LA license, so lets drop paying that.

Meanwhile at ZZZ Corp: no we aren't getting any revenue from MPEG-LA for out patent on transposing MacGuffin. But look: Apple and Microsoft and Adobe all transpose the MacGuffin exactly how the patent explains to do it. If we drop out of the patent pool now, and then file a new derivative patent on fast MacGuffin transposing, then everyone will have to pay us fees themselves, or not implement the new, faster MacGuffin transpose.

<comment><USER5> >That's precisely the point - if MPEG-LA couldn't get Google to license the patent pool then other patent holders in the pool might jump ship too.

But there is no pool for VP8. I'm not aware of anyone being able to articulate a specific patent that VP8 is alleged to infringe. The point of a patent pool for VP8 could never be to actually license anyone because the only reason to use it over H.264 is if it's royalty-free. The point of _threatening to create_ the pool is to cause FUD as to its royalty-free status. The "license" Google just bought is them paying MPEG-LA to shove off and stop spreading FUD about VP8.

</comment></comment></comment></comment></comment></comment><comment><USER6> This seems like a pretty rational way to go. It side steps the issue fairly cleanly by paying off the consortium who now would look bad if they came back and tried to sue people for using VP8.

<comment><USER7> Pretty sure the handful of people who use VP8 aren't going to cause a PR problem for MPEG LA or its members.

<comment><USER8> It's obvious you have a personal axe to grind with VP8. You show up in every VP8 thread, going on and on about how VP8 is dead on arrival[0].

Why don't you tell us all why you're so personally invested in this argument?

[0] <http://www.hnsearch.com/search?q=VP8+taligent>

<comment><USER7> Give us all a break. I am just as 'invested' in this as anyone else is.

I am critical of VP8 because I believe in companies like Google, Apple, Microsoft etc working together to define standards in the common interest of the consumer. Google's entire behaviour with VP8/H.264 as well as their FRAND abuse goes entirely against this.

Standards are good for everyone.

<comment><USER8> _Standards are good for everyone._

Royalty-free standards are even better. Given the state of the video codec world at the time of Google's On2 acquisition, purchasing a codec that was explicitly designed to avoid MPEG-LA patents seems like the only viable path they could have taken to a royalty-free codec for the web. And remaining royalty free is essential to the very concept of the World Wide Web.

Developing a new royalty-free standard would only invite participants to try to include as many encumbered concepts as possible to derail the royalty-free aspect, or to delay ratification and implementation for as long as possible to preserve the revenue from their royalty-bearing codecs.

Having a standard that is designed by committee should not be an end in itself, but only a means to an end, and if other means are more expedient, then the other means should be used.

<comment><USER3> Exactly. Having been involved in the H264 process (as well as On2/VPx), I saw first-hand how the big guys abused the process at every turn. Their attitude was not "we're doing this for everyone", but rather, "cool, with this patent pool thing we can collude on pricing and it's totally legal!"

Then they spent the rest of the time jockeying to get their allies into position to ratify their precious patent-protected IP into the standard so they could reap the royalties and remain in a position of control.

To their credit, the people who actually ran the standards process attempted to thwart this behavior (they even tried to produce a "royalty free baseline"), but the powers that be were just too entrenched and committed to their predatory ways for it to succeed.

I was there, I saw.

</comment></comment></comment></comment></comment></comment><comment><USER9> Now if only Google would actually remove H.264 support from Chrome.

<comment><USER10> A huge part of the problems with the web are people playing politics with technology.

Leave the highly common hardware accelerated that's the _only_ one all browsers support alone.

VP8 can beat it on technical grounds.

<comment><USER11> As far as I remember, Firefox only supports H.264 on Windows. So it's not quite supported by _all_ browsers.

<comment><USER7> Firefox supports H.264 on Mac via the QuickTime plugin.

<comment><AUTHOR> Firefox supports H.264 on Linux via the Flash plugin

<comment><USER12> Flash has historically always been used to deliver H264 to Firefox, though. That's not quite the same as the browser supporting it in <video>.

</comment></comment></comment></comment></comment></comment><comment><USER13> This sounds bad. Does it mean that Google admits that VP8 is patent encumbered now? What are those patents and is it really true or it's Google chickening before the MPEG-LA trolls and there are no real patents involved?

<comment><USER14> Looks like they just payed the bullies instead of fighting them.

<comment><USER13> Google should disclose what those patents are so others could evaluate whether they really affect the codec or not. While I don't like that Google obliges these trolls, this can be conductive for wider VP8 adoption.

<comment><USER3> On2's patents:

[http://patft.uspto.gov/netacgi/nph- Parser?Sect1=PTO2&Sec...](http://patft.uspto.gov/netacgi/nph- Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch- adv.htm&r=0&p=1&f=S&l=50&Query=AN%2F%28%28%22Duck+Corporation%22+OR+On2%29+ANDNOT+Green%29%0D%0A%0D%0A&d=PTXT)

MPEG's patents (pdf, sorry):

[http://www.mpegla.com/main/programs/avc/Documents/avc- att1.p...](http://www.mpegla.com/main/programs/avc/Documents/avc-att1.pdf)

enjoy

<comment><USER13> This doesn't help sorry, since it doesn't say which patents are supposedly affecting VP8, and which Google has supposedly licensed.

</comment></comment></comment></comment></comment><comment><USER15> There's also a post on the webm project blog about it: <http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html>

> we may sublicense those techniques to any VP8 user on a royalty-free basis

What did Google put in their drinks?

<comment><USER16> And what did the complimentary Google Glasses actually show?

</comment></comment><comment><USER3> This is an excellent development -- it takes almost all the remaining FUD out of VP8.

</comment><comment><USER17> Way to legitimize the FUD, Google.

<comment><USER2> They've already spent over $100M on VP8; I guess they figured it wasn't worth spending more to fight 11 companies to the death.

<comment><USER13> It could be beneficial if they'd bust their patents in the process.

<comment><USER18> You have no concept of how much this would cost :)

</comment></comment></comment></comment><comment><USER19> Invent your own technology and then license the patents for it from someone else.

Hmmm... Why doesn't that seem right?

</comment><comment><USER20> I wonder if this also relates to the Motorola-Microsoft lawsuit over Motorola patents being used in Microsoft products... apparently MPEG-LA figures in there somehow: <http://www.groklaw.net/article.php?story=20130302164903635>

</comment><comment><USER21> This is an educational take on VP8 that considers both patent issues and technical issues: <http://x264dev.multimedia.cx/archives/377>

</comment><comment><USER22> What does this mean for the WebRTC developers who made Opus and are now looking at making a video codec?

It would have been nice to have examples of video that didn't step on MPEGLA's patents.

<comment><USER12> There is a push to make VP8 MTI for WebRTC, but there was obvious pushback from people who preferred H.264, despite most of the normal arguments for H.264 (hardware support) have zero bearing on the low-latency requirements of WebRTC (most hardware encoders can't meet the requirements for videochat).

Those people didn't have an argument and can't even pretend they have one now.

What's going to happen next is that all in the MPEG-LA will still oppose making VP8 MTI (because the licensing for it is obviously way less interesting for them compared to H.264), but any neutral bystanders might be swayed more in the direction of VP8.

 _It would have been nice to have examples of video that didn't step on MPEGLA's patents._

We have, it's called VP8.</comment></comment>


Monster bundle by Appsumo - $99 for $5k+ services - <AUTHOR> http://www.appsumo.com/?monsterbundle <comment><USER2> Aside from the books and subscriptions, seemed to me like a lot of trial accounts, basically. It feels more like buying a coupon book than getting anything tangible this time.

I rather like the idea of AppSumo, just this time I have a hard time seeing which of these are good deals. After going through them all one-by-one I still can't tell if it's worth a hundred bucks to the average startup.

<comment><USER3> I had that same feeling, and was not convinced it would be worth the time to research the true value.

<comment><USER4> This bundle rocks! If you're worried about not getting what you want, Noah is the nicest guy around. Will give you a 100% refund, no questions asked. <http://appsumo.com/faq/>

<comment><USER5> if i don't buy the bundle that i don't want in the first place then i don't have to worry about the troubles with a refund.

</comment></comment></comment></comment><comment><USER6> It bugs the absolute shit out of me that every time I hit AppSumo, they ask me for my email address even though I've already given it to them.

<comment><USER7> Sorry. That should only happen once per forever. Also, it is cause the link is to appsumo.com instead of to the deal (appsumo.com/lean) which skips the email page.

<comment><USER8> I think I've entered it about a dozen times myself. I never clear cookies.

<comment><USER9> well, that you (and I) bother, says something about their service.

</comment></comment></comment></comment><comment><USER10> One thing that annoyed me about some of these AppSumo deals, is that I got bitten by that fact that some of them had an expiration date. There seem to be alot of constraints that don't show up until AFTER you pay for it. Would be nice to make some of these details more upfront

<comment><USER7> Fair point. We have the finer details section under each item. How can we make that more clear?

<comment><USER10> Well, as an impulse buyer, I saw some of the headlines and just pulled the trigger without looking at the bottom row of fine print of every single deal. You're probably thinking great, ideal customer. That happened about twice though before I decided to just not bother looking anymore until I have a real pressing need for some of the offers, due to some of the expiration dates. True, the notices are there, but they really are in fine print at the bottom of each deal's page. IMO, there could even be a simple warning at the bottom of the main page like "Some offers are only redeemable before a certain date. Some restrictions may apply - See deal page for details" Even something along those lines would be a bit more informative for the buyer and offer a clue that there are possibly certain restrictions to pay closer attention to. No more buyers remorse.

</comment></comment></comment><comment><USER11> clickable without the email submit nag <http://www.appsumo.com/lean/>

<comment><USER7> THANK YOU. Can someone ask a mod to change the link to this?

</comment></comment><comment><USER12> No offense intended to anyone here but one of the Appsumo deals I signed up for was, absolutely, a scam.

My advice would be to only sign up for these offers if you won't be upset if some of the vendors refuse to honor the text of their offer, just assume that some will pull a bait-and-switch and you won't be too disappointed.

Do not think that you'll be able to persuade them to honor the offer as described, I made that mistake and simply wasted a lot of time; they know that, ultimately, no-one is going to bother taking legal action, so, they'll just stonewall you until you go away.

Also, pay extremely close attention to the expiration dates.

</comment><comment><USER3> I guess Noah needed to do something to make up for the long-form sales letter debacle. :-)

There are a hell of a lot of services here... What are your must-haves?

</comment><comment><USER13> Wow, this is most probably the biggest startup bundle ever.

He should add some startup furnitures + office space. Then it would be awesome.

</comment><comment><USER14> Awesome, the return of the Lean Startup Bundle! Sold!

<comment><USER7> Only took us 5+ months to get this setup :)

<comment><USER14> I can see there was a lot of timing and coordination involved, though. Worth the wait!

</comment></comment></comment><comment><USER15> Great deals, thanks Noah!</comment>


Ask HN: Light weight opensource Jenkins alternatives - <AUTHOR> Is there a light weight opengsource and self-hosted jenkins alternatives?
I need:
1. a web UI
2. authentication
3. can periodically run nothing but shell scripts
4. with (live/historical) terminal logs for each run.
5. maybe packaging or download links for each build ( not important).
I googled, most solutions are cloud based and are not free. <comment><USER2> Have you looked at Drone ([https://github.com/drone/drone](https://github.com/drone/drone))? They push their hosted service pretty hard but you can also self-host it (I currently am). I think it covers most of your needs except for #3. I haven't seen that done but that doesn't mean it isn't possible...

</comment><comment><USER3> Try minicron. Also, more alternatives/info here:

[https://news.ycombinator.com/item?id=14065884](https://news.ycombinator.com/item?id=14065884)

<comment><AUTHOR> Thank you, but installing minicron requires the following dependencies:

Database SQLite MySQL PostgreSQL

Web Server / Reverse Proxy Nginx A simple example config for nginx is provided.

Apache If you're using apache as your reverse proxy you need to ensure you have the following modules installed:

libapache2-mod-proxy-html apache2-utils

Run the following to enable them and then restart apache a2enmod proxy proxy_html proxy_http xml2enc

<comment><USER4> Is it a problem that a web app has a database and web server dependency? It's got to put the data somewhere and run the app...

<comment><AUTHOR> database can be embedded, for example sqlite. web server can be self contained too. no need for apache.

<comment><USER5> In this case they have you covered: Can use SQLite and not bother with a reverse proxy (see above)

</comment></comment></comment></comment></comment><comment><USER6> I said team city.

Then realized you said Oss

Take a look anyway

</comment><comment><USER7> GitLab has a CI offering in their community edition, although I haven't used it personally.

<comment><USER8> GitLab isn't really "light weight".

<comment><USER9> We actively try to make improvements so GitLab uses fewer resources, but with the scope of the application it's definitely not easy to make it super "lightweight".

You can see the hardware requirements here: [https://docs.gitlab.com/ce/install/requirements.html#hardwar...](https://docs.gitlab.com/ce/install/requirements.html#hardware- requirements)

<comment><USER8> I mean, I don't use GitLab but I didn't really mean it disparagingly - for the OP's purpose, GitLab is massive overkill, and will need a lot more resources than a more targeted solution will.</comment></comment></comment></comment>


TROS: IBM mainframes stored microcode in transformers - <AUTHOR> http://www.righto.com/2019/11/tros-how-ibm-mainframes-stored.html <comment><USER2> Just a few years later, HP did 16 layer PCBs instead of the mylar tape and achieved ROM that was very dense and fast for its time[1]; though apparently yields were quite poor.

1: [http://www.hp9825.com/html/the_hp_9100_rom.html](http://www.hp9825.com/html/the_hp_9100_rom.html)

</comment><comment><USER3> I've heard about program store sheets in the Bell System early electronic computers, but I'm not sure how they compare to this. Never have found a good explanation of how they worked, just a few of my older colleagues described a stack of "memory sheets" they'd swap when it was time to change the computer's programming.

<comment><USER4> The #1 ESS telephone switch's processor used two types of memory. Ferrite sheets were used for read/write memory to store temporary data, in a manner similar to magnetic core memory, while twistor memory was used for rewritable but mostly read-only storage, to store the system programs.

[https://en.wikipedia.org/wiki/Twistor_memory](https://en.wikipedia.org/wiki/Twistor_memory)

[https://en.wikipedia.org/wiki/Number_One_Electronic_Switchin...](https://en.wikipedia.org/wiki/Number_One_Electronic_Switching_System)

<comment><USER5> My stepdad worked for AT&T back in the 70's/80's. He took us to his office one night and we saw an old ESS switch that had magnetic core memory. I just started programming at the time but remember it creeping me out for some reason.

We also listened in on a random phone call and called a small restaurant in France to listen to the menu of the day.

</comment></comment></comment><comment><USER6> So while we are in awe, there is some group of engineers that are going "hey grandkid, let me tell you about Mylar memory. They pushed the envelope back in the day. It would be nice if some of these articles would have names so we could go "wow Bob, that was some amazing engineering".

<comment><USER7> What's Mylar memory? Is it magnetic core memory?

<comment><USER8> The article starts with

"This unusual storage mechanism used a stack of Mylar sheets to hold 15,360 bits, equivalent to 1920 bytes."

<comment><USER7> Yes I know it even has a picture. My question is what is it?

<comment><USER9> It's a sheet of Mylar that has had conductive traces deposited on it, forming wires. This means it can be bent to go around curves without the use of additional connectors.

The interesting thing to me about the TROS sheets is that they were initially manufactured to be the same [0] but were programmed by punching out (cutting) the traces in places to zig-zag the current path either through a transformer loop or around it. Presumably there was a machine that positioned a punch to the correct position, based on coordinates from an input punch-card deck, before descending and cutting through the traces.

[0] Note that there are two designs - one with the inputs on the left and one with the inputs on the right, to line up on the connector block to the diodes. Although it's possible it's the same design, just flipped before the punching step.

<comment><USER7> Got it. When I saw the squares it reminded me of magnetic core memory. I thought the squares were the punches but I can see it in this image[1].

[1] [http://static.righto.com/images/ibm-360-tros/tros- diagram.jp...](http://static.righto.com/images/ibm-360-tros/tros-diagram.jpg)

</comment></comment></comment></comment></comment></comment><comment><USER10> Huh. Kind of similar to rope memory in function but packaged completely differently.

<comment><USER11> The article actually mentions that and compares the two: Rope memory has a higher storage density (important for a spacecraft) while mylar TRO is easier to change the programming (hole punch a stack of sheets vs threading a lot of wire through cores)

<comment><USER12> TFA also notes that the roles of the wires in the two types of memory is reversed

</comment></comment></comment><comment><USER13> As impressive as frightening.

<comment><USER14> What is the frightening part to you?

Sincere question. I am just curious for perspective. I like old tech and am always interested in others general take on it.

<comment><USER13> The amount of ingenuity and complexity and also a bit of "wildness" factor

<comment><USER14> Reminds me of pre digital music. Same things. Humans who knew their shit and who presented raw skill, acumen.

Yeah. I get that.

What if we are somehow forced to return? Some disaster or other.

Will we still be those same quality humans?

<comment><USER13> There's a bit of that in the pre digital eras. Things were much more complex and strange. Before doing anything with electric systems you had to study sophisticated mathematics. Now you can just get along with some arithmetics.

</comment></comment></comment></comment></comment><comment><USER14> Old tech is cool to me because so much of it was human scale.

One can just see the parts. Love it.

</comment><comment><USER15> Can anyone find the speed of this memory?

<comment><USER16> TROS had a cycle time of 625 nanoseconds with an access time of 240 nanoseconds including address decoding and delays through the sense amplifier.

<comment><USER14> My Apple 2 has 100ns RAM. I am pretty sure slightly faster machines used 80ns.

This old memory speed seems fairly respectable for the time.

<comment><USER17> GPIB, a bus system from the mid 60s, requires a response time of <100 ns to a particular signal. That's one of the reasons why it's still practically impossible to implement in software only 50 years later.

<comment><USER14> And we hit that on tech of the era too.

Damn cool.

<comment><USER17> We had discrete logic in the late 60s that achieved toggle rates of a couple hundred MHz (ECL), it was just kinda expensive and needed loads of power. It was (and afaik still is) however widely used in aerospace/military applications (high standing currents and low impedance transmission lines probably make for excellent radiation and interference immunity) and used to be common in high end high frequency test equipment (e.g. counter/timers, synthesizers). I've heard ECL was also very popular for implementing cryptographic devices due to its low noise / switching transients.

</comment></comment></comment></comment></comment></comment><comment><USER18> More than meets the eye

<comment><USER19> I knew it! OS/360 was a decepticon plot all along!</comment></comment>


Are Apps channels? - <AUTHOR>

I contend that Apps are TV Channels
AllthingsD "Apple TV on the Outside, Same Old TV on the Inside" states that an Apple TV, without an a-la-carte channel subscription model cannot succeed, and the cable/Sat TV operators will never give up on their bundled channel subscription and give the Apple TV the option of individual channel subscription, because it will hurt their existing revenues.
I contend that Apple already has those channels individually, and does not need the consent of cable companies. Why, just take a look at your iPad.
You see, you can pick up your iPad, click on the Apps for ABC, NBC. FOX, HBO, Starz, Cinemax, Discovery, CNN, ESPN, MSNBC, etc... and watch any show, any time. Let's take sports as an example: Feel like watching any NBA game, click on NBA Gametime. ESPN? click on Watch ESPN. NFL? NFL Sunday Ticket......I could go on. Same goes for the "News", "Movies", etc...
All Apple needs to do is to make its AppleTV box a bit more powerful so it can run those Apps, and voila, it has an a-la-carte channel model for its next-gen TVs. It does not need any consent, or any Cable/Satellite operators' blessing. It already has the channels in the form of Apps <comment><USER2> Instead of "showtimes" you can have "when to download" times.

Do you think bandwidth will be an issue?

<comment><AUTHOR> no, the same bandwidth that was being taken by channels will be used by the App</comment></comment>


The printer that wouldn't print: Fixing an IBM 1401 mainframe from the 1960s - <AUTHOR> http://www.righto.com/2018/09/the-printer-that-wouldnt-print-fixing.html <comment><USER2> Fixing 1960s and 1970s electronics is hard. But they're fixing IBM's good stuff, not junk.

It's rare to see a transistor opened up today to see what went wrong. From the 1950s to the 1980s, the USAF did that on occasion. The USAF had a project, the Air Force Reliability Program, to make electronics more reliable. About 1% of the electronics boxes in the USAF were stickered with a note like "USAF Reliability Program - do not repair in the field, replace and ship back to ..." Back at Reliability Program HQ, technicians would figure out exactly what had broken and document it. All the way down to the individual component level and below. Transistors would be opened up and photographed under a microscope to see exactly what went wrong. They found problems like this bad transistor in the 1401, where a lead wasn't attached properly.

The USAF followed up by naming and shaming manufacturers. Microphotographs of bad parts were published in Aviation Week. Parts got better.

<comment><USER3> I expected the debugging session to end when they identified the transistor that was bad, but these guys were dedicated!

I've never seen a transistor can opened like that. I love how it's essentially just a shrunken down version of the very first transistor ever made[1]

Great story about the USAF. It's a shame that circuitry is essentially a black box nowadays.

1: [https://physics.aps.org/assets/c5065b1e-4bf2-4501-a05b-6a841...](https://physics.aps.org/assets/c5065b1e-4bf2-4501-a05b-6a841be4559e/e16_1.jpg)

<comment><USER4> A transistor is just as much of a black box, only incredibly simpler.

You can decap hardware today in roughly the same way, and given of course enough time, understand it, and eventually control it.

<comment><USER5> These days decapping involves sandpaper and a magnifying glass.

<comment><USER6> Most likely acid. Sandpaper will destroy whatever you are trying to decap if you get close.

<comment><USER7> Used to be able to burn the package off with a torch and leave the chip somewhat unscathed. I hate to think of the chemicals I was exposing myself to when I did that as a kid, though.

</comment></comment></comment></comment></comment></comment><comment><USER8> I'm lucky if I follow 20% of these posts, but they are consistently my favorite items and I look forward to each and every one. Similar to the Dolphin Emulator blog, it's just a joy reading deep technical dives from people who are passionate about their work.

Even not understanding most of it, I always manage to learn several interesting tidbits.

</comment><comment><USER9> Chain printers like this were amazing to watch, the chain had to move amazingly fast and could break ... I worked with a Burroughs mainframe, we were always cautioned never to stand either side of the printer, because reputedly if the chain broke it could fly out the side and embed itself in the wall (never actually happened to us)

On some printers you could change chains for particular print jobs - when we printed some jobs we'd load up a chain with just digits on it (so the printer could print an entire line while the chain moved 10 locations rather than 48 locations - theoretically 5 times faster.

Page layout was done with a loop of paper tape N positions long (that matched the number of lines on a page) and 10 widem each one of 10 horizontal holes corresponded to one of the fortran carriage control commands "1" meant "skip until there's a hole in position 1 on the tape" \- you'd change to a special loop when printing labels for example, or for different sized paper - if you made a loop and were stupid enough not to have a hole in each horizontal position at least once around a loop skipping to that position would result in a "page throw" fanfold paper would exit the printer horizontally until it hit the wall and would continue to do so until you ran out or someone noticed

</comment><comment><USER10> The very first programming job I had out of college was working on a DEC PDP-8 (not an 8-I or and 8-E, a plain 8), and I remember one time when it failed. I ran a diagnostic program (from paper tape) and the result indicated a hardware failure. We had a service contract, so we called DEC and they sent out a service person. He re-ran the diagnostic and confirmed the fault. I expected him to swap out the failed board, but no. He pulled the board out of the chassis, un-soldered a transister, and soldered in a new one. I can remember to this day, my amazement that he could repair a computer like that.

<comment><USER11> I vividly remember walking into my high school computer lab to find our PDP-11/34A partially disemboweled and someone hunched over the guts of the machine. An update tape from Digital required wire wrap changes which were included in the release notes.

</comment></comment><comment><USER12> Approximate translation of the "print storage" paragraph: "Fetching characters to print via DMA consumed the entire memory bandwidth of the mainframe, so printing caused all computation to stop; unless you leased the 132-word 'print storage' hardware option for an extra $3000 per month (in 2018 dollars)." This add-on looks to be about the size of a largish suitcase. One word in this context was 12 bits, so a grand total of 1584 bits, plus lots of control circuitry.

</comment><comment><USER13> Better than our office couldn't print story. The admin was in a car accident in the late 1990s.

She was gone 3 days before we could no longer print. I remember talking to her and her complaining that we were using too much space for emails, and whoever set up the Network put the email and the print spooler on the same drive. I told people if they cleaned out their inboxes printing should work again, and it did. She returned a couple weeks later and fixed the problem in a more permanent way.

</comment><comment><USER14> I remember reading an old urban legend about someone that got the exact sequence of characters on the print chain and wrote some code to print exactly that line on the 1403.

The legend tells of the 1403 dutifully printing that line by firing all 132 hammers at once, causing the chain to violently break and whipsaw itself out of the side of the printer cabinet.

<comment><USER15> > _You might expect that the 132 hammers align with 132 type slugs, so the > matching hammers all fire at once, but that 's not what happens. Instead, > the hammers and type slugs are spaced slightly differently, so only one > hammer is aligned at a time, and a tiny movement of the chain lines up a > different hammer and type slug. (Essentially they form a vernier.) > Specifically, every 11.1 microseconds, the chain moves 0.001 inches. This > causes a new hammer / type slug alignment. For mechanical reasons, every > third hammer lines up in sequence (1, 4, 7, ...) until the end of the line > is reached; this is called a "subscan" and takes 555 microseconds. Two more > subscans give each hammer in the line an option to fire, forming a print > scan of 1.665 milliseconds. 48 print scans give each hammer a chance to > print each character, and then the 49th print scan is used for error > checking. (For more details of this timing, see Manual of Instruction, page > 37.)_

Based on this note at the bottom of the article that seems impossible, could be I'm just misunderstanding what he's saying though.

<comment><USER16> You are correct; it's impossible to fire all the hammers at once on the 1403 since they fire one at a time. Maybe the self-destructing printer is a different line printer, or maybe firing the hammers in the right sequence over-stresses the chain, but I suspect an urban legend.

</comment></comment></comment><comment><USER15> Since I started college and really knew what breadboards were I always believed they were only every used in schools or else for prototyping, anything in production/commercial used etched silicon, that assumption was killed today.

It now makes sense why it cost $20,000/month (today's $) to use this computer, if you had to manually build each board, the cost for that alone is astronomical...

I think I owe my ECE 101 professor an apology.

<comment><USER2> There are no "breadboards" in an IBM 1401. There's a wire-wrap backplane, but that's a production technology. Even manual wire wrapping is very organized. You have a list of X-Y coordinates to attach, and a supply of pre-cut and pre- stripped wires of the right length. You put in all the shortest wires first, then the next length, and so on. A wire-wrap gun-like tool does the twisting and stops when the wire is tight. It's easy, and the result is reliable. Much better than those solderless breadboards the Arduino crowd uses.

By the IBM 360 era, IBM had much of the production process automated. Wire- wrap backplanes were wired by a Gardner-Denver CNC wire-wrapping machine. IBM's "solid logic technology",a pre-IC technology, placed components in little ceramic bases which were then canned. IBM pioneered automated weaving of core memory. For 15 years, IBM was way ahead on automated electronics manufacturing, and extremely profitable.

All this was a dead end. Making ICs by photolithography became cheaper in the 1970s.

<comment><USER16> Good answer. A couple additional notes: the 1401's backplane was also wire- wrapped by a Gardner-Denver machine controlled by punch cards. Field engineers could modify the wiring with hand wire-wrap tools (to fix problems or add new features), but most wiring was automated.

IBM was using CAD for their systems way back; the 1401's wiring diagrams were called Automated Logic Diagrams because they were computer-generated, originally using a vacuum tube IBM 704 or 705 computer.

I'm still not sure if IBM's solid logic technology (SLT) was a good idea, or if they should have moved to integrated circuits much sooner.

</comment></comment></comment><comment><USER17> I find this stuff so incredibly fascinating that my hands are shaking...

</comment><comment><USER18> If you like stuff like this, follow curiousmarc on youtube. He volunteers there and helps with restorations, and does all kinds of cool restorations at home, too.

</comment><comment><USER19> Does anybody have a scan of a sample printout? If I google it, I just get IBM 1403 results... :-/

<comment><USER19> p.s. Looks like 1403 is the printer unit for the IBM 1401....

</comment></comment><comment><USER20> Wonderful article, as always. It's impressive how detailed IBM's documentation is.

<comment><AUTHOR> What I thought was cool is that it was machine generated.

</comment></comment><comment><USER21> Get to work on the Holmes here with pliers and a blowtorch.

</comment><comment><USER22> I wonder how long it would have taken to debug this back in 1960

<comment><USER23> Probably half the time or less since the people working on it would be more familiar with debugging these sorts of systems.

<comment><USER16> Yes, I expect field engineers back in the 1960s would have found the problem much faster than we did. They had oscilloscopes and test equipment, so we don't have much advantage there. They would be much more familiar with the system and wouldn't need to keep looking stuff up like we did. Plus, they would be motivated by anxious customers breathing down their necks demanding a quick fix.

<comment><USER24> I think the digitizing oscilloscope is quite an advantage compared to the old stuff ;)

</comment></comment></comment></comment><comment><USER25> love that this is done using a garbage scope (rigol). even the garbage of today is quite capable enough to debug the start of the art of yesteryear.

<comment><USER16> I'm quite happy with the Rigol scope I used (DS1054Z), and would recommend it to anyone who wants an inexpensive scope.

<comment><USER24> I am a die hard LeCroy user and fan, but recommend the rigol when asked what to buy. For most people, my criticisms of it are of no concern (I am frequently chaining instruments with GPIB and operating them remotely, and the usb stuff on the rigol doesn't fit into that and just too slow.)</comment></comment></comment>


The Most Powerful Doctor: Bill Gates - <AUTHOR> https://www.politico.eu/article/bill-gates-who-most-powerful-doctor/ <comment><USER2> And that was almost three years ago. Imagine how much more influence he's managed to exert just in the last 4 months.</comment>


Love letter to Vue - <AUTHOR> http://www.evaristesys.com/blog/love-letter-to-vue/ <comment><USER2> Having used vanilla JS, jQuery, Backbone, AngularJS, React (with and without Redux), and Vue (with and without Vuex) I really don't see eye to eye with the folks who love Vue so much.

To me, it looks like Backbone, AngularJS, and React had an orgy and out came Vue. The "opinionated" claim strikes me as marketing BS, templating vs. JSX, attributes vs. components (assuming you're using their templating language), etc. There really isn't a performance benefit over React. You're wading into a new ecosystem without all the build-up React benefits from. The templating language itself is yet another thing to learn, and frankly I just don't think embedding control flow into the templates themselves is a sane approach.

The documentation folks love to talk about is alright, I've definitely seen worse, but it is too much "Go do X" and not a lot of "Why we do X." The latter is a particular strength of React, in my opinion, as they describe very well the underlying logic behind why something is the way it is.

About the best argument for it is the batteries-included nature of the projects, but even then I've not truly had _that_ much trouble upgrading something like React Router such that it would make me question using it in the future.

<comment><USER3> I think it's okay that you don't see eye to eye with people who love Vue.

And I think it's also important to note that most of the things you point out are matters of preference. I've seen Vue fans and React fans argue about these things until they're blue in the face, when all it really boils down to is that some people like the way Vue does things, and some people like the way React does things.

Healthy debate is good. But the downside is that I've noticed these debates devolving into what I call identity politics for programmers - instead of seeing the other group as front-end developers who just like doing things differently, I see people breaking the world down into two groups: people who agree with them, and idiots. And I don't think this approach is very good for us as a community.

So I don't mean to single you out here, but the author didn't really criticize React in any way, so I don't think coming to the defense of React vs Vue here really added to the conversation.

Why not just say, "hey, I prefer React, but it's good Vue exists for folks who prefer a different approach.". Vue's existence isn't a threat to React. It's okay to have multiple approaches to the same problem.

I prefer React too, but I don't think a front end framework monoculture is a good thing so I hope that Vue, React, Aurelia, Ember, and others continue to grow.

<comment><USER4> It's just annoying that when I look for a new front-end job I see more and more Vue.. I really don't want to write all that markup, for me it feels like a step back from React, so I skip those jobs. Maybe I'm just afraid for non interesting technologies becoming a standard I have to concede to eventually.

<comment><USER5> And on the flip-side; I can't stand React so I'm glad to see that Vue is growing. I hate the JSX "everything is JavaScript" mentality where you shove all of your HTML into a render function.

Vue's component separation of HTML/JavaScript/CSS just clicks better for me.

<comment><USER6> > I hate the JSX "everything is JavaScript" mentality

Would you object to things like unobtrusive javascript?

Things like unobtrusive javascript came to be because people recognized early on that HTML was not enoug for writing applications -- that you needed something more. Since basically the entire world has come to embrace unobtrusive javascript, it isn't a logical leap to embrace JSX.

[https://medium.freecodecamp.org/react-s-jsx-the-other- side-o...](https://medium.freecodecamp.org/react-s-jsx-the-other-side-of-the- coin-2ace7ab62b98)

<comment><USER7> Some people don't appreciate being required to run arbitrary code just to view an HTML page and the eye candy of JS is just not worth it.

Sure there are cases where JS is incredibly useful and beneficial, but your website should be able to display the majority of content with JS disabled.

<comment><USER8> Saying that "your website" should be able to "display" its "content" without JS seems to assume (as so many do) that the web is fundamentally a collection of articles (read them, look at the pictures, link to other articles) with a few exceptions, and keeping it that way is every developer's responsibility.

That's not what it is anymore. It has evolved into a general, distributed computing and communications platform. More and more uses of this platform require doing things that involve customized behaviors, not just the built-in features for displaying articles, so more and more people leave JS enabled. Kids who couldn't have afforded a family PC and MS Office now have a Chromebook at school (and maybe at home) and free Google Docs. And how many people whose only internet access device is a phone turn JS off in their phone?

I think it makes more sense now to treat the JS-disabled, article-browsing case as the exception. If I were trying to distribute public health articles as widely as possible, I would try to limit them to simple text, small photos, no JS, nothing that wouldn't have worked 20 years ago. And even for less- critical articles, if they were just simple articles, I'm still inclined to leave out the JavaScript in most cases for the sake of simplicity, reliability, reach, and archival robustness.

But for general purpose today, most developers in the developed world can assume JS is going to be enabled by the market they want to target.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I learned React before I learned Vue. After I wrote an application in React, I decided to try Vue for the next one. It was like a breath of fresh air. The templating language is more intuitive to me and the lack of boilerplate makes it great for the small projects I've used it for.

To each their own. But there is nothing I miss about React after switching to Vue.

<comment><USER10> I'm in the exact same boat. React never really felt comfortable for me, but Vue clicked immediately. Admittedly, I'm coming from an AngularJS background.

<comment><USER11> To me it was the other way around.

Vue felt like a subset of Ember. React did something completly new.

</comment></comment></comment><comment><USER12> After a few years in the Ember ecosystem, I started using Vue a few months ago and damn it's amazing. Of course you can't compare the two at all. I've found Vue and the structures it imposes on your application a bit easier to reason about than what I've found with Ember. It could also very well be that having learnt Ember, I picked up Vue very easily. Either way, I love Vue, and outside of Ember I can't say I've loved any other front-end framework.

<comment><USER11> Yes, Vue is basically the components of Ember, without the MVC stuff.

</comment></comment><comment><USER13> Vue has all the stuff that made AngularJS so great, and none of the baggage. I've made a few small to medium-sized projects with it, and I see no reason to use Angular[JS] or React anymore. I love how well it plays with regular JS modules, allowing you to share your HTTP code and service libraries across multiple apps (Vue or React, or vanilla JS).

Vue hits a nice balance between opinionated code and flexibility. Throw in their ESLint plugin and I think you will end up with very maintainable code.

</comment><comment><USER14> I find such euphoric praises of tech ridiculous. Especially when at the same time its alternatives are declared unusable (or in this particular case "obsolete" or a "trainwreck"). I have not used Vue yet and heard some good things about it. But despite this lack of experience I'm confident to say it is not the solution for everything and everyone.

</comment><comment><USER15> I love Vue.

After Angular 1/2, React, Riot I ended up there. It conforms to my principle of least surprise, and principle of least new ontologies. In the world of transient JS world, it's the best thing that happened.

Hope every other front end framework disappears and the whole world settles on Vue.

<comment><USER16> I actually don't use projects that aren't authored in TypeScript these days, I am looking forward to their rewrite.

Any particular reason that you prefer Vue over Angular seeing as you have had experience of both?

</comment></comment><comment><USER17> We've been using Vue in production since Vue 0.12. It was a joy to use way back when, and it's only gotten better and better.

That's not to say that I haven't shot myself in the foot dozens of times in the process though. We've had to solve a lot of pain points from our original 0.12 code (two-way binding, too many props in components, some jquery dotted in, lots and lots of pre es6 code). But even sitting on code I wrote that looking back makes me cringe, Vue is always enjoyable.

It has truly improved my daily quality of life and I owe Evan You a lot of gratitude.

<comment><USER18> I started looking into Vue just because I looked cool and its good to learn new stuff.

A few month later I got myself a smartwatch besides most of the work was getting around the tizen framework I made my own watchface in Vue - and this was/is a pure joy. [http://wecoso.org/~mit/stuff/myClaw/](http://wecoso.org/~mit/stuff/myClaw/)

</comment></comment><comment><USER19> I'm using Vue for 2 years professionally. Before that, I've used Backbone and Ember (back in the days those were the popular ones) and Angular and React.

React lacked crucial functionality and it felt like I had to rebuild basic functions everytime e.g. a simple input field which communicates its value through setState. In Vue, you just use v-model, but in React you have to add an onchange handler which just feels very low-level - I just don't want to operate on this low level, the framework is allowed to make assumptions e.g. for checkboxes to make my life easier (i.e. grouping all checked inputs with the same v-model name into an array). Another thing I don't like is that JSX is not very good-looking e.g. if I want to add an "if", I need to use the ternary operator in complex components. This is just a hacky way and not very descriptive IMO.

And Angular was awful with its $scope and felt so dirty (it used dirty checking, that's probably why). The new version is ok, but Vue has all the same concepts but wrapped up in a nicer interface. I don't even understand what the ng team tried to achieve with their difficult to read templating language. Looks awful and feels complicated compared to Vue's simple constructs (mainly v-model, v-for, v-if and v-show and v-on, v-bind and ref) - you can learn to write Vue templates in 20 minutes.

The core concepts are reduced to their essentials and it really shines. React is too basic IMO and Angular tried too much with all that controller, service, ... stuff. It was too complicated.

Vue is basically what Web components (using .vue files) should be: Small modules with HTML, style and JS code. And a very nice API and a great developer behind it (so it has all the nice things: vdom, custom rendering e.g. for JSX support, a webpack loader, ...).

Overall, it's the greatest thing I've seen since Ember (and it's much better and more flexible than that).

</comment><comment><USER20> I couldn't be more thrilled with vue.

Having learned with react, I think the component structure and updating are wonderful. But the baggage of the React ecosystem made it tedious to add to projects. What if I don't want to use webpack and npm and babel?

As this author notes, Vue just drops in and works.

I can use it in existing projects. I can use it in experiments. I can use it with my PHP projects. I can use it without a server to compile anything.

It's been a pleasant experience and the tools I've built with it have been refreshingly stable.

<comment> crooked-v > What if I don't want to use webpack and npm and babel?

You may want to look at Parcel, which gets you most of the Babel/Webpack benefits (minification, ES6 syntax, using image files as imports in JS, etc) in a way that "just works".

        npm i --save-dev parcel-bundler
        npx parcel src/index.html    # where index.html has <script src="whatever.js"></script>

...and that's it, if you're not doing anything really weird.

<comment><USER21> I've found parcel to be very buggy

</comment></comment></comment><comment><USER22> If you like templates and framework-specific syntax for conditional logic and iteration sprinkled into your HTML then you will love Vue. If you prefer the JSX approach and relying on JavaScript for conditional logic and iteration then you will love React. Vue does support JSX, but it is not the idiomatic way to use Vue.

<comment><USER23> The other huge difference is how much React beneficiates from static typing (typescript for instance) whereas just like angular, vue templates and all the glue code cannot possibly benefit from it. A vue or angular app is almost as typed checked as a JS app.

I feel most vue lovers don't care about static typing.

<comment><USER24> Vue 3.x (future) is targeting first class Typescript support

[https://github.com/vuejs/roadmap/blob/master/README.md](https://github.com/vuejs/roadmap/blob/master/README.md)

</comment></comment></comment><comment><USER25> > Angular 2/4 is a completely over-engineered trainwreck.

I can appreciate that the author loves Vue.js but I don't think its very constructive have such a binary view of something they clearly haven't spent much time with. Angular is not "over-engineered". Its complete. Its got everything you need and an established, well documented pattern to do it. Its far from perfect but then what is? I've used it, React, Angular 1.x etc and all of them have their strengths and weaknesses. It depends on your team and what you are trying to do.

Its important to remember all these frameworks are built by people just like us who try very hard to make them the best they can be. It would be nice if we spent more time celebrating all the wonderful FREE tools they build for us rather than tearing down the ones that we didn't pick.

<comment><USER26> I'm not in love with the way the MVC framework takes over and wraps the TS compiler (and a very specific version of the TS compiler) to compile templates. Seems an obvious layering violation.

I'll take composition over inheritance in my tooling.

<comment><USER25> I suppose I'd need to know what specifically you've run up against to justify your distaste for the approach. I too prefer composition but I'm not against another way if it works.

<comment><USER26> It's a really bad architecture. Couple of examples

(1) The angular compiler doesn't have the same JS or CLI interface as the TypeScript compiler. I have to know very specifically which I am using when; my build tooling must always know whether it's compiling TS the Angular way, or the vanilla way, and there isn't much commonality.

(2) What if I want to use an alternative TS compiler? Or someone writes a faster one in Go? Or I want to use tsickle [1], which is Closure Compiler- compatible?

Now it turns out there isn't a TS compiler in Go, and the Angular team are the authors of tsickle, and so ngc happens to work with it. But it's an architectural smell to couple that closely for my MVC framework (and IMO with little necessity).

[1] [https://github.com/angular/tsickle](https://github.com/angular/tsickle)

</comment></comment></comment></comment><comment><USER27> Long-time desktop developer's who didn't touch react and even web fe/be until last year opinion here.

While Vue is obviously a kick-starter to frontend programming that makes templating easy and unix-y light, I still have few complaints. First, it is not obvious or easy to start with components. Separate files, build ecosystem, props handling, all this. What I want is to reference 'that last place' in html and have a copy of that template right here that would capture props like un-hygienic macros of C would do. Iow, my style of small apps doesn't map well to heavy isolated-component based style of thinking. I don't want to wash my hands every five minutes when I'm at home.

Second, vue forces you to be fully contained in .data and .methods. I would like to bind to any data and function roots, including _window_ itself, but it's obviously a bad idea to pass window to vue vm for now. But still, it would be nice to forget that vue exists at all at the source level and have just a bunch of vars, functions and [3rd-party] modules at global level and that's it. Now I have to export methods to vue by hand and to have all the state pre-defined, as if it wasn't clear how my state is structured from {{these expressions}} alone. I often find that something doesn't show because I forgot to init data.key = { k2: "" }.

Third, you cannot 'chroot' without making a component. Would be nice to write something like <template v-with='client.contacts'> and then reference 'phone', 'address', etc without a prefix. With copy-style described above it would replace the need for components for me for ages, even if I meet that need.

Still my jquery experiments can't beat vue in simplicity, though I hope some day I'll get rid of vue too (due to points I listed, not because it's bad). But de wae still has to be found yet.

</comment><comment><USER28> After reading the comments, I must be the only person in the world who misses good, old-fashioned Rails templates / views. With someone who knew the internals well, they were a productivity gold mine.

<comment><USER29> That's still a valid way of doing development, but it doesn't really work for a SPA. You may not want a SPA, but if you do, you pretty much need something like Angular/React/Vue.

<comment><USER28> It would still be a valid way of doing development, if teams weren't cargo culting frameworks for tasks that really don't need them. I can't begin to tell you just how annoying React is for making a CMS.

</comment></comment></comment><comment><USER30> Huge fan of the framework and been using it for an year now. My biggest complaint though is the speed at which things move. See for example this PR[1] : it has been reviewed and approved since early January of this year. That's 7 months without it being merged.

1:[https://github.com/vuejs/vuex/pull/1121](https://github.com/vuejs/vuex/pull/1121)

</comment><comment><USER31> One thing I really like about Angular is Angular Material[0]. For me, it solved the same problem Bootstrap first solved - get a decent looking & usable app ready even if you suck at design. With the library of components[1], it's super easy to prototype and build stuff with Angular. Is there an equivalent of this in the Vue land?

[0] - [https://material.angular.io/](https://material.angular.io/)

[1] - [https://material.angular.io/components/categories](https://material.angular.io/components/categories)

<comment><USER32> Vuetify possibly thought unlike material.angular.io it's not supported directly by the framework creators.

Not sure if that's a negative or not.

<comment><USER33> I spent a year working with Angular Material, currently I'm in a project that uses Vue + Vuetify and to me Vuetify has much more to offer than Angular Material.

<comment><USER32> Interesting, I mostly just use Bootstrap 4 (internal enterprise application so the massive adoption and long release cycles help there).

<comment><AUTHOR> I tried doing Bootstrap 4 with Webpack and finally switched to UIkit about 30 milliseconds before committing seppuku.

<comment><USER34> i love bulma css

</comment></comment></comment></comment></comment></comment><comment><USER35> It is interesting how personal the Vue / React divide seems to be. Nobody on either side seems to have very good objective reasons to use their preferred framework, at least for greenfield development. In the end people mostly just "like" one approach or the other - and this is for two frameworks that at a high level share basically an identical design philosophy. I feel like this must go to something very deep about how people think about software development - what it is, what is important about how it is done, etc.

<comment><USER36> Isn't that kind of expected, since both frameworks are so similar? Only thing that remains is what you like, or rather how you prefer your ideas to be expressed in code. And it's great that there are two (or more) solid options.

What is weird to me is that lot of people seem to insist that there are major (sometimes deal-breaking) differences between them, when even core developers of both frameworks agree that they are more similar than different.

</comment></comment><comment><USER37> I wonder if there has ever been an article on Vue where both the article and comments aren't a direct comparison to React.

Look no further than these comments. As always it's a mix of, "I tried React and hated it, then I tried Vue and loved it!" or visa versa.

Metrics such as "I understood it immediately" or "it didn't feel right to me" are shallow and meaningless.

Fact is, React and Vue are increasingly similar. So why these types of articles make the front-page once a week is beyond me.

<comment><USER36> > I wonder if there has ever been an article on Vue where both the article and > comments aren't a direct comparison to React.

This one? The article barely makes a comparison with React, and when it does it emphasizes their similarities.

</comment></comment><comment><USER38> I've never worked with Vue on a full scale project but I loved the simplicity and the great documentation. would love to use it soon.

</comment><comment><USER39> This is exactly my experience. I used AngularJS, then studied many options including the latest AngularJS, Angular 2 and 4, ReactJS... in order to finally settle on Vue. Doing Vue front ends for over a year already.

</comment><comment><USER40> Pretty similar to my experience. Agree on everything.

Now to read the many mentions of react in the comments even though the article has _nothing to do with it_.

</comment><comment><USER4> This makes me think of the Apple marketing campaign in 2004. With Apple everything is better, hmmm not really. Apple has the fastest pc's in the world, hmmm not really.. With an Apple pc you'll get your work faster done, sure? Especially the non-technical designers, writers, musicians etc.. believed that shit. In a way Vue gives me that same feeling.

</comment><comment><USER41> I love Vue! :) best framework ever

</comment><comment><USER42> Knockout JS FOR LIFE!

<comment><USER43> Have you seen MobX [https://mobx.js.org/index.html](https://mobx.js.org/index.html)

</comment></comment><comment><USER44> Evan, if you are reading, I would like to say that I also fell in love with Vue, but I am frustrated that my feature request ( [https://github.com/vuejs/vue/issues/8106#issuecomment-385367...](https://github.com/vuejs/vue/issues/8106#issuecomment-385367128) ) was a little too quickly shot down, without much discussion or understanding. I understand that not every proposal can be accepted, but I think that the merit of the change wasn't even considered. I specifically designed the change to change as little as possible, and have as much power as possible.

I think that specifically in the case of Vue, this hurts more because of the philosophy highlighted in the article- to not stand in the way of experienced developers who know what they're doing.

(Edit: oh no, please don't come with the downvote train. This is a real issue, when you have something that solves 99% of your problems but you can't get it to 100%.)

<comment><USER45> This piqued my curiosity, so I read through the issue and here is my take: you are proposing a change that implements a _second_ way of loading async components, in addition to what's already supported [1]. This is unlikely to go through.

What you want is achievable with the existing async feature, except you either need to 1) keep a list of component names up to date, or 2) use a special component like `<dynamic-loader>` instead of the component tag directly. Neither is a deal breaker, nor enough to warrant introducing a duplicate API; it's rare that you'd be using advanced features like async components while lacking a build process.

Evan's first answer wasn't the most friendly but you also come out as very combative in those messages - as reinforced by your suggestion here that the 'merit of the change wasn't even considered'. Maybe there is some middle ground to be found, an alternate proposal, but I find it extremely unlikely anything will come out of this discussion using this tone. Humility is a must even for experienced developers.

[1] [https://vuejs.org/v2/guide/components-dynamic- async.html#Asy...](https://vuejs.org/v2/guide/components-dynamic- async.html#Async-Components)

<comment><USER44> Thank you for the reply. I hope I am not combative in this reply, I just want you to understand from my point of view.

It's not exactly a second way of loading async components - because the standard async components must be pre-registered in a list (your point #1) - It's a way of _lazily_ resolving components, i.e., only when they are needed. In fact, my change also works for synchronous components, that's why it's not duplicating functionality. But normally, if you already have the component definition loaded, you might as well register it, there's no point in lazily loading synchronous components.

But your #2 point, imho it's not a viable solution because it uglifies the application source code. The way components are loaded should be an implementation detail - for example, I could lazily load components during development and then compile those components before deploying to production into an bundle that automatically registers them all with Vue.

I fully agree with the need to be polite and humble when dealing with people, but maybe because I am not a native speaker, I never thought I was being aggressive, I simply saw(think?) that the people I communicate with didn't undestand what I was proposing, and as such I am trying to convince them of the very real need that I have.</comment></comment></comment>