www.webdeveloper.com
Page 2 of 2 FirstFirst 12
Results 16 to 29 of 29

Thread: Better way to handle LOTS of dynamic content other than splash screen?

  1. #16
    Join Date
    Mar 2012
    Posts
    1,648
    Quote Originally Posted by grofit View Post
    ...however we are lucky as we have a LOT of things we can improve.
    That comment just cracks me up...

  2. #17
    Join Date
    Jul 2014
    Posts
    11
    That screenshot is everything, that is the firebug output, count the lines... there is 35, I blurred things as to keep the anonymity of the project (which is besides the point of this discussion), if you look in my 2nd reply I give you details on file sizes and amounts of external resource calls. Also I am not using Bootstrap, I have a class (or function if you prefer) call Bootstrapper which basically kickstarts the framework initialisation and resource loading, think of it as an entry point, and it is housed within Bootstrapper.js file.

    There is a lot of individual image loads which you are correct can be made into a spritemap and I believe that was mentioned somewhere, but other than that your only other negative was that I was using bootstrap (which I am not), I would say the number of requests is a bit high, and can be dropped with further file combining in the build step however nothing really screams out at me as overly bad.

    I will concede you are right, people use the term HTML5 to encompass the new Html element specifications and the new javascript native objects available. However everyone knows what you mean when you say HTML5, and like you say if you look at HTML5 purely at the markup changes then it is fairly trivial.

    Now onto patterns & practices, and I fear that you have been lied to at some point, as there is not a direct correlation between time spent in an industry and proficiency in that industry. I have worked with developers twice my age who know half as much, or developers half my age who know double what I do. So your proficiency is generally measured by how flexible and knowledgeable you are in a given situation, now if the topic was HTML markup specifications you would have us all beat, however that is 1 small part of a MUCH bigger picture.

    So when you say things like:
    Actually, I have this nasty habit -- and it pisses off most people arguing things like this with me -- of actually learning something BEFORE I badmouth it. OF course, why is it that people who call stuff like that "Good patterns and practices" are ignorant of things like the WCAG, semantic markup (aka using HTML properly), inheritance, selectors, manipulating the DOM, or even the underlying languages on which their beloved "frameworks" are based? (jQuery is a great one for that last bit! You see it a lot in PHP too -- bloated code that needs a library or brute forcing things THE LANGUAGE ALREADY DOES)
    I really worry as you are getting hung up on the simplest part of web design, any donkey with a keyboard can put together html (and some of those donkeys even know what a doctype is). Yes there is some finesse around divs vs spans, tables vs ul etc, however you can style it however you want with CSS, make a ul look like a table, make a table look like a ul, it doesn't matter. We have moved on a web developers from the drudgery of having to care about it, most peoples frequently used tags are div, p, img anything else is for a specific use case. So if we spend all our time worrying about the raw HTML (which honestly matters little unless you are adding lots of redundant container elements) but it does not matter, we moved on from ASM to C++, from C++ to C# and now we look towards Functional and Duck Types languages and platforms.

    So when you start to see HTML as fairly inconsequential and the majority of the work being JS and CSS then you start to realise that you need to put some strategy and forethought into your designs. CSS for example is nice, but wouldn't it be nice to be able to re-use css chunks or have css variables that can be calculated based on inputs? I am sure you will say no, but the rest of us said yes and so came LESS and SASS. Wouldn't it be nice to not have to worry about adding and removing stuff from the DOM every time something changes? (again feel free to say no but you see where I am going here) we said YES thats a genius idea, why do I want to spend time fiddling with the lowest level of HTML manipulation when I can just provide some data and have it update for me. This is what Knockout and other modern JS view frameworks do.

    I would LOVE too see you write http://knockoutjs.com/examples/contactsEditor.html that example in html with raw js dom manipulation. I am not saying you cannot, but whats the point of expending more effort for a lesser outcome?

    You say above that you learn about something before you bad mouth it, however I honestly think you have 0 knowledge when it comes to these frameworks and you are just throwing as many anecdotal fallacies into this as possible. If you can explain to me the benefits of using raw JS and DOM manipulation with native objects vs using a framework such as Knockout then I am more than willing to hear it (it is 17kb by the way).

  3. #18
    Join Date
    May 2014
    Posts
    1,038
    Quote Originally Posted by grofit View Post
    That screenshot is everything, that is the firebug output, count the lines... there is 35
    Odd, it's chopped off here around the 20th item.

    Quote Originally Posted by grofit View Post
    I blurred things as to keep the anonymity of the project
    Which is fine, it would just be nice to see the file extensions so you know what the file is -- load order based on file type and code location is one way to optimize; crazy as it sounds.

    Quote Originally Posted by grofit View Post
    if you look in my 2nd reply I give you details on file sizes and amounts of external resource calls.
    Which is 1/10th what I'm asking...

    Quote Originally Posted by grofit View Post
    Also I am not using Bootstrap, I have a class (or function if you prefer) call Bootstrapper which basically kickstarts the framework initialisation and resource loading, think of it as an entry point, and it is housed within Bootstrapper.js file.
    Ah, my bad. I saw that file and with bootcrap now having a JS include, it was a logical assumption -- but again, assumption based on an incomplete picture.

    Quote Originally Posted by grofit View Post
    I really worry as you are getting hung up on the simplest part of web design, any donkey with a keyboard can put together html (and some of those donkeys even know what a doctype is).
    You would think so, but then why is it the majority of people sleazing out HTML any old way can't even follow the simplest of it's rules -- like actually using tags for what they are FOR. HTML is to say what things ARE so that when things like visual appearance are unavailable the page is still useful.

    Quote Originally Posted by grofit View Post
    Yes there is some finesse around divs vs spans, tables vs ul etc, however you can style it however you want with CSS, make a ul look like a table, make a table look like a ul, it doesn't matter.
    Unless you are a screen reader or a search engine, in which case what tags you use IS important because CSS means absolutely NOTHING to them, nor does a tags default appearance because -- Screen readers and search engines don't have eyeballs! Hence "semantic markup" -- though I've soured on that phrase and am likely going to start calling it what it truly is, "USING HTML PROPERLY".

    Quote Originally Posted by grofit View Post
    So when you start to see HTML as fairly inconsequential and the majority of the work being JS and CSS then you start to realise that you need to put some strategy and forethought into your designs.
    Which is a short-sighted pissing all over accessibility, usability AND graceful degradation, much less forgetting why HTML even exists in the first place.

    CSS and JS are there to enhance functionality, not supplant it in all but the rarest of cases. Diving for those before you even think about accessible markup is like sleazing out a PSD and calling it design -- putting the cart before the horse.

    Which is why I laugh when I see people using JS to do things HTML can do without it. Or using JS to do CSS' job...

    Quote Originally Posted by grofit View Post
    CSS for example is nice, but wouldn't it be nice to be able to re-use css chunks or have css variables that can be calculated based on inputs?
    You mean like by... grouping selectors and leveraging inheritance properly? A failure to do so being why halfit nonsense like LESS and SASS are popular amongst people who to be frank, haven't learned enough about CSS to be writing it? Much less knowing enough about it to even say if LESS/SASS is actually delivering any benefits?

    Just more crutches for the inept that makes more work, not less; usually because of deficient education on how to use HTML and CSS.

    Just because something is popular doesn't make it good... Lemming effect.

    Quote Originally Posted by grofit View Post
    Wouldn't it be nice to not have to worry about adding and removing stuff from the DOM every time something changes? (again feel free to say no but you see where I am going here) we said YES thats a genius idea, why do I want to spend time fiddling with the lowest level of HTML manipulation when I can just provide some data and have it update for me. This is what Knockout and other modern JS view frameworks do.
    ... and likely in the process being inaccessible, slow, and a waste of time since you can usually do it faster and in less code without them. YMMV, but to me they are again, a crutch at best, pointless bloat recreating existing functionality at worst.

    Quote Originally Posted by grofit View Post
    I would LOVE too see you write http://knockoutjs.com/examples/contactsEditor.html that example in html with raw js dom manipulation. I am not saying you cannot, but whats the point of expending more effort for a lesser outcome?
    Stunning example of everything wrong with development today -- between the inept re-re inaccessible broken "I can haz intarnets markup", lack of semantic relationships, and what it has the giant pair of brass to vomit up and call the SIMPLEST of HTML structures a "form" -- that tool is more idiotic than what people were barfing up and calling websites in frontpage fifteen years ago! HELL, IT's the SAME CRAP!

    Tables for layout, no LABELs, no FIELDSETs, nested tables without scope attributes, broken keyboard navigation --- what that tool "does" is such complete rubbish I pity anyone DUMB ENOUGH to use it... which means you're right, I wouldn't waste the effort on making such a pointlessly useless garbage tool. That is EXACTLY the type of nube predating garbage I'm talking about -- and if you don't know what's wrong with what that tool does, to be brutally frank do the world a favor, back the hell away from the keyboard and don't come back until you've bothered learning how to use HTML and CSS properly!

    What that tool vomits up and calls markup is so disastrously bad and reeking of pre 1998 practices, that hold it up as an example of doing something that has any business even being done on a site ... wow, just WOW. Say hello to 1997 for me! I'm sure Netscape Composer 4 and Frontpage will keep you company.

    If what you are doing bears any resemblence to that? Yikes. Just throw it all away now.

    side note, if I did that, I'd probably send the data serialized or ASCII controlled instead of JSON, but that's just because I find JSON and XML to be grossly inefficient data methods -- which is why I only use those formats when pulling from someone else's data sources. Though really, I'd just *SHOCK* let the resulting form do what it does and if need be, intercept onsubmit while still letting it drop through script-less.

    Quote Originally Posted by grofit View Post
    If you can explain to me the benefits of using raw JS and DOM manipulation with native objects vs using a framework such as Knockout then I am more than willing to hear it
    Faster code execution, use less code and simpler to do it... greater likelyhood of being able to generate SEMANTIC markup and actually *SHOCK* use HTML tags for what they are FOR instead of being at their (seemingly halfwit) whims of abusing markup out of ignorance.

    Quote Originally Posted by grofit View Post
    (it is 17kb by the way).
    minified and gzipped it's 17k... it's 46k not counting gzip, so that's 46k of wasting battery and processing time... what's the formatted version? 200k+? (probably around 100k less comments) -- minified it's already half my unminified page allotment!

    But then when I say my usual target template (not counting content) size is 72k or less in a dozen or so files, HTML+CSS+SCRIPTS+IMAGES without whitespace stripping, minification or gzip...

    Kind of a laugh -- you say HTML is easy -- if so why are so many developers completely incapable of using it properly?!? To the point keyboard navigators, users on screen readers, and even search engines can't use the pages vomited up that way?


    ... and I do mean vomited up.
    Java is to JavaScript as Ham is to Hamburger.

  4. #19
    Join Date
    May 2014
    Posts
    1,038
    Gah, I'm still laughing -- it's such a laugh how many people who claim to know what they are doing can't even be bothered to build a form or table properly, or use them for what they are for...
    Java is to JavaScript as Ham is to Hamburger.

  5. #20
    Join Date
    Jul 2014
    Posts
    11
    You have a valid point on your screen reader point, for people with accessible issues design over content can be a pain. However in most cases having links do your navigation and using the correct symantic element for the right task will suffice. If it is a heading use one of the H* tags based upon its importance and logical position in the document. If it is a paragraph use a p tag, if it is an image use an image tag rather than a background, lists as lists, tables as tables and finally divs for block spans for non-block. You must only deal with inept developers if these are you main concerns day to day... There are a few quirk and other tags that can be used to make your details more semantically correct but in most common cases in web sites (again sites not apps) you will mainly have textual and image content, so its not too hard to group it as such.

    Your argument about library sizes is fairly unimportant, yes granted if I was including every library under the sun, or using non minified versions then LORDY LORDY CALL THE INTERNET POLICE! however if it has a 17kb cost for the functionality it provides I would give up that 17kb any day. Given that most static assets can be cached at browser, proxy, ISP, cdn, host level before it needs to be re-served its a bit of a moot point, assuming you have set your caching rules correctly.

    I do not like talking about previous workplaces, however I think this anecdotal story is of value here... So I was going to work for a governmental service body to help them improve their existing web based application (for right or wrong), and our team had 5 developers (of different skill levels), 2 testers, 1 architect and 2 XML architects... now I had to ask myself what was so hard about XML for it to need 2 architects (who were being paid effectively 2 other staffs amounts). After looking at the work they turned out, I realised it was a bit of a scam they had going, as they told everyone XML was very hard and it was all about making the data descriptive and extensible, and you know what they turned out after about 4 weeks... an XML schema to store some data, with an XSD to verify it... thats 4 weeks for 2 people to come up with the XML representation of a POCO... Now far be it from me to tell them that we could have done that ourselves with one of the many POCO -> XML tools or just let ASP MVC do it for free via its auto serializing, however because of their pursuit of semantic correctness they wasted a lot of peoples time and ended up producing something inferior to what a computer would do... also it would mean any time a change was needed to XML they would have to approve it, and the whole process slowly ground to a halt as people were hung up on what XML looked like rather than not caring... it is a container for data... its the data you care about.

    Now granted HTML is slighty different as the semantic layout describes to certain programs the context and meaning of the data, but it is not hard to layout your HTML is a valid way, nor is it hard to comprehend why you should use the right tag for the right content, so when you say this stuff is hard and everyone else is inept you remind me of the 2 xml architects who wasted everyones time, their heart was in the right place though...

    Now let us touch upon your SHOCKING statement in regards to using raw JS and DOM manipulation vs a framework (such as knockout):

    Faster code execution, use less code and simpler to do it... greater likelyhood of being able to generate SEMANTIC markup and actually *SHOCK* use HTML tags for what they are FOR instead of being at their (seemingly halfwit) whims of abusing markup out of ignorance.
    - Faster code execution is possible
    Sure I can agree with that one, but I do not really deem it important, fast is fast enough. The reason why people use C# without care of the GC causing performance problems, because it doesn't matter 99% of the time unless you are doing something VERY wrong, which most people dont.

    - Less code
    Now lets assume you mean total code, then yes possibly you could make your own framework to handle DOM interactions and manage HTML events and adding and removing of elements as you add and remove data to your object, but it would be more code to maintain, it would only serve this one purpose and would be bespoke so everyone else would need to learn your way of doing things. As in most cases you will have view logic (interactions with HTML) and business logic (actual logic which is bespoke to your application), you are focused on view logic in most of your arguments, which is boiler plate to most people.

    So yes you could possibly shave off a bit of total code, but if we were to look at actual code you care about, then no you would be able to use FAR less code to do the business requirements using a framework. So from the point of view for most people (how much code am I writing) there would be FAR MORE doing it with raw JS and Dom manipulation.

    - Generating semantic HTML
    You keep harping on about this, but I do not see what the big problem is, yes if you are using divs for everything and you are not putting alts on images and are doing other wacky stuff then yeah sure, there may be a problem. However in view related frameworks they only spit out HTML you tell it to via templates, it doesn't just make up random elements and plonk them in the DOM, sure some may do but I doubt many people use them. In the examples I have discussed (Knockout, Angular, Ember etc) they will not make up DOM elements, they do what you have told it to, so the framework is only as bad as the developer using it.

    So surely if I were a good developer and knew semantically correct HTML, and the framework will create the HTML as I have indicated, then it is just making glorious HTML that we all want, the framework is not inherently evil just because some bad people misuse it...

    Stunning example of everything wrong with development today -- between the inept re-re inaccessible broken "I can haz intarnets markup", lack of semantic relationships, and what it has the giant pair of brass to vomit up and call the SIMPLEST of HTML structures a "form" -- that tool is more idiotic than what people were barfing up and calling websites in frontpage fifteen years ago! HELL, IT's the SAME CRAP!

    Tables for layout, no LABELs, no FIELDSETs, nested tables without scope attributes, broken keyboard navigation --- what that tool "does" is such complete rubbish I pity anyone DUMB ENOUGH to use it... which means you're right, I wouldn't waste the effort on making such a pointlessly useless garbage tool. That is EXACTLY the type of nube predating garbage I'm talking about -- and if you don't know what's wrong with what that tool does, to be brutally frank do the world a favor, back the hell away from the keyboard and don't come back until you've bothered learning how to use HTML and CSS properly!

    What that tool vomits up and calls markup is so disastrously bad and reeking of pre 1998 practices, that hold it up as an example of doing something that has any business even being done on a site ... wow, just WOW. Say hello to 1997 for me! I'm sure Netscape Composer 4 and Frontpage will keep you company.
    Maybe the markup in that example is bad, but its just HTML written by some guy... the tool is not at fault for the guy telling it to output bad HTML... if you used it you could use other HTML in the views place. So again your anger should be directed at Steve Sanderson for his tutorial, not at the tool which is doing a very fine job of making the developers life easier. If you don't want an easy life and want to worry about every browsers quirks with the DOM and manage all manner of events which matter little to your business logic then go ahead and do so.

    I am quite shocked that no one else is really jumping to the defence of using javascript view frameworks and other libraries to simplify non business logic boilerplate tasks/code.

    Finally you keep poo-pooing "best practices" and "patterns" etc as if they are some black magic that should not be used, however VERY intelligent people come up with these solutions to business problems. Like Steve Sanderson, he did not just invent Knockout for his own amusement, he is a clever guy solving a problem we all know about (the dom and managing view/data updates). Martin Fowler is a clever chap, he has been in the industry about the same amount of time as you and he is quite big on his patterns & practices... nothing you have said is a tangible pattern or best practice people can use to improve their day to day roles, you are basically calling everyone else a dunce while saying that all tools out there should not be used because we are all too stupid to use them...

    @jedaisoul
    I couldn't find an edit button to edit my last post to include a point on your quote (surely some usability thing...), but it was meant in the context of performance caps, most apps hit their performance cap early because of architectural flaws, however in our case we have a pretty decent architecture so we can improve a lot of (already good) areas to get further performance benefits without making too much of a concession at the technical level.

  6. #21
    Join Date
    May 2014
    Posts
    1,038
    Quote Originally Posted by grofit View Post
    You have a valid point on your screen reader point, for people with accessible issues design over content can be a pain. However in most cases having links do your navigation and using the correct symantic element for the right task will suffice.
    Which sadly due to most scripttards and back-end developers not knowing enough about HTML, is a rarity at best.

    Quote Originally Posted by grofit View Post
    If it is a heading use one of the H* tags based upon its importance and logical position in the document.
    Remembering that when they say 'importance' in the specification they mean level import, not "importance" as in "importance" (just like <div></div> is not what the spec means by an "empty" tag -- thank you uselessly convoluted legalese!) -- H1 is the heading under which everything on the page is a subsection, h2's indicate the start of a subsection of the h1, h3's indicate the start of subsections of the H2 and so forth, with HR being a change in topic when no heading is appropriate or desired -- which is why skipping over levels going 'down' the tree is gibberish (see how most people use H4/h5 with no h2 or h3 preceeding them), why pairing a H1+H2 as title and tagline is gibberish (which was FINALLY understood by the HTML 5 jacktards with them killin off HGROUP)... and of course once you figure in heading navigation in browsers like REAL Opera (as opposed to the pathetically crippled ChrOpera) or assistance aids like JAWS, why SECTION, ARTICLE, ASIDE and NAV is just pointless code bloat.

    ... but of course, another reason I think HTML 5 is "the incredible man", since it pisses all over that. Follow the yellow line in the snow... follow the yellow line in the snow... don't eat the yellow line...

    Quote Originally Posted by grofit View Post
    and finally divs for block spans for non-block.
    Excepting that DIV and SPAN are semantically neutral, and should only be used for the application of styling hooks once you've expended what the tags with actual semantic meanings can do... which is why 99% of the time people do things like <div id="mainMenu"><ul> it's a "DIV for nothing". There's a reason the second step to developing a normal page for me is to apply semantic markup WITHOUT DIV or SPAN... since DIV and SPAN have no meaning... and why most of 5's structural tags are pointless code bloat since they are in most cases redundant to existing tags and/or the content itself.

    Which anyone who took the time to embrace STRICT, separation of presentation from content, and progressive enhancement realizes -- which of course is why the sleazeballs out there love HTML 5 and recently are trying to discredit those techniques, and anyone who promotes their use -- in the same way your SEO-tards are always resorting to as-hominem attacks to try and discredit Matt Cutts.

    Quote Originally Posted by grofit View Post
    Given that most static assets can be cached at browser, proxy, ISP, cdn, host level before it needs to be re-served its a bit of a moot point, assuming you have set your caching rules correctly.
    Excepting of course that just because it's cached doesn't mean it doesn't have to be re-parsed in an interpreted language. Just because it's 17k minified and gzipped doesn't mean the browser isn't sucking down horsepower for nothing (and battery on mobile) running the 46k of white-space stripped scripting.

    The more scripting it has to parse, the longer it's going to take to render... no matter how small you make it's download -- see the nonsense of resorting to base62 encoding like "packer" does, nothing like having to parse three times (initial, unpack, eval) before it's even run. Quite often that extra handful of bytes saved in bandwidth isn't worth the time it takes for the page to actually run in the browser.

    Quote Originally Posted by grofit View Post
    the whole process slowly ground to a halt as people were hung up on what XML looked like rather than not caring... it is a container for data... its the data you care about.
    XML just annoys me as a data storage format -- it's nice for transferring between databases where the data format on one doesn't match the other, but that's about all it's good for. JSON is similarly flawed... Typically data is a uniform format, which makes even CSV more efficient. The real laugh is a lot of the die-hard XML nutters will claim XML is machine readable -- which as someone who started out on a RCA 1802 processor makes me just want to pimp-slap them. The only reason XML exists is to be HUMAN readable. Are the integers stored in binary or BCD? Are the strings run-length limited or zero terminated? Are the floats bit-packed? No, everything is stored as flat ASCII -- so much for 'machine readable'. I'm sure anyone who's ever tried turning ASCII into binary numbers is right there with me on putting boots to backsides on that one.

    It's why I actually favor ASCII control codes... since in 99.999999999999999999999999999999999999999% of non-binary data the odds of anyone using codes other than /t/n/r is pretty damned slim. It's also ridiculously easy to parse since you can just use split/explode. But of course most people handling data online these days have no clue what SOH, STX, ETX, OET, ETB, EM, FS, GS, RS or US are...

    Quote Originally Posted by grofit View Post
    Now granted HTML is slighty different as the semantic layout describes to certain programs the context and meaning of the data, but it is not hard to layout your HTML is a valid way, nor is it hard to comprehend why you should use the right tag for the right content, so when you say this stuff is hard and everyone else is inept you remind me of the 2 xml architects who wasted everyones time, their heart was in the right place though...
    Except that proper semantic markup is about accessibility, graceful degradation, and things that actually matter in terms of delivering content in a manner useful to visitors, and by extension search engines -- there's more to delivering content on a website than what it happens to look like in front of you... a lesson lost on a lot of the people slapping together off the shelf code any-old-way.

    Quote Originally Posted by grofit View Post
    Sure I can agree with that one, but I do not really deem it important, fast is fast enough. The reason why people use C# without care of the GC causing performance problems, because it doesn't matter 99% of the time unless you are doing something VERY wrong, which most people dont.
    The problem is that when it comes to web stuff, most people ARE doing something VERY wrong. Usually falling into those magical three categories of stuff that could be written tighter/cleaner without the framework, stuff that's CSS' job, or stuff that just doesn't belong on the web in the first place.

    ... and your pop-in complaint? That COULD be a speed issue -- the time it takes for the renderer to show your new content due to scripting overhead, parsing markup to the DOM overhead, and rendering time overhead.

    Remember, the more DOM elements, the longer render takes. The more scripting, the longer the render takes. The more CSS rules to be applied, the longer the render takes. IF you change the CSS rules, be prepared for layout shift and an even longer (and annoying to users) rendering. You force a document reflow by doing innerHTML to an attached DOM element, be prepared to trip ALL of the above. (which could be your 'pop-in' problem right there)

    AT THE SAME TIME -- I partly agree; there are times where people's speed complaints are BS, like the anti-table zealots arguments magically turning "don't use tables for layout" into "never use tables"; halfwit reasoning at best, outright ignorant nonsense at worst. One of their big claims is "tables take longer to render" -- which if a 386/40 with 8 megs of RAM running IE 4 can render a table in an acceptable amount of time, is that really a valid argument when phones are now treading into the multi-ghz multi-core age?

    Quote Originally Posted by grofit View Post
    Now lets assume you mean total code
    Actually, I mean overall code NOT counting the framework against it. I see this with jQuery all the blasted time, where people for example will use 10k (minified) of their own JS in addition to the 100k (minified) of jQuery, to do what I can do in 10k or less WITHOUT the library without minification. Image sliders/rotators are a stunning example of this... as are lightbox effects... or ajax loads... or content generation...

    Even if it does end up more code NOT counting the libraries against it, at maximum it's usaully 10% more TOPS.

    Making DOM elements and populating their content/attributes is easy. Walking the DOM is a little trickier but if you master that you can do away with a lot of memory and speed wasting nonsense frameworks make their bread and butter.

    ... to be continued (that annoying 10k limit again, mated to that WONDERFUL wait 60 seconds)
    Java is to JavaScript as Ham is to Hamburger.

  7. #22
    Join Date
    May 2014
    Posts
    1,038
    ... continued

    Quote Originally Posted by grofit View Post
    - Generating semantic HTML
    You keep harping on about this
    For good reason, it's called accessibility -- of course if you care about accessibility and things like search, you're only using scripting to enhance functionality, not supplant it.

    Quote Originally Posted by grofit View Post
    So surely if I were a good developer and knew semantically correct HTML, and the framework will create the HTML as I have indicated, then it is just making glorious HTML that we all want, the framework is not inherently evil just because some bad people misuse it...
    Then why have I NEVER seen it done. No seriously, NEVER.

    To me it's more work, more code, and in general shooting yourself in the foot before you even start developing. Hell, I made my own stupid little library (not a framework) and I won't even use it's 16k uncompressed (4k gzipped minified) as I just wouldn't use more than a third it's methods on any given project...

    I mean is it SO hard to just create a 'make' prototype to create a populated node? Much less to make a new one simply leaving a copy off the DOM so to make a new section you just appendChild(node.cloneNode()) or insertBefore(node.cloneNode(), previousAddedNode.nextSibling)?!?

    Especially if you have multiple clusters of elements that are similar?

    Much less you could simply pass a properly built node as the base markup, pull it off the DOM at first execute, and use it as the template for plugging in new content? FirstNode/NextNode.... It's not rocket science.

    Quote Originally Posted by grofit View Post
    Maybe the markup in that example is bad, but its just HTML written by some guy... the tool is not at fault for the guy telling it to output bad HTML...
    There's an old saying, "if the front-end is that bad, how bad is it on the back-end?" -- back in the day a lot of the stuff people slapped together in Clipper suffered from this -- and today the same thing applies on the web.

    hell, that stupid malfing data- attribute garbage alone violates the most basic of good scripting practices for websites. "If it's scripting only, it doesn't go in the markup". But then, the same could be said about CANVAS, PROGRESS...

    Quote Originally Posted by grofit View Post
    I am quite shocked that no one else is really jumping to the defence of using javascript view frameworks and other libraries to simplify non business logic boilerplate tasks/code.
    That's because you're on a WEB DEVELOPMENT forum that isn't a shill to it's book selling like certain other sites. I'm sure if you went to Sitepoint you'd have droves of "me too" wonder poster sycophants supporting your viewpoint -- since they go out of their way to drive away dissension that might negatively impact the sales of their latest Yank-tard and Meyer-Weiner books; no matter how badly it preys on the ignorance of their client-base and promotes bad practices, calling it good practices just so the "I canz haz website" crowd can be deluded into thinking they can.

    Quote Originally Posted by grofit View Post
    Finally you keep poo-pooing "best practices" and "patterns" etc as if they are some black magic that should not be used
    No, we just have different definitions of "best practices" -- mine come from things like the 4 STRICT specification, the WCAG, and people who have an interest in a usable, accessible web.

    Quote Originally Posted by grofit View Post
    nothing you have said is a tangible pattern or best practice people can use to improve their day to day roles
    ... and semantic markup, separation of presentation from content, progressive enhancement are what exactly? You know, the things you should probably have in most cases before you even THINK about throwing scripting or back-end code at it -- since that's what those should be working with and/or manipulating?

    Also, I agree with a lot of the concepts -- like separating input routing from data processing from output; I'm just not sold that MVC is the answer to that in an environment that is inherently NOT event driven... at least not unless you're going to implement the new push technologies. THEN it would make sense. But in something that's inherently top-down mono-threaded sequentially processed typically using interpeted languages? That's when shoe-horning MVC into it is akin to trying to shove a fat woman's size 20 hoof into a size 7 shoe, even if you pull off that miracle, it's unlikely she'll walk very far.
    Last edited by deathshadow; 07-29-2014 at 02:06 PM.
    Java is to JavaScript as Ham is to Hamburger.

  8. #23
    Join Date
    Jul 2014
    Posts
    11
    I tend to use JSON, fast is fast enough... dont get me wrong if you really need to look after those bytes and ticks then by all means use binary etc, however it is rarely an issue these days. Mobile phones can run even the most battery intensive applications for an age. It is like the logic around picking bytes of ints, yes in some cases it may make sense, but in most cases you can use ints throughout your coding life without any worry of repercussions, granted you are wasting 3 bytes per variable allocation however its 3 bytes you can waste without much worry, and most do.

    I do agree that there is a processing overhead in having lots of JS logic, however I do not deem it to be slow or even noticeable in most cases (sensible use cases).

    So I think one of the sticking points in our discussions here about frameworks such as MVC/MVVM is our perspective on what the framework is offering.

    So yes in most cases it is doing DOM manipulation (which in all honesty I am thankful for, the most abstraction I can get on that mess the better, I understand it I find it cumbersome and a concern I do not want to worry about) however it is not the DOM manipulation which defines it.

    Let us take the example below:

    Code:
    <script type="text/javascript">
    function SomeUserModel() {
    	var self = this;
    	self.firstName = ko.observable();
    	self.lastName = ko.observable();
    	
    	self.fullName = ko.computed(function() {
    		return  self.firstName.concat(" ", self.lastName); 
    	});
    }
    
    var viewModel = new SomeViewModel();
    ko.applyBindings(viewModel);
    </script>
    <input id="first-name" type="text" data-bind="value: firstName" />
    <input id="last-name" type="text" data-bind="value: lastName" />
    <div id="full-name data-bind="text: fullName"></div>
    Now that uses Knockout and ignore the typos, inline JS and the lack of containing form and no specific ouput/mark element for the calculated field etc, let us just focus on what matters the most, getting the job done. So as you can see we have added the data-bind and everything else is done for us. There is not much DOM manipulation here, but every time the input is changed, KO will update the view model, so in *most* cases where you need to interact with the DOM, change your data based on user input this has immediately simplified our business logic and cut down our maintainable code base. Also for free if we change the data model, the front end would be updated.

    Now lets look at the same functionality using native JS:

    Code:
    <script type="text/javascript">
    function SomeUserModel() {
    	this.firstName = "";
    	this.lastName = "";
    }
    
    var dataModel = new SomeUserModel();
    var setupInteractions = function() {
    	var firstNameElement = document.getElementById("first-name");
    	var lastNameElement = document.getElementById("last-name");
    	var fullNameElement = document.getElementById("full-name");
    	
    	var reprocessFullName = function() {
    		fullNameElement.textContent = dataModel.firstName.concat(" ", dataModel.lastName);
    	};
    	
    	firstNameElement.onchange = function() { 
    		dataModel.firstName = firstNameElement.value;
    		reprocessFullName();
    	}
    	lastNameElement.onchange = function() { 
    		dataModel.lastName = lastNameElement.value;
    		reprocessFullName();
    	}	
    }
    </script>
    <input id="first-name" type="text"  />
    <input id="last-name" type="text" />
    <div id="full-name></div>
    Now there is a bit more overhead but its not AMAZINGLY complex, however we have to do more work to get our actual business logic working. So its 17 lines vs 30 and this is a trivial example, so it is taking almost double the maintainable code to do what is a trivial business task.

    So if we take this simple example as a basis, and extrapolate for most knockout lines of code written there will be about 75% more maintainable lines of native code, and this is before we get onto advanced topics such as ajax data fetching and retrieval and template loading etc. You could write your own framework here to wrap up these sort of things, but then you are writing your own MVVM framework which is basically what Knockout is.

    THIS is the problem it is trying to solve, *MOST* developers do not think about accessibility, if it is a task on the sprint/project then it will be looked at, and in most cases it is not a mammoth job to make a poorly accessible site more accessible. If anything it would be harder if you WERE doing raw dom manipulation yourself as you may need to change your divs to labels in some places, or your tables to ols etc and thats ignoring the more obscure HTML elements.

    https://developer.mozilla.org/en/doc...5_element_list

    So if you just worry about writing the HTML and letting the DOM manipulation happen via an (intelligent) abstraction layer you can stop worrying about the semantics of it being outputted, as you will specify the templates you want and the bindings you want, then you never even need to even look at the DOM, you just worry about the HTML (view) and the business logic being run on it.

    Now if we were talking about PURE content websites, which have very little to no user input then there is no point in frameworks like this. However web applications are usually about 50-50 user input to viewable content, whereas websites are about 5-95 user input vs viewable content. So it is different concerns and different problems and solutions, you use the best tool for the job at hand.

  9. #24
    Join Date
    May 2014
    Posts
    1,038
    Silly question, but does knockout plug in unique and proper names on the form so you can use a normal submit? If not... that's one of the things I'm unclear on and why I wouldn't use it.... as it is if it's not changing the ID's in your example to be unique as it makes more of them, it's rubbish.

    Much less it puts a scripting only element in the markup that shouldn't even be shown until populated...

    Though your second script is filled with 'i can haz js' code... like the multiple VAR for nothing, failure to reduce document, manipulations in the global namespace...

    ...and to be frank, I can't figure out what purpose either of them is supposed to serve other than copying values into JS for no reason other than to waste RAM. Really your "comparable" script reeks of inefficiencies. (like using concat for... uhm, yeah -- that shouldn't even work)

    Code:
    <input type="text" id="firstName" name="firstName" type="text"  />
    <input type="text" id="lastName" name="lastName" type="text" />
    <div id="fullName"></div>
    
    <script type="text/javascript"><!--
    
    (function(d) {
    	var
    		first = d.getElementById('firstName'),
    		last = d.getElementById('lastName'),
    		full = d.getElementById('fullName');
    	first.onchange = last.onchange = function() {
    		while (full.firstChild) full.removeChild(full.firstChild);
    		full.appendChild(d.createTextNode(
    			first.value + ' ' + last.value
    		));
    	};
    })(document);
    
    --></script>
    354 bytes vs. your knockout's 296 bytes -- whoopedee do. Personally, I find it far, far clearer than KO's uselessly vague and cryptic way of doing things... and it does add that there's no risk of namespace conflicts with other routines... Much less the removal of the excess handler 'overhead for nothing' with it constantly initializing objects and creating new objects for christmas only knows what. I'm SO sure that's efficient... NOT

    It's not a great example by any means -- usually I try to avoid direct targeting like that... and I'd probably be using an eventAdd instead of directly accessing onchange, but again, a small library that polyfills how js behaves would go a lot farther than the mess of pointless objects for nothing that is KO. I mean I'd probably have a flush function, addEvent function, nodeAdd function to detect object or text -- but that's small library stuff to save overall without changing how .js actually works. You get into something more complex and lots of complexity, hard coding is going to be smaller as those ACTUALLY save you code -- something I'm not sold on knockout actually doing in all but the smallest of testcases. (like this one) and even when it does, the amount of savings will NEVER equal the size of the lib until you get into the megabytes of code, and even then ... not so much

    I'm actually wondering if you intentionally padded your example with pointless code, or if you actually write JS that way. If the latter, it would explain why you think Knockout is so grand. I mean... you do know how scope works in JS, right? Those variables for nothing, objects for nothing, function for nothing, copies of values for nothing REALLY left me scratching my head to the point at first I couldn't even figure out what EITHER of your code snippets was trying to do!
    Last edited by deathshadow; 07-29-2014 at 03:23 PM.
    Java is to JavaScript as Ham is to Hamburger.

  10. #25
    Join Date
    May 2014
    Posts
    1,038
    Oh, for laughs, here it is using my crappy little "elementals.js" library:

    Code:
    (function() {
    	var
    		first = _d.get('#firstName'),
    		last = _d.get('#lastName'),
    		full = _d.get('#fullName'),
    		handler = function(e, t) {
    			full.nodeReplace(first.value + ' ' + last.value);
    		};
    	first.handlerAdd('change', handler);
    	last.handlerAdd('change', handler);
    })();
    288 bytes. A hair smaller than your knockout code -- but needs a 3.7k minified/gzipped lib. (16k full version)... different is it just adds helper functions to still work how JS works, instead of re-inventing things in a manner that prevents people from learning how to use the underlying language properly.

    I really need to change handlerAdd to accept arrays for targets and not just for actions.

    _handlerAdd([first, last], 'change', handler);

    Would be cool... and handy. Probably just make it recursive to simplify the logic like I did the other actions. Hey thanks, gave me an idea.
    Last edited by deathshadow; 07-29-2014 at 03:48 PM. Reason: Oops, forgot how my own lib even works, shows how often I use it.
    Java is to JavaScript as Ham is to Hamburger.

  11. #26
    Join Date
    Jul 2014
    Posts
    11
    I think you miss the point and I EXPLICITLY said to ignore the dumping of html and logic as it was just to show a scenario/use-case, your focus is soley on DOM interaction and semantic HTML, you do not seem to grasp that these things are of little importance outside of the accessibility topic, and again I see it as trivial to change your HTML output to be more semantic without any issues framework or not...

    You are saying words like separation but your approaches are the complete opposite, the whole point of having these frameworks is to abstract the HTML (I am sure your just **** yourself through your eyeballs at that comment), but if you look at my KO example, my business logic has no idea about what HTML it is being bound to. So the firstName variable could be applied to multiple DOM elements or a single one... or none, it doesn't matter its a view concern.

    Now just take a moment and think about what I just said, using these frameworks separates me from the DOM and HTML... why is that a good thing?

    WELL, if you want to do some automated tests to prove your business logic works you do not want to have to worry about the view, it is just that "a view" on the data. So let us say in my trivial example above I want to prove my fullName is correctly calculated, using knockout all I need to do is instantiate the SomeUserModel, set the firstName (James), set the lastName (Bond) and then assert that the fullName is correct (James Bond). So how would you test your business logic if you are tied to the DOM elements?

    Once you strip out the DOM, and just work with the data then your REAL problems begin, such as validating the data (irrespective of the DOM) saving and loading data, realtime data transferring, adding and removing complex data to the view (again I add this to the view not the DOM, it is all handled for me) and like we have already discussed I control the HTML output as I tell it how to add templates or what bindings to carry out.

    Using approaches like this achieves an improvement in logic and view decoupling, allows for mocking of components so you can test in isolation. Allows re-use of logic and allows REAL domain modelling in the web front end, as you can base your view around the data which is what you should care about. Sure make your view as semantically correct as possible, but its not a difficult task. As mentioned before all it takes is a quick look at the mozilla list to see what elements best fit the given content.

    How do you currently achieve things like:

    - View Component Re-use (i.e having a login component on every page)
    - Validate user input
    - Test your logic (assuming the sites you work on have logic, if not they are not apps)
    - Handle reading and sending data to third parties

    The ONLY reason I am continuing this conversation is in the hope that others that have your point of view MAY somehow realise that the game has changed, and maybe look at the bigger picture here.

    You said yourself this is a forum of WEB DEVELOPERS, yet I have not heard any actual development from your points, its just HTML writing which is more a designers job, the developers deal with logic, what is logical about HTML... it describes data... it has no logic...

    I am saddened as I really think you are misguided and are misguiding others because you want things to be the same way it was a decade or so ago. I do agree that we should all strive for semantically correct HTML, but there is no reason we cannot do that while making our lives easier and the web better (oh my goodness YES I DID JUST SAY THAT)... I advocate using the right tools for the right jobs, if you have logic you should be using a framework which abstracts the DOM, you should be testing your logic, you should be using patterns and practices, such as Inversion of Control, Loosely coupled components, wrappers around transport mechanisms (ajax, websockets etc)... THESE are the things which matter in the modern day development of web applications, hell I am even using Typescript and compiling to JS so I can make use interfaces and generics to make my life easier as a developer and reduce the amount of time it takes for me to release worthwhile functionality...

  12. #27
    Join Date
    May 2014
    Posts
    1,038
    I'm actually having trouble making sense of your latest post -- I see a lot of words that don't seem to actually say a whole lot of anything meaningful -- or just don't seem to mean what you think they mean.

    Quote Originally Posted by grofit View Post
    I think you miss the point and I EXPLICITLY said to ignore the dumping of html and logic as it was just to show a scenario/use-case, your focus is soley on DOM interaction and semantic HTML, you do not seem to grasp that these things are of little importance outside of the accessibility topic
    Or the search topic, or the speed topic, or the combination of both with google penalizing slow sites...

    Quote Originally Posted by grofit View Post
    You are saying words like separation but your approaches are the complete opposite
    Then you're not seeing it. HTML for what things are, CSS for what things look like, JS for enhancing functionality... Server side input, data handling, output as separate things in a linear instead of event driven fashion (since unless you go push web tech is NOT event driven -- it's coming, we're not there yet). Top down linear model -- it's how the underlying tech and underlying languages work, it's PISS simple... why make it needlessly convoluted and abstracted to the point that, well... you end up not knowing enough about JS that you

    Quote Originally Posted by grofit View Post
    the whole point of having these frameworks is to abstract the HTML
    An abstraction of something so simple you shouldn't need to abstract it, and that pisses all over accessibility in the process? There are enough retard sites right now that are useless to me and most everyone I talk to as visitors thanks to that garbage without adding to the list.

    Quote Originally Posted by grofit View Post
    but if you look at my KO example, my business logic has no idea about what HTML it is being bound to.
    A pointless code-wasting abstraction for nothing, to avoid dealing with something you on one hand called easy, but can't be bothered to deal with?!?

    Quote Originally Posted by grofit View Post
    So the firstName variable could be applied to multiple DOM elements or a single one... or none, it doesn't matter its a view concern.
    So in other words you wanted to use a class? Or maybe if these are scripting only elements generate them yourself instead of crapping all over the markup with them? Or maybe walk the dom off a common parent element by structure? Or maybe a generic class/function handler to which you pass the elemnent or ID?

    Quote Originally Posted by grofit View Post
    Now just take a moment and think about what I just said, using these frameworks separates me from the DOM and HTML... why is that a good thing?
    NO CLUE. Sounds like throwing more code at a non-issue from a lack of understanding how to use HTML, JS or what the DOM is in the first place. Abstracting from the very tech that for all intents and purposes is your ONLY 'view' and the only thing that really matters when it comes to actual user interaction doesn't sound particularly bright to me.

    Quote Originally Posted by grofit View Post
    WELL, if you want to do some automated tests to prove your business logic works you do not want to have to worry about the view
    Ah yes, that silly "view" thing.... that sadly has less business in JS than it does in PHP. MVC -- a brilliant programming model for C++ using Win API or GTK++... as a web tech? not so much. I do see where it's useful -- I've used it in the environments where it makes sense (including multithreaded apps) -- the web just isn't one of them because the web 'doesn't work that way' hence the typical massive stack of "code for nothing" at it to drag it kicking and screaming into doing so... poorly.

    Quote Originally Posted by grofit View Post
    So let us say in my trivial example above I want to prove my fullName is correctly calculated, using knockout all I need to do is instantiate the SomeUserModel, set the firstName (James), set the lastName (Bond) and then assert that the fullName is correct (James Bond). So how would you test your business logic if you are tied to the DOM elements?
    You seem to be misusing words again -- "Business logic"?!? Hell, even the use of the word "assert" troubles me; what is this, Prolog? PPL?

    Assuming I'm deciphering that grok properly, Is it REALLY that hard to say:

    isCorrect = (first.value == 'James') && (last.value == 'Bond');

    within the scope of the anon?

    Though I'm guessing wildly as you are using terms that mean little or nothing out of context, reeking more of marketspeak and... well, one of those things I often complained about decades ago with programming languages like C where it's "designed to make programming look hard".

    Quote Originally Posted by grofit View Post
    Once you strip out the DOM, and just work with the data then your REAL problems begin
    Doubtful -- I really think you're not grasping what JavaScript is or how to use it with statements like that.

    Quote Originally Posted by grofit View Post
    such as validating the data
    Check against .value on the user inputs, NOT that you would be trusting that client-side in the first place since ALL user input is suspect and you should NEVER trust it there. If you're checking it client side for anything more than telling the user they screwed up as an enhancement to the form... well, that just reeks of "security, what's that?"

    Quote Originally Posted by grofit View Post
    saving and loading data
    Use a form, serialize the data, use matching names and/or ID prefixes or even better, a DOM walk...

    Quote Originally Posted by grofit View Post
    realtime data transferring
    Serialize it, send it as a AJAX request, not rocket science.

    Quote Originally Posted by grofit View Post
    adding and removing complex data to the view
    A function or two at worst...

    Quote Originally Posted by grofit View Post
    Using approaches like this achieves an improvement in logic and view decoupling
    In other words overcomplicating something simple...

    Quote Originally Posted by grofit View Post
    allows for mocking of components so you can test in isolation
    Because the static test markup one should make before even thinking about style or scripting couldn't possibly handle that :/

    Quote Originally Posted by grofit View Post
    Allows re-use of logic and allows REAL domain modelling in the web front end
    Not sure what "domain Modelling" is either, since neither term is really related to the other...

    You really seem to be mis-using a lot of the terminology here...

    How do you currently achieve things like:

    Quote Originally Posted by grofit View Post
    - View Component Re-use (i.e having a login component on every page)
    Not sure what that even means in this sense, but I suspect that's the shoe-horning MVC into something that should simply be handled by the site template.

    Quote Originally Posted by grofit View Post
    Validate user input
    Since it would be in form elements, attach classes saying what validation needs to be done like "v_require" or "v_email" (handy for styling too, two birds one shotgun), hook onsubmit to pull all INPUT, SELECT and TEXTAREA to check them doing a 'prevent' type method on failure while inserting helpful error boxes next to the inputs and probably putting an error class on them too, likely focusing the first form-element with an error on it in the process.

    Though again since I have a clue about what security is, I'd make it work WITHOUT scripting first if sending it server-side, since you cannot EVER trust client-side validation. Client side validation is an affectation to avoid a pageload as a convenience to the user, NOT even close to a replacement for server-side checks since ANYTHING you do client side can be hacked by a five year old script-kiddy.

    Quote Originally Posted by grofit View Post
    Test your logic (assuming the sites you work on have logic, if not they are not apps)
    Actually type something in and see what happens? Have a return vomiter dumping htmlspecialchars of $_POST?

    Quote Originally Posted by grofit View Post
    Handle reading and sending data to third parties
    Format conversion isn't a big deal unless you need legacy browser support.

    Quote Originally Posted by grofit View Post
    its just HTML writing which is more a designers job
    If you don't have a firm grasp of HTML, you have NO business doing anything you're talking about... and leveraging HTML to do what HTML does often means SIMPLER logic for the code that has to deal with it, be it back-end or front-end.

    Quote Originally Posted by grofit View Post
    because you want things to be the same way it was a decade or so ago.
    Better than dialing it back to a decade and a half ago like most of the 'current wave' of trendy nonsense is. HTML 5 and frameworks, the bleeding edge of 1997 markup meets 1970's sleaze, all while trying to behave like a 1983 Apple LISA.

    Quote Originally Posted by grofit View Post
    if you have logic you should be using a framework which abstracts the DOM, you should be testing your logic, you should be using patterns and practices, such as Inversion of Control, Loosely coupled components, wrappers around transport mechanisms (ajax, websockets etc)...
    Which all sounds rosy until it ****cans the UX, prevents you from having the slightest inkling how any of it works or even if it's being done correctly. I actually kind-of wonder if you actually know what half those mean since you seem to either be using them out of context, or just blindly parroting them because you heard them someplace. I know the terms, just not in the manner you're using them...

    Again though, shoe-horning concepts like event driven programming models into languages and environments that are inherently linear-execution single-threaded pull-only? You don't see the problem with this?

    Past six to eight years it's like 1993 all over again when databases started migrating to GUI's... poorly; It took the better part of the next decade to drag them kicking and screaming back to where they could perform well again unless you were lucky enough to still be on big iron.

    Abstractions are no good if you end up writing effectively as much code (+/- 10%) as you would without it, and separate yourself from how anything works in a manner that makes everything needlessly and pointlessly convoluted.
    Java is to JavaScript as Ham is to Hamburger.

  13. #28
    Join Date
    Jul 2014
    Posts
    11

  14. #29
    Join Date
    Jul 2014
    Posts
    2

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles