Carbon emissions and costs of subsidizing New York nuclear vs renewables - <AUTHOR> https://www.sciencedirect.com/science/article/pii/S0959652618326829 <comment><USER2> One of the authors is known for _heavily_ cherry-picking his facts, making some pretty extreme and outrageous assumptions, and suing fellow academic critics who point this out. Caveat lector.

<comment><USER3> For others: [https://en.m.wikipedia.org/wiki/Mark_Z._Jacobson](https://en.m.wikipedia.org/wiki/Mark_Z._Jacobson)

<comment><USER4> Oh, _that_ guy. Suing PNAS and the author of a study critical of his work is honestly quite shocking. One would hope the work would stand for itself, or at least the response should've been another paper rather than a lawsuit.

<comment><USER5> You find it shocking that he might have a valid case against them, or that he has money to waste on legal harassment ?

<comment><USER6> It is thoroughly inappropriate to respond to legitimate criticism, made in good faith, published in a reputable journal, with a lawsuit.

It doesn't matter if you're right. If you're right; arguments can be made to show that your opponents are wrong (and he was in fact allowed a rebuttal letter in PNAS). Filing a lawsuit breaks any semblance of civility of discourse and dispassionate pursuit of truth; and results in everyone worse off, as the discussion has become thoroughly toxic.

It's burning down the entire house because someone disagreed with your analysis.

<comment><USER5> Whether it was appropriate or not depends on whether the criticism was legitimate or not. That is the legitimate purpose of legal proceedings to determine.

</comment></comment></comment></comment></comment></comment><comment><USER7> >We compare the cost of maintaining a proposed subsidy for New York's three upstate nuclear power plants with the cost of replacing the plants with renewable technologies from 2016 to 2050

Is operating the plants until 2050 really something people consider? From a brief google search those nuclear power plants were all built in the 70s-80s. Power plants are usually designed for 30-40 years of operation. Operating them for 70-80 years seems ill advised from an economic and safety standpoint.

<comment><USER8> I imagine building a new plant -- even to replace an existing one -- would be a politically uphill battle.

There are plenty of folks who consider coal or natural gas to be "more renewable" or "more green" than a nuclear plant.

<comment><USER9> Wait who considers coal more green than nuclear? That's nonsense. Renewable is understandable as a sort of redefinition of terms, but I don't see how anyone explains away coal as "green."

<comment><USER10> There is such as thing as "green coal", a.k.a. "clean coal". Methinks it's an oxymoron, but some people seem to disagree :/

<comment><USER11> I don't think there's anyone who believes in "clean coal" that isn't a lobbyist or a dupe of one. Theoretically coal-with-carbon-capture could be clean, but I'm not sure if any of these have ever been built and they would have high running costs.

</comment></comment></comment></comment></comment><comment><USER12> So, knowing the way technology works, one has to figure older legacy systems are painful to deal with. Not always, but usually.

Knowing that most code deployments for server side software cannot claim the benefits of total rewrite from scratch, many of us would love to get a chance at trying exactly that.

What would this assessment look like for a nuke-to-nuke replacement, instead of nuke-to-wind/solar?

In other words, if they abruptly terminated use of all the aging nuclear plants today, and immediately started building totally new, highly modern nuclear power facilities, how would that stack up against this research favoring renewables?

<comment><USER7> Nuclear power doesn't look that great from a cost standpoint once you factor in decomissioning of the plant after use, storing the waste from both fuel and decomissioning (some of it basically forever), etc. A lot of those have been externalties payed by the government, making it profitable for the operating company, but that shouldn't cause us to build more.

If you used modern cutting-edge designs things might look differently, but anything that is actually being built are updated versions of designs from the 70s. Nobody wants to spend lots of money on research and take the risks with building more radical new designs.

<comment><USER13> Nuclear plants are required by law to save up capital as they go for decommissioning themselves.

They used to be required to pay into a fund for long-term waste storage, and that fund has about $40 billion now. But after the Yucca Mountain project was shut down, the nuclear operators had to store the waste in concrete enclosures on their own properties, so they went to court saying they shouldn't also have to pay the government to do nothing. In 2013 the courts agreed.

There are actually a lot of companies that want to spend money on R&D and build radical new nuclear designs, including Terrapower, Moltex, Terrestrial Energy, Flibe, Thorcon, Elysium, and many others. In the U.S. the NRC makes this extremely difficult.

A couple years ago I got to sit in a meeting between representatives from about a dozen of these companies and a former head of the NRC. The reactor people said their biggest problem was that the NRC requires a near-complete design before they'll even look at it, and then they give a straight yes or no. If yes you still just have a paper reactor, and if no then you're done. The design process costs several hundred million dollars and you have no idea whether the NRC will let you do anything with it. It's a very difficult environment for investors.

The reactor people said just a more phased process would help a lot. The NRC person dismissed their concerns, said it wasn't the NRC's job to help develop new technology or promote nuclear power, and wasn't interested in climate change.

<comment><AUTHOR> I can understand that this makes new nuclear development in the US a non- starter. Why is the outlook for nuclear just as abysmal in the UK and China though if their regulators are not as disincentivized to permit innovation?

<comment><USER14> I don't know about the UK, but China has been building new reactors. In fact, that's what's gotten some reactors to a TRL status where they can build them in America.

But from people that I've talked to in the UK, they seem to be more afraid of nuclear than Americans. This seems to be a common trend in Europe. Many people citing radioactive mushrooms from Chernobyl.

</comment></comment></comment></comment></comment><comment><USER15> Are they including the cost of storing power for peak demand and low generation times?

<comment><AUTHOR> New York state has pumped hydro storage facilities. Any other gaps will be filled by natural gas until utility scale battery storage comes down in price.

[https://www.dec.ny.gov/energy/43242.html](https://www.dec.ny.gov/energy/43242.html)

[https://www.nypa.gov/power/generation/blenheim-gilboa- pumped...](https://www.nypa.gov/power/generation/blenheim-gilboa-pumped- storage)

[https://pv-magazine-usa.com/2018/12/17/new-york-ups-its-ener...](https://pv- magazine-usa.com/2018/12/17/new-york-ups-its-energy-storage-goal-3-gw- by-2030/)

<comment><USER16> > gaps will be filled by natural gas until utility scale battery storage comes > down in price.

So emissions will actually rise, until Magic Future Tech (TM) arrives to save our bacon? Great plan. Just great.

Well, if not the climate, at least the fossil industry will be happy about this paper.

<comment><AUTHOR> > So emissions will actually rise, until Magic Future Tech (TM) arrives to > save our bacon? Great plan. Just great.

That's exactly how we arrived with solar and wind so cheap between the 70s and now. Batteries _will_ get cheaper, as demand for them for EVs brings more manufacturing capacity online.

[https://electrek.co/2018/08/02/tesla- gigafactory-1-battery-p...](https://electrek.co/2018/08/02/tesla- gigafactory-1-battery-production-20-gwh/)

> "At the end of July, Gigafactory 1 battery production reached an annualized > run rate of roughly 20 GWh, making it the highest-volume battery plant in > the world by a significant margin. Consequently, Tesla currently produces > more batteries in terms of kWh than all other carmakers combined."

> Panasonic recently commented that 'production at Tesla is gaining momentum' > and they plan to add 3 battery cell production lines. It should result in an > annual production rate of 35 GWh.

> At 35 GWh, they would be producing at the originally announced production > rate, but Tesla has since increased the planned total capacity to 105 GWh of > battery cells and 150 GWh of total battery pack output.

<comment><USER15> I agree with you. That demand will drive production up and economies of scale and research will drive costs down. But I still think the article should include all the facts. The storage / peak supply side of things is very expensive at present and it seems to have been left out of the equation. I'll be super happy when renewable are end to end the cheapest options. That's going to be a great day, but I don't think we're there yet.

</comment></comment></comment></comment></comment><comment><USER17> Winder power is never just wind power. Looking at the power generation of example Germany we see a massive 75%+ use of wind power in good conditions, but then see it all replaced with coal + oil + gas when it is not.

Power generation is no longer based on demand. Weather sets the energy price, which dictate when it is economical to use fossil fuels. Wind is already at the point where the price per wat is fantastic, the environmental effect minimal, but if you include the need to infuse dirty energy when weather is not optimal the average wat start to look very different.

If we have to pick between wind + coal, or only nuclear, the carbon emission will favor nuclear. An other version is wind + fewer nuclear plants and lower energy usage during low wind conditions, but there is only so much that the energy usage drop when prices goes up. There is also a bunch of wind + "battery" research, but I have not heard of any national power grid fully investing in that.

<comment><USER18> I'm not sure why you're being downvoted. You make some reasonable points.

I would say though, in the short term, we could stand to increase renewables massively with out needing to solve the storage problem, virtually every watt of installed capacity we add is directly offsetting dirty producers.

Grid scale battery storage is just starting to be implemented, theres also hydro, and 'smart' grid solutions. Whether any of this turns out to be a silver bullet I don't know.

<comment><USER17> Yes. Short term renewables supplement existing grid and reduce the average pollution. It is good to reduce the problem and should be used so that on good conditions it will practically take over all production. However it can not replace the polluting producers on its own, who seem to have started to switch operation to mostly when there is not enough renewables to supply the demand (marginal costs like fuel + investment vs the so-called merit order).

Nuclear could operate just like the dirty producers and only operate when the combined wind and solar is too low for the demand, which would further reduce the environmental impact, but the massive investment needed in nuclear makes the economics of it a bit complex and I have not read if the marginal costs of nuclear operations make this a viable tactic. It would however reduce the nuclear pollution down to the gaps where wind and solar is not enough.

That leaves future tech solutions. Smart grids sounds great, through I do not know how big part of it is a political issue or technical problem. Just getting the steel industry to focus operation on energy producing peaks seems to be a major challenge, and they already have the incentive that the energy get cheaper if they do so. Converting hydro to create burst of power rather than continuously is also something very interesting but has also both political and technical issues to solve. Then we have different from of battery ideas, all from pumping water to different heat capturing concepts, through I think that is even further away form being implemented on a large scale.

The article talks about the proposed subsidy, and this is where I think we need to think about the grid as a whole. If the goal is to fill the gap when wind and solar can't supply the demand then the discussion should not be renewable vs nuclear. It is very possible that the specific subsidy is a bad tactic and they would be better served by trying to narrow the gap with even more wind and solar, but then we need data to show that existing dirty producers are preferred over nuclear in order to fill the remaining gap. That to me is a hard sell, but I am open to be convinced :).

<comment><USER18> "Nuclear could operate just like the dirty producers and only operate when the combined wind and solar is too low for the demand"

Not quite. Nuclear isn't _that_ dispatchable.

In general I agree though, short term we should be using all tools at our disposal, long term depends on how energy storage etc works out.

</comment></comment></comment></comment><comment><USER19> This study forget one important fact - reliability of the wind or solar. Unless there is a serious breakthrough in the storage technologies, nuclear is irreplaceable, be it for the good or bad.

<comment><USER20> Is nuclear good at scaling up or down production?

<comment><USER21> It's great. France literally does load follow based on demand: raises/lowers control rods throughout the day.

<comment><AUTHOR> The US Nuclear Regulatory Commission does not permit automated load following of US nuclear generators. France and Germany nuclear regulators considered it earlier in the permitting process, hence the functionality exists there (load following incurs higher maintenance costs for components such as valves, but does not incur a higher fuel cost).

</comment></comment></comment></comment><comment><AUTHOR> > Abstract: "We compare the cost of maintaining a proposed subsidy for New > York's three upstate nuclear power plants with the cost of replacing the > plants with renewable technologies from 2016 to 2050. Keeping nuclear > operating with subsidy until 2050 is the most expensive option, costing > $32.4 billion (2014 USD) over that period in the base business as usual > case. The least expensive option is to shut down nuclear today and replace > it with onshore wind, saving $7.9 billion. All analyzed renewable scenarios > lead to 20.1 to 27.4 Mt CO2 greater life-cycle emission reductions. In > addition, re-investing the cost savings of the renewable scenarios into > additional onshore wind increase CO2 savings up to 32.5 Mt."

</comment><comment><USER22> This is the kind of junk science that ruins energy discussions. Seriously, hand waving away the energy storage problem of solar/wind by assuming a magic technology will be created?

Other than that Mrs. Lincoln, how was the play?

</comment><comment><USER23> Does the "replacement" cost include _all_ decommissioning and environmental remediation costs?

<comment><AUTHOR> I haven't read the entire paper, so I can't answer if the paper addresses that. Note that work (decommissioning and environmental remediation) needs to be done regardless when those nuclear generators reach end of life. In similar fashion, renewables are less expensive than continuing to run existing coal generation facilities in several markets, and those coal plants will need to be decommissioned regardless of ongoing cost comparison.

The cost of remediating all of this legacy generation is going to be eye watering, every nuclear and coal power plant a Superfund site.</comment></comment>


Principles of Rich Web Applications - <AUTHOR> http://rauchg.com/2014/7-principles-of-rich-web-applications/ <comment><USER2> This is a great article. It's extremely thorough, and touches upon most the difficulties I've encountered in my (limited) experience coding JS on the web, as well as several I hadn't even considered.

My only complaint, if it can be considered a complaint, is that the author doesn't address the real-life costs of implementing all his principles. The main one is the complexity of the server- and client-side architecture required to implement these principles, even for a minimal application like TodoMVC [0].

I agree that user experience is extremely important, and perceived speed is fundamental, but I certainly don't think it's important enough to justify the cost of figuring out how to implement all these principles, especially for a startup or other small team of developers.

Of course, the hope is that tooling will quickly progress to the point that these principles come essentially for free just by following the best practices of whatever libraries/frameworks/architectures you're using. There was probably a time where the basic principles of traditional static web apps (resourceful URLs, correct caching, etc.) also looked daunting for small teams, but that's quite manageable now with Rails/Django/etc. (and maybe earlier frameworks).

[0] [http://todomvc.com/](http://todomvc.com/)

<comment><USER3> There is one such framework: [http://derbyjs.com/](http://derbyjs.com/) It's been in development for about 3 years, so it certainly has a cost to implement. It is being used in production by Lever (YC) to ship very usable enterprise software.

There is even a TodoMVC example being submitted for Derby: [https://github.com/derbyjs/todomvc/tree/master/examples/derb...](https://github.com/derbyjs/todomvc/tree/master/examples/derby)

Another nice thing is that the templating engine can be used client-side only if you want: [https://github.com/derbyjs/todomvc/tree/master/examples/derb...](https://github.com/derbyjs/todomvc/tree/master/examples/derby- standalone)

</comment></comment><comment><USER4> JavaScript "is the language of choice for introducing computer science concepts by prestigious universities"!? God help us all.

I see the link to the Stanford course, but I hope it's still in the minority. JS is not a language that I would want to teach to newbies, especially if those newbies are on a path towards a CS degree.

<comment><USER5> FWIW, CS 101 isn't a required (or popular) Stanford course, and isn't part of the CS major. The intro series is 106A/106B/107, which are taught in Java, C++, and C respectively.

There are plans to switch out Java for Python eventually but no major classes are taught in JavaScript--the closest it gets is a graduate Programming Languages class that spends a few weeks on JavaScript to illustrate closures and first-class functions.

<comment><USER6> There's no undergraduate class that illustrates closures and first-class functions (whether in javascript or otherwise)? That seems odd...

<comment><USER5> The undergrad core (and degree) is 90% Java, C, and algorithms.

To be fair, though, many undergrads take graduate classes and the department encourages it--the only difference is a 2XX course number instead of 1XX, and sometimes a bit more rigor.

</comment></comment></comment></comment><comment><USER7> I can't stand how the Facebook feed updates in realtime. I read a bit, leave the tab, and when I come back to it it updates, so I have to find my place again (which I don't do, I just go "screw facebook" and close the tab ^^). The same for forums, if I want to see new or changed posts, I'll hit F5 -- and when I don't press F5, it's not because I forgot, but because I don't want to. Pressing it for me is a great way to make me go elsewhere; or in the case of facebook, to stay and resent you.

I don't _need_ to know in realtime how many people are on my website. I need to know how many there were last week, and compare that with the week before that. Likewise, I don't really need to see a post the instant it was made. At least for me, the internet is great partly because people chose what they do how and at what pace, because it's more like a book and less like TV, and making it more like TV is not improvement.

This is not against the article per se, which I found very very interesting and thorough, just something I have to get off my chest in general. Though I really disagree with the article when it comes to the facebook feed, I think that should serve as an example for what _not_ to do.

Please, think twice, and never be too proud to get rid of a shiny gimmick when it turns out it doesn't actually improve anything. Let's not sleepwalk to a baseline of stuff we just do because everybody does it and because it's technically more complex. As Einstein said, anyone can make stuff more complex :P

<comment><USER8> I would argue that in the case of Facebook's updating feed that the idea is fine, the implementation is buggy.

What should happen is the new content is loaded above and instantaneously the document scroll position is updated to preserve the previous position. This will allow new content to come in without disrupting your experience.

<comment><USER7> That's fine for a few updates, what if you have a lot? Memory may be cheap, but why not use it for interesting things? I mean, what problem does an auto- updating feed or endless scrolling solve that are easily dealth with by pagination, expire headers and manual refresh? Other than "user stickyness is not 100% yet" I mean, which I don't recognize as a valid problem.

</comment></comment></comment><comment><USER9> A single page app is just this: a web page that doesn't ever reload the page or reload scripts. It doesn't matter how much content the initial page had on it, and it certainly doesn't mean that you send an empty body tag. The history APIs even let the back button and URL bar behave exactly as the user expects them to, but without a single round trip if you already have the data and resources.

While it's certainly true that the first page may load slower, and you'll load a few scripts as well, you never need to reload those again. Frameworks like Angular encourage you to use a "service" mindset that capitalizes on this property.

The longer you use a single page app, the fewer round trips you will have. If you ask me, your communication should only be for raw materials (scripts, templates) that you won't need to validate or request again during the current session, and raw data (json). This is more loosely coupled, more cacheable at all the different levels, and more scalable in large part due to the decoupling.

Once the initial view loads, I totally agree that you should intelligently precache all your resources and data asynchronously in the background to usher in the era of near zero-latency user interactions. Preferably, you do this in an order based off of historical behavior/navigation profiling to best use that time/bandwidth you have before the next click.

I get the impression articles similar to this one that there was once a similar mindset surrounding mainframes and dumb terminals. The future is decentralized, web included.

<comment><USER10> I think people have different use cases that they aggregate under "web application". If you are building a desktop replacement application then I can see that initial load might not be such a big deal but if you are building a less complex application like the Twitter UI then server side rendering makes more sense. It's all context specific in the end. To hard to make general claims.

<comment><USER9> Actually, I think twitter is a prime candidate for a JSON-driven client- rendered application. It's a pretty static shell, with a static tweet template iterated over large amounts of tweet data.

You could completely eliminate a huge number of round trips by just getting tweet data and user data after the initial pageload. The user data is quite cacheable and you could create a single endpoint that allows the user to precache the required user data (display name, photo url, id, etc) for everyone he follows in one round trip.

<comment><USER11> [https://blog.twitter.com/2012/improving-performance-on- twitt...](https://blog.twitter.com/2012/improving-performance-on-twittercom)

They moved away from client-side rendering. Quoting:

 _There are a variety of options for improving the performance of our JavaScript, but we wanted to do even better. We took the execution of JavaScript completely out of our render path. By rendering our page content on the server and deferring all JavaScript execution until well after that content has been rendered, we've dropped the time to first Tweet to one-fifth of what it was._

<comment><USER9> I'm not a Twitter historian, so I may be wrong, but I'd be willing to bet that their client side rendering allowed them to scale the way they did. When your customers' computers are doing half the work or more, adding a customer costs you half as much or less.

</comment></comment></comment></comment></comment><comment><USER12> This is not a great article and is resistant to criticism by virtue of its excessive length. Still, I'll try to point out some major flaws.

1\. Single page apps have many drawbacks that are conveniently not mentioned: Slow load time, memory bloat, persistence of state on reload, corruption of state and others. SPAs are just another misguided attempt at making web apps more like desktop apps. Web apps are network applications - if you remove the network communications portion, what is the point of them?

2\. JS is a great tool to make pages more responsive. This has been the case for years and I am lost on why the author writes on and on about it without any poignant observations or facts.

3\. Using push (web sockets) is a valuable tool for accomplishing particular features. This does not mean that more is better and we should start using it for everything. Server pull is a strong feature of the web and is arguably a key to much of its success.

4\. Ajax is great, no argument.

5\. Saving state as a hash value in the URL not only puts JS actions into history, but makes them visible and bookmarkable as well. Push state is a quagmire.

6\. The need to push code updates is one of the problems caused by SPAs that is not needed in normal web apps. Even so, this could be solved with a decent, as yet unimplemented, application cache.

7\. Predicting actions is overkill. If you focused on doing everything else well, there is no need to add significant amounts of complication. More code = poorer performance and decreased maintainability.

<comment><USER13> I agree with all of your points but number 1. I think a good SPA should be a network-reliant application whose complexity is demanded by the use case. And a good framework for one should have provide near instant load times: a small core library with additional resources and logic only loaded on demand.

<comment><USER12> I think of good applications as a collection of SPAs. There is no benefit to forcing every single feature of an app into only one page. Ajax means we can implement more functionality without a page reload, which is good to a degree, but at a cost of slower initial load, losing URL state, and difficulty tracing UI behavior to underlying code.

I am working on a legacy SPA now and it's horrible. (Our users have learned to refresh frequently due to uncertainty of state.) I am not sure how much to blame on poor implementation as opposed to inherent weaknesses of SPA architecture.

<comment><USER13> Almost all of the SPA frameworks out there right now are nightmarish. I think React is pretty good but limited. What you're describing is probably a much better way to handle the needs of most sites.

</comment></comment></comment></comment><comment><USER14> Is there any web application framework, presumably encompassing both client- side and server-side code, that implements these principles? I'm guessing that Meteor comes closest.

<comment><USER15> DerbyJS ([http://derbyjs.com/](http://derbyjs.com/)) is built specifically for these principles. I'm working on big updates to the documentation right now, but I can say that we have a great solution for Server HTML + Client DOM rendering, realtime data updates, and immediate optimistic updates on user interaction in the client.

By building on ShareJS, DerbyJS uses Operational Transformation for collaborative editing of data in realtime, which means that users can see data updated immediately in their browser even if other users can edit the same thing at the same time. This is the same approached used by Google Docs.

<comment><USER15> Also, here is a video from a very informal talk I gave on similar concepts last year at our office: [https://www.youtube.com/watch?v=iTC5i63eOzc](https://www.youtube.com/watch?v=iTC5i63eOzc)

</comment></comment></comment><comment><USER16> Here's a few thoughts:

I can see that in terms of bandwidth, SPA can be more efficient then normal HTML page. But this makes a few assumption. First, that your JS package never changes. As soon as 1 character changes in your package, the cache is invalidated and the whole package needs to be downloaded. Like you said, it's application specific. But if your app has ~3 pageview per session, it becomes very hard to justify the use of a SPA.

As for acting as soon as there's a user input, this can be done with SPA or not. One thing to mention though, is that Pull-to-refresh is something that is gradually falling out of favour.

Besides those 2 things, insightful post.

<comment><USER17> > I can see that in terms of bandwidth, SPA can be more efficient then normal > HTML page. But this makes a few assumption. First, that your JS package > never changes. As soon as 1 character changes in your package, the cache is > invalidated and the whole package needs to be downloaded.

Sure, but there's strategies against this, right? Generally, vendor and 3rd- party code doesn't change often, so minify and stick all that together. Then, you've got your core application code, which you attempt to keep as small and fast as possible.

I will say, I'm not as experienced as the author of this piece, but at the end of the day I feel like the author is making blanket-statements that honestly don't hold up to the reality of what users actually want. I think it also makes assumptions about your stack, and your resources- yes, if you've got incredibly fast, top of the line servers, server-side rendered pages are probably a better idea, as the time difference between a json payload and the page being rendered by the server is much smaller.

On the other hand, even a cheap rails(ie slow) server with a CDN handing off the client code can shove some JSON out no problem, and it can do it _very_ fast, even the worst-off users usually only at 300ms for total receive time- a time which generally, is 100-200ms slower than your average server's render time of the page alone.

Furthermore, it lets you offload who is delivering said content- if a CDN is giving up all that Javascript, then the initial render times may actually not be that much slower than if it was server rendered.

\----

I also get the feeling a lot of people are making the mistake right now of assuming that because there's been a lot of evolution in the frontend framework world in the past 2 years, that it also means we're hitting peak performance, which couldn't be further than the truth. Angular apparently(I'm going off of what I've seen many say about 1.0 in the post-2.0 world) completely bungled performance the first time around, but it'll be better next year. Ember is already well on its way to being fast, and by summer of next year is going to be blazing quick with all of the HTMLBars innovations.

I think we're barely getting started figuring out frontend frameworks. Even if right now it may not be the best idea for your personal use case, I'd check back once a year until the evolution slows down to make sure you don't end up regretting not jumping in.

</comment></comment><comment><USER18> There are a few issues with these:

1) "Server-side rendering can be faster" \- the information in this part quietly ignores the fact that:

      * even if you have server-side rendering, you are still going to load external javascript/css files

      * browsers optimize multiple resource loading by opening multiple concurrent connections and reusing connections

      * you can and should use cdn (hence actually lowering the 'theoretical' minimum time)

      * browsers cache excessively - and you can make them cache even for longer

      * the fact that rendering on the server-side takes a lot of cpu and hence increases response time dramatically the more requests are made

6) while reloading the page when the code changes is a good idea, hot updating javascript is a really bad idea - beyond the fact that it's terribly hard, will most likely result in memory leaks in the end and as far as I know no one is doing it, it'll be extremely hard to maintain or debug.

The rest of the principles are quite true, informative and should be practiced more often (assuming you actually have the time to engage in these kind of improvements as opposed to making more features).

<comment><USER19> Just to nuance your 1) points about server side rendering, with pro-points :

• you only need html and css loaded to show content to your user, and js loads while the user is watching content, js has some time to be ready on first interaction.

• still feels slower than showing stuff with only html+css

• for pages content that changes a lot, if you rely on cdn for html pages, you need to update content with js on page load and you either ends up with a splash wait-while-we-are-loading or a blinking christmas tree.

• if your html is small enough, the cache checking round-trip is not that faster than loading content, while a JS rendering will need cache round trip AND data loading round trip. You can eliminate some html round trip with cache expiration, but at the expense of reliable deployments.

• still, JS rendering/update can be slower than server side CPU, especially on mobile devices.

<comment><USER18> There is a very simple way to get both maximum cache (without cache round trip, I.E. the ETag or Older-then) and reliable deployments - use version identifiers on the url and no expiration cache.

The only thing that the browser should always load is your base html, and have a single linked js/css that is concatenated and compressed, whose url changes every deployment - most web frameworks already have a way of doing it (Rails, Django etc...).

</comment></comment></comment><comment><USER20> Wow, the views counter... Haven't read the article yet, just astonished at the rate of increase...

<comment><USER21> Do you know how the counter works ? I am a JS noob. I see at the bottom of script he's updating the counter, but who is calling the update ?

<comment><USER22> It's a WordPress website that communicates with a Socket.IO server. I wrote about how to accomplish this here: [http://socket.io/blog/introducing-socket- io-1-0/#integration](http://socket.io/blog/introducing-socket- io-1-0/#integration)

It's true to the spirit of the post as well: the count gets rendered on the server, then reactive updates come in realtime and the view is updated.

<comment><USER23> Love your work, but the yellow flashes did encourage me to scroll that counter above the fold before I started reading. I get distracted easily.

</comment></comment></comment></comment><comment><USER24> > Server rendered pages are not optional

> Consider the additional roundtrips to get scripts, styles, and subsequent > API requests

If you're using a framework like GWT, it compiles all of the relavant css files, javascript, and ui template files, into one .html file. Then there's only one or two http requests to download this html file, and the server only has to handle requests for fetching data, updating or adding stuff, etc. You can also gzip + cache this .html file, to make it even smaller.

It runs lightning fast, too.

<comment><USER25> This isn't as awesome as it sounds. When inlining everything there is no control over the prioritization of resources. Large files like images can block the rendering of your layout giving the appearance of being slow even if the overall download time is less. HTTP2 has stream prioritization to solve this problem and is much more cache friendly.

<comment><USER24> > When inlining everything there is no control over the prioritization of > resources.

You can use split points to divide up your code, only the resources in a given split point are loaded. Example: If the user is viewing your 'Sign up' page, then only the resources for the 'Sign up' page will be loaded.

> Large files like images can block the rendering of your layout

Only small to medium files are inlined. Large files are downloaded as usual.

</comment></comment></comment><comment><USER26> Seems like a well-reasoned set of opinions at first blush. I'll have to give it more time to sink in for the most part, but the one bit that elicited immediate disagreement from me was the particular illustration of predictive behavior. There is unquestionably value in some predictive behaviors (e.g. making the "expected path" easy) but breaking with the universal expectations of dropdown behavior doesn't seem like a strong example to follow.

</comment><comment><USER27> Funny enough I've had to deal with many of these when implementing [http://platform.qbix.com](http://platform.qbix.com)

I pretty much agree with everything except #1. Rendering things on the server has the disadvantage of re-sending the same thing for every window. I am a big fan of caching and patterns like this: [http://platform.qbix.com/guide/patterns#getter](http://platform.qbix.com/guide/patterns#getter)

You can do caching and batching on the client side, and get a really nice consistent API. If you're worried about the first load, then concatenate all your js and css, or take advantage of app bundles by intercepting stuff in phonegap. Give the platform I built a try, it does all that stuff for you, including code updates when your codebase changes (check out [https://github.com/EGreg/Q/blob/master/platform/scripts/urls...](https://github.com/EGreg/Q/blob/master/platform/scripts/urls.php) which automagically makes it possible)

I would say design for "offline first" and other stuff should fall into place.

</comment><comment><USER28> For real-time updates _in response to user actions_ , which is a bigger concern: average latency, or its variance?

Example: Server generates a sine wave which gets displayed as a rolling chart waveform on the client. As client spins a knob to control the amplitude, the server-generated stream should change (sine wave is a trivial example, representative of more complex server-side computation).

<comment><USER29> The real-time updates he's talking about don't require server-side processing - the google homepage switching immediately to the search view for instance - that processing can be contained within the Javascript application, and state is simply maintained against the server (and then by extension across other instances of the application).

I don't imagine he's suggesting we try the same approach where server-side processing is required.

If I have misunderstood you then I apologise.

<comment><USER28> You're right, and your explanation helped me understand the article better when I read it again. Thanks.

</comment></comment></comment><comment><USER30> I really like the simplistic principles [http://roca-style.org](http://roca- style.org) defines for web applications.

I find single page applications way too complex. The amount of code duplication is horrific. So everyone ends up building platforms like GWT or Dart in order to hide that overhead. But that does not mean that things get simple.

(Maybe I'm getting old.)

<comment><USER31> I can see where you're coming from but I find that React (with node on the server and a RESTful database) eliminates a lot of the code duplication because I can run the same view rendering logic on the client and the server.

ROCA is an appealing idea, but my concern is that in order for the the-API-is- the-web-client approach (which ROCA as I understand it seems to advocate) to work you end up mixing two entirely separate levels of abstraction: what may be a good abstraction on the API level may not be a good abstraction on the UI level. It's sufficient if your web app is just an API explorer, but not every app lends itself to that.

You could say that then we shouldn't be building those apps, but that's simply not realistic.

</comment></comment><comment><USER32> A neat example is github.com. When browsing a repository it refreshes only the relevant part of the page. But the URL changes and can be used to navigate to a specific resource.

But as the article points out is often the case, at github.com the HTML loaded does not include the already rendered resource; it must be pulled in via a separate request.

<comment><USER33> The way GitHub works is pretty decent, but also pretty basic. It uses PJAX, so the HTML is still rendered on the server but the body content is updated.

It still has a few issues though, I work on flakey connections now and again and sometimes it just gets stuck - it would be nice if the request were retried automatically after a few seconds.

</comment></comment><comment><USER34> > "Server rendered pages are not optional"

I don't get this, in my opinion they are optional, you can show the ios png placeholder (shown in the next item) which is a very static and cacheable content, while fetching your highly dynamic data from a database or somewhere else.

It feels like the first principle contradicts 2, 3 and 4.

<comment><USER35> The solution you offer is exactly what server rendering is meant to stop. You should load content as fast as possible and that means rendering it on the server.

Please stop putting loading icons and spinners where your content should be.

<comment><USER36> I hear you on this, but the notion that client side is inherently a bigger download is kind of crazy, no?

Heck, if the concern is really about having lots of round trips, rather than server side rendering, you could have the server side stitch the client side components and still allow client side rendering. In fact, doing it that way makes it a heck of a lot easier to avoid reloading the entire page each time. Some kind of weird disconnect here.

<comment><USER35> It depends. I've worked at a company where the compressed and gzipped JavaScript file was over 1MB because there were multiple libraries being included for the use of one function.

That's obviously an extreme example.

Ultimately it's the engineer's job to make good decisions.

<comment><USER36> > That's obviously an extreme example.

No, I think that's missing the point. Sure it could be larger, but presuming you are trying to optimize the experience, there is nothing that would require doing it server side.

Why would the total payload needed to render the page client side _have to be larger_ than if it were client side? Unless you are talking about rendering an image with client side logic instead of sending a PNG/JPEG (in which case, sure, but that isn't what most people are talking about), I can't quite see it.

</comment></comment></comment></comment></comment><comment><USER13> Just one thing to point out: it seems as if a lot of your SPA arguments are predicated on the idea that apps don't chunk and/or stream their logic. While the front-end SPA framework I use is currently pretty bad for SEO, almost none of the download or latency issues are applicable...

</comment><comment><USER37> I think these are great ideals to strive for, but they seem lower priority than a couple things that they can get in the way of if you're not careful.

First, in your quest to show me the latest info, _please please please_ don't introduce race conditions into my interface. I don't want to go to hit a button or a key or type a command, and have _what that means_ change as I'm trying to do it.

Second, it's often important to me what has happened locally vs. what is reflected on the server (especially if that's public). Please _do_ update the interface optimistically in response to my actions rather than sitting and spinning, but please _also_ give me some indication of when my action is complete.

</comment><comment><USER38> "A slightly more advanced method is to monitor mouse movement and analyze its trajectory to detect "collisions" with actionable elements like buttons."

Is this a joke?

<comment><USER39> Read this: [http://bjk5.com/post/44698559168/breaking-down-amazons- mega-...](http://bjk5.com/post/44698559168/breaking-down-amazons-mega- dropdown)

for another useful example of this technique.

<comment><USER38> This is totally different and makes sense. You simply observe if mouse moves off within a certain angle to not make a submenu disappear. This is cheap and useful. It helps the submenu not disappear when you are moving to it, not having to move the mouse exactly along the tiny space that connects the two menus. This can actually save like 10 seconds each time (inexperienced users)!

The other one will ajax preload a dropdown content when it detects that current mouse trajectory is in line with it. Come on.

</comment></comment></comment><comment><USER40> When you are developing a web application for phone, tablet and desktop, is it a good principle to use the same HTML for the three and a separate CSS for each device? is there a case where this would cause problems?

<comment><USER41> It depends how this is setup. If you are using a template engine then I don't see why would this be a big deal if its a technical decision followed throughout the project. If you are not using a template engine and using Javascript to throw things around (like a bunch of Jquery piled on top of each other) then it becomes an issue.

Are you using any kind of server side framework (Like Django/Rails)?

Are you using any kind of client side framework (like Angular)?

Are you using any kind of layout framework (like Bootstrap)?

</comment></comment><comment><USER42> Can we first discuss design 101, i.e. don't put blinking elements in the user's periphery unless it's something really super important? The page view counter not being such a thing.

<comment><USER43> It could be something important. I don't know the exact intention behind this particular view counter, but consider for instance the scenario of using such a counter as an element aimed at enhancing credibility and establishing trustworthiness. You'd be more likely to read an article knowing it was also read by other 100K people, wouldn't you?</comment></comment>


Jelly - Casual work-together events - <AUTHOR> http://workatjelly.com/

<comment><AUTHOR> Originally mentioned by BobbyH here - <http://news.ycombinator.com/item?id=1438813></comment>


Backdoors in x86 assembly instructions microcode - <AUTHOR> https://webcache.googleusercontent.com/search?q=cache:SBqrRHx9IDkJ:https://weekly-geekly.github.io/articles/427757/index.html+&cd=12&hl=en&ct=clnk&gl=us <comment><AUTHOR> Excerpt:

"Do you still trust your processor?

The security of programs and operating systems is based on the security of the hardware on which they are deployed. As a rule, software developers do not take into account the fact that the hardware on which their software is deployed may be untrusted, harmful. When iron behaves erroneously (regardless of whether it is intentional or not), software security mechanisms are completely depreciated. For many years, various models of protected processors have been proposed: Intel SGX, AMD Pacifica, and others. Nevertheless, the enviable regularity with which information about critical failures (from recent ones, such as Meltdown and Specter) and the detected undocumented debugging functions — leads to the idea that our selfless trust in processors is groundless."

===END EXCERPT===

Phrased another way: If the hardware isn't secure, then the most secure software -- ISN'T...

Which relates to the User Agreement -- of every single social network, online service and website (Facebook, Amazon, Apple, Netflix, Google, etc.).

If they promise user privacy, then they promise user privacy based on their part of the software stack, which may comprise several or more vendors, and must include the underlying hardware.

If just one of those parts, such as the hardware, is flaky "a chain is only as strong as its weakest link" \-- then so is that guarantee, so is that CONTRACT that they made to their end-users... In other words, they are "guaranteeing" something that they cannot know to be true across all machines and configurations, and if they cannot know it to be true, they cannot guarantee it...

Which in turn may open them up to future class-action lawsuits.

Also... think philosophically for a moment... would these companies have became as successful as they are, if they would have advertised, in plain and simple english, on their user sign-up pages, something like "HEY, WE CAN'T GUARANTEE YOUR PRIVACY - Would you still like to sign up?".

And now think about stock prices, which exist as a valuation by a market given relative to the ability to keep and maintain profitability from users... would those stock prices have been the same had each company been up-front with its users from the beginning?

Corporate Integrity it seems, at least in this case, is contrary to profitability...

</comment><comment><USER2> never did trust a processor or IDE component, from the day i learned how to use them.

Whitepapers made me suspicious, the reserved words or bit values that where mentioned but not documented despite the parent function being extensively documented was one of the reasons.

the results of bit walking hardware instruction sets and trapping the resulting output states gave me cause to suspect things.

the long and short of it is digital hardware is not open source, and is not an operationaly secure platform.

The advent of microcode, was a major turning point, as processors were effectively wiretapped at that point. It was heralded as a way of fixing mistakes, post-production, so you could reprogram the microcode to do things differently. This puts the user in a very compromised situation, and is getting to be quite extensive as industry has gone beyond simple browser manipulations, and is actually reaching into the firmware that drives the hardware components, and manipulating systems out of band with the processor. The result is a compromised network of digital processors hosted on your mother board.

So what can we do when we design hardware? How about trap and dump? if a word shows up on a bus, a home rolled bus controller/hard wired analogue device could quench that word, [trap-dump] so any and all compromised digital components would not hear evil instructions, and would be muffled from issuing evil bus words.

The microcode is something that is usually an encrypted proprietary firmware, unless the firmware can be opened, understood, and manipulated, by the actual owner/user then evil commands and evil actions, must be censored from reaching in or out. a massive undertaking but well worth it.

ya all can start following the breadcrumbs here:

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

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

[https://people.cs.clemson.edu/~mark/uprog.html](https://people.cs.clemson.edu/~mark/uprog.html)

[https://securiteam.com/securityreviews/5FP0M1PDFO/](https://securiteam.com/securityreviews/5FP0M1PDFO/)

<comment><AUTHOR> Hi Rolph, great links!

You might want to check out this old HN article:

"MyCPU – Homebrew Computer from Discrete Logic Gates":

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

...and not just the link, the comments in that article are information-rich as well.

(There are several others in the same vein on HN, but I don't have them right now...)

Those CPU's typically don't use microcode, and are generally interesting from a hardware enthusiast's standpoint.

Hey, based on your previous HN comments and posts (Synchrotrons, Electromagnetic Propulsion, Plasma Physics, etc.), you seem like a pretty interesting guy!

If you want to have a longer conversation, why not email me at email@example.com ?

<comment><USER2> thanks P373 !</comment></comment></comment>


Google Has Dropped Google Instant Search - <AUTHOR> http://searchengineland.com/google-dropped-google-instant-search-279674 <comment><USER2> This is awesome news. It was always a pain to set up my search engine to have instant off - and of course instant turns back on if you performed a second search on the results page of the no-instant page.

I have _never once_ had my search experience enhanced by this anti-feature, and most of the time it's a hindrance, because I'll start reading the search results, then based on that come up with a new query and start typing it while continuing to scan the page. In non-instant world, maybe 60% of the time I'll end up finding what I want to click on as I continue to scan the page, then stop typing and click on that (or I'll be reading the name of someone that I want to google from the except from the page). In instant world, I have to read the whole page, decide if I need to make a new query, then type it (which is the exact _opposite_ of the intent of instant, mind you).

The worst thing about Instant was that if you started typing something that didn't have results it wanted to display (because maybe it was a NSFW-type query or because it just didn't have good results for the incomplete string), rather than leaving the old page up until it had something it wanted to show, it would just _blank the old page_. Horrible.

<comment><USER3> Yeah, I worked for Oyster (www.oyster.com) and had NSFW instant search issues all the time -- if I mistyped our site domain with two W's as "ww.o" the Instant Search results displayed a rather lewd image. Uh, sorry boss, that wasn't what I was after.

<comment><USER4> I wasn't even aware of this feature, sounds dangerous indeed to jump the gun and search for things as I'm entering the search. Search suggestions make sense, overly eager premature searches not so much.

</comment></comment></comment><comment><USER5> Looks like I'm in the minority here, but I really liked instant. I remember turning in instant from the omnibox in chrome, too. It showed that Google was at least willing to innovate in the search space -- and for some of us, it was a huge positive to have.

<comment><USER6> Yeah, I usually will start my Google searches in the Omnibox, then use the search bar on the page when I needed to find something new. In those use cases, instant is incredibly useful.

<comment><USER7> Man, do I hate the Omnibox with a passion. I wouldn't care so much if it wasn't the default.

<comment><USER6> Why don't you like it?

<comment><USER7> I hate the idea of moving elements around the entire window after I've started using them. I don't want to use the address bar as a search bar, but the overall problem is from a UX standpoint - you start typing into a textbox, and it vanishes/moves into the address bar. That's like starting to turn a knob on a door and your hand is suddenly somewhere else, like down near the bottom of the door or near the top. It's inconsistent and disruptive. It slows down the experience. I didn't come to the page to get tossed around everywhere, I came to search for something and get off of the page as quickly as possible.

And it moves the design closer to the horrible design creeping into applications today: instead of designing for every device, too many apps are designed for the worst platform, which is mobile. Capital One just redesigned their entire site for mobile, which added a lot more navigation/clicks for web users. That's just inferior design. Actually, it's not even design, it's just inferior hack layout.

We live in an era where original web page design was horrible, and somehow we continue to make pages harder and harder to use. There's a pervasive myth among app designers and startups to just 'remove' functionality instead of actually delivering _smart_ functionality. Simplifaction for ease of use is geat, but most simplification is just reducing an app to a single button and just makes real functionality harder to use. Omnibox falls into that trend. Make the search results better, get rid of spam, and stop spending even one second writing code to move the text input around inexplicably.

Good design should be invisible - I shouldn't notice it. Moving elements around after I've started interacting with them is just unnecessary annoyance with no benefit to me as a user. I don't want another crappy universal search bar, which is all this is. I just want to enter a search and move to the next page, so I can try and sift through the crappily selected results Google spits out. I already know Google's results are going to be poor enough I'll have to wade through them, why slow me down up front?

And so on.

<comment><USER8> This seems to be the "new tab/page" box which every browser does, moving from center of page to address bar.

You can easily switch to a different new page or use the address bar from the beginning.

<comment><USER7> I know that, because that's what I do. But my point is, I shouldn't have to know how to 'hack' around the browser just to use a textbox. That's really inferior UX design. I shouldn't even be thinking about any of that, I should be thinking about what the Google results are, not how to use Google.

<comment><USER8> What are you hacking around? Why not just use the address bar all the time?

<comment><USER9> then why putting an input area in the middle of the page with inviting prompt "search google or type url"? simple act of entering search terms and pressing Enter button - instead turns into a mental game of "if it is a brand new search, then search terms will appear in url bar no matter where i type them; when search results come, my search terms will be copied to the input box on the page and later can be edited there". sorry, this is just plain stupid. sounds like an executive design, no normal developer would come up with this crap.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Good riddance.

This was a marketing feature more than anything else so google could boast about how fast their search engine was. However, it always had tons of usability problems for no added benefit to the user, especially when refining a previous search, or trying to retype some funky word you found in the results.

<comment><USER11> Yes, part of it was marketing, but there were benefits, too, e.g. for slow typers, which of course do not abound in this corner of the Internet.

<comment><USER12> In my experience these slow typists also tend to look at the keyboard while they are typing - not at the screen. Thereby completely negating the benefit for this group of people.

I guess that for the intersection of slow typists who look at the screen while typing, Instant Search is useful. But how big is this intersection really?

<comment><USER11> You're right to some degree, but there were lots of user studies done. It was a net positive.

One of the amusing things was that users would follow the instant results without necessarily being consciously aware of them. I.e., when describing their interactions with prototypes, only a few noticed and pointed out that they were getting results without pressing Enter, yet a larger number clicked on them. It had to be pointed out to them, at which point they would often go "whoa". I remember a few non technical users who really raved about it.

<comment><USER12> I wonder if something clever could be done to automatically switch behavior over time based on keystroke timings, suggestion selection behavior, etc.

Maybe it would just end up feeling random and unreliable though.

</comment></comment></comment></comment></comment><comment><USER13> I rather liked Instant Search but it dawns on me that I hadn't noticed it's absence as I never go to the Google homepage any more. Searching from the address bar is all I ever do - and that doesn't seem to have changed.

</comment><comment><USER14> Wow, finally.

This was such a disruptive feature. Completely distracting from the moment you interact with the page. This wasn't a productivity bonus in any way, regardless of purported reading recognition rates and eye tracking/movement measurements.

No, computer. You wait until I'm finished. You wait until I tell you I want you to do something. You don't jump at every flinch of my fingers. Not all interactions require reaction.

<comment><USER15> Now if only they would stop swapping Images, News, and Shopping link around based on my search. I want a picture of whatever I searched for, that's why I clicked the button next to 'All' like I have a thousand times before - don't reorder your damn links from page to page!

<comment><USER16> Oh man, I hate that, especially when it pushes up Maps and relegates Videos to the "More" menu. Google tries to be way too clever for its own good.

<comment><USER15> Yep, that's the worst. Reordering static-looking buttons is awful, but promoting options in and out of a secondary menu is completely deranged design.

</comment></comment></comment></comment><comment><USER17> Meanwhile at google:

A: "We could save hundreds of millions in hardware resources if we disabled instant search."

B: "But we might lose money if we don't show as many ads. OH WAIT..."

The guy did a search and realized that the suggestion menu overlaps on the top of the page, where the ads are displayed.

He then tried to click the ad and he couldn't because the ad results changed the moment he moved his cursor away from the search bar.

It took them 7 years to realize their mistake!

<comment><USER18> I was intrigued that nobody was talking about the revenue effect of the removal of Instant Search. Obviously they did it because of this.

<comment><USER19> I'm pretty sure they turned on Instant Search in 2010 in order to serve more ads not fewer.

The extra load due to this feature was not insignificant. I heard it was the equivalent of an entire datacenter.

</comment></comment></comment><comment><USER20> The most annoying part is still there -- of the home page morphing into the search results page as soon as text is typed. It is a totally nonsensical design.

1) Type stuff into google.com 2) Delete all the text

You are now on a totally empty results page. Why is this a sensible design?

<comment><USER21> This isn't happening for me. Try it in incognito mode, maybe?

<comment><USER22> They already turned instant search off. Without instant search it doesn't go to a results page when you start typing.

</comment></comment></comment><comment><USER23> I hated the "instantness" of Instant Search but loved the keyboard shortcuts which seem to have disappeared. I used TAB and the arrow keys to select a search result and Ctrl+Enter to open the result in a new tab.

It is very, very sad that it is no longer possible to use those.

<comment><USER24> Yes to me it is insane that Google doesn't provide native keyboard shortcuts (at least make it an option) for the search results page. It is available on Gmail, Google Calendar, Google Drive, etc. Why not Google search??

</comment></comment><comment><USER25> Finally.

I completely hated how as I was typing I would change my mind and decide maybe I did want to click on a link only to see it instantly disappear. Then the back-button didn't work as expected, so I just ended up having to re-type my query.

Every time.

<comment><USER26> > having to retype my query

Especially annoying when testing multiple queries to find the optimal one and you decided that a query of 3 submissions ago was the most effective and you couldn't remember it precisely.

</comment></comment><comment><USER27> I loved this feature! This makes me sad. It really shouldn't be a big deal to let people enable it for their own accounts or to just disable it for mobile. I don't see the benefit of just getting rid of it completely.

</comment><comment><USER28> Thank God.

This feature has been the bane of my Google existence. I often want to hit backspace to go back a page, but because their search bar steals my focus, I instead remove a letter or two and perform a search again.

I have never, not once, found this feature to be useful. Who doesn't type faster than they can read a page of results?

<comment><USER29> Removal of instant shouldn't change the behavior of the search bar's focusing. I haven't noticed what your'e talking about, though.

<comment><USER30> They have appeared to have implemented disabling instant search by simply reverting all post-instant search antifeatures:

No instant search

No steal focus on result page (and thus, no breaking backspace)

No overriding arrow key scroll into weird blue-arrow modal UI

Basically 2010 era google, all at one stroke.

The result quality is still kind of meh though.

</comment></comment></comment><comment><USER31> So "I'm Feeling Lucky" is a real and clickable button again!

<comment><USER32> Would have been before, too, if you had JavaScript disabled, wouldn't it?

But yeah, that is interesting. They supposedly lose/lost a lot of money from that button, as it skips past their ads.

Also, they are supposedly redesigning the Google Homepage [0], moving away from having just the search field there to having a news feed, the weather and some such there as well.

So, maybe this change is in anticipation of that and maybe they'll also tuck some ads into there then, to actually monetize the time people spend on their homepage.

[0]: [https://www.theguardian.com/technology/2017/jul/20/google- ch...](https://www.theguardian.com/technology/2017/jul/20/google-change-home- page-first-time-since-1996-app-based-feed-news-events-sports)

</comment></comment><comment><USER33> Instant search was one of the reasons I moved to DuckDuckGo. Google could learn a lot from DDG. There's so many actually usefull features on the results page that now I feel lost when I'm using Google.

</comment><comment><USER34> Good. This was their most useless and wonky feature. Not sure how this was supposed to change search.

<comment><USER35> Yes, this feature had negative value for me. A common use case is that I'm copying keywords from search result snippets back into the search bar to make a more refined followup search, and Instant Search snatches the result away while I'm trying to copy text from it.

<comment><USER36> This is exactly what drove me crazy about it.

</comment></comment></comment><comment><USER37> Does anybody really look at the Google home page any more? Browsers and mobile devices all have search boxes now. Bing tried putting good artwork on their home page, and nobody noticed.

Google's "robots.txt" file doesn't let bots read their home page. Most other pages on Google are bot-readable, but not the home page. It's like they don't want it to be indexed by other search engines. That might change once it gets content.

<comment><USER38> I noticed the art. :)

I thought it was funny because they touted how relevant their search results were then blasted you with seemingly random pictures.

</comment></comment><comment><USER39> I had Instant Search on for just one reason: movement with arrow keys. Since they killed it's bothering me, I hope they bring at least this option back. If not does anyone else has a solution?

<comment><USER40> This. Having to switch to the mouse just to click the first or second search result on the list is going to be really annoying. I hope they bring the keyboard shortcuts back.

</comment></comment><comment><USER41> Suddenly, I can no longer navigate between results using Tab -> Arrow Up/Arrow Down.

Was this removed as well? :-/

<comment><USER42> Oh Lord - hijacking the arrow keys, which I use for page-scrolling, is one of the most annoying things ever. Kill it with fire!

<comment><USER8> It's a list of search results - why scroll when you can directly pick the result?

<comment><USER43> In Firefox I can hit / or ' to type the link I want and hit enter. When sites mess around with keyboard shortcuts it makes my browsing experience inconsistent and disorienting.

<comment><USER8> That's a very slow and technical way but you can still do that if you want.

<comment><USER43> I wouldn't describe it as slow. Rarely need type more than a few characters and I don't need to count.

</comment></comment></comment></comment></comment></comment><comment><USER44> I think this feature might have helped people who are slow at typing.

May be off-topic, but I remember an incidence from Home Depot when I asked a staff member to look something up for me. She pulled up a browser (think it was IE), typed google in the nav bar (perhaps to get to google.com) and got the bing search result for search term 'google'. Then she continued on to use the bing search to look for Home Depot's site (I assume she was thinking she is searching on Google).

I didn't get what I was looking for, but I did leave wondering about use-case or user interaction scenarios like this that I would have never thought of.

Yeah, I think that Instant Search must have had its value for people, even if not much for me.

</comment><comment><USER45> While we're at it, how about bringing back the search box at the bottom of the page, too?

</comment><comment><USER46> Auto complete is already an awesome feature to have, instant search is clutter, it creates too much traffic, and sometimes it doesn't work (nothing shows for a while).

Now it would be nice if google would stop choosing french as a search language because I live there, I have to set it up everyday and I don't want to enable cookies... I don't know if I can access google with english as default in some special page.

<comment><USER47> Have you tried using google.com/ncr?

</comment></comment><comment><USER48> Does this mean we can regain the backspace-to-go-back that's been everywhere since forever, but was killed by Chrome because of instant search?

<comment><USER49> IIRC backspace-to-go-back was not killed because of instant search, it was killed because users kept going back when they didn't mean to, because they thought they were typing in a text box and weren't.

<comment><USER50> There's still e.g. [https://chrome.google.com/webstore/detail/backspace-to-go- ba...](https://chrome.google.com/webstore/detail/backspace-to-go- back/nlffgllnjjkheddehpolbanogdeaogbc?hl=en) but IMO it's ridiculous to not just make this an option. Hide it in a flag. [https://venturebeat.com/2016/08/14/restore-backspace- shortcu...](https://venturebeat.com/2016/08/14/restore-backspace-shortcut- chrome/) they decided that 400k users was not enough to warrant a flag for.

But hey, cmd+q to quit immediately, with "warn before quit" off by default is a great idea. No need to look at that one or make it possible to change the key bind. Never mind that it's one key away from cmd+tab.

This is the kind of stuff you get when you make decisions based on A/B testing.

<comment><USER51> There's a hack to sort-of disable the keybind: Go to chrome://extensions/ and open "Keyboard Shortcuts" (bottom right). Pick an extension you don't use anymore (or install one), and set the shortcut for "Activate the extension" to cmd+q or ctrl+shift+q.

</comment></comment></comment></comment><comment><USER52> I didn't mind it, but I wont miss it either. I usually end up typing my whole search as a matter of "my brain sent these words to my fingers and my fingers are going to type until they are done" kinda thing anyway, so it was a wasted feature

</comment><comment> amiga-workbench Never found this particularly nice to use, at least this will drop their server load a bit.

<comment><USER53> I'd be interested to see if this is actually true.

<comment><USER54> Whether it is actually true is going to be entirely based on what you consider to be "a bit" of server load.

They had to return data for many search results on entry, in addition to suggested autocomplete. Now they just return suggested autocomplete. I'm sure everything in google instant is served from a cached cdn, but it's still going to be "some" server load that is removed.

</comment></comment></comment><comment><USER55> [https://google.com/webhp?complete=0](https://google.com/webhp?complete=0) still works for me. No instant, no suggestions, just type and press enter.

</comment><comment><USER56> I suspect this has more to do with recent European regulations than anything else. Instantly sending search queries without [explicit] confirmation is a minefield of liability for the company.

</comment><comment><USER57> God, instant search was such a pain. So much in fact that instead of typing anything into Google when it was on, I used to type it out in Notepad or another editor and paste that into the box instead. Just found it incredibly distracting otherwise.

Nice to know they've gotten rid of it.

</comment><comment><USER58> Why did they drop it exactly? How does removing it makes search "more fluid on all devices" (according to TFA). I'm not complaining, but I suspect the attention bandwidth now left on the table is going to be plastered with something else soon enough.

</comment><comment><USER59> This way always a bad idea, and I imagine the excuse of "now more users are on mobile" is just there to protect Marissa Mayer's reputation. You should be able to reference the results on a search page as you type your next search.

</comment><comment><USER60> Did anyone else notice they reduced the number of autocomplete fields from 10ish to 4? I really dislike this change for discoverability reasons.

Is there a way to change this?

</comment><comment><USER61> Did the auto search terms contribute to things like Google trends? like half finished searches effecting popularity of an adwords search phrase or similar?

</comment><comment><USER62> Dang. Now I don't have a legit excuse for pausing to view the results for NSFW prefixes of SFW search terms. Ex: _sex[tant]_

</comment><comment><USER63> This feature was never useful. Not to mention wasted bandwidth. Glad it's dead. Just give me simplicity.

</comment><comment><USER64> The article web site crashes Chrome.

</comment><comment><USER65> I won't miss it, I disliked searching when I found my result with partial word and see it for a split second but lose it as I finish typing the word, not reacting quickly enough. Having to backtrack character by character to find it was frustrating. I'd rather just click "search" and not have to deal with the letter by letter tweaking.

<comment><USER66> 'Tis better to have loved and lost than never to have loved at all.'

I honestly cannot understand your sentiment, how can knowing something you are interested in exists be worse than not knowing at all?

</comment></comment><comment><USER67> Glad it's gone. Probably it's more about energy saving and DC optimization.

</comment><comment><USER68> Good. And now stop changing Google. I don't want to be surprised every time I use your tools.

(Edit: And that holds for the doodle too. They are sometimes funny, but not so much so as to warrant making me lose focus. I'm working, not watching TV)

<comment><USER15> My least-favorite change is that the All/Image/Shopping/News buttons on the search page rearrange based on your choice of term. Static-looking features shouldn't shuffle themselves around based on my form inputs!

(It's _worse_ because I've never wanted the Shopping button, ever, but it's bad design regardless.)

</comment></comment><comment><USER69> Finally! I always felt this feature was weird and abrupt.

</comment><comment><USER38> Well there goes an entire category of meme. RIP internet.

<comment><USER70> The search suggestions are still there, so the various memes around "why do ..." still work. The part that's been removed is that Google Instant used to start showing you the results page as you typed, before hitting enter.

<comment><USER38> Ohhhhh. I misunderstood. Thank the lulz gods.

</comment></comment></comment><comment><USER71> On the topic of annoying Google features, did they recently make it so that links to search results opened in new tabs? Is that a feature that one can turn off? It's eating up my iOS tabs!

</comment><comment><USER72> i used instant search to simply see what other people search, laugh, then proceed to finding whatever i want to find by searching myself

</comment><comment><USER73> suggestions are awesome - instant results, less so. overall, a good choice.

</comment><comment><USER74> Poor Mayer ..

</comment><comment><USER75> I hated, thanks

</comment><comment><USER76> The reason, Google wants to display some content (cards with news/trending topics) on the Google frontpage.

</comment><comment><USER77> Please drop support for google AMP or make it optional. Half of the Indian mainstream media is not available on it.

</comment><comment><USER78> Whenever I see "Google Instant" reference, I get always chuckle because I swear that two of my friends and I actually invented it back in '09 for a Yahoo sponsored Hackathon.

I clearly remember one day logging onto my machine, going to google to search for something and just sitting there with my jaw on the ground as the "instant" feature began searching as I typed. I must've sat there for at least 5 minutes. I then proceeded to call my friends and made them go to google to "just execute a query". The response was "those motherf _& kers actually ripped off our idea".

I will say, while the idea was "new" (no one was doing it at the time as far as we were aware of), the hackathon code was pure garbage PHP and JS fueled by free pizza & soda and stitched together to leverage the Yahoo APIs.

We went back and actually looked at our server logs (it was running a .edu/students/ site at the time as part of our portfolios) and noticed SIGNIFICANT traffic spikes from Google & MSFT registered corp IPs. Unfortunately, we figured there was nothing we could do to prove that _we* invented it.

Something for you to chuckle at:

\- Only reference I could find is a wayback link to the 2009 hackathon page ("Skynet Search" was also 'contextual' and knew if you wanted images or maps or directions without having you to make extra clicks). There used to be a blog post mention on yahoo as we got some runner-up prize. [1]

\- Google Instant Launched Sept 2010 [2]

[1] [https://web.archive.org/web/20091024035258/http://developer....](https://web.archive.org/web/20091024035258/http://developer.yahoo.com:80/hacku/show/2009/feb/washington) [2] [https://www.google.com/doodles/google-instant- launch](https://www.google.com/doodles/google-instant-launch)

<comment><USER79> I had instant search on documentation files in ... 1991.

And I'm fairly sure I wasn't the first to think of that either.

Just because you think you think of something 'first' doesn't mean you really are the first and doesn't mean that your idea is being ripped off by others, most likely they were totally unaware of 'your' idea, just like they were unaware of mine.

Most of these are obvious anyway.

<comment><USER78> Fair enough.

</comment></comment></comment><comment><USER80> >Google Instant launched in 2010 under the leadership of Marissa Mayer. Mayer called this change a "fundamental shift in search"....

So Mayer does it again, lol. My favorite thing is how this lady was praised as some sort of genius for managing the Google search page - as if that page is some marvel of modern engineering and not just a webpage with and input and no background.

<comment><USER81> Hm, let's not have personal attacks here, especially for a topic on which you do not have any personal experience.

Having worked on Google Search during this period, I can say definitively that your comment is mostly incorrect. Features at Google are generally bottom-up driven. Mayer was in many ways acting as a gatekeeper to keep some of the crazier stuff from harming the experience or brand.

<comment><USER11> Well, there was a lot of bottom-up work, but in this case Instant was pushed by Marissa. A lot of infrastructure had to be built, scaled and tuned before launch, so that the demos could actually serve the millions of users, their wonky browsers or ISPs, etc.

<comment><USER81> I agree that she supported the launch, but Marissa wasn't involved in any of the infrastructure work, machine planning, etc.

<comment><USER11> Of course she wasn't involved in making things work efficiently and reliably, since that never was her responsibility, but the whole reason all of that had to happen was because she decided to turn what normally would be one of the many, many cool internal demos into a public, differentiating feature (and got signoff from upper management). I'll miss Instant on desktop, for the record. It was a great achievement to implement in a relatively short period of time.

<comment><USER81> I think you're being slightly unfair here in assigning credit/blame/what-have- you.

I agree with you that she liked it, and signed off on the product. However, we had to scale the infrastructure 7x. That wasn't a VP level of money, that was a BoD level of money. The decision to push the launch was made by Eric.

<comment><USER11> I wouldn't quote numbers (or multipliers) here, but my recollection is that, after a lot of tuning, it was lower than what you mention, at least in the section of the stack that I was involved with. Of course, the board had to give some kind of sign off (which is what I meant by upper management), before even knowing the full price :-), but the case for this differentiating feature was being made by Marissa. It wasn't merely signing off. I don't remember anyone ever bringing up Eric when talking about it. If anyone, it was her, for good or for bad. She stuck with it even if early iterations were clunky, slow or inefficient. I'll grant her that she started with something that I thought unfeasible and almost a pipe dream, eventually seeing it turn into something actually useful, with the help of hundreds (Eng, PM, UX, etc.).</comment></comment></comment></comment></comment></comment></comment>


Ask HN: Programming More Efficiently? - <AUTHOR>

I've been programming for a few years now, and I've written a lot of code, but there are times that I want to write quality code 2 or 3 times faster. I do my best to keep my workflow straightforward, eliminate distractions, and stay focused on my tasks, and I get quite a bit done each day but the more I can do, the better, right?
I'm wondering if any more seasoned developers have good advice for me, as far as improving my workflow, and coding more efficiently? I use Vim, and am trying to improve my muscle memory for operating on code. Any vim user tips? At what intervals should I take breaks from coding? Should I stay away from developing on the weekends to let my mind rest? Should I keep working on weekends to keep my brain active? At times I have to switch projects and work on something completely different, sometimes even in a different language, and that seems to throw my mind of for a few minutes. Is there anything I can do to make the process of switching projects easier? Is it normal to be thrown off by an abrupt project-switch? Sometimes I have to do 2 or 3 projects concurrently, and I end up having 2 or 3 bash windows open with different projects in each one. Should I try to just work on one thing at a time?
Thanks for any advice, I'm just trying to improve my developing habits and consolidate my workflow into something that's as efficient as possible. Any advice from seasoned developers would be awesome! <comment><USER4> The only reliably effective way to improve quality and reduce time is to practice. This does not mean, however, that you should burn yourself out. Apply common sense: don't do something that is making you hate doing it. Only do it when you can afford the time, and not at the expense of your sanity.

Aside from that, the only thing left to do is to minimise your unproductive working habits. The whole 'Vim is faster' thing is just a distraction - <USER2> can be 'fast' in a million and one different setups - the point is that if you pick a particular setup, you should learn how to use it. Learn the shortcuts and the tools available. This is just common sense. You don't learn to drive through trial and error - you know what each action you make is going to do before you do it. Read the manual.

Personally, I find that the best all-round way to improve my code quality and efficiency is to read for pleasure. Whether it's books or blogs, it doesn't really matter much to me. I find that when I have been reading, I can think more clearly about problems. I can spot ways to abstract problems far more easily, and I can express my ideas more coherently. Additionally, talking through a problem helps me a lot. Even if I am just explaining the problem to somebody who is not contributing anything to the solution - the mere act of being forced to provide an explanation can often highlight the solution far more quickly than if I had just sat in silence trying to figure it out.

For me, the workflow is about minimising unproductive habits rather than improving efficiency. The real test is how quickly you can identify the solution to a problem - the task of actually writing the code is something that is left to individual tastes and preferences. In all things - <USER3> first, act later :)

</comment><comment><USER5> Some general tips for improving workflow: \- within a specific file/project, try to recognize places where you are retyping the same (or very similar) code blocks repeatedly. try to pull those out into a function to avoid redundant code and typing

\- try to recognize code structures that you are typing repeatedly across projects, and see if you can make snippets that reduce the number of keystrokes and time needed

\- if you are performing the same action multiple times, try making a macro

\- get familiar with the keyboard shortcuts for your editor of choice. Try to do as much without the mouse as possible

\- for whatever editor you use, do a bit of research to figure out what good plugins there are that might help you. for example, if you write a lot of HTML, you could benefit from the emmet plugin (zen coding).

\- try out a lot of apps. If you think "there should be an easier way to do this", then there probably is.

\- avoid shortcuts that sacrifice quality for convenience. doing something quick and dirty will often just create more work for you later.

\- don't ever make mistakes. or, if thats not possible, have a plan for debugging.

</comment><comment><USER6> I definitely block out my time for projects and work on one thing at a time for a day or two if I can. Task switching can be expensive, but if you have some state saved outside of your head/computer, it can help jog your mind when you want to come back to the task. So I keep a (paper) journal of things I'm working on.

Coding is all about the mental work, so if you can keep your mind sharp it is good. Get enough sleep and devote some time to learning new things that are beyond (more difficult than) the work that you do. Getting better is all about challenging yourself.

</comment><comment><USER7> One thing that has helped me when moving back and forth between projects is to use screen (you may prefer tmux) to wrap up particular contexts, having my bashrc set things like my history file based on a single variable. Just keeping history from getting mixed up helps a lot, I find, but it also gives hooks for other bits of tweaking (aliases and such)

</comment><comment><USER8> Is this question about programming more efficiently or managing your workload more efficiently?

I would definitely suggest working on one thing at a time. If you have multiple projects, just timebox them. 3 hrs working on project A, 3hrs working on project B (or 1 day working on project A, 1 day working on project B, etc).

<comment><AUTHOR> It's really a question about improving my workflow and improving my programming habits, in an effort to product quality code quickly.

Sometimes I'll get pulled onto different tasks abruptly and I don't really have a choice of when I get to switch, it usually happens only four or five times a day, so it's not a huge problem but it does interrupt the blocks of time I try to spend on other larger projects. I'm just wondering if there's any way to make the process of switching between projects easier?

<comment><USER8> I would suggest taking copius notes and using writing documentation to get over the switch.

For example, when I get started on a project, I normally sit down at my computer and surf the internet for maybe 20 minutes and play around in the command line. This "down-time" helps me get into the flow of things. Plus I normally try to avoid tight-deadlines so I don't really care if I spend 20 minutes dinking around on Hacker News.

If you have a similar work-pattern, maybe those 20 minutes could be spent instead reviewing a README.md or working on a Trello board, or adding new links to an internal wiki you've set up for the project.

I've found that touching the documentation that I've created really helps me snap back into a project since I can see exactly where I left off. And if I don't know what to do, I work on planning out the project.

Also, if all of a sudden I have a great idea of what to do, I'll spend half and hour or so making files and directories and writing the code entirely in comments. Then, when I come back to the project, it's only a matter of replacing the comments with real code.

</comment></comment></comment><comment><USER7> As a vim user, I have found a lot of benefit pushing my compiling and tests into a form where I can run make from inside vim, and get errors in a format vim understands (filename:line: error).

Edited to add: and learn your way around copen, cbuffer, cnext, cprev</comment>