The Cost of JavaScript in 2019 - <AUTHOR> https://v8.dev/blog/cost-of-javascript-2019 <comment><USER2> Code splitting can be a nice optimization but it can also be a lot of effort for little gain as it is in our case. It is an optimization for the few times a user hits our app with a stale or empty cache. And we have no mobile users, this is an enterprise analytics app.

We do not grow organically by people stumbling on our app and thinking "wow that was fast". We go through months of enterprise sales process to ink a deal, then onboard maybe 20 key users at the company.

To put the effort into code splitting would be purely an exercise in keeping up with the new hotness. That's not to say we don't keep a close eye on the package size, just that it's not much of a great optimization for a regular user's experience in our case.

Also serving all assets from the same domain saved us some time in domain resolution.

<comment><USER3> The last part, absolutely yes. CDN's are obsolete, although they'll jump through all sorts of hoops to convince you that's not the case.

As long as your service uses HTTP/2 it's far more efficient from DNS and multiplexing/TCP/TLS handshake standpoint to serve from your own domain. And better for security most of the time since hardly anyone uses CSP and hash signatures for their third party scripts.

The original sell of CDN was that everybody would have the same libraries cached. With the massive poliferation of JS you would have to have a 100 gig cache for that to be remotely true.

A couple years back I moved a C# app to .NET core for the HTTP/2 support. I tried removing the ~4 external CDN dependencies just to see what happened. Load speed improved around 30% because no additional DNS lookups and TCP window stuff worked around by multiplexing.

An aside, try not to use multiple subdomains. They trigger DNS lookups and don't work as well with CORS. It's easy to accidentally trigger cors and a bunch of meaningless round trips by using different subdomains

<comment><USER4> I think you are conflating general Content Delivery Networks with "shares JavaScript library repositories that happen to use a CDN". While the "it's a shared repo of common JS files so it's already cached" idea never really worked (you are right about the added cost of DNS + tcp/TLS) general Content Distribution Networks absolutely provide performance benefits by delivering your static (and optionally dynamic) content from edge nodes that are much geographically closer to the visitor. Usually these CDNs front the entire site origin, so you dont have extra dns/overhead for subdomains like shared JS repos.

(I work with many IR Top 100 retailers, and I've helped to build the dashboards comparing edge vs origin. It's valuable even for sites where the majority of the visitors are in the US, and especially so if you have a substantial international audience)

<comment><USER3> When they front the origin there's definitely an advantage, I agree.

But that implies: You allow a CDN to host your initial asset, possibly a security risk

You only use that one CDN for most/all non-dynamic content.

When latency becomes that important I would rather host my own AS. Giving CDN the origin and your first content load is effectively handing off your entire site security to a third party.

At that scale you could easily and cheaply run multi-homing on your own AS in maybe 10 colos across the world. Maybe 100k a year to eliminate third party risk. Maybe worth it? I think so

</comment></comment></comment></comment><comment><USER5> Ugh.. does anybody else have this feeling that no matter how fast JavaScript gets, average web app performance will not change at all? Kind of like with risk compensation principle - the safer your gear, the more risks you take on, we're in the same spot with web/electron apps.

JavaScript vms got so much faster than 10 years ago and yet all the web sites are much worse. Memory and cpu hogs.

This is not something improving the vm can fix. There just is no competition so that customers could send a feedback signal saying that performance is unacceptable.

<comment><USER6> What do you mean there's no competition? This feels like such a weird statement when there's competition in just about every market segment on the web. If you mean there's no competition where the differentiating feature between competitors is performance then well sure, that's a lot rarer.

For user-facing applications performance only really matters in human time, and is pretty far down on the list of how people choose software over things like features, price, ease of use, etc.. Until performance becomes a big problem because the app/site becomes unusable it's basically no problem.

Hackers might not like it but we're such a weird market to sell to. Not necessarily that performance is a weird preference but that by in large hackers are perfectly fine with woefully inefficient feature-packed apps for their "primary" apps like their IDE but then want super lightweight skeleton- featured experiences for everything secondary.

<comment><USER7> Performance _is_ a feature. In fact it's the most important feature.

<comment><USER8> Well, correctness / security are probably more important than performance.

(Spoiler alert: If your system is well-enough implemented to be correct, it is well on the way to being secure and performant too)

</comment></comment></comment></comment><comment><USER9> If you look at why the bundles are so big, the frameworks are so large etc., you'll realise it all comes down to fighting browser deficiencies:

\- no declarative APIs for DOM updates

\- no good APIs to do batch updates

\- no native DOM diffing (so decisions on what to re-render have to be done in userland)

\- no DOM lifecycle methods and hooks (you want to animate something before it's removed from DOM, good luck)

\- no built-in message queueing

\- no built-in push _and_ pull database/key-value store with sensible APIs (something akin to Datascript)

\- no built-in observables and/or streaming

\- no standard library to speak of

\- no complex multi-layered layout which matters for things like animations (when animating a div doesn't screw up the whole layout for the entire app/page)

etc. etc. etc.

As a result every single page/app has to carry around the whole world just to be barely useable.

<comment><USER10> > As a result every single page/app has to carry around the whole world just > to be barely useable.

So pages before this javascript bloat became commonly accepted were unusable? Maybe at some point web developers have to accept that the web was simply not built for the things they're trying to do with it, and that comes with a cost. Maybe they should evaluating whether they _really_ need animations on everything, whether everything _has_ to be a SPA made in [current popular framework]. I'm not even saying these things are bad, they absolutely do have value, but that value has a tradeoff, and usually that tradeoff is placed on your customers.

<comment><USER11> The parent's point is that, if all these things were browser JS runtime features, there'd be no tradeoff to be made. They'd be "free."

If every JS page in the world today includes the same line of code, isn't it obviously the fault of browser makers for not making that line of code part of the JS prelude and thereby making it "free"?

<comment><USER12> That's a slippery slope. We'll eventually turn the browser into an OS.

And more features = more surface area for bugs.

<comment><USER13> An OS? An exaggeration maybe, but only slight. The browser is pretty much its own environment already. It's been the case for decades. It can display text, process a variety of media, and run programs (written in JavaScript). The main cause of frustration at this point is that, compared to other popular programmable environments (C, PHP, Python, node.js, etc), where some real focus is put into evolving the language along with a variety of primary development tools, people in charge of the browser's ecosystem seem to still be coming to terms with the programmable part of its identity.

All the dilly-dallying results in community efforts that pile on top of each other to create all this bloat that is carried from one tool to the next framework.

</comment></comment></comment></comment></comment><comment><USER14> "Avoid large inline scripts" should be 'Avoid all inline scripts' in practice.

Inline scripts prevent using CSP 'unsafe-inline' therefore increasing XSS risk. Performance is only a secondary problem here.

<comment><USER15> What's wrong with the hash approach?

<comment><USER14> It's not "wrong" in the sense of being intrinsically unsafe, but IMHO it's a bad habit which can tempt to insecurity in the end.

When working with external files a programmer almost has to work with the framework, and once (s)he does that the framework - well, a modern framework - would take care of the security details and do it right.

When working inline it's too easy to add a script tag manually, and from there it's a bit too easy for someone in the team to miss something (write a js without the hash/nonce and not notice the warning) or talk him/herself down to lowering security ("importing this 3rd party js is too hard, lets use just a nonce and forget about hashes", "this policy is too constraining, it's just a SMALL script, no risk here").

When working in a team, it's much better to have a hard and fast rule which forces everyone to work right. There's really no reason to use inline when using external files works really well now - and is apparently better for responsiveness too.

</comment></comment></comment><comment><USER16> It's interesting that they benchmark Facebook and Reddit, two sites I find significantly more laggy than, say, Google. Are there choices in _how we build sites_ that are more important than how V8 can optimize things?

<comment><USER17> Are you comparing the Facebook news feed to the Google home page? Is that a fair comparison, considering the news feed does a lot more than loading static assets? Unless you were comparing the News Feed to say, logged in Gmail.

</comment></comment><comment><USER18> I read the title as "the price we're paying for everything being written in JS these days"

<comment><USER19> Me too. I keep asking people about the business value of Elm vs JS. Why isn't Elm-lang wildly popular?

(I think I know the answer, but even so I'm interested in what other people think.)

<comment><USER20> Because it's a business risk.

\- It's very easy to find JS programmers. There's a _lot_ of them. But programmers proficient with pure functional programming languages are harder to come by.

\- JS is natively supported by browsers and it is pretty much guaranteed that the code you write is going to work for ever. Elm on the other side, who knows? It might lose steam and go into support mode, or drop support, or maybe they introduce breaking changes in a future version. JS is a much safer bet.

\- Writing Elm does not guarantee a good polished product. You can write bad software in good languages and vice-versa.

That being said, it's only a risk. Maybe your team is more comfortable with Elm and they get more productive. Maybe the language design makes easier writing code with less defects. Maybe it actually gives you an edge.

It is hard to say if Elm brings value to your business. It most likely depends on what kind of a business that is (web agency than cranks 3 visit-card websites a day? Or is it one developing a complex app?)

In any case, managers get very nervous about languages that are not mainstream. And they do have good reasons.

<comment><USER19> Thanks for replying.

> But programmers proficient with pure functional programming languages are > harder to come by.

I used to get a similar argument when pushing Python over Java, and my counterargument is the same: I wouldn't hire a JS programmer who was afraid or unwilling or unable to learn Elm. I would bet that any normal person smart enough to solve Sudoku problems could learn Elm, I wouldn't make that bet with JS/CSS/HTML.

> It might lose steam and go into support mode, or drop support, or maybe they > introduce breaking changes in a future version. JS is a much safer bet.

But who is using _just_ JS these days? Frameworks and transpiling are the order of the day, no? Same argument applies to them. And JS is a moving target too. As for "breaking changes", well, it is just version 0.19 so far. Once they hit 1.0 I would bet on Elm being more stable than JS+Whatever.

Weigh this against _zero front end bugs_. That's a staggering (if hard-to- quantify) cost savings.

> Writing Elm does not guarantee a good polished product. You can write bad > software in good languages and vice-versa.

Yeah but that's not an argument in favor or against any particular language, and in the specific case of JS vs Elm I think it's clear Elm wins. If your developers are truly crap then, yeah, Elm won't save them. But then you also have bigger problems than what tech stack to use, eh?

<comment><USER21> > I wouldn't hire a JS programmer who was afraid or unwilling or unable to > learn Elm.

Would you hire an Elm programmer who was afraid or unwilling to learn proper JS?

<comment><USER22> Also I want to throw in that learning a new paradigm (Elm) is something else entirely than going from one imperative language to another one.

<comment><USER23> In all fairness the functional paradigm isnt exactly all too hard to grasp (when it comes to what you need to be effective at least, you dont need to understand what a monad is, I still dont!). I started learning Clojure completely cold going through Exercism and it took me maybe 2 weeks of doing a problem a day (not much work at all) before I felt like I started to "get" FP. In fact, I would say it's even easier in a lot of cases because FP is a much "purer" skill set- any imperative language still uses functions, and arrays, and switch statements, and overloading. In FP, you have all of those familiar concepts (just presented in a possibly different way) but you dont need to worry about how classes work at all, or even loops in some cases!

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> This is an excellent analysis of JS performance and usage, although it seems to suggest optimizing your site for V8 a bit too much.

Also, the "LONG TASKS MONOPOLIZE THE MAIN THREAD. BREAK 'EM UP!" section header felt a bit on the nose.

<comment><USER25> > it seems to suggest optimizing your site for V8 a bit too much.

+1. After seeing some opinions that Chrome is becoming the new IE over the past few weeks, I've switched to Firefox to do my small part in trying to prevent another browser monopoly.

<comment><USER26> Which parts of the article aren't applicable to Firefox? It seems like most of these idioms should give advantages to SpiderMonkey (if it's still called that) and V8.

</comment></comment></comment><comment><USER27> Tip no. 1: Don't put any code on the page that doesn't need to be there, then any minute differences in the exact implementation likely won't add up to much.

</comment><comment><USER28> I would also be interested in the cost of developer time lost by using the language itself and compensating for it's almost entirely lacking standard libraries.

<comment><USER29> I have usually found, installed and started using a good javascript library in less time than it would take me to make sense of MSDNs enterprise-soup documentation.

<comment><USER30> What does MSDN have to do with this? Are you talking about C# and .NET specifically? Have you seen the current documentation? [https://docs.microsoft.com/en-us/](https://docs.microsoft.com/en-us/)

<comment><USER29> Yes, I felt brave, so I went after everyones darling C#, and not an easy target like Java.

I read C# documentation several times a week. I do not like it.

<comment><USER31> Can you provide some examples of documentation you do like?

While I can't ever remember reading some documentation and saying, "Wow, that was fun!", so I can't say there's any documentation I like. But I do find that the MSDN documentation usually gets me working, and not reading documentation much faster than others for e.g. Python, Java, JavaScript, CSS, my pedometer.

<comment><USER29> > Can you provide some examples of documentation you do like?

MDN (Mozilla documentation for web stuff) is generally pretty good. Obnoxious colors aside, this javascript library is very easy to get started with:

[https://localforage.github.io/localForage/](https://localforage.github.io/localForage/)

</comment></comment></comment></comment></comment></comment><comment><USER32> As a JS dilettante, I found this incredibly surprising.

        const data = { foo: 42, bar: 1337 }; //

>>> can be represented in JSON-stringified form, and then JSON-parsed at runtime:

        const data = JSON.parse('{"foo":42,"bar":1337}'); //

>>> As long as the JSON string is only evaluated once, the JSON.parse approach is much faster compared to the JavaScript object literal, especially for cold loads.

<comment><USER33> I hate these microperformance hacks. There's no way you're going to have a bottleneck here and you're making the quality of your code dramatically worse.

<comment><USER34> I hate that this micro performance hack actually is better - why don't they just fix this in the JIT so that the literal is just as fast as the JSON parse? Why do we have to think about this?

<comment><USER35> The runtime can't know whether it's parsing a plain old JSON-compatible object literal until it, well, parses it.

<comment><USER36> IANAProgrammer but couldn't it do like try..catch and assume it's JSON compatible and fall back to the [much] slower method if the parse fails? Does that cost too much time/resources?

<comment><USER37> That would make all JavaScript that has non JSON object literals (most JS code) slower

<comment><USER36> How much slower?

We already established it's far slower parsing js; in most cases JSON parsing would fail - IIRC - on the first character ^[^{] ... so would it be worth being slower by the time it takes to check the first character, and then only JavaScript that started with { would be slower. Which I guess is virtually none.

I suppose those sorts of questions are part of what makes language design interesting.

</comment></comment></comment></comment></comment></comment></comment><comment><USER38> "With HTTP/2 multiplexing, multiple request and response messages can be in flight at the same time, reducing the overhead of additional requests."

Oh... we are using Servlet 3.0

<comment><USER39> Odds are good that a reverse proxy will improve availability on your servers. It will also allow you to fix this problem.

<comment><USER38> Looks that is true. Thanks for the information!

</comment></comment></comment><comment><USER40> Another strategy is to make the files cacheable, and have some version naming scheme to invalidate caches. You can also lazy load features as most users will likely only visit the front page and then leave after 3 seconds. No need to have users wait for functionality they wont use.

<comment><USER39> Several of the bundling tools have had a way to emit the file with a hash of the contents on the end of the filename, rather than using version numbers.

One of the places this helps you is when you push out a one line javascript bug fix without invalidating your CSS caching across the entire site, because the CSS files are identical.

It also helps you with people with the website open when the new code gets pushed. They either have all the old code or all the new code and no bizarre mishmash of the two.

<comment><USER40> With making the files cache-able I mean _not_ bundling them. The first load will be longer (unless you use lazy loading), but successive page loads will get the files from cache, and if there's an update, only that file will update. It's not usual to have updates shipped several times per day, and if there's many users there will also be many unnecessary reloads of the bundle.

It's a bit of a optimization as to be 100% sure users always get the latest files the version naming scheme is needed, but most of the time it will work anyway, eg. if you have no caching layers /CDN etc in-front of the web server. So if you want to shave off milliseconds on first load, go with the bundle, but if you want to save user's bandwidth and make your site/app more lightweight - don't bundle!

<comment><USER41> Most bundlers have ways of splitting the bundle into smaller pieces that can be cached (and cache-busted with the hash in filename) independently. I think that's what the parent commenter was talking about. So you don't have to choose between one huge bundle and hundreds of individual non-bundled files, with code splitting and lazy loading, you can do something in the middle and have like 3-30 "minibundles". Then, if you make a modification that only affects one of those bundles, only that bundle needs to be reloaded and others can still be served from cache.

</comment></comment></comment></comment><comment><USER42> With their redesign and a few other choices, Reddit has gone from one of the most beautiful places on the web to the second most hostile UX that I put up with.

I don't want to "GET NEW REDDIT" as I'm urged to in the top left of every page because I don't want a card-based layout. The whole reason I and so many others left Digg for Reddit to begin with was for a highly skimmable, information-dense site!

Similarly, I don't want to install a mobile app. The page worked fine on mobile when I got my first iPod Touch a decade ago. Why do I have to see a huge USE APP button in the nav bar and then lose another 20% of the page at the bottom to a See Reddit In section at the bottom that's also urging me to install a native app?

Infinite scroll actually slows down my browsing experience too, since it no longer loads as many entries at a time and I have to keep waiting for pagination.

<comment><USER43> For desktop

old.reddit.com

or for mobile

reddit.com/.compact

Both are low nuissance and both still work for me, although I am not sure if that is region based.

<comment><USER42> > old.reddit.com

It doesn't put a big red "GET NEW REDDIT" in the upper left that does a single-click update of your account settings? What region are you in?

> reddit.com/.compact

I just tried that and the top 40% of my screen was spent on a banner telling me, "You've been invited to try out Reddit's new mobile website!" Clicking that lead me to a page where both the top bar and the bottom section harass me to install their mobile app.

<comment><USER44> I use a uBlock Origin rule to hide the upper-left button.

<comment><USER43> Indeed I overlooked the fact that I am also using ff+ublock.

</comment></comment></comment></comment></comment><comment><USER5> Largest cost of JavaScript is having to write JavaScript. It's insane anybody would willingly do that nowadays. I think literally everybody writing JavaScript secretly wishes they were using some other language with JS transpiler.

I refuse to believe anybody can honestly say they want to write JavaScript code unless it's code that makes them write less javascript in future.

<comment><USER27> I have yet to find a better package, when you transpile, debugging always has that funky thing with two different source codes where you wrote one and the other is what is running. And it is not like you can do anything that you can't do in JavaScript, either you have a feature subset, or you ship with a library that the transpiler attached.

<comment><USER45> You miss the point. The issue isn't whether it's nicer to use a transpiled-to- JS language or JS itself. The issue is that JS as the root is an unfortunate situation, and there are so many other languages that would be superior.

Just look at the history of JavaScript. It does not deserve the attention or human time that it currently gets (compared to other languages, assuming we could all decide simultaneously to replace JavaScript with another language).

<comment><USER46> I have a hard time justifying using any other dynamically-typed language over JS. And JS' static typing story is pretty mature. And it has cool features like async-everything and a first-class Promise.

So, let's not be too extreme here just because you don't like something. It gets really silly to hear HNers suggest the equivalent of "I don't understand how people own blue cars. They must secretly aspire to drive $myFavoriteColor. Don't they realize how stupid blue looks to me?"

</comment></comment></comment></comment><comment><USER45> They left out measurements of "cognitive load".

</comment><comment><USER47> Const data() = JSON...

</comment><comment><USER3> Great article. I applaud the massive amount of effort that's resulted in JS being far faster than anyone ever expected.

It's time to switch to WASM though. Half native speed with almost no parsing overhead. As integration and tooling improve I see no reason to stick with JS.

It also rectifies a number of historical mistakes that are nearly impossible to fix. Mainly threading. WebWorkers etc are a huge hack. No atomic data structures, no shared memory, huge overhead. WASM will be many times faster than JS from threads alone. Add the natural speed advantage and you're looking at maybe a 20x performance difference.

<comment><USER48> The last milestone I see on the WASM page is from 2017 - is it still a thing?

<comment><USER3> It's stable now and implemented in all major browsers.

<comment><USER49> Last time I checked you didn't get DOM manipulation, so you'd still need to use JS for that.

<comment><USER3> Yes. Rustaceans have stepped up and provided a ton of nice shim layers though. So practically, you don't have to actually write your own js to interface

</comment></comment></comment></comment></comment><comment><USER50> This isn't quite true. It's only true if you're browing from a computer that is moderately fast (at short timescales before throttling at minimum) and using a browser that does not respect your software freedoms. There are literally hundreds of millions of us out there where executing javascript code on sites made entirely out of javascript can be significant. Weather it's because you use many, many tabs, or browse using an old smart phone.

But of course that's not the real cost. That's the computation cost. The real cost of websites switching to an application model directly targeting the DOM is the loss of accessible webpages and the chance that every time you're going to get owned. Weather it's some information leak from speculative execution or something else.

Running JS on every page these days is just as stupid as opening every attachment you get emailed to you.

</comment><comment><USER51> _" On mobile, it takes 3–4× longer for a median phone (Moto G4) to execute Reddit's JavaScript compared to a high-end device (Pixel 3), and over 6× as long on a low-end device (the <$100 Alcatel 1X)"_

Notable that they avoid the iPhone comparison. It runs circles around even the top end Androids for JS performance.

<comment><USER52> Maybe you misunderstand what this article is about, s not about what is the best phone, is about how JS is run in real world where not everyone has super fast internet all the time and not everyone has a super fast phone or computer.

So if you are a web developer you get some good advice from this article related to JS not what phone to buy.

<comment><USER51> They are making the point that low end phones are much slower in executing JS than high end phones. Perhaps to remind developers that their experience, on their phone, isn't the experience everyone has.

I imagine a lot of developers have recent iPhones. They are, depending on benchmark, up to 3x faster than a flagship Android. Which means the top to bottom chasm is much larger than the snippet suggests. Noting it would strengthen their point.

<comment><USER52> OK, sorry I missundertoo then the iPhone point, my bad, I interpreted it as iPhone is super fast so nobody should forget to mention in any article the iPhone is the fastest phone and Intel i9s are the fastest CPUs.

I agree that we the developers should not forget that a lot of people have less powerful hardware.

I sometimes hit thus problem at work, say we offer feature X like uploading an image and you can crop that image and apply a filter, how should I add this feature but not have the code even load in the browser if you don't intend to use, is there a pure JS way to do it? AFAIK thee is no good way to load a script at runtime and get an even when the file is loaded and parsed.

<comment><USER53> > _AFAIK [there] is no good way to load a script at runtime and get an [event] > when the file is loaded and parsed._

You can do this easily by creating a script element dynamically and then either:

1) Listen for the load event on that element, or

2) Have the dynamic script call a function that is already loaded.

Here is an example of the first technique:

      let script = document.createElement( 'script' );
      script.addEventListener( 'load', () => {
          alert( 'three.js is loaded: ' + THREE );
      });
      script.src = 'https://ajax.googleapis.com/ajax/libs/threejs/r84/three.min.js';
      document.head.appendChild( script );

[https://jsfiddle.net/geary/szmc1L0h/9/](https://jsfiddle.net/geary/szmc1L0h/9/)

<comment><USER52> Thanks, I use this techinque but I had issues with it in the past, I tried a few minutes now to find documentation to confirm if the onload guarantees the script is loaded and finished parsing/interpreting but I can't find it.

Your example code works in all the browsers I tested so maybe it was an issue ith th particular script I was testing, there are third party scripts like for embedding an image editor, those could also use this trick to load some dependencies.

Great. so I was wrong then, this should work with most third party scripts.</comment></comment></comment></comment></comment></comment>


Show HN: Cloudburo Publishing Bot for Evernote - <AUTHOR> https://publishingbot.cloudburo.net/ <comment><AUTHOR> Just to give a short overview:

A powerful, intuitive content publishing approach aimed a Startup, Micro Businesses, Freelances, as well as Hobbyists Blogger.

You will use the power of Evernote's One Workspace to manage and collect great sharing content, to compile it and then leave the task to the Publishing Bot, to deliver the content to your nicely, mobile-friendly designed Web site.</comment>


Herschel telescope switched off - <AUTHOR> http://www.bbc.co.uk/news/science-environment-22914076 <comment><USER2> So if Herschel leaves L2, will it go into a permanent heliocentric orbit or will it decay?</comment>


Show HN: Matlock Extension – Discover the Open Source Libraries Pages Are Using - <AUTHOR> https://getmatlock.github.io/ <comment><USER2> I just received this email:

      Hi Nikolas,

       My friend Oliver and I have included d3 in our chrome
     extension https://getmatlock.github.io/, which works by
     identifying the open source libraries a webpage is using.
     Our goal is to give credit to the work that open source developers make.

       We just submitted it to Hacker News news.ycombinator.com,
     so if you think this would be useful for open source
     developers, we hope you'd consider throwing an upvote our way ;)

      Hope you don't mind the unsolicited email

Lol. Okay, every time I submit something to Hacker News I'm just going to spam a bunch of people as well :P

<comment><AUTHOR> Hey njn; apologies for the annoyance. My buddy Adam who I worked on it with reached out because we included d3 as part of the extension. Thought it would be useful, but apologies that you got annoyed by it :(

</comment></comment><comment><AUTHOR> Hi all - Been working on this extension with my buddy Adam (for both Chrome and Firefox) for a while. I wanted to know which Open Source libraries pages were using, and pull in info/context/data from GitHub (and a couple other sources) based on those libraries.

The idea is pretty straight forward: you click on the Extension Icon, and it'll analyze the page you're on and show you the libraries, basic data from GitHub (like star-count and when it was last committed to), the location of the developer(s) (if shared), and the description.

Open to any feedback or questions :)

</comment><comment><USER3> this is very useful for figuring out what components your legacy projects are using. very nicely done. thanks for the hard work guys!</comment>


Ask HN: Do You Worry about Patent Infringement when Deciding on Startup Idea? - <AUTHOR> Given the 'obviousness' (not in the legal sense) of many business process patents relating to the web, it seems that a new web startup would find that it stands a not insignificant chance at infringing on some intellectual property.<p>Has anyone done a patent search prior to developing a web startup?  What did it cost? <comment><USER2> IANAL, and this is not legal advice, but I have heard this analysis from software engineers wiser than me:

Unless you have very specific expertise in the interpretation of patents, given their specialized lanaguage and all the circumstances of related law and practice, you are highly likely to misinterpret them in expensive ways.

Further, if there's evidence you've knowingly infringed a patent, damages are much larger. So in some ways it's better _not_ to seek out information about related patents, unless it is a part of your professional job description.

When you're applying for your own patents, a certain amount of research about prior work and patents is necessary. But otherwise, you can wait for those with patents to inform you of their claims. That call may never come; it will typically only come if you're successful, and at that time the deep expert analysis of specific situations becomes cost-effective.

(A different analysis for other engineering domains -- hardware, chemicals/materials, drugs, etc. -- may apply; this analysis most pertains to software and business methods.)

Also, you mention business process patents. They might not survive in current form past the present Supreme Court session. See:

[http://www.businessweek.com/technology/content/jun2009/tc200...](http://www.businessweek.com/technology/content/jun2009/tc2009061_905686.htm?chan=top+news_top+news+index+-+temp_news+%2B+analysis)

<comment><AUTHOR> Thanks for the advice, I'll take it!

</comment></comment><comment><USER3> You shouldn't bother, except perhaps in a few specialized fields.</comment>


Marc Andreessen's theory of the bubble in bubble-spotting - <AUTHOR> http://www.vox.com/2014/5/8/5691670/Marc-Andreessen-theory-of-the-bubble-in-bubble-spotting

<comment><USER2> I remember similar lines from the real estate sector around 2006.

Not that I know if tech is in a bubble or not, but there does appear some overvaluation and a bit of irrational exuberance. No offense Marc, but you are not exactly an unbiased observer.</comment>


Show HN: React component for A/B testing. What do you think? - <AUTHOR> https://github.com/react-alpha-beta/alphabeta#alphabeta <comment><USER2> There are a couple other A/B testing utility components out there:

[https://github.com/pushtell/react-ab-test](https://github.com/pushtell/react- ab-test)

[https://github.com/olahol/react-ab](https://github.com/olahol/react-ab)

How does this differ?

At first glance: I might be misunderstanding something, but the need to create a custom backend endpoint seems like a pretty big commitment, especially if I'm already using an existing service.

It would be nice if the impression data were exposed in _callbacks_ passed to the "ABComponent" as props, which would allow us to use existing services to track such things. This would prevent the need to have a custom endpoint that is coupled to this specific implementation.

</comment><comment><USER3> That is a great component, will definitely use it in my next project!</comment>


Always bet on text - <AUTHOR> http://graydon2.dreamwidth.org/193447.html <comment><USER3> People can read much faster than they can speak, and they can google a new words.

You can Ctrl+F arbitraly big text files for keywords. Good luck with doing the same with 2-hours-long video file or mp3. You will need to listen to the whole thing. That's what annoys me about the new trend to do tutorials as video.

You can easily diff text.

Text works with version control systems.

Text works with unix command line tools.

You can trivialy paste relevant fragments on wiki pages, in emails or IM discussions.

Google translate works with text.

Screen readers work with text.

<comment><USER4> OK, there are so many advantages of text. I wholeheartedly agree and prefer plain text over most "smart" formats.

BUT.

I have this pet idea about source code. Text isn't the optimal format because a program _is_ not a lineal thing, but closer to a tree structure.

Why have we settled on programs written in text? Pretty much for all the reasons you wrote and the fact that we've had bad experiences with other kind of formats in the past. Being able to fall back to plain text when things go wrong is very nice.

But it has its own sort of usability problems. There's an _impedance mismatch_ between text and programs and sometimes it shows. Actually we don't see it more often because we tend to think that text is the way it is done, always was done and always will be done.

<comment><USER5> >Text isn't the optimal format because a program is not a lineal thing, but closer to a tree structure.

I can tell you what it's like from experience. The Interlisp D environment used a structure editor rather than a text editor. I found it infuriating and clumsy. Admittedly I had come from the emacs-infused PDP-10/Maclisp & Lispm world, so I gave it several months, but in the end I adapted an Emacs someone else had started and did all my editing in that.

I figure if this would work for any language it would be Lisp, and it didn't work for me. It sounds like a great idea, since if the editor's "buffer structure" _is_ the program structure it's easy to write lambda functions to, say, support refactoring your code. But it was rarely convenient.

The other thing that didn't work for me was that it was of course a mouse- driven interface (this was PARC after all) and I found shifting my hand off the keyboard all the time slowed me down a lot too.

<comment><USER4> _I found it infuriating and clumsy._

I've heard about programs that tried to do that before that had massive usability problems. Your comment seems to confirm that diagnostic.

 _I figure if this would work for any language it would be Lisp_

I guess it would be more of a novelty for _other_ languages.

 _I found shifting my hand off the keyboard..._

That's a big no-no!

EDIT: By the way, I've been experiencing something similar recently, teaching Scratch and AppInventor to my son and a group of children at Coder-Dojo:

[http://medialab-prado.es/article/coderdojo](http://medialab- prado.es/article/coderdojo)

Kids like the mouse interface, but I do find it very limiting and slightly infuriating.

</comment></comment></comment></comment><comment><USER6> I agree that text is undervalued in our current media happy era; I say this as someone who uses terminal applications as much as possible (email, twitter, accounting, programming, etc. - I secretly pray for a return of the text only internet)

On the other hand, there are things that pictures can convey in ways that plain text couldn't approximate.

To link to a famous example: [http://en.wikipedia.org/wiki/File:Minard.png](http://en.wikipedia.org/wiki/File:Minard.png)

Just looking at this, in half a minute or so, you get a pretty good idea of the quantities involved, how they evolved over time, how they are linked together, etc. Conveying the same information with pure text would be much more lengthy.

I'm not going to make an entire case for this right here - just read Edward Tufte's books if you aren't too familiar with those ideas.

<comment><USER7> I agree, the wikipedia example is especially strained, sure you can not represent that sentence clearly in picture, but can you represent Mona Lisa or Beethoven's 5th in text? Different types of representations are used for different things, sometimes they overlap and one is more efficient than the other and yes text has been pretty useful.

<comment><USER3> > can you represent Mona Lisa or Beethoven's 5th in text

It was first created in text :)

<comment><USER8> How many people could fully experience Beethoven's 5th by reading the sheet music, assuming they've never heard it before?

<comment><USER9> For musically gifted people who read sheet music every day, I have heard that they start to hear scores in their head while reading them, and that it's not so different than reading words. So in the case of classical music, the comparison to text is quite applicable. Shakespeare is almost unintelligible to me until I see it performed. I see no difference between this and a textually encoded symphony.

</comment></comment></comment></comment></comment><comment><USER10> > Text is the most efficient communication technology. By orders of magnitude. > This blog post is likely to take perhaps 5000 bytes of storage, and could > compress down to maybe 2000; by comparison the following 20-pixel-square > image of the silhouette of a tweeting bird takes 4000 bytes: <Twitter Logo > Here>.

My reaction when reading this was, "Yeah, but that's because you encoded it in PNG. That's a 'good-enough' encoding, but you can definitely make it more efficient by making it an SVG, since that image is of the kind that's ideal for vector graphics." And then I remembered SVG is a text-based image format.

Touché, frog hop. Touché.

Adding to the point: karma system on sites such as Reddit has incentivized converting text into images, because text posts don't get karma. For example, r/quotesporn[1] (safe for work) has many more users and quotes than r/quotes[2] which allows only text.

As a collector of quotes, this annoys me to no end, because I can't copy/paste the quotes into my personal quotes collection.

[1] [http://reddit.com/r/quotesporn](http://reddit.com/r/quotesporn) (safe for work)

[2] [http://reddit.com/r/quotes](http://reddit.com/r/quotes)

<comment><USER11>
      > As a collector of quotes, this annoys me to no end, because
      > I can't copy/paste the quotes into my personal quotes collection.

I haven't used it myself, but you might find [http://projectnaptha.com/](http://projectnaptha.com/) interesting — it's in- browser OCR of text in images.

<comment><USER12> I used the Chrome extension for a few months and the OCR was never very accurate. Even giant, clear block letters were often not recognized.

<comment><USER13> It always worked pretty well for me. It just got annoying to have on all the time.

</comment></comment></comment></comment><comment><USER14> Doug Engelbart of Mother of All Demos fame talked a lot about artifacts. Books are an artifact of paper and text. WISIWYG is an artifact of print media.

The technology of the medium determines the best way to convey information through it. And on top of that, whatever people are used to may influence what they do in a newer medium. For example we write to imitate speech. We use books on screens and try to recreate the world of print with WISIWYG design tools.

Text may be an evolutionary winner so far, but it is by no means some ideal artifact for communicating when computers are widespread.

<comment><USER15> Text may be an evolutionary winner so far, but it is by no means some ideal artifact for communicating when computers are widespread.

Which is...right now.

<comment><USER14> Yes. There are few serious attempts to come up with better artifacts because we're so used to existing ones.

And another point of Doug is we're too lazy to learn complex new artifacts. Reading and writing takes a while but it's worth it. If someone comes up with a better idea that needs time to master it will be a hard road ahead, people like short learning curves when dealing with computers.

<comment><USER16> On a small scale I do think we have been developing new ways of expressing and communicating though. Smileys to me are a good example of this, but you can even include the 'x is typing a message' and 'read at <time>'.

While there is no universal consensus on what exactly this kind of 'information' means, within specific groups (and ages) they can convey a lot.

I've been chatting since I was fifteen or so, and to me and many people I chat with, a particular smiley, or the 'is typing' message can have a lot of meaning. I even find myself actively 'manipulating' this information at times: I might intentional start and stop typing at times as an analogue to the face- to-face act of saying 'hmm', looking away thoughtfully and not answering immediately.

I suspect all this meaning encoded in non-text things (practically speaking) is even more common among younger people.

</comment></comment></comment></comment><comment><USER17> Yes, and this carries over _very well_ when talking about code and programs.

Whenever I hear about the stories of the potential of graphical programming languages, "live" code environments living in their own VM, and graph-based logic stuff, the first thing that comes to mind is how come those systems have such a short shelf-life even when some of the concepts behind them are so brilliant.

Between the increased storage space, the interoperability issues, and the exponential difficulty in dealing with non-text media in a variety of operations, there's so much more additional friction to these systems that in the end they're not worth it. Unless, of course, they can be trivially converted to plaintext and parsed as such, then they have a fighting chance.

</comment><comment><USER18> Every letter, number or any sign is a "picture". In fact every written text is in fact structured array of simplified pictures, which happens to be understandable under conditions of given language rules. What should be bet is information. It doesn't really matter what communication tool will be used - information is the creme de la creme. Think about this - I can write simple text: "Mother should love their childrens". Would you still bet on text, if i wrote this in different language? "Każda matka powinna kochać swoje dzieci" or "Kila mama lazima kuwapenda watoto wao" isn't as understandable by most of people, despite the fact letter I used are almost identical. And how about other characters? "יעדער מוטער זאָל ליבע זייער קינדער" or "すべての母親が子どもを愛する必要があります" (thanks google translate ;))? In the end what matter is not text itself, but message behind it.

<comment><USER3> > Would you still bet on text, if i wrote this in different language? "Każda > matka powinna kochać swoje dzieci"

I happen to understand that, and if I haven't I would just google translate it.

Now, if you made a video saying that and I couldn't understand you - no such luck.

Text is the only medium for which we have reliable operations working on semantic level.

<comment> squeaky-clean The parent post even used google translate to generate some of those sentences. You can't do that with video/audio.

You could enter the sentence into google translate, have it attempt to synthesize a pronunciation, and then you verbally mimic it to the best of your abilities. But now, not only are you compounding the inaccuracies of google translate, plus the inaccuracies of the speech synthesizer, plus the inaccuracies of your own pronunciation, which means the viewer has no reliable way to return to the original source material. But the entire process is still reliant on text at one point.

</comment></comment></comment><comment><USER19> I was just telling my wife the other day about how much I'd hoped that text went away in favor of better communication mediums.

I feel shy to admit it, especially here, but I dislike text. I dislike it because it's unnatural. I view it as a hack that was adopted to help communicate ideas through time and space. It's a cool hack, but still unnatural. It requires huge amounts of training to participate, and it has other issues.

I dislike it at a more fundamental level because it tends to leave ideas 'set in stone'. Text, like architecture, seems to have an unnatural tendency to remain unmodified through time and space. It creates dogma and worship and takes up the space where new structures could have potentially formed. It creates things like the bible and the constitution - things that morph from their original intent into an unbreakable form of reverence. Since it disconnects the 'bodies' of the reader and the author, the reader has a tendency to mistake the text as something different from the author and his ideas.

Text has a place - to store the facts of the world at a given time and place, certainly. To store ideas that can be accurately represented with discrete symbology. To transmit the ephemeral. But, I truly hope that we abandon text as a 'serious' medium for ideas in favor of video, audio, simulation, and virtual reality.

Many of us have a bias toward text because that has been how we have lived our lives, through its symbols. Text has altered our brains. But, imagine that you could relive your life without it, with other forms of communication, would you still want it?

<comment><USER8> Text is the only good form of asynchronous communication we have in our daily lives. Without it, we'd all be recording voicemail for one another constantly. Who the hell wants to do that? Not to mention the fact that making audio recordings is much harder to do discreetly and impossible to do in many noisy or strict environs.

And seriously, what is natural? How is human architecture any less natural than a beehive or a beaver dam?

<comment><USER19> Natural is adapting to change, understanding that the environmental context is always changing. Architecture is usually built to last forever, but it always has to be torn down, at great expense. Or, the expense is too great, and it remains, an archaic eye-sore.

I text message as much as anyone. But, I think we all know that text messages are ephemeral. I've edited (ironically) to make that more clear.

<comment><USER20> > _Architecture is usually built to last forever, but it always has to be torn > down, at great expense. Or, the expense is too great, and it remains, an > archaic eye-sore._

Just like beehives, beaver dams and ant hills.

> _But, I think we all know that text messages are ephemeral_

Much less than sound or vision.

To make vision, sound, touch, etc. good as foundations for information exchange, you'd have to give more control to the receiving party. Make the medium skimmable and searchable.

</comment></comment></comment></comment><comment><USER21> I did some research on textual vs graphical representation for my master. According to that research (not on my comp so I can't reference it) - one of main advantages of text is a near universal set of symbols (like Ascii for images), more constrained relationships (images are 2D while text is essentially 1D).

<comment><USER22> Most of text is 2D. What is usually regarded as text is just a collection of simplified and arranged 2D symbols. What is usually regarded as a picture is collection of unarranged non-simplified 2D symbols. 1D text would be more like morse code.

<comment><USER21> I didn't meant as a visual reprentation. Text no matter how well formatted/displayed will only flow in one direction* (be it up-down/down-up and left-to-right/right-to-left). In a picture you have no such constraints. Thus a picture is harder to scan by humans and machines alike. It takes expert knowledge to tune out some of distractions of visual representation.

* Exception being texts that are deformed to instill a sense of confusion and to simply play with how text looks like. Or possibly some really obscure non-European writing system that writes non-linearly.

</comment></comment></comment><comment><USER23> Early in science education is the very important lesson that you _always_ write units for your answers, as they are _more important_ than any numerical value you happened to get. The best teacher I ever had liked to use an example of a simple cake recipe: "2, 8, 9, 2.5" tells you nothing, while "flour, butter, eggs, sugar" is something you could _experiment_ with to find the specific values. The text units (labels) convey far more information.

I propose that this is one of the key reasons why text files are vastly superior to binary formats. While they end up very similar in _normal_ use, the readability enables investigation and experimentation, while writing a raw struct out to a file keeps the meaning in the (possibly lost or unobtainable) original program files.

// if speed is needed, you can always cache the parsed version of the text file

</comment><comment><USER24> I don't understand the purpose of this post.

"Text wins by a mile." Wins what?

"Text is everything." I don't get his point.

The opening of this post has the feel more of a fan blog about their favorite baseball team than something intellectually serious.

In the second paragraph the author says "text is the most powerful, useful, effective communication technology ever, period." I suppose this is the purpose of this post? I guess if he is saying if he could only have one form of communication, he would choose text (removing speech from the list). I guess, but is this actually a debate? Are there really different "camps" that prefer images over text or video, etc?

I could delve into the arguments presented in the article but I think first I need to understand the thesis.

EDIT: To the down-voter, do you have anything to ask or say? Or are you just down-voting because you disagree? Everyone is interpreting this article to mean "there is too heavy a bias towards multimedia on the web today" but this is not the thesis of this article as I see it. The author is making arguments that text is better than multimedia in an absolute/complete sense. This is an entirely different argument.

</comment><comment><USER25> A couple more points about text:

1) In addition to being searchable, text lends itself to other forms of automated processing such as translation and text-to-speech for the vision impaired.

2) I'm prone to debilitating eyestrain headaches when I try to do any kind of graphical work on a computer, yet I can write text without looking at the screen.

<comment><USER26> isn't it very temporary advantage, till couple of decade back text wasn't searchable, and in couple of decades images may be equally searchable. Also pictures commonly have universal meanings.

<comment><USER27> > Also pictures commonly have universal meanings

Not really. Here's a common example

[http://theblitzbit.com/wp- content/uploads/2012/09/swastika.j...](http://theblitzbit.com/wp- content/uploads/2012/09/swastika.jpg)

This pictures means different things in different cultures.

Something else [http://www.ritex.it/images/20111116_A.jpg](http://www.ritex.it/images/20111116_A.jpg) Try asking a Chinese farmer what this is.

<comment><USER28> Try asking an American what this picture means -

[http://www.slate.com/content/dam/slate/archive/2010/03/1_123...](http://www.slate.com/content/dam/slate/archive/2010/03/1_123125_2245632_2246167_2247195_100308_signs_exit_greentn.jpg)

Most people would know that means "exit" but in true American fashion the United States uses a different sign - [http://www.oneskilladay.com/wp- content/uploads/2013/05/Exit-...](http://www.oneskilladay.com/wp- content/uploads/2013/05/Exit-sign.jpg)

I gotta say it took me a long time abroad to figure out what the green running man sign meant.

</comment></comment></comment></comment><comment><USER29> I tend to agree. Yet human thoughts are presented in the form of pictures (dreams? you don't really see text in front of you when dreaming).

It's one thing that a computer cannot make sense of 4000 bytes of a tweeting bird, but human brain instantly recognizes the rendered sign.

Also, videos and music are very hard to describe in text: it just does not have this unique feel video or music piece does.

<comment><USER30> Videos described in text are called "stories".

Imagine a technology that can create a present experience in the user's brain that engages all the senses and evokes a dream-like state of being there... that technology is called "text" (that's a loose paraphrase of someone in the interactive fiction community, though I can't remember who.)

Music, I will grant you (mostly), but text really is an unbelievably powerful, flexible medium. It can't do everything, and everything it can do requires a certain amount of work on the reader's part and a huge amount of work on the writer's.

The remarkable thing about text is it allows us to tame and control our dreams. We don't dream in text, but we can use text to evoke waking dreams. We can be in Mirkwood or on the slopes of Mount Doom in a way that mere video can't compare with.

<comment><USER31> How do you search a video anyway? assuming there was no text medium.

<comment><USER32> Pattern matching the audio wave or video bitmap frame-by-frame.

</comment></comment></comment></comment><comment><USER33> No discussion of labor? You guys are missing a major part of the argument.

Looking at OPs article, if my purpose is to explain human rights, text is staggeringly more efficient in labor of creation, not just time spent interpreting it or storing it or searching it.

An artists life work might produce a painting that conveys the entire meaning of the definition from the article of human rights. Maybe. I bet that would be an amazing painting and I'd enjoy viewing it. But ... aside from high art, can we afford general commerce in an artistic style? Is it affordable for society to create an interpretive dance implementation of my mortgage statement and is that a wise use of limited artistic skill and labor?

Its possible to create deeply meaningful works of art, at staggering expense of materials and labor both creation and interpretation and storage and archiving. That doesn't mean that most human creations (my water bill, the instructions for my TV, the receipt Amazon included with my $4 HDMI cable) are worthy of artistic labor.

If a graphics artist or painter is any good, I don't want that artist to waste time on my electric bill, I'd much rather have the fruits of their labor hanging on a wall in a frame. If they're not any good, I don't want them screwing up my electric bill making it incomprehensible.

</comment><comment><USER34> Not only is text durable, but plain text data is universal.

Take a document written in the word processor du jour 20 years ago. It is highly unlikely you could mount the physical media, let alone import the data with high fidelity. But plain text can be read by just about any tool, whereas binary/proprietary formats are limited by the longevity of the hardware/software that created them.

<comment><USER35> "Universal" is a strong word for data adhering to an arbitary standard that has only existed for a tiny fraction of human history.

As for not being able to mount physical media, how is that problem not exactly the same regardless of the text encoding?

<comment><USER36> Indeed - ASCII is not "universal". It's just common.

Hand someone who's no knowledge of ASCII some ASCII bytes, and no compliant editors, and see how hard it is to figure out they're dealing with the English alphabet.

ASCII mostly benefits from being a single-byte format - if a tool parses ASCII, then it's very easy for humans to go "right, that's English" looking at the output.

But this would be just as true if we had tools which handled Unicode (and most editors do exactly that now). Or it we had some other type of common binary standard which also encoded units.

It's all about the metadata - which isn't necessarily always in-band.

<comment><USER37> It wouldn't be that hard. You can think of ASCII as a simple substitution cipher - practically a Caesar cipher, really - and simple frequency analysis makes cracking such a thing literally child's play. It might take a bit longer if the data were presented as a bitstream, and you had to work out what the char length was, but even that wouldn't be too hard as there's a lot of repetitive structure in ASCII bits.

</comment></comment></comment></comment><comment><USER38> 'Always bet on text' is a catchy slogan, but the author fails to define 'text'. This is confusing because the post contains a lot of pictures of things that I don't know we would all agree are text.

Let's start with a radical position. Is something text iff it can be directly encoded in UTF-8? What, then, about symbols that have not yet made there way into Unicode? Like an i dotted with a heart. Does it become text when the Unicode Consortium says so?

Nowadays memes tend to be distributed as (animated) bitmaps. But if we wanted to, we could encode them more efficiently. So are they text?

If 'text' = Unicode then that would also mean that many mathematical expressions (matrices, fractions) are not text. Math texts before symbols were not very readable: [http://www.boston.com/bostonglobe/ideas/brainiac/2014/06/bef...](http://www.boston.com/bostonglobe/ideas/brainiac/2014/06/before_symbols.html)

ASCII-encoded math is not without problems either.

Does 'text' include semantic markup like 'emphasis', 'heading', or 'list- item'? Does it include visual markup like 'italic', 'underline', 'blue', or 'Times New Roman'?

Does 'text' include newline and tab characters? Is it correct to say that newlines and tab characters exist on paper? If they don't then why do we use them to indent blocks of code?

If a sheet of paper with scribblings can be text, then can a bitmap be text too?

Now that I've brought up mathematics, HTML, and code, should we think of text as a linear medium or is it better to think of texts as trees?

What about handritten class notes that include arrows that link together different text fragments? Are these arrows part of the text? Does that mean that texts are directed graphs?

I'm even wondering if the author might actually have meant 'always bet on language', although that seems kind of obvious.

Or perhaps he meant 'don't needlessly throw away information', which is what would be happening if your CMS served pages as HTML image maps.

That is to say, even if we're all inclined to say that text is awesome, which we probably are, we might still be saying quite different things.

<comment><USER22> Alphabets are just symbols that have some sort of meaning to you. Alphabets in a row are text. There are symbols that have no meaning to you but still are te xt such as Kanji or Korean alphabet for some people yet you consider them text. Unicode has nothing to do with what is considered text. Humans have for millenia used pictures as symbols that are used for text, in egypt for example.

<comment><USER38> Note that Unicode includes hieroglyphs: [https://en.wikipedia.org/wiki/Egyptian_hieroglyphs#Unicode](https://en.wikipedia.org/wiki/Egyptian_hieroglyphs#Unicode)

<comment><USER39> Not just hieroglyphs... Unicode includes anything you can imagine

<comment><USER38> It includes many things, but not, for example, an 'i' dotted with a heart. And to represent mathematics well you need to use MathML.

<comment><USER40> There was a request for it: [http://www.evertype.com/standards/iso10646/pdf/n258a-heartdo...](http://www.evertype.com/standards/iso10646/pdf/n258a-heartdot.pdf) (but do note the date)

</comment></comment></comment></comment></comment></comment><comment><USER41> Text also has a history and toolset that is hundreds (printing presses with moveable type) to thousands of years old (writing systems usable with some sort of scribe tool to mark clay tablets or draw on papyrus scrolls). The ability to quickly communicate in images is remarkably new relative to all that. In the renaissance you had three proper types of intaglio processes (drypoint, engraving, etching), but novel ideas required someone to create new printing blocks from scratch in a laborious process, especially relative to moveable type. Only since the advent of GUI computing systems have we had tools that make it easy to effectively communicate with images (CAD, vector and bitmap drawing apps, image manipulation apps, video editing). These tools are still very much in the realm of professionals, but tablets have done a lot to democratize the ability for laymen to use them to communicate. Furthermore, memes now form a basic form of communication, which you can see through reddit and hipchat integration.

In 100 years, what the average person will be able to communicate quickly with images is likely to be unimaginable to us today.

Anyways, I'm not saying text isn't superior in many ways, just that its way to early to judge images given technical limitations.

I think writing systems like the Chinese writing system is instructive in this respect. It had roots from thousands of years ago, like western writing systems, and both were about as effective until the end of the 19th century with the linotype machine and the mid to late 20th century with 7, 9, 14 and 16 segment liquid crystal displays. Western writing systems enjoyed a big advantage from a technical perspective until only recently because they were simple enough in form to be conveyed by simpler technologies than the Chinese writing system.

If such a gulf can exist, even if only for a few decades, between two "text" systems, then it's not a stretch to see image-based systems as comparable, but requiring better technology to become a powerful as text in the sense that Graydon is talking about here.

</comment><comment><USER42> If Chinese can be read faster (I don't know), than it's the picture that matters. Here, try to represent this picture in text:

[http://upload.wikimedia.org/wikipedia/en/b/b8/Kevin- Carter-C...](http://upload.wikimedia.org/wikipedia/en/b/b8/Kevin-Carter-Child- Vulture-Sudan.jpg)

It's 28K, a full text definition might be smaller but will be hardly accurate. My brain can process this single picture faster than a possible text representation of it.

Text is more practical 99% of the time but it's actually small pictures, known as letters, used together to symbolize concepts. I don't think my brain interprets letters individually, but my eyes mostly catch word by word, hence a picture.

<comment> andrey-p > I don't think my brain interprets letters individually, but my eyes mostly > catch word by word, hence a picture.

That's a normal thing. You read words based on their outline rather than individual letters, what with the bits that stick upwards (ascenders) and downwards (descenders). Which is why ALL CAPS TEXT IS A LOT HARDER TO READ QUICKLY, and why if you jmuble some lettres in a few wrods you can still read them with relative ease.

So the way humans read text is still kind of image based - you match a word based on a preexisting idea of what they should look like. It's just they're coincidentally easy to read by computers, too.

<comment><USER43> To expand on that perspective, words signify small, almost atomic, concepts which are relatively easy to learn - optimal elements with which to express less universal and more complex concepts. Each word can be viewed as a shorthand to a already previously defined expression.

In that context, letters would be to words what pixels are to bitmaps.

Make words more complex (also longer) and the set of those elements will be able to encompass a wider, more versatile set of "elementary" concepts (akin to a wide tree structure), but this will also be harder to learn within a reasonable amount of time. In case of pixels this is comparable to higher bit- depth.

Yes, nobody knows the full vocabulary of any natural language, but we still understand each other due to knowing a common subset of words, having redundancy within and between sentences passages etc.

Make words less complex and they will encompass a narrower set of concepts, but the whole set of them are easier to learn. You will usually have to use more of them to express concepts (deeper tree structure) though. Similarily, one would need to use a larger amount of pixels with low bit-depth to express intermediate colors.

This is comparable to having well named functions in program code - <USER2> the program into functions well enough and you will have created a set of relatively universal concepts, which the another person might understand without delving too much into the body of the implementing function each time.

Similar relationships can be perceived on the word-sentence and sentence- paragraph level, of course. Therefore the difference between pictures and text has more to do with partitioning information between abstraction levels than with some fundamental difference.

The optimal way of partitioning data varies depending on content.

For example, concepts of left and right are inherently connected with our visual and spacial perception of the world and are therefore better expressed by invoking our spacial recognition (a two dimensional image). That is because definitions for these atomic concepts are practically hardwired and require no learning.

Therefore, finding the best way to express information for humans and computers alike is akin to finding the optimal point between two extremes of reduced set of simple concepts and a larger set of complex concepts, that are easy enough to parse by both.

In the case of humans, the physical medium will always most likely be eyes for read mode due to built-in parallel processing and high bandwidth, and a subset of our muscles (currently fingers) for write mode. I'm not sure how fast can we successfully parse audio signals, and brain-to-computer interfaces are still too slow.

As for the partitioning of information - who knows? Physically we have colors, brightness, shapes, sounds, temperature, touch, and more at our disposal. But the best way depends on our brain, and what size of information units it is best equipped to process.

And that is definitely not 8 bytes.

</comment></comment></comment><comment><USER44> I am actually somewhat worried about the longevity of our current tools. When we die, what will happen to our digital photos, and writings? Will our children find our diary in our home directory like they do when it sits on the bedside table? Will they look at our wedding pictures like they do when they find old photo albums? Will they remember our PhD thesis when it was never printed, but only ever a pdf?

Quite possibly, we might end up a forgotten generation, since procedures for cataloging digital memorabilia will only be invented after the lessons learned from the deaths of the first digital natives. One can only hope that archive.org will at least have an ugly copy of our blog.

<comment><USER45> The Library of Congress is archiving all of twitter as well, at least.

</comment></comment><comment><USER46> Text existed before the proliferation of other media probably because it was primitive and inferior. Chimpanzees lived for eternity before human beings appeared. I don't see anything great in that. We didn't use a lot of multimedia in the beginning, primarily because of tech limits. Now that the conditions are ripe, why not? If everybody is using more and more of it, it's for a reason. Apple and MS brought about a revolution, exactly because they unlocked the killer feature that was the GUI. Ask if many of us would like to go back to the 80s regarding computer UI, that would be a nightmare. I certainly feel a 2-min video overview of product features is tons better than an one-hour read. Images and in general sensory feelings are always much more natural to human beings, which in essence are still a kind of animal. Texts were invented to maintain civilizations and enforce social hierarchies, but it was never ever _natural_ nor great in this matter.

The Twitter icon takes a lot of space in a digital form, yet it only takes one minute to draw by hand, while the author probably wrote for an hour.

In all it's just a pointless, childish and tunnel-sighted rant. "Bet" on text? Bet what? I'm quite amused by the number of upvotes here. Though gladly I see many sane counterarguments high up there also, which is quite reassuring :)

</comment><comment><USER47> Not sure what the fuss is about. Sometimes text is optimal, other times images, video or something else is more suitable. I don't really understand the point of this article.

</comment><comment><USER48> Please describe an average Git commit graph as text in a way that you can actually draw some insight from it. And no, ASCII art doesn't count.

<comment><USER23> Project FOO, Chapter 5, Verse 18-27 (King Linus Version)

And 171b25e, after one hundred sixty and two log entries begat fe961ca. And 171b25e continued as a tagged branch after it begat fe961ca while the author made eight hundred more log entries, and begat further experimental feature branches. And when the number of log entries wase nine hundred sixty and two, 171b25e's branch was closed.

After fe961ca was sixty and five years log entries, and was known as e56b8bd, who begat 882b79d. And e56b8bd was rebased to the project root after it begat 882b79d.

And 882b79d preceded a hundred eighty and seven log entries and was then known as b6ff3ed, and begat 99e395a. And b6ff3ed continued after it begat 99e395a for seven hundred eighty and two log entries and begat many experimental feature branches.

And the current HEAD of the house of proj/foo.git is still 99e395a.

\--

Joke aside, _technically_ that problem has been solved before.

For a serious answer, "git log" should be very durable, and if you want a nice graph with it, something like this has benefits of both text and graphs:

        git log --graph --pretty=format:'%h -%d %s (%cr) <%an>' --abbrev-commit --date=relative

</comment></comment><comment><USER49> People can read text and understand it. Computers need parsers. Parsers are hard to write, and the time needed to parse one text will be just proportionate to the length of the text. Parsing can't be parallelized.

I'm sure the browser industry could benefit from a open, compiled html format, it would be so fast. I still wonder why there is no such format.

It's not about filesize though, gzip does a really great job at compressing text, but it's just about making a page load faster. It's no surprise to see web browser use so much memory: html is very flexible (there's nothing better), but it's fat.

That is a problem somewhat similar to the RISC vs x86. Risc has a simpler set of instructions, is a faster processor, but executables are much much bigger, requiring more cache. x86 has a more complex set of instructions, so it's slower, but the executables are much smaller. It's a balance to find.

I wonder if you could extend battery life by using compiled html. I would love to test that kind of tech on "normal" cellphones and see if how it performs.

<comment><USER50> > I'm sure the browser industry could benefit from a open, compiled html > format, it would be so fast. I still wonder why there is no such format.

Has anybody even tried making one and it just hasn't been adopted or is this a new idea?

<comment><USER49> Microsoft already has the .chm format, so there might be a patent, but I'm no expert. I don't really know how their format works though. It might be compiled as in "obfuscated".

But I don't think there's any existing, open format like that. Plain text html has the advantage of being easily diagnosed and immediatly readable, but you could easily make a binary format decompilable. I guess most programmers prefer having plain text because it's right before their eyes, it also sort of is "open", but that's not what open source really means.

It's not a new idea, but when I think about it, compiled html is a good solution to speed up web browsers. Now the .CHM format is not what you would want, as it's more targeted towards documentation, and is not extensible with CSS like html is now. It's an abandoned format I guess. Lighter than PDF I think.

By the way, when I say compiled HTML, I mean a binary version of a webpage that is already parsed. Would be a tree structured file. The goal is to remove the parsing phase.

But indeed, that could be a good opportunity for big tech firms to push that format. As long as it's open it might be a big success.

</comment></comment></comment><comment><USER51> There are 20 year old binary formats that we cannot recover because we have lost their decoders. There are 4000 year old texts we have been able to decipher because text is so many orders of magnitude easier to decode. There are anthropologists who argue that it wasn't tools or speech that led humanity out of caves, but writing (and the abstract thought that is facilitates.)

<comment><USER52> How would I find those anthropologists' arguments? Sounds interesting. (I majored in anthropology, a long time ago.)

</comment></comment><comment><USER53> If done properly, multimedia can convey information that text cannot possibly do. Text just lack the dimensions that multimedia have. An example includes the RSA Animate series, which take really good books written by really good authors and condensed that into very informative 5-minute videos.

</comment><comment><USER54> I liked the article, but in retrospect I'm not clear what it's arguing against. What are the technologies that people have promoted to the author but are trumped by text? I feel like there's an interesting story there.

<comment><USER17> Specifically, non-textual representations of code.

</comment></comment><comment><USER55> I know there are reasons for it, but I'm still sad to read that HTTP/2 will use a binary format instead of text :( [http://http2.github.io/faq/](http://http2.github.io/faq/)

<comment><USER56> maybe because binary is the lowest level format of text

</comment></comment><comment><USER57> I don't get the point of this to be honest ... things that can be stored as text generally are, those that aren't, e.g. videos, photos, sound files, can't be represented by text - they're media.

<comment><USER58> You're new around here, aren't you?

Ironically enough, I'm trying to make a webpage more readable (just for my own damned use), and was stymied on this page:

[http://www.inscc.utah.edu/~tgarrett/Garrett.html](http://www.inscc.utah.edu/~tgarrett/Garrett.html)

By the fact that the "Education ... Positions ... Activities" elements _are a fucking image_.

[http://www.inscc.utah.edu/~tgarrett/Garrett_files/shapeimage...](http://www.inscc.utah.edu/~tgarrett/Garrett_files/shapeimage_2.png)

Note that the color selection means that this is almost completely unreadable on either a dark or a light background.

Actually, a deep red does fairly OK: rgb(192, 0, 0)

</comment></comment><comment><USER59> Although it's certainly true text is powerful, text is also a reduction of reality.

There is a whole universe of things phenomena text it's sub-optimal for. Experiences being one of them.

</comment><comment><USER60> _text is the most powerful, useful, effective communication technology_

True, and very interesting to consider.

OTOH, if you can simulate a person who knows how to express themselves speaking to you personally, there's and even technology you tap into. That's a technology _we_ have actually adapted to biologically.

Everything else is just hijacking faculties designed to allow your uncle to explain to you how to make rope from bark.

</comment><comment><USER61> This is a great argument for text over icons in design. I wonder if in 250 years people will still know what the 3 bars (hamburger?) icon did.

<comment><USER58> I've got no idea what it does _now_. Other than that sometimes useful things are under it, sometimes not.

<comment><USER28> Me too, kinda. I mean I eventually (through trial and error) noticed it brought up a menu, but god that's not in any way obvious at first. It is funny because until I read something about it I didn't even know what it was supposed to represent.

Apparently its an old icon but I never really saw it (that I can recall) until mobile got popular.

I had a teacher in high school who thought the "graph" icon in Microsoft Word was "library books." She called it the "library books button." I guess 3 lines isn't enough information to convey meaning. Even though the button meant "put this information in graph form" she didn't see that the icon represented a bar graph.

</comment></comment></comment><comment><USER62> I would like to point out that cave art far predates any substantial 'text' we might have. Even if just as a shape to form a glyph, images are by far the most powerful method of human communication—no language is at all necessary. Language can add power, but at such a cost (learning a language takes years).

</comment><comment><USER63> Text is great, but graphs and diagrams are often better for representing certain kinds of information or relationships. When I read a scientific paper, the figures are often what I look at first after the title, sometimes even before the abstract.

</comment><comment><USER64> I'm disappointed the author has illustrated their article.

</comment><comment><USER56> "Text is the oldest and most stable communication technology [...]"

I don't really know but text is probably not the oldest...

</comment><comment><USER65> This is why scripting/interpreted languages are vastly faster to produce than compiled programming languages.

</comment><comment><USER66> That's why Unix uses text, and not some binary form, for most data exchange.

</comment><comment><USER67> The vast information in DNA is also represented in "text", sort of.

</comment><comment><USER68> There are plenty of advantages to text formats, to be sure. Others have mentioned many already, so I won't repeat them. But let's also consider both the disadvantages and how many of the advantages are "accidental" rather than inherent benefits of using a textual format.

One disadvantage of text is its lack of expressive power. Try reading the equation shown in the article aloud. Now try giving a one hour lecture on advanced quantum mechanics without the aid of mathematical notation. We can often represent information far more concisely and accurately with a good notation than with text alone, particularly when there is some inherent underlying structure that goes beyond what we can conveniently represent with some linear sequence of a tiny set of symbols. Computers are good at that kind of thing, but we don't read Shakespeare in binary, and we certainly don't draw the Twitter icon from the article using nothing but 1s and 0s.

Another disadvantage of text is how much it relies on everyone to use the same conventions, even though in the real world they don't. Go just about anywhere in the world and you can recognise what the little pictures of a man and a women on the two doors in the restaurant mean. Replace them with 'M' and 'F' and you'll see people who don't speak English waiting outside to see who comes out of which door. We use different languages. We use different alphabets. In technology, we use different encodings for glyphs and invent all kinds of other concepts in an attempt to standardise how we represent written text, and we _still_ create numerous bugs and portability issues and lost-in-translation problems. We've been using computers for half a century and change, and we still haven't standardised what the end of a line looks like. Or was it the end of a paragraph?

Now, certainly the simplicity of a text format has big advantages today in terms of things like searching for data and programmatic manipulation. But how much of that is just convention and historical accident? Right now, I'm typing this using an input device heavily optimised for text, because that's what my computer comes with. If I want to input some graphical notation, say an equation, my choices are probably limited to using some awkward purely textual representation (TeX notation, etc.) or some even more awkward half-text, half- mouse graphical user interface. Neither is an appealing choice, which is why it takes those of us working in mathematical disciplines forever to type up a simple note or paper today.

Technology does exist that can interpret a much wider range of symbols drawn with a stylus or other pointing device as an alternative means of input, but usually as a niche tool or a demonstration of a concept. Until we routinely build user interfaces that parse freeform input and readily turn it into whatever graphical notation was intended, a lot of us are still going to reach for a pencil and paper whenever we want to draw some quick diagram to explain an idea. But I bet a lot of us still do draw that diagram instead of speaking for another five minutes to try to explain it.

Personally, I'm looking forward to the day when source control _doesn't_ show me a bunch of crude text-based edits to my code, but instead a concise, accurate representation of what I actually changed from a semantic point of view. But to do that sort of thing, we have to have more semantic information available in the first place, instead of relying on simplistic and sometimes error-prone textual approximations.

<comment><USER69> _Technology does exist that can interpret a much wider range of symbols drawn with a stylus or other pointing device as an alternative means of input, but usually as a niche tool._

Handwriting math equations is built into Windows 7 and 8. Over half a billion computers potentially have access to it.

[http://windows.microsoft.com/en-us/windows7/use-math- input-p...](http://windows.microsoft.com/en-us/windows7/use-math-input-panel- to-write-and-correct-math-equations)

<comment><USER68> That's a great example of what I mean. The intent is laudable. For now, the tool is far too limited/flawed for professional work, but one day maybe our input/output devices will be kinder to this kind of interaction and our software will routinely support alternative forms of input to work with data that isn't purely textual.

I think a more polished example that is available today is the use of stylus and graphics tablet with drawing software. That is a relatively mature field where the use of alternative input methods to keyboard+mouse is well established, and skilled users already do some amazing things.

</comment></comment></comment><comment><USER70> Some stuff is good for stuff. Other stuff is good for other stuff. :)

</comment><comment><USER71> Text is just small pictures, so always bet on small pictures.

</comment><comment><USER72> This is why Snapchat is a chat, in addition to being a snap.

</comment><comment><USER73> And then there's XML...

</comment><comment><USER74> I guess I'll have to drop Blender and use text files to create 3D models, because some guy on the internet thinks that text is "the most powerful, useful, effective communication technology ever, period".

If the point of the article was to trick people into clicking, then it succeeded in that I guess.

<comment><USER75> Maybe you should try [http://www.openscad.org/](http://www.openscad.org/)

</comment></comment><comment><USER76> The arguments presented are highly biased. Text is great but images conveying the same meaning are always better. Why ? We can grasp the same information when conveyed via image. Say you are conveying an idea to someone or speaking to a conference - you always try to minimize text and use graphics to illustrate concepts as people tend to understand faster that way.

<comment><USER54> > _Text is great but images conveying the same meaning are always better._

This is clearly false, and makes me think you didn't read the article, since the article provides a counterexample right near the beginning; try to express this in an image: "Human rights are moral principles or norms that describe certain standards of human behaviour, and are regularly protected as legal rights in national and international law."

Of course nobody's proposing we abandon images; they're indispensable for many things, like the conference slides you mention. But if I had to do a presentation and was _forced_ to choose between only text and only non-text images, I think the best choice would be clear.

<comment><USER30> Slightly off topic but that's a terrible definition of human rights (and being in nice crisp text makes this immediately apparent).

A far better one is, "Human rights are political conditions necessary of the life of a morally autonomous being." Tyranny and democracy are both "political conditions", as is "the rule of law" and various other things. One useful thing about this definition is that under it rights are both natural and inalienable: a right may be violated (a condition may not be met) but the necessity of certain political conditions for moral beings to be able to make their own moral choices (moral autonomy) cannot be removed.

So not only does text enable us to present ideas more succinctly and precisely than images, it allows us to _argue about them_ effectively, and to have those arguments remain somewhat accessible for thousands of years. Images can be used as components of an argument (I've never published a scientific paper without graphs) but without the accompanying text the argument is woefully incomplete, whereas text alone is capable of sustaining a vast range of arguments without any accompanying images.

</comment></comment></comment><comment><USER22> Fuck Hacker News. The comment system here sucks camel's ass.

After 5 comments I couldn't post for -1.5- 3 hours. That's fucking retarded. And your fucking emotional downvote shit. Worst fucking site for discussion ever.

I thought I could come back but after being involved in more free communities this site feels like a fucking prison where you get beaten and put in a quarantine cell for saying nigger or jew or fucking anything that might offend someone's fucking ass.

Fuck you Fapper Jews.

<comment><USER22> Can't handle the truth it seems. Thanks for the downvotes.</comment></comment>