Looks pretty good in the immediate area: http://www.walkscore.com/score/253-ne-2nd-st-miami-fl-33132
2,736 karma · joined February 19, 2010
I suppose it depends on your definition of "suburban". Each one of those cities has a bona-fide city center and nearby residential development dense enough to allow a very walkable environment. It's a lot worse in many places back east including my area.
And, the idea of the target funds is that they become more conservative as you reach the target. The pure index funds do not. So they are basically index funds with portfolio rebalancing.
https://institutional.vanguard.com/VGApp/iip/site/institutio...
Ad injection - Putting ads on web pages they didn't write, such as Google search results.
Ad substitution - Replacing ads on web sites with their own ads.
Cookie stuffing - Injecting or clobbering referral cookies for sites like Amazon so that they get an undeserved commission on things you buy.
That's total garbage. The browser does awesome presentation and layout with the markup you give it and you can control what happens via declarative CSS. VB6 couldn't even make a dialog look nice when you changed the system to Large Fonts.
Silent failure? You must have forgotten `on error goto 0`.
The advantage of this approach is that if you decide you need more of jQuery (for example to support a plugin) you can pull in what you need rather than reinvent and debug your own.
For example, processing power, communication speed, and storage has improved by orders of magnitude, but battery capacity is perhaps better by one factor of ten. Much of the advance in battery life comes from reduced power consumption by other components. Much of the advance in software development has come by creating inefficient abstractions that let us create things faster but squander CPU, network, and battery life.
Most companies today are willing to burn up some hardware performance in order to reduce software development time. If they're burning too much, they'll fix it or they'll go out of business. Premature optimization is still not a good idea.
The `yield` calls are definitely simplifying the no-errors case, but it looks like any of those yields can throw an error back to the enclosing function. All the errors from all the yields end up in the same function? If you care about some or all of them and want to tell where the problem occurred, you'd need to wrap each `yield` in a try/catch?
For example, many infinite-scroll pages add a small amount of content to the DOM and then ask, "Did I fill the page enough?" by asking for the new height of the page. Each time they do that it requires a reflow where the browser recalculates the height of the page. When the added content is small it may take four or five trips through this loop to feed enough content into the page. A better alternative performance-wise would be to make each chunk of added content a fixed height. That way it's easy to do the math inside your own code, add four or five chunks, and the browser will do a single reflow at the end.
If you look at the "flat" designs that are becoming common in operating systems and apps, they perform well in these situations because they are very regular and easy to compute. Things like rounded corners, transparency, and drop shadows all make pages slower to render.
That sounds dangerously like premature optimization. For example, why spend the time creating optimized image sprites if it turns out they don't contribute significantly to load time? It's better to spend development time doing something else.
> And that's why the internet is full of massive, bloated, slow web pages. Single decisions don't cause bloat. Bloat comes from a slack attitude towards efficiency.
By using the word "bloat" it sounds like you're talking about bytes. Again, byte counts often aren't always the main culprit in slow loading of web pages. Synchronous scripts and/or 302 redirects can be much worse, for example. Don't start with the premise that the bytes are the problem and do a lot of work to reduce them, only to find out it isn't the problem. Profile the page load and see what is really the problem. Then fix that.
I see a lot of discussion here based on the premise that this smaller script will make a big difference in overall page load time. It's why the audience in that video was leaning towards the site with the most JavaScript being the slowest. The first benefit listed on the minified.js page is "Minified is smaller!" so exactly what benefits does "smaller" imply?
> The only people who would possibly be interested in this project are people who are attempting to optimize the experience their app provides, presumably in a holistic fashion.
I agree, and creating your own homebrew framework for a large project in a holistic fashion has its own pitfalls. Especially if you've never done it before.
api.jquery.com/on/#direct-and-delegated-events
> Delegated events have the advantage that they can process events from descendant elements that are added to the document at a later time. By picking an element that is guaranteed to be present at the time the delegated event handler is attached, you can use delegated events to avoid the need to frequently attach and remove event handlers. This element could be the container element of a view in a Model-View-Controller design, for example, or document if the event handler wants to monitor all bubbling events in the document. The document element is available in the head of the document before loading any other HTML, so it is safe to attach events there without waiting for the document to be ready. ... In addition to their ability to handle events on descendant elements not yet created, another advantage of delegated events is their potential for much lower overhead when many elements must be monitored.
Well my answer to the credible question is that jQuery has to normalize and fix bugs for just about all the browsers it supports, it's not just an oldIE problem. Plus, jQuery provides abstractions above the basic DOM operations which are pretty low level. So if you don't want to use jQuery you'd probably want some other library to provide equal or greater abstraction.
> Quite outside of the time to download, there is a measurable cost to parse all of that boilerplate code as well. This has more of an impact on mobile, obviously.
Measurable of course. Significant as a portion of the page load time for most pages? Well that's a different thing. And of course if you want it, jQuery 1.8+ provides the ability to create custom builds if you know you don't need parts of it.
Look at this video at 6m30s: http://channel9.msdn.com/Events/Build/2012/3-132
Productively optimizing a web page is no different than optimizing any other code. If you want to know why a web site is slow, profile it or run it through a tool like webpagetest.org. Don't just set off to rewrite all your loops to run backwards, or eliminate function calls, or reduce the amount of this or that without any understanding of the result.
Agreed, although I always thought the sticking point for SWA was paying commissions and not data access. For a sample search from BWI-SFO their price was only about $20 more expensive than the lowest fare ($520).
If you listen to Bill Gates speak, he honestly sounds like someone who believes what he is saying and backs it up with money. As a rich man he certainly has other options. He can give a hearty "fuck you" or even a dismissive "I don't care" to the world and take his money to do whatever he wants. You know, like Larry Ellison or dozens of other people who've made their fortunes off the public.
So this is "accepted": https://github.com/scalatra/scalatra/pull/267
But this is not: https://github.com/jquery/jquery/pull/1255
Yes, and just like the strings case it shows how useless most primitive types are from a program correctness and documentation standpoint. Languages like C++ and Java encourage programmers to treat them as mystical bags-of-holding and forget about their limitations or relation to the data being processed.