mtrpcic

18 ms·

1. 151.▲
   by mtrpcic 12y ago

   https://github.com/firebug/firebug/tree/master/extension/ski... Look for firebugBig.png and firebugSmall.svg. I _think_ those are the files.
2. 152.▲
   by mtrpcic 12y ago

   I thought that as well, but then I realized that there are some other fairly large benefits to the touch screens, namely the ability to change the entirety of the controls when needed. If something goes wrong, the entire control panel can
3. 153.▲
   by mtrpcic 12y ago

   Thanks for someone pointing this out. There are a lot of places in the code that could use some cleaning up. The overall frontend code structure is a little lacking: * There's a "main.js", and a bunch of empty .coffee files
4. 154.▲
   by mtrpcic 13y ago

   I agree with this. By inlining all the JS and CSS, you lose the entire benefit of the browser cache, making each HTTP request for a real page a lot larger.
5. 155.▲
   by mtrpcic 13y ago

   I think part of the problem is that Chrome uses a branch of Webkit, and combined, Webkit has a huge majority of the market share (Safari, Mobile Safari, Chrome, Mobile Chrome). It's a clear winner for "first target", but I a
6. 156.▲
   Show HN: Phonebook.js, a lightweight API wrapper to clean up your $.ajax soup(github.com)

   6 points by mtrpcic 13y ago|1 comments
7. 157.▲
   by mtrpcic 16y ago

   The article makes mention that the example doesn't use the HTML5 History API, and that the onus is on the developer to check for and use that as appropriate.
8. 158.▲
   by mtrpcic 16y ago

   That's why this approach isn't for everyone. To each his own. One thing to keep in mind, however, is that the approach is meant more for projects that can be thought of as "web applications", rather than websites; things that would requir
9. 159.▲
   by mtrpcic 16y ago

   That's the thing. When you're making something on the web, you need to define to yourself whether it's a Web Application or a Web Site. The hashbang approach lends itself very well to the Application side of the browser.
10. 160.▲
    by mtrpcic 16y ago

    That's a good point. The big issue is loading the "Heavy" part of the DOM every time (navigation links, header/footer, user panel, etc), rather than the real "content". I'll make an edit and make that a more prominent point. Thanks for t
11. 161.▲
    by mtrpcic 16y ago

    It's true that the caching argument seemed contrived (and was, in a sense), so I've added an edit to it to take your comments, as well as others, into consideration, and to make them known to other readers. Thanks for the feedback.
12. 162.▲
    by mtrpcic 16y ago

    I agree, and that's kind of the point I was making towards the end. You need to know what your target audience is, and whether or not those are issues you might face. In either case, if you have a "DOM Heavy" application, you can still sa
13. 163.▲
    by mtrpcic 19y ago

    I would suggest setting up a website (nothing fancy, but enough to get the message out) that had your ideas, show transcripts, etc. It would also be beneficial to get some shows out on your own through YouTube. You might find that you don