Hi folks.. Just wanted to share with ya'll that my better var_dump() for PHP, htmlMicroscope, has been out for a few weeks now. I don't normally post updates to forums when I've created a new version, but this time it's warranted, because I've finally cracked the barrier that prevented any browser from showing objects with more than a thousand keys on a single level from being shown without freezing the browser. The whole thing is almost ridiculously asynchronized now. I'm very proud of my coding efforts. I cracked this puzzle myself Anyway, without further ado, I give you; http://fancywebapps.com/products/htmlMicroscope
Wow, that has to be the most annoyingly slow loading filled with stupid animated garbage that has no business on a website with inaccessible illegible color contrasts in uselessly undersized fixed metric fonts I've seen since... since... since someone made a site on purpose to make fun of all the things that don't belong on websites. As to the tool itself (that I'm not even sure I'm seeing on the page you linked to) -- sounds to me like you've made an overcomplicated mess to make the equivalent of echo '<pre>',print_r($var),'</pre>'; But again the page is so filled with illegible color contrasts and illegible fonts, with endless pointless scripting for nothing I'll be buggered if I can find anything of value there... or have the patience to wait for the goofy fade in animations on every blasted link. Hard to take your project seriously with that unmitigated disaster as the website being used to present it.
So, unwanted troll, you think you know everything better than everyone eh? At the very least you're insulting a gift horse.. And I'd add you fail to see the frigging genius of either my framework (which is SLOW because it's intended for high-bandwidth environments like fiber-to-the-home), as well as the fact that with htmlMicroscope it is a heck of a lot easier to plough through really big arrays, which you could then use to make apps that put much more information (than before) in a single nested array/object, for ease-of-overview. But then again, you got it all figured out eh? Your road to Rome is the only road worthy to be travelled? You sound like my programming teacher in technical school. He also didn't know how to code. Take another look at the code that makes up htmlMicroscope, specifically the JSON decoder that doesn't use eval() and can decode asynchronously or synchronously, depending on what the application developer wants. Then you might start to see that this is indeed a cool component. But as a general rule for you: don't troll, don't look a gift horse in the mouth. Nuff said, fool.
@rene7705, he seems to enjoy ranting. I wouldn't take it too seriously or expend any time on him. All the best with your product, mate!
1) not sure what async/sync has to do with a JSON decode... do you mean it starts working on it before it's finished loading? That could be semi-useful if you had packet level control of the data; too bad neither PHP or Javascript support such methods of accessing data unless you're wasting time brute force adding such a thing -- which would probably take longer and so much code it would be slower than just waiting for the server or browser to just grab the whole thing. 2) not sure what an eval would have to do with a JSON decode unless you're doing it client-side... since PHP has a perfectly good JSON decoder built in... in which case why is this in the PHP section? 3) Fine, call it trolling if you like -- god forbid someone points out to you what a useless train wreck the site it's on is -- if you don't know what's wrong with your website, I pity anyone who is duped into using anything you've written there. Illegible text colors (much of which is the transparencies fault), illegible font sizes (it's all PX), layouts that are useless on anything less than 2560x1440, splash screens, annoying slow animations, painfully ugly use of fade-in effects with the 'scripting for nothing' page-loads are evil "dodge", broken unusable cascading menu (likely from using javascript to do CSS' job), tables for layout, incomplete/malformed tables, span doing headings job, single TD per TR tables (at which point there's no legitimate reason to be using tables), iframes, nothing resembling sensible use of heading tags (so kiss off heading navigation), XML properties on HTML in a 5 document (as if you wrote it as the non-deployable 1.1 and swapped just the doctype)... ... and then you have the chutzpah to say your teacher didn't know how to code. If true, it's reflected in your work.
Oh boy. Ok, stupid fisherman, I'll bite. And now I'm gonna drag you into the deep. your (1) is just a load of technical verbal diarrhea, sorry fisherman. (2) it's in the PHP section because this component of mine allows you to push arrays that are megabytes in size and potentially very deep in structure to the client, by using a PHP-language-level JSON encoder that pushes out chunks of 25mb of JSON as <div><!-- {"json":"yay"} --></div>. The non-eval() JSON decoder is indeed on the client side, and the fact that you have to ask about that shows you how much YOU know about programming. And in case you're wondering, you need all this because no browser can handle data strings over 25mb in length. eval() can't handle any errors in JSON, nor shows you where in your JSON that error might be (my component does that, in an onError callback handler no less), nor can eval() handle very long (multi-meg) JSON strings. All limitations that my component overcomes for you without 2 years of development time on your end. (3) My site renders in all browsers, the component works in all browsers (in IE since windows 8 at least, and it really wasn't my fault that it didn't work in the IE of win 7 and earlier), and the fact that you don't like my coding style is exactly what makes you so much a lamer like my coding teacher was. We, his students, were divided into 2 groups; the nitwits, in it for just the money of the 90s internet boom, whom that teacher got to teach, and us, the arty techs, who actually ended up teaching the teachers quite a few tricks about coding while we were there. See, at first, the teachers, and in particular 1 stubborn one among those, decided it always had to be the style as taught in the book that they should see as exam input from their students, incuding me. Not realizing that in coding there are many ways to Rome, and not realizing it's more about making sure those that come behind you to work on your code CAN actually work easily on that code. If I put only a single TD on a TR, did it occur to you I did that so that it's easy to turn that thing into 2 columns without much hassle? I LIKE TABLES. F-OFF if you don't! And eh, if you're such a genius, you should learn to make more accurate bug reports, and be a little more polite towards those that give you free work, so that they (like me, you're continuing to insult me in public here, fool) CAN actually improve what you're complaining about. That menu of mine, HOW IS IT BROKEN? Be precise, dear fool trollman fisher.
In other words data sets so large they shouldn't be in JSON in the first place and should be parsed into a real database? Though it's odd you started the thread about it being a better var_dump (a php function) and now its got something to do with JSON? Massive JSON that like CSV or XML might be cute for moving large amounts of data between databases, but if you're gonna be slicing into parts and performing operations on REALLY should be loaded into a db? Assuming a massive display -- useless on my 1680x1050 laptop since that menu bar is chopped off... and of course the whole "You have to scroll sideways a mile and a half" to see the actual table data because of your invalid table structures with TD counts that don't match for every TR... Oh I see, it only works in FF. Take a look at it in Chrome, Opera or IE9. Let's see... pull a screencap here... after waiting the two minutes and some change it takes at 22mbps between the massive page bloat, pointless annoying images, and endless pointless scripting for nothing... http://www.cutcodedown.com/for_others/rene7705/brokenUseless.jpg ... and that's running it on the desktop at two-thirds my 2560 display. Your menu in the center subsection doesn't scroll with the scrollbar -- in no browser other than FF does your center column table render in a useful fashion and instead blows out the side as well. As to the other menu, when you hover over products the 30 second plus fade in is annoying enough, but since it has 'gap' issues meaning half the time you try to mouse-down to the other options it disappears, and the second level cascade is effectively impossible to even get to... ... and that's before we talk about how your over the top transparency makes much of the text illegible (the yellow and green on the right in particular) depending on which massive bandwidth wasting for nothing (since it's covered up by content) background is loaded... and of course all those fixed metric (px) fonts that are an accessibility train wreck. It's what I usually mean when I refer to the "WCAG, what's that?" crowd of developers. It is an inaccessible broken bloated train wreck of scripting for nothing, gee ain't it need animation and other garbage that makes it difficult to get at the mere 4k of actual content on the page... which makes your 68k of markup a bit of a head scratcher -- if not for your decade and half out of date methodologies! You know, I'm no fan of teachers either on this subject, but I am a fan of actually *SHOCK* following the specifications and recommendations of the people who came up with HTML. Are you at least familiar with the concepts of separation of presentation from content? Semantic markup? Accessibility? That's rhetorical, it's apparent from your site you've dismissed them and just want to sleaze out your pages any old way. That's funny with your 68k of markup (post generation), 1.8 megabytes of document by the time the scripting gets through with it, and 1.5 megabytes of javascript and 83 separate files (hello handshaking hell)... to deliver 4k of plaintext! Nothing like blowing 4 megs of bandwidth to do 70k's job... while making 100% certain it's inaccessible to scripting disabled/unavailable users, screen readers, tablets, screens narrower than 1920px, anyone who needs to zoom due to the illegible non-dynamic fonts, etc, etc... Did it occur to you that failing to keep the column counts the same in every TR results in a broken layout in everything but firefox? Are you aware of the concept of semantic markup where you're not supposed to use tables on non-tabular data? I mean, let's go through some of this: <body style="width:100%;height:100%;overflow:hidden;" onload="siteCode_fwa.startApp()"> STYLE being presentation that has no business in your markup, and any script worth using should be hooking that itself instead of being in the markup on the body tag -- in both cases so it can be cached across page loads AND in the case of STYLE so that you aren't sending your screen target CSS to other devices where it may not apply. <div id="siteLoadingMsg" style="position: absolute; width: 100%; text-align: center; font-size: 200%; font-weight: bold; top: 146.5px; left: 0px; display: none;"> <span id="javascriptEnabledTest" style="color: green;">This site with opensourced web components will show soon.</span> </div> Code (markup): any script worth using would add that itself -- of course it behaving as a splash page means scripting disabled/blocked (like the 10% and growing of internet users who are downloading things like the noscript extensions for FF or Chrome, or just plain opera users who have it built in) won't get a broken page... and again presentation inlined in the markup for no good reason... AND a span for nothing. Even your site logo: <div id="siteLogo" class="animatedJavascriptButton animatedTheme__siteLogo_fancyWebApps_002 animatedJavascriptWidget_initialized" style="position: relative; visibility: visible; left: 5px; width: 540px; height: 100px; z-index: 99000; top: 5px; text-align: left;"><div id="siteLogo__item__0" class="ajsb_item" url="javascript:siteCode_fwa.logoClicked();" style="text-align:left;cursor:pointer;position:absolute; width:540px; height:100px;" onclick="fwa.ajsb.onclick(this,event);" onmouseover="fwa.ajsb.onmouseover(this,event);" onmouseout="fwa.ajsb.onmouseout(this,event);"><table style="cursor:pointer;position:absolute;width:100%;height:100%;z-index:1100"><tbody><tr><td style="text-align:center;vertical-align:middle;filter:alpha(opacity=100);z-index:1100;"> </td></tr></tbody></table><div id="siteLogo__item__0__img1" class="ajsb_img" style="text-align: left; z-index: 100; position: absolute; width: 540px; height: 100px; background-color: transparent; background-image: url("/fancywebapps/com/animatedJavascriptThemes/siteLogos/siteLogo_fancyWebApps_002.png"); background-position: -550px -1320px; opacity: 1;"></div><div id="siteLogo__item__0__img2" class="ajsb_img" style="text-align: left; z-index: 101; position: absolute; width: 540px; height: 100px; background-color: transparent; background-image: url("/fancywebapps/com/animatedJavascriptThemes/siteLogos/siteLogo_fancyWebApps_002.png"); opacity: 0; background-position: 0px -1210px;"></div></div></div> Code (markup): That's one hell of a lot of code for what any sane developer would use: <h1 id="animatedLogo"><a href="/">FancyWebApps.com<span></span></a></h1> With the span only really being needed if you care about supporting IE7 (generated content working in IE8/newer) and the ID just being there for the animation script to target it... it should just need it's background-position slid around by the script... Which shouldn't take more than half a K of scripting at most... the script for doing that animated logo therein being smaller than the markup you are using for it. Mentioned it above, but again it has gap issues so if you hover the products list half the time you can't get to it's sub-items, and getting to the third level dropdown is nigh impossible excepting blind luck. The fade in animation takes so long you don't even realize it IS a dropdown unless you have the patience of a saint... opera and chrome both seem to have positioning issues with that silly slow animated background; which is why I'd swing an axe all all the goofy bandwidth wasting animations for NOTHING and use CSS to build that menu in a much more sane and accessible fashion. Even if I was to keep that animation all those presentational images and inlined scripting you have in the markup would get ripped out and placed where they belong -- the external stylesheet -- and then slide the background-image around instead of this bizzaroland massive scripting mess you're using for it... where you're using god only knows how much scripting and 17k of HTML to do less than 2k of markup, half a K of CSS and maybe 1 or 2k of scripting's job! Which sums up the code for the entire page -- you've taken something simple; 4k of actual plaintext content -- and ignored accessibility standards, the entire point of HTML, the entire point of CSS, and thrown endless pointless markup with even more pointless scripting at it... EVEN for the effects you are doing. Today's a busy day, but if I have time I'll do a rewrite of that menu and your H1 to show you EXACTLY what I mean by your having WAY more code than necessary. I'm NOT trying to pick a fight or insult you despite your thinking that was my intent -- I'm trying to point out that to be frank, you've got some WEIRD ideas on how to go about doing things.
Hi, I've watched your version and can't agree more with the 'ranting' of ryan... Its nice that someone tries to make a better version for var_dump and print_r but why did you create it? did people ask for another better version? i never did anyway and if you need to verify so much data you don't do it manualy (i don't! therefore i use databases and queries). As i've looked into the source i see alot of data ALOT OF DATA again, i'm not going to investigate my outcome this way as it would take alot of time to process and time is money!. I agree also with Ryan that you could rethink this all, make a good base (that's looking great in ALL BROWSERS). I hate FF just because it's FIREFOX and work 99,9% with Chrome. But all my works goes tru IE/FF and chrome to make shure it works on all browsers exactly the same. Also put CSS where it belongs, small fixes in the HTML code with style="" are allowed in the development fase but not when you put things online (for the world to access) i know i also have projects online with style="" but knowing that it works in all browsers i don't care the extra (little) bandwidth... in your case heavy bandwidth (and yes i know internet keeps growing, but why not make it your intention to make things smaller instead of huge..). To end this, i just want to say its nice to see people making free stuff, but please hear what others have to say. We try to make the web better, but not bigger sorry for my poor english and write mistakes, it comes out of a good heart
Your arguments would be valid if you had made them in the early 1990s, when we were still using slow audio modems. If you think I'm using a lot of markup and graphics to display a webpage, wait until 3D will get used; google:scenejs And i'm stopping the discussion here. I've tested my code in all browsers on windows 8, that's as far as I'll go. A real critic would have simply passed me the actual fix in the code to solve the problem on some browser on some OS that I simply don't use. Not nag about how the web should revert to the early 1990s.
It is not... I tossed together a rewrite of the animated header and the menu -- to show exactly what I was talking about... though that 1.3 MEGABYTE logo png is horrifically bad -- by itself being eight or nine times the upper limit I'd allow for an entire page template (HTML+CSS+SCRIPTS+IMAGES, not counting content)... Still, I was able to gut the markup down to almost nothing, create a dynamic CSS sprite image animation routine, and replicate most of the functionality in around 1.8k of markup, 4.25k of heavily commented javascript, and 1.8k of CSS. http://www.cutcodedown.com/for_others/rene7705/template.html as with all my examples the directory: http://www.cutcodedown.com/for_others/rene7705 is unlocked for easy access. It uses CSS3 transitions for the fade-in/out effect on the menu so IE doesn't get those (oh noes, not that), but the page remains functional. It's impractical with the alpha transparent png to have images off graceful degradation -- which is why I don't design content elements using those in the first place if it can be avoided -- of course that's part of why you've got a ridiculously massive 1.3 megabyte logo image. Really I would try to find a way so that when images are disabled (which a LOT of users do due to bandwidth limitations not just in pipe width, but bandwidth caps and overages. Ask our friends in Canada or New Zealand about that one!) The animation script for the menu and the logo share the same timeout handler, I set it up to handle multi-column and single column sprite sheets, as well as looping, bouncing and hover. The original the H1 seemed to reset the animation on hover and then play normal -- which seemed like a waste, so I tossed in a hoverlock... That's where if you mouseover the element it goes to the end of the animation and stays there until release. In terms of that menu animation, I'd give serious thought to axing the cut corners and alpha png for a flat background, and use CSS3 rounded corners with box-shadow on those -- saving massive amounts of bandwidth and probably looking nicer too. IE8/lower wouldn't get the extra effects, OH WELL. Using palletized PNG you'd end up with something that only needed a 5 to 10k image, instead of the 62k one. Because the menu hovers are CSS and based off the LI, it lacks the gap-select issue. The only thing the scripting does is animate their backgrounds -- the rest is CSS' job. ... and like all GOOD scripting, it isn't crapped all over the markup over and over and over; it is separate. This is because the proper approach to building a website is to ask "what is this content", then mark it up semantically, and then progressively enhance it with scripting. You then hook the elements as needed from the script, instead of slapping "onmouseover","onmouseout" on things every single time. The DOM exists for a reason, use it. So all that, in a fraction the code, over lunch. Oh, and using the TITLE attribute on elements when it's identical to the content of that element? Waste of code, waste of bandwidth, waste of effort. No legitimate reason to EVER do that. ... and that's just the logo and menu! The entire site is filled with massive bloat, pointless scripting for nothing, AJAX/DHTML trickery to make the content inaccessible, and on the whole... well again, 3.4 megabytes of code (and 4.2 megabytes once images are added on) to deliver 4k of plaintext and a dozen content images... (all of which are adverts)
Its pitty that you stop this discussion, you can learn from it and yes i refer to the early 1990, coz still fast sites rocks and slow sites not.. You are expecting to much from your users and i can guarantee that your htmlMicroscope won't get much attention from REAL programmers, sorry m8t. But its your missed posibilities, not ours.. btw hope that you are happy with your project, then your goal is reached! Ryan: ment indeed deathshadow sry m8t.
No problems. I was just worried deathshadow might have been disappointed that his ranting was attributed to someone else.
Is there a use case for this tool? I understand what you're saying it does, I just can't figure out why to do that.
It's not even a '90's thing -- or as he put it 'slow audio modems' -- though admittedly I try to keep in mind that most of the people in my town only have a 768kbps connect (the cheapest plan) or 3mbps at max -- We've been promised cheap fiber for a decade, still no sign of it... but what about the folks on metered connections or bandwidth caps? Been to Canada lately? New Zealand? People accessing via 3g/4g tethers? Limited bandwidth phone services? Sharing that nice fat pipe at Panera bread or Starbucks? (Yes, that's a double-pun). Sitting here on a 22mbps while watching Hulu, torrenting an ISO of Haiku (the OS), while the roommate watches her lesbo prons? How about this one, Google penalizing slow websites? ... honestly I think they need to make it more of a pimp-slap than they have Good laugh being the site in question is too massive for pagespeed or yslow to even attempt to analzye it! Admittedly I think both have some noodle-doodle flaws (like overvaluing CDN's -- interesting since Google and Y! sell CDN space) but it's a good starting off point. I mean, between being devalued for no semantics, DHTML making the page empty, text that has nothing to do with the content preceding it devaluing any text that's actually in it... I'd be shocked if any search engine even lists the site -- and if it does, it would be ENTIRELY due to backlinks since this: "This site with opensourced web components requires javascript enabled in your browser." Is the only text most search engines, screen readers, half the tablets out there, or all the power users who run selective script blocking would even be able to see. That's the whole AJAX/DHTML building of content garbage I was talking about making the site needlessly and pointlessly convoluted, inaccessible, and on the whole such a train wreck it's doubtful anyone would take anything offered on it seriously. ... and that's before talking the massive tool for sending a data format client side that has no business being processed client side.