Enough with the JavaScript already - <AUTHOR> http://fr.slideshare.net/nzakas/enough-withthejavascriptalready <comment><USER2> Before "js everything", it wasn't just a plain simple pure web. It was flash and gifs and "dynamic html" that would break in half of the browsers, and you'd show a special version of your site saying "we're not paid enough to support your browser, go get another one".

Clients never were reasonnable in their demands, nor did most of the site owner have good and simple tastes and care about efficiency, nor did half of the internet care about user experience first above everything else.

Saying that the use of js has because heavy handed is cool and fun, but for any serious discussion there should be more acknowledgment of why we are in this situation in the first place. I'm not sure it's so much worse than 5 years before, at least we can read most things on mobile devices.

As a side point, I've done project on ultra weak platforms were every js had to be hand written to gain speed and memory space. I wouldn't try to do the same on some cookie cutter corporate site with a 600k slideshow loading on the front page, where having easily replacable components and tried and true pieces to test on the 20 combinations of browsers is far more critical that cutting 20k of compressed script.

<comment><USER3> I think this is very true. When Java launched I re-did the Sun home page as an applet. Bill Joy suggested that in the future HTML would be gone and each web page would be its own Java applet. He was mistaken of course :-) But as I've watched the emergence of 99% js pages I am reminded of his insight. His reasoning was pretty straight forward, the reason PDF (and that thing Imagen/Xerox did (DDF?)) existed was that to convey the document creator's intent to the consumer over a fungible media like computers, required that the document be a program describing what it looked like, leaving it up to the end node to interpret that program and then do its best to recreate it for the end user. That was something ASCII could never do. So with web pages, especially interactive ones, they were destined to be "programs" rather an some form of semantic markup structure.

I have come to appreciate that this is a pretty profound concept (well for me anyway :-), having the end result sent as generalized instructions for reconstruction, rather than as a external representation of the constructed object.

<comment><USER4> It's funny, the whole java applet thing was actually a better solution than JS in a lot of ways (shipping compiled/compressed bytecode with a security manager), just way, way ahead of it's time, and with a terrible windowing/drawing toolkit that meant it would never be adopted.

<comment><USER2> I think that in the mobile side it actually went the way you describe. In japan docomo offered an open java platform (free to use, free to install, no gatekeeper for standard apps). Mobile html was only useable for dead simple things, there was no js of course, and any service with mildly complex things to do or show would be better to implement in it's own app. It sounds terrible, but the user experience wasn't that bad. The terrible toolkit part was solved by Docomo shipping it's own UI toolkit (no J2ME compatibility, but it was so much more useable), and I think at some point there was a way to launch an app from the browser without installing it but I'm not sure my memory serves me well.

The choice of java was made for security of course, and I never heard of any serious breach in 10 years following the mobile tech news.

We get the same phenomenon I guess with the "go the mobile app" redirects on websites that don't want to have x optimized versions of the same service.

</comment></comment></comment></comment><comment><USER5> It's not really an either or thing. You can go too far with client side rendering. But progressive enhancement can only bring you so far in delivering an interactive experience - it's typical that his example is a simple tabs implementation - of course that's easy to do without much js.

That's why I like knockoutjs - it makes it easier to sprinkle in the data- bound rich interactive UI to the pieces of your page that need it and leave the rest as normal server side rendered content. It doesn't force you to go whole hog client side.

One key area of performance where js rendered UI helps a lot is in customizing an otherwise uniformly served (and cached) page. 95% of the page is uniform to everybody, so render that server side and cache the heck out of it (varnish or whatever). Then, bind the pieces of the UI after page load and customize them based on the user - their login status, their location, etc.

<comment><USER6> have you actually done this? I was wondering if this is a feasible and good way to use knockout!

<comment><USER5> yeah, a good description in passing in terms of using a framework as an "island of riches" here:

[http://blog.stevensanderson.com/2012/08/01/rich- javascript-a...](http://blog.stevensanderson.com/2012/08/01/rich-javascript- applications-the-seven-frameworks-throne-of-js-2012/)

we use this technique at food52.com, e.g this content page cached uniformly, login system, recipe saving widget, comment system all done in ko.

[http://food52.com/recipes/22888-yotam-ottolenghi-sami- tamimi...](http://food52.com/recipes/22888-yotam-ottolenghi-sami-tamimi-s- basic-hummus)

more interactive / sophisticated uses of ko coming in our new shop soon for the cart functionality.

</comment></comment></comment><comment><USER7> 2013 - I stopped paying attention to every new framework or MV-whatever that comes out. What matters is the product and end user experience, and every single decision on how to go about making that product should be made with that thought in mind.

For me, it's not even javascript anymore. Objective-C and Java rule 2013 since web apps are not as pleasant to use on mobile.

<comment><USER8> "Objective-C and Java rule 2013 since web apps are not as pleasant to use on mobile."

Or with some MVVM, Xamarin and some C# or F#... write once, compile for all mobile platforms. Never having to once touch the nastiness of Obj-C or Java.

<comment><USER9> What's nasty about Obj-C?

<comment><USER10> The syntax and the APIs.

<comment><USER11> I understand that the Smalltalk like syntax of Objective C can be difficult to understand at first glance; however, once you've worked with it a bit, the syntax becomes quite expressive -- each argument is labeled; something like using named arguments in Ruby, but it's not optional.

Not sure what you mean about the APIs being nasty. Can you elucidate?

<comment><USER10> [https://developer.apple.com/library/mac/#documentation/Cocoa...](https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/Reference/NSString.html#//apple_ref/occ/instm/NSString/localizedCaseInsensitiveCompare):

<comment><USER12> Could you go further? What, in your opinion is wrong with NSString? How would you fix it?

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I wonder if there'll ever be an alternative to Javascript. I'm not talking about those things that eventually get translated to Javascript, I'm talking about a native platform well thought-through and based on a typed language that isn't a mess. Yeah, I know: it's not Javascript that's broken, it's the DOM. I'd argue that both should be replaced by something else, otherwise the future will be 90% native mobile apps, which isn't a bad prospect if you can afford to develop and iterate for two different leading platforms.

<comment><USER14> Absolutely. Write in whatever language you like, compile to asm.js - that way you're running in the browser, at about half native speed.

<comment><USER15> Asm.js is not an alternative to JavaScript, though. It is JavaScript, just a really mangled and ugly subset of it.

cliveowen was clearly talking about "an alternative to Javascript" and "not [...] those things that eventually get translated to Javascript". Anything targeting Asm.js is merely targeting JavaScript.

The "half native speed" claim is quite dubious, at best. Even if it were realistic, that's still quite a horrible decrease in performance relative to native code. It's not as bad as the typically much worse disparity, but it's still not good at all.

<comment><USER16> Talk about JavaScript being replaced wholesale should be regarded as therapy. Therapy to dull the realisation that JavaScript is now immortal because it gained such massive reach and entrenchment. It's the web counterpart to C the immortal.

</comment></comment></comment></comment><comment><USER17> JavaScript is a tool. Once it becomes trendy idiots will always abuse a tool. It's not JavaScript's fault people are bad at web design and development. If it wasn't fucked up JavaScript these people were contacting you about it'd be something else, be glad you have a job.

<comment><USER18> It does not however, preclude the possibility that the tool is in fact a bad tool, and that the tool is bizarrely the only tool we have.

They say poorly skilled people blame their tools, and that highly skilled people who know their tools well, will know how to use it well. That being said, see that circular saw over there that will occasionally bounce and cut off its user's fingers? I'm not gonna use it, no matter how skilled I am.

I for one am hoping for a replacement for JS (that isn't Dart, which feels like JS Patched). I have more than just a hairy experience with JS lately.

<comment><USER19> Fortunately, JS is _not_ the only tool we have. JS is a relatively fine _compile target_ , and with asm.js, a pretty fast one.

So pick your favorite among CoffeeScript, TypeScript, Dart, GorillaScript, Elm, ClojureScript, etc, or try compiling your favorite language using LLVM.

Let a compiler take care of all the numerous rough edges raw JS has.

<comment><USER20> > _JS is a relatively fine compile target ..._

No, it's not.

> _... and with asm.js, a pretty fast one._

And asm.js demonstrates why it's not, because asm.js isn't JavaScript. It's a strictly defined ASCII-encoded bytecode that happens to be representable using a subset of valid JavaScript.

At which point, one must ask, what bizzaro-world engineering justification do we have for using a JavaScript subset as a first-order bytecode format? Why couldn't the silly JS bytecode format be a second-tier target for legacy browsers that don't support a proper format?

On top of which, why are we willing to throw away 2x+ performance (in the _best_ case)? Is the iOS/Mac App Store not successful enough for us, such that we absolutely refuse to try something other than adding more JavaScript to every problem we face with web app deployment?

<comment><USER21> asm.js is JavaScript. It executes according to the semantics specified in ECMA-262.

The 2x performance numbers for OdinMonkey are not "best case": they _include compilation time_ and will certainly improve (they are better now already).

Regarding having a "real IR", throwing away backwards compatibility for surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for example. It failed.

<comment><USER20> > _asm.js is JavaScript. It executes according to the semantics specified in > ECMA-262._

No, it's a strictly defined text-encoded bytecode that happens to be representable using a subset of valid JavaScript. If you deviate from the standard using valid JavaScript, you lose the gains.

Calling it "JavaScript" is just a semantic game. You can't output arbitrary but fully 100% standards-compliant JavaScript from a compiler and expect asm.js to do anything meaningful.

> _Regarding having a "real IR", throwing away backwards compatibility for > surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for > example. It failed._

The irony is that these things fail _because_ of the people who wish to maintain the status quo, and then those same people point to the failure as justification for maintaining the status quo.

It's not like you folks at Mozilla couldn't get support for a "real IR" from Google/Chrome -- that's half the market right there. In fact, the actual problem is that Google could never get support from _you_.

<comment><USER21> > If you deviate from the standard using valid JavaScript, you lose the gains.

That's true for lots of JavaScript optimizations. JS optimization is all about speculation that the more dynamic features won't be used. Try adding calls to "eval" within a JavaScript function in any modern JS engine and watch its performance drop by an order of magnitude. Does that make functions that don't use "eval" no longer JavaScript? After all, adding a call to the standardized function "eval" negates the performance benefits of "eval"-less JS.

asm.js is just this principle writ large.

> Calling it "JavaScript" is just a semantic game.

No, it means that asm.js is backwards compatible. That is not a game; that is the entire point. That is why asm.js worked in Chrome (with good performance even!) from day one.

> It's not like you folks at Mozilla couldn't get support for a "real IR" from > Google/Chrome -- that's half the market right there. In fact, the actual > problem is that Google could never get support from you.

Because PNaCl is not a good idea for Web content. People have this idea that Mozilla knows PNaCl is "better" than asm.js, but Mozilla wants to stick to JS out of some sort of pride or NIH syndrome. This is not the case. Backwards compatibility is the main advantage of asm.js, of course. But there are also many others: LLVM IR is a compiler IR and was not designed for this; asm.js is smaller when gzipped than LLVM bitcode; asm.js compiles faster than PNaCl; asm.js can reuse the JavaScript infrastructure, leading to a smaller, simpler browser; asm.js does not have the Pepper API which reimplements all of the Web APIs in underspecified ways.

<comment><USER22> Maybe it's time to go back to the HotJava[1] approach and use Java bytecode as the canonical "bytecode for the Web".

OK, to be fair, the browser itself doesn't really need to be written in Java. But other than Javascript, (and maybe Flash, I suppose) Java bytecode probably has the most penetration as a mechanism for delivering "programs" over the web. Maybe we should just embrace it...

[1]: [http://en.wikipedia.org/wiki/HotJava](http://en.wikipedia.org/wiki/HotJava)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> Another presentation making similar conclusions, but with different arguments, that I recently saw on reddit (not sure if it made it to HN).

[http://www.infoq.com/presentations/web-development- technique...](http://www.infoq.com/presentations/web-development-techniques)

[http://www.reddit.com/r/programming/comments/1eiykw/web_deve...](http://www.reddit.com/r/programming/comments/1eiykw/web_development_youre_doing_it_wrong/)

(back to me...)

I wonder if the pendulum is finally swinging back, to working with the affordances of the web, instead of fighting them. I hope so.

This might have an interesting relationship to the rise of mobile. It's still not possible to rival native apps with HTML apps on mobile (a controversial assertion, but one that is 'trending' too) -- so if you ARE building a web app, you've got to actually have reasons to prefer web apps. Even if that's just cost/speed of development. But if you've actually chosen to build a web app, maybe you're more likely to want to work within the web instead of fighting it. If you don't like the architecture of the web, you could have just written a native app instead.

</comment><comment><USER24> One can do a great many things with disciplined Javascript, and I shudder to think what Twitter was trying to do on their front-end that caused a 5x increase in load time compared to server-side template-rendering.

That being said, I would very much welcome a high-performance alternative to Javascript that also runs in any browser -- something in the spirit of C or Java, which could be embedded in Javascript and vice versa.

<comment><USER25> I agree - but moreover, I'd like to see a single, cohesive replacement for the whole web stack. One standardized language to handle styling, scripting, server-side, and the document (in fact, let's just get rid of the notion of a document - we are building dynamic applications now, not documents). I understand that one reason we have separate languages is in light of security, but I think this could be made even better with special permissions (like unix file permissions but for code functionality/access).

<comment><USER26> Client- and server-side code is separated in literally every application to use a network, because they must necessarily be run on different computers. In most applications they can be the same language (C, C++, Java, etc.), but they have to be separate programs. I think what you're mostly complaining about is the JS lock-in on the browser side, which is a legitimate complaint, but a different one.

re:HTML - What's the difference between a dynamic document and a dynamic application, really? With JS and CSS3, HTML is unrecognizable - pair it with something like Backbone.Marionette, and the only thing HTML is doing is defining your display in a structured way, more like the XML definitions of an Android view than an old-school document.

</comment></comment></comment><comment><USER27> All the includes are insane as well. Run Noscript or any other JS blocker and visit a few big sites and you'll see that you end up running JS from half the Internet.

I'm joking of course, but some sites have dozens of includes from other sites, advertisers, CDNs, etc.

<comment><USER28> I installed Ghostery but did not set up any filters; with just that, it shows how much external resources / from which external parties things are loaded. Some sites have like twenty external dependencies, and multiple analytics gathering scripts (which may get embedded via the iframes of advertisers).

<comment><USER18> I work in advertising. I have seen Ghostery rack up close to 300 trackers before. Piggybacked pixels... they're everywhere

<comment><USER29> How does one even collect the data from 300 trackers?

<comment><USER30> Your 300 affiliate marketing partners run software from their affiliate network which automatically analyzes their tracking pixel server logs to determine how far the traffic they steered made it through your purchase process based on the pixels they requested (unique for each page) and the unique ID in their cookies. Then, their affiliate network collects the sales commissions and pays out the affiliate partners.

<comment><USER29> Ah, gotcha, that makes more sense. I was like, 300 individual sites with individual tracking on what page, what the, how the, etc. Thanks for the clarification!

</comment></comment></comment></comment></comment></comment><comment><USER31> A few points of contention... First, it doesn't seem like TFA is opposed to JS, as the linkbait title would seem, but the overhead of some sites/libraries.

I think that jQuery is probably a bit larger than it may need to be. Most of this is to work around edge cases or missing features in supported browsers. I think that the biggest issue may well be cost(s), and trust. It would be entirely possible to have a jQuery-like framework that would bring in only those shims as needed as part of loading from a central source. Unfortunately, that has costs in terms of both maintenance as well as deployment/cdn. It's probably not worth it.

Second, you are getting a lot of unused features with most frameworks (like jQuery), however this can be mitigated by using a common CDN, where caching helps a lot. Using the google, or ms cdn for jquery is a no brainer for a public facing application. I think that jQuery is too useful to just be replaced with one-off components.

As to jQueryUI, when you compare what it does with other toolkits, it's actually very impressive. Just look at the load size for the JS for Bootstrap for example... and bootstrap doesn't do all that jQueryUI does.

More and more frameworks have checkbox build options to give more fine grained builds specific to your needs with less overhead. Also, as pointed out in a few slides, you can load certain scripts and features as an on demand or post- load approach.

For example _ALL_ my scripts tend to be at the bottom before the closing body tag (unless it's a single page application). Even then, the analytic scripts are last... imho the page being served to the user is the most important thing... it should be mostly functional without JS. And in terms of scripts, in the larger sense analytics are pretty low pecking order... when you have 10k users an hour, missing 2-3 analytics loads is no big deal.

</comment><comment><USER32> Enough with the no-context-attached slides already.

Seriously, if you don't have a recording of the talk, or a transcript, at least provide an article or something.

<comment><USER33> I will never understand the utility of posting slides from a talk online without the audio.

<comment><USER34> I found the slides to be quite informative.

<comment><USER35> I agree, but I definitely see the grandparent's point. These slide decks are annoying as hell. They're inconvenient for quoting, reading on-the-go, and they can leave out a whole lot of context. This is a trend that really needs to go.

</comment></comment></comment></comment><comment><USER36> I don't know if I should laugh or cry: I had to temporarily disable NoScript for both slideshare.net and slidesharecdn.net to read these slides.

<comment><USER37> Is it ironic that this slideshow complains about Javascript but requires it to be viewed?

<comment><USER38> no, it's not

</comment></comment></comment><comment><USER39> JavaScript assumes a "web browser". What happens when we're not using a "web browser"?

A few days ago, I was actually downvoted for even suggesting that a user could disable JavaScript and that this might reduce her vulnerability to exploits. I'm always fascinated by the strength of the bias in favor of JavaScript.

I'm guessing that so many developers are now so heavily invested in JavaScript that if it were to become less popular they believe they would suffer somehow. They will thus defend this language with fervor. That's my guess.

Days ago we saw Dan Bricklin, who is no stranger to a world without a web browser and is responsible for the app that literally launched the PC into the mainstream, put in his plug for JavaScript. But we also learned he's written entire spreadhseet applications in JavaScript. It appears he's heavily invested in this language. It stands to reason he would defend its use.

On this thread someone mentioned that Bill Joy thought Java applets would power the web. Not surprising considering his company was responsible for Java, and he has called James Gosling, the father of Java, his favorite programmer.

I think when we look at JavaScript we need to ask ourselves who stands to gain the most from it. My belief is that it benefits developers more than users. It's aesthetically pleasing to most developers, but more importantly, programming in JavaScript requires less work than using a language with manual memory management that does not expect to be run inside another application (a "web browser"). JavaScript boosts productivity.

Users, I believe, do not see the same benefits. (e.g. I have seen Marissa Mayer while at Google state how important speed is to users. We might accept that speed is one benefit that users would recognize.)

Because the love for .js is so strong and criticism of it is not well received, I won't go into any more detail. But suffice it to say, if there are problems with using JavaScript, I believe it is not developers who would suffer the most from them. I believe it is users who would bear the burden.

<comment><USER40> Well , now that developpers can do crazy stuffs with javascript they will never use it responsibly and will show every trick they know to the user, because they want or because their clients want it.

I remember the time when 100ko pages were considered too heavy. now devs dont even bother optimizing images and use 500 ko png logos...

It's not unusually today to see 2MO homepages ...

</comment></comment><comment> chestnut-tree There is a place for Javascript, but it feels like it's being excessively overused.

Anyone who browses with Javascript disabled (using, for example, the noscript browser add-on) will be aware how many sites, even those with mostly text content, fail to load without Javascipt.

Google's blogger/blogspot service is one of the worst offenders. Here's an example: the official Android blog from Google. The page simply won't load with Javascript disabled. Once it is enabled, you have a page of mostly text. This is simply bad web practice in my opinion.

[http://officialandroid.blogspot.co.uk/](http://officialandroid.blogspot.co.uk/)

</comment><comment><USER41> Slide 19 seems broken for me.

I remember from last time someone posted this that slide 19 was like slide 18 but with all of the features over in the JS box. In this version, both slides are identical.

</comment><comment><USER42> Many sites already use Google's hosted javascript libraries for JQuery, Prototype, etc...

Could Google reduce load time in Chrome by building these into the browser, so that anytime they see the include pointing to Google CDN, they just skip it and let the pre-included library take its place?

<comment><USER43> The number and versions of these libraries is just immense.

A lot of what the early versions of these libraries used to do is now handled by upgraded versions of javascript.

Adding JQuery etc. to the browser is a short term fix, that would become a problem further down the track.

<comment><USER42> I agree about the short term fix thing.

What I meant was, "_Would_ it actually save any time to do this." not "They should do it."

I am curious if there would be any speed gains, not just in data transfer but in javascript initialization and execution.

Also, it would be an interesting "aspirational algorithm" if they only did this for the best/latest versions of these libraries, encouraging developers to stay up-to-date.

</comment></comment></comment><comment><USER44> In every situation that you allow your engineers to develop for the technology instead of for their customers, this is going to occur.

Does the customer care that the latest MVVM JS tool is being used? Not unless your customers are only other developers. The customer cares about getting whatever widget you are selling them quickly and with as little thought as possible on their side to consume it.

</comment><comment><USER45> Why store state in DOM? Isn't that bad practice?

I remember reading DOM access is the slowest part of JS [needs verification]. So you want to trade performance for few dozen kilobytes of assets that can be cached?

<comment><USER46> I'm not exactly sure what you're talking about, however mobile phones have awful bandwidth and awful browsers with not enough memory to cache everything they can.

In the context of websites, you also want the experience of new users to be the best it can be.

Basically, caching is nice, but it only works efficiently for applications that users visit often and that don't rely on links going viral, such as GMail. However, if you rely on caching for providing an acceptable user experience in cases where you rely on links going viral (such as Twitter), then you're screwed. Twitter has a mobile optimized web page that's much, much lighter than their desktop version and they did it for a good reason ;-)

<comment><USER45> Let me rephrase then; storing state in DOM may be ok for small pages with some insignificant JS on top to provide progressive enhancement, but from web app point of view its totally unfeasible and saving a few KB is IMHO not worth it.

</comment></comment></comment><comment><USER47> To bad you have to pay $399 to watch the videos.

[http://velocityconf.com/velocity2013/public/sv/q/479](http://velocityconf.com/velocity2013/public/sv/q/479)

I realize it costs money to run a conference but that seems excessive.

<comment><USER48> Here's the version from SF Web Perf - [http://www.ustream.tv/channel/sf-web- performance-group-meetu...](http://www.ustream.tv/channel/sf-web-performance- group-meetup)

<comment><USER47> Awesome, thanks.

</comment></comment></comment><comment><USER49> This deck is really hard to flip through on an iPhone. Nothing a little JavaScript couldn't fix.

<comment><USER50> I've often thought touchscreen devices would be complemented well by a set of arrow keys. (On a desktop, you can flip through the slides with the left and right arrow keys.)

</comment></comment><comment><USER51> Airbnb's Rendr seemed to be a nice solution to this problem

[https://github.com/airbnb/rendr](https://github.com/airbnb/rendr)

</comment><comment><USER52> Javascript itself has warts and they are easily overcome. I've found that the biggest hurdle for me, someone who's written native desktop applications, are the libraries are a huge hurdle. I still don't understand the obsession with MV* "design patterns," in GUI code.

It's made worse by the fact that the model we have to base our GUIs off of is a based on hierarchal documents.

<comment><USER53> Those bloated GUI libraries are part of the problem, in my opinion.

HTML is a great document definition language in the right hands but like JavaScript, its poor use can create a nightmare. You can fix this by learning to write clear and simple semantic HTML but if you have to work on legacy code that doesn't really help.

</comment></comment><comment><USER54> Though I would like to see the talk in its fullness, and I am a full-on Javascript fanboy, I have to agree with the core thesis. In 99% of cases, there's no reason to do all rendering client-side, especially on content- centric sites. And devs do sometimes get too dependent on kitchen-sink libraries, rather than rolling their own native JS to address their own specific need.

</comment><comment><USER55> On many sites, the (cached) load of 500k of gzipped JS is dwarfed by the amount of HTML, CSS, and images loaded.

</comment><comment><USER56> I'm really perplexed by one of the central complaints in this slide deck. JS load time is just not a serious problem in my experience. The use of CDN's and the browser cache has made loading scripts almost irrelevant in terms of page performance. Its a problem for first time visitors who have a cold cache. And then it amounts to adding an additional 1-2 seconds of load time once and only once on their first visit. I really don't get bent out of shape by that. I'd be worried if that 1-2 second overhead was incurred with every single page load with every single user. that's just now what happens though.

</comment><comment><USER57> I see one problem:

\- Entire generation of programmers may not have any knowledge about how computer works

<comment><USER24> No?

If that were to happen, it would be a problem with the programmers more than anyone else.

<comment><USER57> with JavaScript, there is no need to know how computer works, so why would anyone learn(deeply) about that?

<comment><USER24> You act as though Javascript will take over the programming world -- I can confidently say that it won't

<comment><USER40> mind you it will ... ( and i'm not pro javascript ).

</comment></comment></comment></comment></comment><comment><USER58> What I don't get is the sites that load ALL their content using JavaScript. Sure, I see the point in loading more content if the user scrolls down to the bottom of the page, but why would you do that straight away?

</comment><comment><USER59> Funny thing is, I use JavaScript libs like Ext JS because they don't impose HTML/CSS on me.

I can write the whole application in JavaScript and I just have to mess with the DOM and it's ugly friends when in trouble.

<comment><USER40> doesnt matter , they use it under the hood. and the fact that you have little control over how ExtJs actually uses the DOM will not make your app faster...

<comment><USER59> That's a two-edged sword.

If I rely on an API, which abstracts everything, I benefit of every performance improvements they make "under the hood".

If they are better with performance than me, I win. If I'm better with performance than them, I lose.

</comment></comment></comment><comment><USER60> The reality is... JavaScript is here to stay. So stop your complaining, that's such as waste of time. Rather than complain, champion better solutions. Be bold and advance a new and more efficient agenda.

</comment><comment><USER61> Just because it's badly abused doesn't mean it's bad per se. Let's say you build your SOA: JSON API + Mobile App. At this point, if you plan to build a web app to browse your content, it's very hard to render pages server side without code duplication/collision with the API. If you go with the full js MVC approach you can reuse your api and just worry about the templating and event binding. Maybe this approach doesn't yet scale to the size of Twitter, but I hope the web moves towards fat clients optimization.

</comment><comment><USER62> A lot of JS usage on web browser is as a tool to manipulate DOM. A bigger part of the problem, I think, is the DOM API. Another big part of the problem is of course inconsistencies between browsers. Because of those 2 problems, our client-side code becomes complex. Changing JS with "$LANGUAGE_X" wouldn't help much. If the DOM API is much better and web browsers behave the same way, things would be much different.

</comment><comment><USER63> There is a very important reason client-side js apps are appearing: managing stateful apps over a stateless protocol means spending about half of your time and complexity budget dealing with state transfer. Js clients bring us back to the days of true application programming. They use REST and HATEOAS in a very natural way that most app servers have not. Maybe it's time to let the server side handle what it's good at?

</comment><comment><USER64> If I had time to get something up and running where the html could be rendered on both client and server using the same code base in the early stages of a project then I would.

It all depends on the project of course but currently here is the order in which I tend to do things:

1 Write an api

2 Write web/mobile apps to consume it

3 Optimize by pre-rendering the html when needed if the project becomes popular enough or if it really needs to be crawled.

</comment><comment><USER65> I think the summary is more helpful than looking at the slides. Does anyone have a link to the video talk about this?

</comment><comment><USER66> I love how the tech community promotes something until it's over used and only AFTER everything breaks then we THINK about how / when we can use a technology...

</comment><comment><USER67> I don't always read Hackernews, but when I do I read it with this - [http://nojs.herokuapp.com](http://nojs.herokuapp.com)

<comment><USER68> its flat design, or should I say no design. prettier than hn

</comment></comment><comment><USER69> Did anyone else think this was pedantic?

</comment><comment><USER70> Very nice, but unfornately, it seems we lost a lot of information from just watching slides...

</comment><comment><USER71> This slideshow lost all credibility when it said to put your analytics in the <head> tags. Sure some analytics providers might recommend you do that, but that is wrong and only serves to

A) Slow your site down B) Introduce a single point of failure into your webpage

All scripts should be loaded either async or at the end of the dom.

<comment><USER72> If you load the analytics script anywhere other than the head, you potentially miss user input while the page is loading. For a slow-loading page, this could make you lose out on useful data. I realize that this argument is somewhat circular.

<comment><USER71> You should avoid including script tags in the head because it introduces single points of failure in your app. Losing a few ms of 'analytics' time is better than providing your users with a broken site because your analytics scripts (or any other hosted JS files) didn't load and waited 5-15s to timeout (depends on browser).

Steve Souders gives a great talk on this: [http://www.stevesouders.com/blog/2010/06/01/frontend- spof/](http://www.stevesouders.com/blog/2010/06/01/frontend-spof/)

</comment></comment></comment><comment><USER73> Ironically, slides are hosted on a JS implementation of presentation software.

</comment><comment><USER74> Who's the superman?

</comment><comment><USER75> If you use it in the right way, there would be no problems.

</comment><comment><USER76> Amusing, this article was submitted 2 weeks ago and got no comments.

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

<comment><USER77> Bad timing?

</comment></comment><comment><USER78> Store state in the DOM? Really?

<comment><USER79> For the sort of small-scale interactions Zakas was talking about, that's a perfectly reasonable thing to do.

</comment></comment><comment><USER80> Bird gotta fly, fish gotta swim, hater gotta hate. I love JS!

</comment><comment><USER81> OK, who clicked through all 84 slides?

</comment><comment><USER82> To say it in the words of @fat: hi haters [https://pbs.twimg.com/media/A_G3NghCIAEAGbM.jpg:large](https://pbs.twimg.com/media/A_G3NghCIAEAGbM.jpg:large)</comment>


Fake Ads as a Business Model - <AUTHOR> http://oleb.net/blog/2016/03/fake-ads-as-a-business-model/ <comment><USER2> i fully support this :)</comment>


Swift arrays are too swift for our own good - <AUTHOR> http://blog.human-friendly.com/swift-arrays-too-swift-and-flexible-for-our-good

<comment><USER2> What all these discussions miss is that what is immutable is the variable, not what it points to.

It helps to think about Swift's _let_ as C++ _const_ and how it maps to library data types, not as ML's _let_.

Given that the target audience are Objective-C, C and C++ developers, I don't think it is too bad of an option.

<comment><USER3> Ocaml arrays are in fact mutable in the same way as Swift arrays. In fact, if I recall right, Ocaml ref's are implemented as single item arrays.

I imagine the point is to have a low level type describing an area of contiguous mutable memory, rather than expecting people to use arrays everywhere. Not that I know anything about Swift of course.

<comment><USER4> The problem I have with Swift is that Apple minimized the set of containers. There are only two: Dictionary and Array.

Array when mutable acts like a list: items are indexed by an integer, and you can replace, add, and remove items.

Array, when immutable acts like an area of contiguous memory: items are indexed by an integer, and you can replace items.

Dictionary, when mutable, acts like a map: items are indeed by key, and you can replace, add, and remove items.

Dictionary, when immutable, acts like a read-only map: items are indexed by key. You cannot add, remove or even replace items.

That is inconsistent. I think they would be better of adding List as a third container type, and changing Array to a fixed size (at creation time) container. Immutable Lists and immutable Arrays would behave exactly the same, but I don't see that as a problem.

On top of that, they chose to make Arrays and Lists value types, (prematurely?) optimized Arrays (but not Dictionaries) to copy-on-write their data, and decided to make that manual copy-on-write (to ensure that an Array is yours and only yours, you have to call _unshare_ on it)

My disclaimer is that I only read the ePub that Apple provided, and somewhat partly so.

</comment></comment></comment><comment><USER5> It's really not that big of a deal.

It was a tradeoff, for which they provide functions (unshare and copy) for opting out of the default behavior if you so choose.

You aren't hamstrung here. In fact, this Array behavior is going to be absolutely great for manipulating image and other fixed buffer operations. It's a week in, what looks like a wart today can be a great feature in the future.

</comment><comment><USER6> Why should fully immutable arrays be more performant/better than those with fixed length?

I guess,you'd be able to do faster & more memory efficient slicing with fully immutable arrays and not be required to think as much about where and how you're modifying an array, but other than that the current implementation seems just like a native C array to me that is only referenced via pointers.

If I'm not mistaken, however, full immutability would lead to higher memory consumption in case of array modifications. Given that Swift was started in 2010 when the iPhone 4 had a mere 512MB of RAM, and that it's targeted at mobile devices, this seems like a good reason to limit memory consumption here.

<comment><AUTHOR> My problem with it is how confusing the default behaviour is. As I say it is a perfectly reasonable datatype but in my view a misuse of let to create it.

Any time you pass an array as an argument you have to expect that it may be modified (so you must copy it if you still need the array as it is). Every time you return an array you have to expect that it can be altered so again you need to copy it if you still need it. Given this immutable arrays may let you use less memory because they would only need to copied when they were written to not as a precaution when they are passed as arguments.

</comment></comment><comment><USER7> How about a full implementation of tupples() for constant lists? Just disable var for tupples and they would act just like python's. (or something along those lines)

</comment><comment><USER8> I don't know Swift, but ... use a vector?</comment>


Team produces weird optical phenomena - and rewrites the rules of refraction - <AUTHOR> http://www.tgdaily.com/general-sciences-features/58245-team-produces-weird-optical-phenomena-and-rewrites-the-rules-of-refr

<comment><USER2> Interesting stuff, but to me it's a bit of a stretch to say that they've rewritten the rules of refraction, since the basic laws assume ideal interfaces between media. What they've actually done is created a material so exotic that that abstraction is no longer sufficiently accurate to describe it. I imagine QED (<http://en.wikipedia.org/wiki/Quantum_electrodynamics>) still holds.

<comment><USER3> "[I]t's a bit of a stretch to say that they've rewritten the rules of refraction."

Indeed. It appears more akin to the situation we have with classical and quantum mechanics: classical (Newtonian) mechanics fairly accurately describe the behavior of macroscopic objects at relatively slow velocities. We acknowledge that the system is not valid outside of that range. But since that range encompasses the bulk of our everyday, practical experience, classical mechanics are exceedingly useful.

Classical optics are not suddenly outdated with these discoveries. Snell's law and the lens-maker's formula are just as relevant as they were yesterday. We just need to add a few more terms to the equation if we etch a gradient of nano-scale resonators to the surface of our optical element. (Boy, do I feel like Geordi in _Star Trek_ reading that last sentence aloud.)

Negative index of refraction materials are not quite new: wikipedia indicates that they are already being used in commercially-available products (<http://en.wikipedia.org/wiki/Negative_index_metamaterials>). For me, the most exciting application is creating a lens that circumvents the diffraction limit that limits optical imaging resolution. Right now, the most sophisticated, expensive microscope objective lenses can just barely resolve sub-cellular structures only under very particular conditions (i.e., not alive). A diffraction- _un_ limited "superlens" made out of this stuff could enable us to see even smaller objects under physiological conditions. It would be fantastic if we could capture the release of individual neurotransmitter vesicles at a diseased synapse, for example.

Besides negative index materials, there are a whole class of non-linear optics (<http://en.wikipedia.org/wiki/Nonlinear_optics>) that allow engineers to do all sorts of funky things in their instruments, like doubling the light frequency or self-focusing.

</comment></comment><comment><USER4> This actually sounds both revolutionary and immediately practical for lens design. Covering lens with gold nano antennae sounds expensive, and I assume the surface is delicate, but thin spectacle lenses and super lightweight camera lenses are an obvious result.

<comment><USER5> absolutely. you could make much more compact "telephoto" lenses too. or connect "bifocals" to the nerve that controls eye focussing and have glasses that automatically focus to the correct distance (yes, i am getting old). or stationary solar collectors that adjust to the moving sun (or that still move but self-correct for distortions and support flexure). or a new kind of electronic ink. or...

this is huge, yet the report covers just silly mirrors... weird.

<comment><USER6> Many of those ideas require not only that we can make this stuff in bulk at low prices, but also that we can dynamically change the stuff after production at high speed. I did not read that in the article. Did I browse it too fast?

<comment><USER5> ah. maybe i misread the article. where it says antennas i assumed they were active. but if they're just passive (conductive) elements then you're right. i guess that is more likely :o(

[edit:] that would certainly explain why they only mentioned silly mirrors!

</comment></comment></comment></comment><comment><USER7> Isn't a fresnel lens really just an non-idealized boundary layer too? <http://en.wikipedia.org/wiki/Fresnel_lens>

<comment><USER8> Correct, but with the caveat that it only really works along the optical axis. Off-axis you get horrible artifacts. If I recall correctly these metamaterials do not have that limitation.

</comment></comment><comment><USER9> How is this new? Surface plasmon resonance effects with gold are, I'd thought, an exciting but well-understood phenomenon in nanotech.

Using gold nanoparticles to achieve unique photonic effects has been done since the Roman Empire and the Lycurgus Cup (this artifact used relativistic behaviors of gold to show two different colors, depending on the light source being either reflected or refracted)

</comment><comment><USER10> I'm not sure this rewrites any rules, it seems "just" nanooptics when surface structure with patterns below the wavelength of the light is reflecting, refracting or diffracting the light.</comment>


Show HN: Cloudlytics- Decode AWS Cloud Logs and Bring Visibility into the Unknown - <AUTHOR> https://www.cloudlytics.com/

<comment><USER2> Cloudlytics is an AWS Cloud Log Analytics tool. It is designed to offer operational intelligence for AWS Cloud Infrastructure Log files. These log files are generated when users consume Cloud Services on Amazon Web Services, which contain raw information pertaining to user access patterns. Cloudlytics process these raw log files and provides meaningful analytics on an easy to understand dashboard. It currently supports analytics for Amazon S3, CloudFront, Elastic Load Balancing (ELB), and AWS CloudTrail (for all API access logs) & billing Analytics on AWS.

</comment><comment><USER3> A wonderful tool to know and analyse your logs. and make meaning of it.

<comment><USER4> Thanks, Would look forward to any feedback.</comment></comment>


I Gave Up Practicing Medicine - <AUTHOR> http://philip.greenspun.com/careers/why-i-gave-up-practicing-medicine <comment><USER2> People are slowly learning what we already knew for ALL of human existence. My cousin is in the same boat. 10+ years of college/med school. Just had her first child and has decided to be a stay at home mom instead. She was on a full ride starting as an undergrad (she's a great student and doctor and now will be a great mom).</comment>


Jennicam and the Birth of 'Lifecasting' - <AUTHOR> http://digg.com/2015/reply-all-jennicam <comment><USER2> I'm not directly exposing my life, but I have been running a site that streams photos taken within 250 meters of my cell phone's current location every three minutes. Check it out: www.instagrampostsnear.me

Side note: If anyone that has art world connections could hook me with the possibility of exhibiting some of the best photos, it would be very much appreciated.

<comment><USER3> hey that's cool. how did you get the gps location of your phone programmatically? is this a commercial project or are you going to open source it?

<comment><USER2> I am using a custom built iOS app to regularly send my gps coords via an HTTP request to a Flask app. The majority of the code is already open source, but I certainly think it has the potential to be a commercial project. If anyone wants to fund it, send me an email, haha.

</comment></comment></comment><comment><USER4> There's work at Indiana University that is about machine learning and lifecams. The question is thus: is there an algorithm that can determine private moments (bathroom, sex, ...) and remove them from the video/picture stream?

One of the research faculty obtained $1.5 million from the NIH for this research.

Source: [http://itnews.iu.edu/articles/2014/iu-study-explores- privacy...](http://itnews.iu.edu/articles/2014/iu-study-explores-privacy- implications-of-life-logging-camera-devices.php)

<comment><USER5> >One of the research faculty obtained $1.5 million from the NIH for this research.

There are presumably other uses for this technology....

</comment></comment><comment><USER6> Does anyone remember DotComGuy? (not to be confused by the similarly named Kim of recent fame) A man with the audacious goal of staying inside for a whole year and just ordering whatever he wanted off the internet.

Perhaps not so impressive now, but in 2000 it seemed pretty futuristic. I wonder what crazy social experiments are happening today that will seem normal in 15 years.

<comment><USER7> > Perhaps not so impressive now

These days you could do one with the rule that you're not allowed to use the internet for your day to day life (e.g. Still use it for work, still use it to update your online diary for the challenge)

</comment></comment><comment><USER8> Whoa. The real story here is that Digg is still around.

<comment><AUTHOR> Since its demise and revival by Betaworks, Digg has actually been one of my favorite front pages...somewhere between HN/NYT, and Reddit. They have a few clickbait things but mostly a pretty interesting variety of aggregated stories. This was the first time I've seen them publish their own articles (though I think they've been doing videos for some time)

Also, to give credit where it's due: Digg was one of the few places to follow through on the "let's make something better" after Google Reader closed shop...I hadn't used Google Reader in awhile so I've forgotten what features it excelled on, but Digg's reader is the only feed reader I use currently: [http://digg.com/reader](http://digg.com/reader)

<comment><USER9> You should give Snapzu ([http://snapzu.com](http://snapzu.com)) a try. We're trying to keep improving on it, so any feedback is welcome!

<comment><USER10> I used to use Snapzu but forcing users to click a link twice (once to take you to the Snapzu comment page and then again to "Continue Reading") to navigate to the article is awful and probably a large reason people give up on it.

<comment><USER11> Digg does the same with videos. Very frustrating.

</comment></comment></comment></comment></comment><comment><USER12> I've been doing something similar for the past few months[0], but via an app I made specifically for this kind of thing[1]. It's really cool to be able to play back my montage, and there really is a sort of voyeuristic pleasure from watching other people's "lifecasts."

[0] [https://www.youtube.com/watch?v=izZkCTBI3Bo](https://www.youtube.com/watch?v=izZkCTBI3Bo) [1] [https://itunes.apple.com/us/app/beet-for- moments/id960913398...](https://itunes.apple.com/us/app/beet-for- moments/id960913398?ls=1&mt=8)

<comment><USER13> wanted this for a while, will have to check this out. do you have servers mashing the video clips and keeping a video link on youtube or just keep appending?

<comment><USER12> The clips are stored individually on our end and played in sequence in the app (this allows for easy scrubbing/segmenting of series of clips, as well as things like watching friends' updates as they post videos). The YouTube compilation is all the clips exported from the app and then I put some music in the background.

</comment></comment></comment><comment><USER14> This is a weird memory trip. I went to Dickinson College as well, though a decade later. I always forget how awful and prison like those rooms in her dorm were. The cam doesn't give you the sense of how small they were. I believe that room is about 10x6, basically the whole thing except the door and desk are in frame. A friend actually lived in that room, in maybe 2007 and it was surreal to stand in there know it had been the birthplace of the internet overshare.

</comment><comment><USER15> I wonder if it's legal and interesting to have a drone that follows me and records my life but from afar, while avoiding obstacles.

<comment><USER16> 10-20 minute battery life is normal for quadrotor drones right now.

</comment></comment><comment><USER17> Anyone read The Circle? - [http://www.amazon.com/The-Circle-Dave- Eggers/dp/0345807294](http://www.amazon.com/The-Circle-Dave- Eggers/dp/0345807294)

Pretty soon everyone will be "going transparent" whether or not they'd like to.

<comment><USER18> Yes! Lots of interesting ideas - and some thinly veiled and extremely acerbic criticism of Google et al. - in that book. It's a quick read, and certainly not Eggers' best or most important work, but I think it'd definitely be of interest to many here.

</comment></comment><comment><USER19> Have loved the idea of 'lifecasting' since the very begining. From Jennicam to Justin Kan's original JTV (and iJustine rocking on the same platform.) to Frank Taylor who is still broadcasting for many years over at: [http://franktaylorslifecast.com/](http://franktaylorslifecast.com/)

There was also the oft forgotten Control.TV which Seth Green was a part of. The show focused on one guy living in a house completely rigged with cameras who's day to day activities were decided by the viewers. Almost everything was sponsored, so he would eat Snickers bars all the time, drive a Ford, etc. Of everything, control.tv was my favorite and I'm still looking for something to replace it.

Alas, I dont think Periscope OR meerkat will be that thing.

</comment><comment><USER20> It's scary to think about, but one of my college roommates had a similar setup for years. This story was a big walk down memory lane for me. His bedroom (and I think the common living room in our suite) was on a webcam 24/7 for my last two years in college (1999-2000). I think it was influenced by Jennicam, but there were a number of people that had similar sites (I remember a Lauracam...).

I had my own webcam, but wasn't very keen on being as transparent. I was happy to live as a role player (Roommate #3) on his site.

The site was "bixworld.com" if anyone ever visited it.

<comment><USER21> I had a college friend stream live video using his webcam in his dorm room in 1997 or so. Apparently he didn't warn his roommate about it so every once in a while you'd catch his roommate walking around without a shirt on.

</comment></comment><comment><USER22> Gimlet Media's Reply All podcast had an episode about Jennicam:

[http://gimletmedia.com/episode/5-the- jennicam/](http://gimletmedia.com/episode/5-the-jennicam/)

They also had a blog post with additional facts like it got her a walk on role on Diagnosis Murder:

[http://gimletmedia.com/2014/12/6-things-i-couldnt-include- in...](http://gimletmedia.com/2014/12/6-things-i-couldnt-include-in-reply-all- episode-5/)

<comment><USER23> This article is by the Reply All team.

</comment></comment><comment><USER24> I webcasted my wedding in Vegas ($100 add on). It was a great hit. With more millennials jumping into the marriage pool, this is a great startup vertical (horizontal?). Just make a pi, put a sim card on it / satellite link/ connect to wifi, and you can invite everyone to your special life event.

<comment><USER25> The real problem is spotty internet connections causing the filming of the "big event" to fail. Just has to happen a couple of times before people will be leery of your product (because when it comes to weddings everything has to be "perfect").

<comment><USER26> Such a livestreamer would have to use data connections with fallbacks from multiple mobile data providers and possible a satellite fallback, and a mobile signal booster to bring inside venues.

<comment><USER27> Last I checked that was stupid expensive. Here in the Bay Area Caltrain doesn't have wifi (lol?) so I went on a kick of "I'm gonna get THE BEST MOBILE INTERNET AVAILABLE ANYWHERE" to use on the train. I ended up with a simple Verizon jetpack because the satellite internet stuff comes in briefcases, is CRAZY expensive (like thousands of dollars for the equipment and hundreds for the service) and on top of all that it's stupid slow.

$2,239, up to 492Kbps: [http://www.groundcontrol.com/BGAN.htm](http://www.groundcontrol.com/BGAN.htm)

</comment></comment></comment></comment><comment><USER28> I just read a digg story about Jennicam. Next I am going to surf over to Kozmo and have some snacks sent over.

<comment><USER29> You'd better check if you have enough flooz, though.

<comment><USER28> Ah yes, who could forget Flooz. The original Bitcoin.

</comment></comment></comment><comment><USER30> Holy crap digg.com still exists!?

</comment><comment><USER31> Hmm, it does seem to predate Justin.tv, although it was just regular image updates, not video. Basically a traffic cam for a college woman.

<comment><USER28> Yes, it "seems" to predate Justin.tv by eleven years actually.

It also predates Google, Facebook, and web based email.

<comment><USER32> Just to keep the timeline clear, it only predates web-based email by a couple of months. Jennicam started in April 1996 and HoTMaiL came out two and a half months later. It predates those other things by years.

<comment><USER33> Web-based email was launched in Q1 1995 actually.

[http://en.wikipedia.org/wiki/Webmail](http://en.wikipedia.org/wiki/Webmail)

So it doesn't predate webmail at all.</comment></comment></comment></comment>


Review: HTC Incredible - <AUTHOR> http://blog.badera.us/2010/05/review-htc-incredible.html <comment><USER2> Engadget's review is better: <http://www.engadget.com/2010/04/19/droid- incredible-review/>

<comment><USER3> From engadget's review - "It should also be noted that the browser on these phones is equipped with Flash lite, though we had lots of trouble getting videos to play on many of the sites we visited (Engadget included). If someone was hoping to convince us that Flash could work on a device like this, consider the job unfinished."

<comment><USER4> Another interesting snippet regarding HTC Sense:

"To say that this UI is competitive with something like iPhone OS 3.1 (or 4 for that matter), or Palm's webOS is an understatement; in many ways it's superior to what Apple and Palm are offering."

</comment></comment></comment><comment><USER5> I helped a client set one of these up yesterday. It was OK -- I didn't find anything super impressive about it. The client also has an older Blackberry which was able to play video about as quickly.

One thing to note though: it comes with a different mail application than Droid's, and that mail application silently bombs on self-signed SSLs. So, if you want to use SSL with your POP or IMAP account, in some cases you'll hit "Next" after setting up the server information, the mail program will go to "Verifying account information" for a bit, then come back to the same screen you were already on without any warnings.

Otherwise -- honestly, having used iPhones and an iPad recently, I found myself thinking that it still wasn't an iPhone killer, which is sad. I'd really like to see a solid iPhone killer on the market.

</comment><comment><USER6> I got this phone on day one. I've used most smartphones out there, this by far offers the most pleasant experience.

If you're looking to get one, I'd say the overall thing that blows me away is the performance in general. I've never used a more responsive phone- that includes the iphone. Sense UI, is better than I thought. In fact, I thought I was gonna flash it and put stock android on there, but now I think next time if I don't get an HTC, I might flash it and put sense on it.

Only downer is batter life- but that's an issue with most phones.

</comment><comment><USER7> The main photo at the top of the review is not the Incredible but rather the HTC Supersonic. I've had the Incredible for 2 days now. My very brief review: feels nice in the hand, great Google integration, sweet camera, many functions take one more step/button-press than on the iPhone, calls work.

<comment><USER8> How's the touchscreen? The thing I've always hated about Android devices was the jerky scrolling on web pages, as apposed to how it's silky smooth on the iPhone/pad.

<comment><AUTHOR> You're in luck: silky smooth it is. Upgraded sensor over the Nexus One. Better multitouch, better responsiveness in general, lower battery drain.

</comment></comment></comment><comment><USER9> _On the front of the device you've got... four touch-sensitive hard buttons_

Hard buttons are fine, but please, please don't make them touch-sensitive.

<comment><AUTHOR> I think it's feasible to hit them without looking as is, with just the haptic feedback. And in the dark, they light up. But yes, full physical buttons will still have an advantage in some scenarios.

<comment><USER9> The biggest problem I have with them is that they're prone to accidental presses. Also, there's no feedback of any sort--soft touch-sensitive buttons at least offer some visual feedback.

<comment><AUTHOR> There is haptic feedback.</comment></comment></comment></comment>


Anatomy of an ELF executable - <AUTHOR> https://kishuagarwal.github.io/life-of-a-binary.html <comment><USER2> Strongly recommend reading "How To Write Shared Libraries" by Ulrich Drepper [https://software.intel.com/sites/default/files/m/a/1/e/dsoho...](https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf)

I recently dove into ELF files so I could convert ELF binaries to DOS EXE, for a little bit of retro programming with modern compilers. Not that I couldn't have used DJGPP.

<comment><USER3> > I recently dove into ELF files so I could convert ELF binaries to DOS EXE, > for a little bit of retro programming with modern compilers. Not that I > couldn't have used DJGPP.

That sounds pretty cool, did you make anything you could share?

<comment><USER2> Going to post it to GitHub when I have a moment. I literally wrote the code a couple weeks ago.

Edit: [https://github.com/depp/elf2dos](https://github.com/depp/elf2dos)

</comment></comment></comment><comment><USER4> Interesting article. When I was studying the elf format myself in the past I've also found very useful this poster. [https://github.com/corkami/pics/blob/master/binary/elf101/el...](https://github.com/corkami/pics/blob/master/binary/elf101/elf101.pdf) The author has made many more for similar binary formats.

<comment><USER5> COM files are great... no headers, you just sort of start. Data, code... whatever.

</comment></comment><comment><USER6> > You can ignore the directives starting with cfi. They are used for call > stack unwinding in case of exceptions.

It might be worth compiling with -fno-asynchronous-unwind-tables, which will get rid of those.

<comment><AUTHOR> Thanks for the suggestion. Do you have any good reference for reading about this feature?

<comment><USER6> GCC's option page lists what it does: [https://gcc.gnu.org/onlinedocs/gcc/Code-Gen- Options.html](https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html). However, it's not all that obvious that this is the flag that controls whether the "cfi" labels are emitted. Here's a more general Stack Overflow question about creating nice assembly output: [https://stackoverflow.com/questions/38552116/how-to- remove-n...](https://stackoverflow.com/questions/38552116/how-to-remove-noise- from-gcc-clang-assembly-output)

<comment><AUTHOR> Nice. Thanks for sharing the stackoverflow link. Will check that.

</comment></comment></comment></comment><comment><USER7> Are you the author? Great job for the detailed writeup. Small nit, I noticed you misspelled the interpreter section, it should be .interp instead of .intrep

<comment><AUTHOR> Thanks @ddcc7. Yes, I am the author. Fixed the spelling mistake.

</comment></comment><comment><USER8> ELF may find new life as a format for data structures in persistent RAM, given a few extensions.

</comment><comment><USER9> Mods fix title: "Life of a binary"

<comment><AUTHOR> I don't see any option to edit the title now. Anyways, I don't see it would change any meaning of the article.

<comment><USER10> I would suggest "Anatomy of a Linux ELF executable" for the title. A binary file could be anything.

<comment><AUTHOR> I agree. You know of any way to edit now? Edit option is disabled now.

<comment><USER11> OK, we've done that now!

<comment><AUTHOR> thanks @sctb

</comment></comment></comment></comment></comment></comment><comment><USER12> Title should have (2017).

<comment><USER13> A lot has changed in the world of ELF executables, this information is just _soo_ misleading.</comment></comment>


Ask HN: Best Mea Culpa When You Really Screw Up?  - <AUTHOR>

We had an incident (long story) which resulted in the loss of some customer data (files/data gone but no sensitive data compromised).
I'm wondering what is the best way to explain and make things right with our affected clients? Direct email, blog post, and/or something else? Who has done this right/wrong in the past?
TIA <comment><USER2> How many clients were impacted? If it was under 100, call each of them and explain. If it was over 100 but under 1000, send an email and include your direct telephone number or cell phone number. Be prepared to eat some crow on the phone.

Over 1000... hire a PR expert because you're gonna have some real problems either way. (edit: Actually, I don't know if that's the right response here. It's outside of my experiences so maybe someone could weigh in on what to do on a problem of that scale)

The important thing is to identify the impacted clients, assess the severity of the problem, and tell them how you're going to prevent this from happening again (I assume you've figured out how to stop this from happening again).

Good luck.

<comment><USER3> No matter how many were affected, call your best 100 customers and talk to them about it. Say that you messed up, and are changing things to ensure this does not happen again, and then keep blabbing on until the phone call turns into a discussion of features and new stuff that your doing.

Now you have a sales call. Every point of contact with a customer, even telling them you screwed them, is an opportunity for a sale, or at the very least to come out of the situation more understanding of each other.

</comment></comment><comment><USER4> If you are accredited with the BBB make sure to respond if they contact you. Failure to respond to an inquiry will result in loss of accreditation.

A previous employer of mine learned this the hard way.

</comment><comment><USER5> Yeah definitely be open about it, don't hide anything, and prove that it will never happen again

</comment><comment><USER6> Full disclosure, full restitution, genuine contrition.

</comment><comment><USER7> explain the measures you are taking to ensure that it never happens again</comment>


Ask HN: Should you roll your own auth? - <AUTHOR> Hi folks,
I know this question has been asked many times, but I see a lot of conflicting opinions, across the internet. I'm in no means a professional developer (i'm just a high school student).
I'm asking specifically for Ruby on Rails, but feel free to leave your general opinion as well.
Cheers! <comment><USER2> As with many questions the answer is "it depends"

If you are trying to learn authentication then yes go ahead and implement it.

But if you are trying to build a commercial grade product, then your best bet is to use a 3rd party library or commercial service that has been tested and it's stable and reviewed for security.

</comment><comment><USER3> If you're dealing with production traffic and live credentials... NO!</comment>


Most trees alive today won't survive in the climate expected 40 years from now - <AUTHOR> http://www.rapidshift.net/most-trees-alive-today-wont-be-able-to-survive-in-the-climate-expected-in-40-years/ <comment><USER2> Worrying news. There's a YouTuber - CodysLab (relevent video: [https://m.youtube.com/watch?v=sghWcjGYSxY](https://m.youtube.com/watch?v=sghWcjGYSxY)) - I watch that experienced this exact die-back with pinion-pines.

It's interesting to see how a marginal increase in temperature can have huge impacts on the ecosystem, for example incests able to survive where previously they couldn't.

I'd also be interested to see what the impact of a large number of tree's dying out would cause - growing up deforestation of the rainforest was a huge environmental issue (and continues to be).

</comment><comment><USER3> > At the current pace of warming, much of the world will be inhospitable to > forests as we know them within decades. The extinction of some tree species > by direct or indirect action of drought and high temperatures is certain. > And some recent research suggests that, in 40 years, none of the trees alive > today will be able to survive the projected climate.

That is so ridiculous. Temperatures within 40 years aren't going to change by much more than they've already changed over the past 100 years. Did most forests die off and vanish? No, in fact the extra C02 in the atmosphere, and warmer climate is beneficial for tree growth - if only we weren't clearing the forests we'd have more trees today. The earth has been hotter than where we're headed with global warming. It was heavily forested at that time. To be extra clear, none of that is saying global warming isn't a huge problem, just that forests dying off probably isn't the part to worry about.

Articles like this do climate science a serious disservice and give people reason to doubt climate change - they're counter productive.

<comment><USER4> Most trees alive today were already alive 40 years ago; saying that they won't survive the temperature in 40 years is simply saying that the warning in the past 40 years has already used a large part of their tolerance.

BTW, I wouldn't bet that temperatures will change only a little in the next 40 years, considering how many record temperatures we've had in the past ten.

<comment><USER3> We're warming about 0.2C per decade. So, even assuming that accelerates we're going from a current 1 C change since per-industrial times to 2 C change in average temperatures. I'm going to call that a little compared to what's coming over the next couple centuries.</comment></comment></comment>


Ask HN: Should I move my startup from SV to SF? - <AUTHOR> First time poster here.
Most of the past posts on HN comparing "SF vs SV vs. East Bay" look at it from the perspective of where an individual looking for work should choose to live. I'm hoping for advice from the perspective of founders, CEOs, and/or recruiters. If I want to be close to great talent to build my team around, where should our office be?
We're in Palo Alto right now and hiring. Applicants are coming from all over the bay (literally) and I'm realizing that no matter where we are located, we're going to end up missing out on good people. We're hearing a lot of "I've been riding caltrain / driving 101 for X years and I can't do it anymore". Right now being in SV is turning away some SF talent. I imagine the same is true the other way around. Is this a "grass is never greener" situation? Is trying to please everyone inevitably going to lead to pleasing nobody? If I have to commit to one side of the bay, which talent market should I "give up"? Lastly, how much stock should I put in my own personal location preference (my wife has a job down here in Palo Alto, and if we move the organization to SF then either she or I will have to commute which I worry will burn us out and then what happens to the mission)?
I'm willing to work off "gut feel", but it would sure help to get some more data if possible.
Context: We're a high tech nonprofit. B2C. Our big three functions are community mgmt, product (dev+design), and biz dev. We have revenue and are no longer in need of startup investment. <comment><USER2> Here are my thoughts. If you no longer need funding and are just concerned with missing out on talent, then I'm not sure it matters where you're located. Maybe start figuring out how to be a distributed team or get some space in SF in a co-working space where those that live in SF can go to work there. You'll never lose the anxiety of wondering if you're missing out on top talent. That will always exist. The best way to temper that anxiety is trust those that you have or make it easier to let your team work remotely.

</comment><comment><USER3> This isn't an answer, but ever consider a remote office?

<comment><AUTHOR> Does that work at small scales? Does 2-3 people in Palo Alto + 2-3 people in SF a team make?

<comment><USER3> I've worked on 100% remote teams for the past 5 years. The first company was ~8 people, and the second is 5 people. I'm a huge advocate of allowing people to work from home.

Other people have done better work laying out the benefits of remote work than I could, but here's some food for thought:

\- Remote workers get an instant boost in work-life balance that doesn't cost the company anything. They have no commute, and they can choose to live in less expensive areas. Those are huge happiness boosts and also a great way to retain employees, since few companies allow remote work.

\- Costs for office space go down.

\- Studies have shown that people hate open offices and are less productive in them. Productivity is greater when people can have a quiet, private space to make phone calls or just think. Office space with individual offices for each employee are expensive and rare.

\- You can hire from anywhere. My company currently employs an excellent senior developer who refuses to leave his home in small-town North Carolina. We pay him far less than he would make in NYC or SF, so both he and our company win.</comment></comment></comment>


A $150,000 Small Business Loan–From an App - <AUTHOR> https://www.wsj.com/articles/a-150-000-small-business-loanfrom-an-app-11546002022 <comment><USER2> [https://outline.com/WyH9FB](https://outline.com/WyH9FB)

</comment><comment><USER3> This is about loans from Square. They started the same year [1] PayPal began doing the same thing.

"PayPal Holdings Inc. has extended more than $6 billion in small-business loans since 2013, using data it collected by processing payments for Internet retailers."

Others are following suit:

"Intuit Inc. started offering loans to businesses that use its Quickbooks software based in part on the data contained in their accounting statements. First Data Corp. now lets businesses that use payments devices from Clover, a Square competitor that it owns, take out loans based on their sales history."

[1] "A team of techies at Square dreamed up its lending program, now called Square Capital, in 2013 when Square was around four years old."</comment>


Rest in Peace, Google Glass: 2012-2014 - <AUTHOR> http://www.pcmag.com/article2/0,2817,2469916,00.asp

<comment><USER2> I'm still curious if Google ever really planned for Glass to be more than a niche/experimental device. I'd be surprised if most of the big players in the field don't have similar R&D projects going on all the time but Google is different in that they sometimes release early versions for enthusiasts and developers to see how people use them out in the "real world".

It doesn't do much for their image as people seem to discount anything that isn't an immediate success but I guess it's the sort of thing you can do if your company has the kind of resources that Google does.

I'd have loved a set if only for the novelty and tinkering potential but even after the project went on for a year or two it's still priced like an expensive developer kit. I wonder if things would've been different if they had sold them for under $500 instead of three times that amount. It wouldn't be the first pricey gadget I bought without an immediate compelling use (just ask my Leap Motion, Oculus Dev Kit, and piles of other sub-$500 devices I've got laying around).

I guess what I'm really curious about is what they've taken away from this little experiment. What have they learned about these kinds of interfaces and devices that might show up in more mainstream devices down the road?

</comment><comment><USER3> I'm a schmo who bought a Google Glass and accept this was a bad purchase. I bought it for one app ... the ability to cast a video to my parents via Google hangouts. Google took this feature out after my 30 day return was over. Now, Glass is a paperweight for me. I know there are other apps out there that do video casting but I'm not going to force my parents to learn yet another app again (was hard teaching them hangouts the first time).

<comment><AUTHOR> I was kind of wary at the use-cases Google presented for the device. It all seemed to be some variant of what a gopro does.

I think without it supporting AR it was always DoA in my mind.</comment></comment>


Show HN: Covid Guard – The global Covid-19 screening platform - <AUTHOR> https://covidguard.io <comment><AUTHOR> Covid Guard is a platform aimed at collecting and analysing anonymous health information to get a real-time overview of the pandemic and prevent new outbreaks.

We leverage a source of information still untapped in most countries – the symptoms of the population – which can provide valuable insights without having to rely on limited resources, such as swabs or serological tests.

By using the platform, users directly contribute to the safety of their own community while receiveing constant updates on their areas of interest (through maps and customised reports).

Our aim is not to directly identify those who may have contracted COVID-19, but rather to statistically determine high-risk areas and identify anomalous patterns days or weeks in advance compared to conventional solutions (i.e. contact-tracing apps). That way, we allow authorities to promptly focus their efforts on the most critical areas, making the most of the tools at their disposal.</comment>


How to Build a SaaS Unicorn: The Outreach Story - <AUTHOR> https://blog.getlatka.com/outreach-saas-revenue-sales-customers/ <comment><USER2> Not to be dramatic, but it would be nice if this domain/"enterprise" were not allowed here based on the reporting from Vox[0].

[0] - [https://www.vox.com/recode/2019/11/26/20930374/nathan- latka-...](https://www.vox.com/recode/2019/11/26/20930374/nathan-latka- podcast-saas-data-top-entrepreneurs)

<comment><USER3> After reading that article, I have got to say that it's so ironic that many of these SV founders are mad that Latka is selling their company data. One actually said when I provided that information for the podcast, "I didn't intend for that data to be sold."

Latka's argument is that he is clear in the podcast and many other places that is what he does.

It sounds like he is playing startup founders with their own game. Provide a service that the founder/company wants for free or little cost. Then turn around and sell their data to 3rd parties.

I would be willing to bet that is the business model of many of the companies that have appeared on the podcast and are mad at having their data packaged and sold.

And Latka's response is the same as all the founders of those types of companies.

"It's in the fine print, bro!"

<comment><USER4> What's good for the goose is good for the gander. Here is a human person doing to corporate persons what they have been doing to human persons.

It drives a stake in the heart of their hypocrisy.

They take your private info and sell it for marketing and he takes their marketing and sells their private info. The desire for HN'ers to silence this publication of private data speaks to the nature of the community being blind to their own wrongs.

</comment></comment></comment><comment><USER5> Congratulations! Some key take aways:

1\. Postpone investment in marketing for the first few years and focus on the product. No need to spend time on social media.

2\. Bid on competitors brand names in Google Ads.

3\. When you buy other SaaS, give them testimonials with back links to boost your SEO.

<comment><USER6> The article omits arguably the highest-impact element:

      4. Be comfortable selling a product that almost all customers use to send spam to strangers.

That's the ingredient many, hopefully most, entrepreneurs don't have. Outreach got popular by letting salespeople send the same template to more strangers, faster. That was its whole business for the first few years.

Even today, the leftovers exist on their Web site. [https://support.outreach.io/hc/en- us/articles/216288348-Avoi...](https://support.outreach.io/hc/en- us/articles/216288348-Avoiding-Spam-Filters) is one example: "When using Outreach, it is up to the individual to follow these requirements. Remember, being marked as spam can have a detrimental impact on your organization's deliverability rates."

If there's a universal lesson, it might be to find a market, customer, or delivery method that you are uniquely suited for. Outreach's founders cared less than average about enforcing policies or making a positive overall impact, and they found a field where caring about paying customers at the expense of all other stakeholders (like recipients) was rewarded. While I sure wouldn't encourage differentiating that way, the concept works.

<comment><USER7> >Outreach's founders cared less than average about enforcing policies or making a positive overall impact

Didn't realize you were privy to the founders' nefarious intentions, do you have evidence to back this claim up? That's a huge story if you're telling the truth.

<comment><USER6> There's nothing nefarious about it. These are 2 of many relative priorities. For example, at one extreme, some people care only about impact and don't care at all about money; that usually leads to a not-for-profit. At the other extreme is barely-legal greyhat malware/adware, where a lot of collateral damage is accepted as long as it's profitable.

I wouldn't personally be comfortable with the tradeoffs that Outreach made, but it's legal and making them doesn't make them evil. One might describe it as greedy.

(I don't think greed is newsworthy and I'm far from the only person to see it here. Regarding evidence of Outreach's spot on the continuum, [https://twitter.com/annepmitchell/status/671386007850192896](https://twitter.com/annepmitchell/status/671386007850192896), [https://twitter.com/dswiese/status/713039678287405056](https://twitter.com/dswiese/status/713039678287405056), and [https://twitter.com/troyd/status/753721604081799168](https://twitter.com/troyd/status/753721604081799168) are 3 of many examples.)

<comment><USER8> Making legal trade-offs can be evil, and setting & enforcing social norms is a basic responsibility of every adult.</comment></comment></comment></comment></comment>


Valve Index FOV technical deep dive - <AUTHOR> https://www.valvesoftware.com/en/index/deep-dive/fov <comment><USER2> This looks like a great idea for all the games they'll never make.</comment>


Bookicious – Great book collections for founders and entrepreneurs - <AUTHOR> http://www.bookicious.com/collections/

<comment><AUTHOR> Hi there guys, I am Mauro, the one who created Bookicious!

Hope you like Bookicious and If you have any feedback or opinion, feel free to tell me.

Thanks a lot!</comment>


Compensating contractors with equity? How to value your pre-seed startup's stock - <AUTHOR> https://launch.gust.com/blog/how-to-value-startup-stock?utm_source=hn&utm_medium=social&utm_campaign=launch <comment><USER2> Founders: Don't be too surprised if a contractor prefers cash. Or a high percentage of the enumeration cash with little stock. You might calculate (future) company valuations and how to structure stock grants, the contractor might prefer a simple standard contract without extra clauses on grants.

I've worked as contractor for equity in the past. And advisor. And I've friends who did that kind of consulting, usually as favor, e.g. MySQL performance tuning. For me that work was extra to an already existing contract/work (one that covered my rent).

The most frustrating part were the emails back and forth on the equity. Not the amount/percentage, but the founder are (of course?) new to the topic, didn't know how to add that to an existing contract, added many "what happens when" clauses and I can only imagine every contract looks slightly different. To give an example: bonus equity when a certain series-A valuation is reached (because I've build the MVP that was presented to VCs).</comment>


Comparison of Comet server implementations - <AUTHOR> http://cometdaily.com/maturity.html

<comment><USER2> How about Faye? It's an implementation of the Bayeux protocol in JavaScript and Ruby, with both server and client code available in both languages. There's a JS client for browsers too:

<http://svn.cometd.com/trunk/bayeux/bayeux.html>

<http://faye.jcoglan.com/>

<http://github.com/jcoglan/faye></comment>


Sclack: The best CLI client for Slack, because everything is terrible - <AUTHOR> https://github.com/haskellcamargo/sclack <comment><USER2> Extra points for the "Made with [rage emoji]". Can't stand the cheap sentimentality of "Made with [heart emoji]" (Then again, maybe people who use that line mean it...).

<comment><USER3> I agree.

The rage emoji reminds me of the expression "to use with anger", which has come into vogue on HN in the past year or so.

vt. to use for a real task, as opposed to just testing it out.

"Has anyone used this in anger?"

[http://onlineslangdictionary.com/meaning-definition- of/use-i...](http://onlineslangdictionary.com/meaning-definition-of/use-in- anger)

<comment><USER4> I suspect it's a Perl thing (use Perl with anger).

Here is a 1998 Usenet posting in alt.sysadmin.recovery that uses it:

[https://groups.google.com/forum/message/raw?msg=alt.sysadmin...](https://groups.google.com/forum/message/raw?msg=alt.sysadmin.recovery/1g9EAV3CXqU/ND5SR8Zvj- EJ)

The message ID is: email@example.com

Ah, slrn; what I'm using today. :)

However, Philip Wadler (famed FP computer scientist) used this phrase in a February 1998 article called "Functional Programming: An angry half-dozen":

[http://www.cs.huji.ac.il/course/2003/pllab/print- files/wadle...](http://www.cs.huji.ac.il/course/2003/pllab/print- files/wadler.pdf)

The paper says that a postdoc colleague, a dozen years earlier (thus 1986) asked Wadler about his new bicycle: "have you used it in anger yet?"

Wadler may have introduced this as a meme pertaining to programming languages or constructs. In any case, if he did actually glean it from someone else's internet posting about a programming language being used in anger, he's sure not admitting it in this paper.

<comment><USER5> > I suspect ["used in anger"] is a Perl thing

It predates usage in the context of Perl, or any other software. Indeed it probably predates the existence of software :-)

I think it originates in a British military context (i.e. shots fired in anger rather than in training).

Edit: These answers [1] include a citation from 1798. Sorry if you actually just meant first use in a software context.

[1] [https://english.stackexchange.com/questions/30939/is-used- in...](https://english.stackexchange.com/questions/30939/is-used-in-anger-a- britishism-for-something)

</comment></comment></comment></comment><comment><USER6> It seems to be a TUI (textual user interface), not a CLI (command line interface). If you want a Slack TUI client, there was already [https://github.com/yuya373/emacs-slack](https://github.com/yuya373/emacs- slack) (And I think that one can display images, so maybe it's really halfway between TUI and GUI.)

</comment><comment><USER7> How does this compare to wee-slack (slack gateway/plugging for the wee-slack irc client)?

[https://github.com/wee-slack/wee-slack](https://github.com/wee-slack/wee- slack)

<comment><USER8> didn't they deprecate the gateway last year?

<comment><USER7> Wee-slack is a gateway for weechat; it uses the slack api. But weechat can function as its own proxy (client/server split between the gui/tui and the network bits).

So not irc gateway, weechat gateway.

</comment></comment></comment><comment><USER9> Wonder how this compares to [slack- term]([https://github.com/erroneousboat/slack- term/](https://github.com/erroneousboat/slack-term/))...

<comment><USER10> Well it's maintained, to start with. The slack-term author has the disconcerting habit of rejecting issues because he doesn't like terminals.

<comment><USER11> Wow, you're not wrong. I just went through the closed PR list. Terrible maintainer. Even closes PR's for typos in the README. Doesn't even give a reason why he closes.

<comment><USER10> It's his project, and I'm not the one who is going to judge his maintainership, but I am glad that there is choice in this class of application.

</comment></comment></comment></comment><comment><USER12> I like the idea of this, but it crashes for me on startup. I would definitely use a Slack client like this, but installation with `pip install` would be much better than having to install from source.

</comment><comment><USER13> Wonderful! I hate slack GUI: kills battery and too slow.

I am eager to try that!

I would love some irc bridge functionality hyperlinking the images, but it may be too much to ask.

</comment><comment><USER14> What's this poking fun at: "because everything is terrible"?

<comment><USER15> The syrupy messages you see on Slack when it starts up.

<comment><USER16> arent those set by your admin/team?

<comment><USER17> There are defaults that most people probably don't change.

</comment></comment></comment></comment><comment><USER18> I wish there was one of these that actually reversed the protocol so you can use username/password. Unless I'm mistaken, token is an opt-in/out feature for each slack admin.

</comment><comment><USER19> How hard would it to be to get images to be shown in the CLI? Or is that not possible with whatever stock terminal software?

<comment><USER20> Pretty much impossible. There are some programs that can kind of do some images, but certainly not gifs

<comment><USER21> imgcat can do gif in iTerm

<comment><USER20> Yes, but only iterm

</comment></comment></comment></comment><comment><USER20> This is awesome. Will most likely be contributing to this

</comment><comment><USER22> Looks awesome, I can't wait to check it out.</comment>


How does a CPU work? - <AUTHOR> https://prdeving.wordpress.com/2017/03/31/how-does-a-cpu-works/ <comment><USER2> This explains some digital logic but does not actually explain how a CPU works.

It does not explain an XOR gate, but references them. It also does not explain flip-flops, but references them also.

There should probably be an explanation of state machines since they are usually used to control the cycles in a CPU.

The title is actually "How does a CPU works?" but other than these few things it was a good article.

I know that text messages seem more harsh than intended and do not wish to seem demeaning, but helpful.

I bought a book called "Thinking Machines" by Irving Adler in 1962 which explained the concepts in this article (except for the 74181 ALU) and the XOR and flip-flops but did not understand how a computer actually worked until many years later.

<comment><AUTHOR> I totally agree with you, but as you know, a CPU is pretty complex and is not possible to explain it all in just one article. Before writing it i've been looking for something similar and have not found any other article that explains as much as i've covered, so, to me it can be considered far from being perfect but "good enough".

Also, i'm technical but don't want to spoon-feed anyone, the article says what a logic gate is, how are they built and which ones are the basic ones, after that, just some wikipedia and google will be enough to teach any reader how to build the other variations, same applies to flip-flops.

I'm not witting this as rude as it looks, indeed, i agree that i've been far from explaining exactly how everything works and fit together, but i tried my best to make it simple, not too techie and easy to read, and becoming a text- book was just out of my scope.</comment></comment>