www.webdeveloper.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 29

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

  1. #1
    Join Date
    Jul 2014
    Posts
    11

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

    I have a project which is all js and html (other than a thin routing layer on the server) using knockout (with external templates) and some other techs.

    The problem I have is that the pages load the bare minimum by default. A title some meta description for the bots then it will then kickstart a chain of JS resource loading which loads up the styles, framework, the relevant viewmodels etc (which inturn go to web services to be populated with data) then once its all loaded its ready to use.

    So to begin with our first problem was that as we were loading a LOT of stuff dynamically via a resource loader we would end up having lots of *popping* in the pages, where content chunks would appear and css would be evaluated making stuff restyle and it looked ugly and in some cases if a web service was slighly bogged down a user could start doing stuff before it had fully loaded.

    So as there seemed to be no way to avoid loading this stuff dynamically (there is a long story to this, and it involves allowing user plugins which change styles and functionality as well as other smaller reasons such as web services and other async events) we thought we would put a splash screen in, which functions fine. It will load up, wait for the event to know that everything is loaded then it will fade out and the system is ready to use.

    However we were looking at SEO based improvements and as we have a splash screen and everything is loaded via async calls google and other bots struggle to index it and find links to other pages (As they wont have loaded when they scan).

    So I just wanted to see if anyone else can think of a way for us to have our cake and eat it.

    Like I said pages need to contact web services in some cases, and users may override the themes via plugins which means when loading up it needs to do dynamically load different CSS and JS so its not like I could statically write each page as it wouldn't cope with the flexibility.

    Any advice would be great.

  2. #2
    Join Date
    May 2014
    Posts
    1,020
    Really it sounds like you've done EVERYTHING wrong -- what you describe is a laundry-list of how not to build a website. I'd have to actually see the site in question to weigh in more, but "splash pages" were on every top ten list of how not to build a website last decade for a reason.

    If you care about search, and care about usability, and care about accessibility, you have to keep in mind the unwritten rule of JavaScript -- "If you can't make a site work without JavaScript FIRST, you likely have no business adding JavaScript to it!"

    How big is your average page content? What's your total CSS for the entire site? If you have more than two files per media target (like screen) and more than 48k for the ENTIRE SITE, you're probably doing things wrong. If you have to JS load your CSS, you are doing something horribly and disastrously wrong...

    Without seeing the site in question I'm stuck making educated guesses, but really it sounds like exactly the type of thing I'd tell you to pitch in the trash and start over WITHOUT all the scripttardery. You take content of value, mark it up semantically, then progressively enhance it with CSS and scripting where and only where needed. Anything else is ... well, the road to failure, which it sounds like you've just discovered a trail-marker for.

    Though there's a LOT of stuff people put on websites that IMHO has no blasted business on websites -- see 90%+ of what people do with JS.

    Oh, and never heard of "knockout" -- but after a quick Google... Yeah, start over and forget that garbage exists. It seems to be just another way to piss all over a website with "JS for nothing"... or more specifically processing stuff client side that has no business being done client-side.

    You might be all flashy and filled with "gee ain't it neat" stuff, but the result is likely all flash, no substance, and useless to visitors... and if it's useless or painful for visitors, it's probably also a disaster to search since, as Matt Cutts keeps telling us, write for the users, NOT the engine -- and that means if you can't make the site work without scripting BEFORE adding scripting to it... well, then you're not doing that.
    Last edited by deathshadow; 07-28-2014 at 05:51 AM.
    Java is to JavaScript as Ham is to Hamburger.

  3. #3
    Join Date
    Jul 2014
    Posts
    11
    Actually its probably designed better than a large amount of websites out there it just has a lot of technical leaps which require constraints in other areas. It uses the same codebase on mobile devices as well (the views are different but framework is the same).

    Knockout is one of the best approaches to designing JS webpages, (Angular, Backbone etc are equally as good before people kick off).

    So granted you cannot see the code nor the site so you cannot really gauge if I am some lunatic or actually know what I am talking about. The system depends upon javascript, its an application not a website with pictures and blurbs, it is also client side driven as it is FAR more scalable and maintainable if you just isolate your domains, we have a web service and use CORS via Ajax to call to the web service directly to the back end.

    To answer some of your questions:

    How big is your average page content?
    About 300kb on average, some pages contain more images, but most of the styling is achieved via CSS3 styles so we dont need to cheat with gradient images etc.

    What's your total CSS for the entire site?
    Each page is different, there is a default style sheet which every page uses and 1-2 shared component styles, then there is one for each page (written in LESS outputted as CSS via build script). There are however a few other CSS files required which are minified and merged as much as possible for things like colorbox and some other 3rd parties. Generally there is about 3-5 CSS files per page totalling about 20kb, however about 5kb of that is an embedded loading gif someone put in the CSS as inline data.

    If you have more than two files per media target (like screen) and more than 48k for the ENTIRE SITE, you're probably doing things wrong.
    I could minify further but there is diminishing returns on this as it is more effective to load a handful of small resources in parallel than load 1 big one up front. So we stick to 3-5. In our debug environment there is a lot more but that is because we are constantly rebuilding and need to debug issues, however for a release build its about 20k, although its a bit of a moot point these days as its all fully cached on the client until the next build is released (due to custom querystrings on the args and removal of etags).

    If you have to JS load your CSS, you are doing something horribly and disastrously wrong...
    I would not agree, in MOST situations yes something may be wrong, however as we allow re-theming and plugins on the system we need to be able to let the users change their css styles, so due to this we have a theming framework which works out what theme the user is using and then redirect to that rather than the default one, this does however require a HEAD call before hand to prove the files exist before including and default back to the original theme files if a CSS file for the users given theme does not exist.

    The CSS and JS loading is not really to much of a worry for me as its all pretty quick and cached very well, most of the problems are down to the external templates that are loaded once that template is needed, which is driven by web service ajax responses and the knockout js framework doing a data bind update with the newly populated data.

    The framework itself is amazing, we have managed to completely run a web application without a server and have the same app built off same business logic for the mobile devices (using Phonegap), we also wrote most of the framework in typescript, so we can get more reuse and compile time safety (although we do have automated functional tests and JS unit tests as part of the build script).

    Like I say this is a web application, you cannot remove the dependency on javascript as its the JS which does all the hard work, everyone is preaching about HTML5 and how ace it is, but most of them dont realise that MOST of the HTML5 improvements are JS based, so to make use of localstorage and give the users a rich application you need to use a lot of JS.

    One thing that I did find worrying was your comment:

    Oh, and never heard of "knockout" -- but after a quick Google... Yeah, start over and forget that garbage exists. It seems to be just another way to piss all over a website with "JS for nothing"... or more specifically processing stuff client side that has no business being done client-side.
    I would say that you should go read up on MVC/MVVM based client side libraries as this is the way the world is heading regardless of if you agree or not (I work as a developer and have seen countless companies picking up these techs and moving away from heavy ASP MVC or RoR servers dishing out HTML). Also in most cases your paradigm is incorrect, where you say "or more specifically processing stuff client side that has no business being done client-side." In most cases why should your server care about what you are displaying to the client, all it cares about is getting data from a database and then spitting out some html and no doubt bastardising it along the way. So why try and do more than just pass the data to the client and let it deal with how it should be displayed, as the client owns the HTML/JS/CSS. So it makes more sense and in most cases makes your app FAR more scalable to put all client related functionality into clientside. Stuff like Creating an Account, Authenticating a User and other concerns obviously need to be done at a web server level, but in most cases they can just be web services which spit out json/xml results for you to consume in your client.

  4. #4
    Join Date
    Mar 2012
    Posts
    1,641
    I'm with deathshadow on this. I may be guessing wide of the mark, but I suspect that this wonderful JS app is intended for the work environment? If so, it sounds to me, as a former business analyst, like a recipe for users to spend more time configuring their client environment than doing work! It's happened before, and likely will again. People who have little or no expertise in business analysis who think that user choice and/or shiny new technology are substitutes for good design.

    On the other hand, if it is not intended for the work environment, why does this one app need to be all things to all men? Surely that is the multi-tasking OS's responsibility? I realize that smart phones are not multi-tasking, but that is because of the pitiful information bandwidth of such devices. And if your app is slow on PCs, what is it like on mobiles anyway???
    Last edited by jedaisoul; 07-28-2014 at 09:16 AM.

  5. #5
    Join Date
    Jul 2014
    Posts
    11
    There are only really 2 main features of the application at the moment, one stores input heavy documents with lot of validation and the other one is like a chat room when they can discuss and share the documents.

    Believe it or not I am actually a well versed BA/PM in Agile and other Pragmatic approaches (although BA tasks rarely have anything to do with UX tasks), we even have CI servers, backlogs with well defined BDD (As A, I want, So that... Given, When, Then) style stories and tasks with clear acceptance criteria and tests which are run to prove the features do as expected.

    So it is an app geared towards people who fill out lots of manual paperwork and often need to edit it, so we just provide the document in one place for them to edit it as much as they want. However some people may want to add new functionality to it via a plugin. Someone may want to re-style it to make some information more prominent than others etc.

    The main high level stakeholder requirements were:

    - System to manage the input, import, export and persistence of documents
    - System to allow collaboration on the documents and conversations around the documents with traceability and document data embedding
    - Ability for plugin developers to augment the system functionality and styles


    From a technical point of view the requirements were:

    - Clearly separated client views
    - Data consumed and exposed via web service
    - Service contract sharing between all platforms (nodejs, browser, phonegap)
    - Event driven architecture for plugins to hook in and operate seemlessly

    So we have met all requirements, and I do not think removing javascript is the answer nor is throwing glitter at it in the hope that it looks pretty but is as functional as a dead fish. You have to meet in the middle, a mix of functionality and usability. We are no longer in the dark ages of the internet where Javascript is locked down by companies (some still do) and everyone just wants *cool* snow and rain effects in JS on their sites.

    HTML5 is GEARED around using JS such as Localstorage, Filereader, Canvas blitting. If we were to take Deathshadow's lead then the web would crumble back into a lot of scrolling marquees with animated gifs. So in this instance I believe (as someone with more than 2 braincells technically inclined) that the technologies being used are probably some of the best available today. Really the ONLY issue we have currently is the page popping due to dynamic resource loading, which we could do via:

    - JS Resource Loader (what we currently do)
    - Package/Module Loader (i.e. RequireJS etc)
    - Move back to a server driven HTML view where the server pre-fetches a lot of the views, so the page load time is longer but more is loaded up front (you would then need to have models defined in server language and client language for views and you would also still need some dynamic loading for custom themes and plugins)
    - Add a build step to MUNGE html, css and js into big single files (which again still requires dynamic loading at some point, its just later on)

    So really the page popping has lots of different solutions, and the splash screen is only there to hide the popping which is not ideal and is not required from a functionality point of view, it is there ironically to be a usability thing to shield the users from partially loaded pages and css element pops etc. It is not a major problem, users are happy enough although the overall web design could do with large improvements the splash screen does not bother them, it is more the SEO bots it bothers, which is why this conversation in the team started. This is just the app though, there is a wordpress front end blurby thing for users to view and get info, pictures etc (Which does not have splash screens), it is just once they click through to the application aspect of it then its a tool to be used, and granted it could possibly look a bit prettier, but functionality wise it is pretty great, and that is thanks to Knockout and the other modern techs we are using to solve business problems... this is not the early 90s, JS is here to stay and in most cases these days is used for meaningful reasons (like localstorage, ajax calls etc) not making fancy snow effects or making little flowers follow your cursor.

  6. #6
    Join Date
    Mar 2012
    Posts
    1,641
    Quote Originally Posted by grofit View Post
    There are only really 2 main features of the application at the moment, one stores input heavy documents with lot of validation and the other one is like a chat room when they can discuss and share the documents.

    ...

    So we have met all requirements...
    These two statements seem to conflict. Your design may meet all requirements, but it sounds like the majority of the app is vaporware at the moment. If so, how can you have "met all requirements"?

  7. #7
    Join Date
    Nov 2010
    Posts
    1,085
    can you guys stop arguing with the OP, please? It's not like they're going to redesign their entire project based on the fact that a couple of strangers on the internet have differing development philosophies. If he'd asked if we thought this was a wise approach this discussion may be valid, but to me it seems like you're butting heads pointlessly.

    @grofit: assuming you have callbacks and know once all your content is loaded (ie, the point at which your splashscreen would disappear) you could disable form elements (and user interaction) until everything is loaded, which may go some way to solving your first problem.

    screen popping and FOUC is trickier and depends greatly on the layout of your page, how elements are positioned, etc. You can of course set elements to have static dimensions and then load the content in or use visbility:visible|hidden to create "placekeepers". But then if your content is truly dynamic and you don't know how much of it is coming in, you may have to resort to scroll overflows (ugly, I know) or a more linear layout (more dynamic elements getting added to the bottom of the page) or keeping these elements in hidden divs or modal windows and only allowing them to be displayed once all the content is in.

    Some ideas, anyway. Hard to be more specific without seeing what you are working with (but I understand why you can't show it) and no idea if you've already discarded these approaches - hopefully something popped.

  8. #8
    Join Date
    Jul 2014
    Posts
    11
    Hey,

    Just to be clear the app is live on the internet with a small user base (and has been for months), we are not publicly pushing it until we are happy with the design and have some more features added, such as more document types supported and have our mobile application completed and out (as currently it has been in beta for a while but JQMobile was a nightmare so we keep changing technologies).

    @xelawho

    This is the problem, most of the stuff will be in the same location for the document view however the dom elements do not exist until the templates have been loaded (via ajax using Knockout External Templates), one quick fix I have thought of would be to have the build process pull in all templates into each page, however this then bloats the main page, as caching means once it is looked up once it is near instantaneous to fetch again. Also yes the entire system is event driven, so there is a central event hub which handles pub/sub model, so there is an OnPageLoaded event which is triggered when the page has loaded (this is different for certain pages as some have more dependencies than others, but the event is always triggered).

    I was going to post on SO originally but I do not think there would be 1 single answer to this hence why I came to forums to discuss the problem and the possible solutions, however I do not think I will find a *quick win* for this, the bulk of the problem stems from the web service lookups which you cannot really *fudge* like you can html templates and or js resources (as with these client side files you can append to root views in worst case). I am half tempted to just remove the splash screen and just do as you say, make everything invisible then fade it in over time as a prototype to see how it looks, but its basically gonna be same solution as splash screen, just rather than putting a curtain over it while it loads we just hide it while it loads.

    Thanks for the information though it is very applicable and I will have a think on what you have said...

  9. #9
    Join Date
    May 2014
    Posts
    1,020
    Quote Originally Posted by grofit View Post
    So it is an app geared towards people who fill out lots of manual paperwork and often need to edit it, so we just provide the document in one place for them to edit it as much as they want. However some people may want to add new functionality to it via a plugin. Someone may want to re-style it to make some information more prominent than others etc.
    Sounds like you need a native app, not a crapplet. THOUGH, not seeing why the initial load of content and style cannot be a simple flat page load, you then ENHANCE with your scripting after to allow the restyling... if they restyle, save it as a static load for later. They make an edit, you can show the edit in realtime BUT still static load next time they access it.

    I'm not sure where it "popping in" would even play into it, unless you're using hundreds of K of JS and CSS to do the job of tens of k of same.

    Quote Originally Posted by grofit View Post
    - Service contract sharing between all platforms (nodejs, browser, phonegap)
    ... and those right there I'd sooner eat a bullet.

    Though all that marketspeak that doesn't really say anything wasn't exactly blowing my skirt up. REALLY set off a lot of warning bells in my head of people who shouldn't have websites setting up the requirements for one.

    Quote Originally Posted by grofit View Post
    HTML5 is GEARED around using JS such as Localstorage, Filereader, Canvas blitting.
    Two of which are NOT HTML 5 whatsoever, and one of which shouldn't be since there's NO legitimate reason for it to even have a tag being a scripting only element. The new scripting is NOT HTML 5, no matter how many people shove it (and the CSS3 stuff) under 5's banner.

    But to be fair, my list of 'useful' things added in 5 consists of manifest and... well there's... uhm there's... well there's manifest for making crapplets.

    Quote Originally Posted by grofit View Post
    If we were to take Deathshadow's lead then the web would crumble back into a lot of scrolling marquees with animated gifs.
    BWAHAHA.... not quite -- since those to are on the PREVIOUS decades "how not to build a website" alongside things like splash pages. Crazy me believes in accessible delivery of content on websites, and a rabid hatred of how all these HTML 5 crapplets are pissing on the usability of the web. See how AJAX-tards have taken webmail, which a decade ago I was thinking was going to kill off mail clients -- and has sent users like myself running and screaming back to mail clients thanks to the buggy, broken, slow, browser crashing script-tardery. Most of what you're talking about is to me the same thing as those marquees and animated gif's; crap that gets in the way of what's important -- delivering content to users in a speedy and accessible fashion.

    Quote Originally Posted by grofit View Post
    So in this instance I believe (as someone with more than 2 braincells technically inclined) that the technologies being used are probably some of the best available today. Really the ONLY issue we have currently is the page popping
    Which if all you're loading is CONTENT, I'm not sure what you mean by 'popping' other than *SHOCK* content appearing -- unless you're loading a bunch of other garbage or don't have how you're plugging it into the page properly handled... but of course if all you've done is slap together a bunch of off the shelf framework nonsense, what did you expect? You start out with megabytes of scripting and endless server-side overhead for nothing all to avoid the dreaded pageloads (which is what it sounds like you've done) before you even think about the content, and you expect that to end up useful to users? Bwhaahahaa.... oh man, you slay me.

    But again, WILD GUESS with no concrete information to base it on... apart from your listing a bunch of bloated crap that to be frank, likely has no business on a website in the first place.

    Quote Originally Posted by grofit View Post
    - JS Resource Loader (what we currently do)
    - Package/Module Loader (i.e. RequireJS etc)
    - Move back to a server driven HTML view where the server pre-fetches a lot of the views, so the page load time is longer but more is loaded up front (you would then need to have models defined in server language and client language for views and you would also still need some dynamic loading for custom themes and plugins)
    - Add a build step to MUNGE html, css and js into big single files (which again still requires dynamic loading at some point, its just later on)
    The first two of those reek of "Good god man, throwing more code at it is not the answer"... The latter two sounds like... well... so poorly worded I'm not quite sure what it even means.

    ... and I'm not saying you can't enhance it with scripting for the functionality, but you've taken a bunch of shortcuts in the form of sleazy frameworks and off the shelf solutions -- making it sound like you probably have megabytes of scripting for nothing, and if there's a problem with how content is "popping in", there's probably a problem with your ajax or how you're using the scripting to plug in that content -- laughably much of that could probably be avoided if you just had normal page-loads when people go to a different page... use the scripting and AJAX for when things are changed by the user in realtime, NOT for when they are loaded from the server!

    Which is a mistake I've seen a LOT of people using that MVC 'event driven' nonsense encounter with the web, since event driven + web delivery === /FAIL/ no matter how many "experts" seem to be claiming otherwise with their fat, bloated, massively stupid megabytes of scripting for nothing.

    But then where most people use 100k of markup, 50k of CSS, two megabytes of images and a megabyte of scripting totalling dozens if not hundreds of files, I use 72k in a dozen files or less. If I can't fit it into those restrictions, I start hacking away the rest as a bad idea.

    Mind you, you're building an applet, so it should be bigger than a normal website, but sleazing together a bunch of off the shelf code is going to be crap. It always is. I've NEVER seen ANYTHING built with that type of nonsense that wasn't a train wreck of ineptitude and ignorance.

    Though again, we're all just making wild guesses based on what you're saying and our own experiences with the tech you're talking about -- To be frank, you're not going to get a real answer from anyone without showing what it is you're working on -- no code, no page, no demo, no real answers other than rampant speculation. You're asking us to do brain surgery through a key-hole without an endoscope.

    Even just a information -> document size from FF's web developer toolbar (assuming the scripttardery doesn't make the browser lie) or a waterfall of an average pageload would speak volumes about where the problems lie. HOW MANY scripts are being loaded? How big are they? How many requests does a user change create? How many requests are made when you load a 'content' section using the scripttardery? How many separate CSS files are they? How are they loaded? When? Where? By what means?

    Without that? Good luck getting a proper answer from anyone. It could be as simple as your load order and where you're placing scripts in the markup, and using AJAX to do a normal pageloads job. For all the TALK about AJAX being faster/cleaner than pageloads, if your markup isn't crap, and you're not building 90% of it on the DOM using scripting, using a normal page load is going to be way smoother, cleaner and reliable than anything you can do with JS... in the same "good god man, throwing more code at it isn't the answer" way.

    McCoy: "My God man, drilling holes in his head is not the answer! The artery must be repaired!"

    But again, wild guess since you've provided... nothing of substance for any of us to give a real answer on.
    Last edited by deathshadow; 07-28-2014 at 06:21 PM.
    Java is to JavaScript as Ham is to Hamburger.

  10. #10
    Join Date
    Jul 2014
    Posts
    11
    I dare not post a link lest you send your html zealots to destroy it and build a church dedicated to bad practices and classic ASP upon it.

    Now what you term as *craplets* (its not an applet by the way, that is a java only embedded thing), is just what the modern age calls a web application. Not a web SITE, this application is not there to give information or show pictures (in the context of information), there is a wordpress front page for that, so no problems there the content aspect of the system is served fine and is pretty helpful, we also have a helpdesk which also hooks into it all, so have no fear, the users who do not want functionality out of the internet and just want static pages can get their fill from those components.

    Now just so others do not stumble across this grisly thread and somehow take your word as gospel, I just want you to quickly nip over to Wikipedia (it is mainly static content so don't fret) and view the entry on HTML 5 Features.

    To quickly touch upon some of your other misguided points:

    Mind you, you're building an applet, so it should be bigger than a normal website, but sleazing together a bunch of off the shelf code is going to be crap. It always is. I've NEVER seen ANYTHING built with that type of nonsense that wasn't a train wreck of ineptitude and ignorance.
    AngularJS, KnockoutJS, Backbone, Ember etc etc

    There are a lot of JS view based libraries, and I would say you are MORE likely to see a trainwreck of ineptitude and/or ignorance without using some form of convention and pattern when interacting with HTML and JS. Yes I know your comment to this will be "We do not need JS" or something to that effect, however when you move past web SITES (which provide information and content) and move to web APP (provide functionality and do a job) then you need to be able to write that logic in the most sane way possible, often using best practices for separation such as MVC and MVVM. If you do not like it then thats fine, however I fear you do not grasp the problem these libraries seek to solve, and if that is the case that's fine, however I would not seek to influence others usage of good patterns and practices because of your own lack of education on the subject, not knowing something does not mean that thing is not worth knowing.

    Even just a information -> document size from FF's web developer toolbar (assuming the scripttardery doesn't make the browser lie) or a waterfall of an average pageload would speak volumes about where the problems lie. HOW MANY scripts are being loaded? How big are they? How many requests does a user change create? How many requests are made when you load a 'content' section using the scripttardery? How many separate CSS files are they? How are they loaded? When? Where? By what means?
    You asked for this information, I provided it. If you were not happy to read the text and want an image I shall provide one for you to peruse at your leisure:

    http://postimg.org/image/6w1kj2hef/

    Each page is different, they all load the same basic libraries and frameworks, but generally each page has its own unique css file and js file, so its another 2 calls. One thing to note, is that some of the includes are from loading freshdesk widget (to allow users to search knowledge base or report issues/get help), then at the bottom a large amount are images. However 362kb for a page is not a mammoth amount, and also if you look 349kb of that is cached anyway so takes little overhead. Some areas I have blurred to keep anonymity of the project as it is not really important. Also as I mentioned there are external templates used for some components so that is why there is a perceivable gap between certain things loading, on average the main content is displayed within about a second then the data entry elements are loaded in afterwards and in most cases its just images which are loaded as and when needed but are often cached anyway.

    Sounds like you need a native app, not a crapplet. THOUGH, not seeing why the initial load of content and style cannot be a simple flat page load
    There are plenty of native applications that do this already, but not many cloud based ones, so the idea here is that you can access this functionality from any computer with a web browser that supports HTML5 features. The initial load of content is a page with a head, body and some static (ish) content, however as within the body there is some data entry and dynamically loaded things it would pop in once the web service has fed the data down, so the splash screen (which is an element on the page set to be full width/height until page is loaded then hidden) just hides it from the user until its ready to be viewed, it can be disabled or removed without any functional issues. We could do a post build step which would munge dynamic templates into the relevant pages as an optimisation for this instance of the system however then initial page loads go up a bit more and the data wont be cached so it ends up meaning more page loads and bandwidth used in the long run. Once the pages are loaded once it is pretty quick to get again as most of it is cached (although the server we are using seems to be ignoring the etag removal).

    (context of service contracts) ... and those right there I'd sooner eat a bullet.
    Do you actually write web applications or do any data driven activities? if you do not want to have service contracts with your data layer how else can you separate it and have other consumers adhere to a standard. If I tell you there is a web service out there for you to connect up to and retrieve your user data for your app, how are you going to interact with it? sure I can give you an API you can adhere to and write your own model which would look identical to the ones provided. Also we scrapped C# and ASP.NET and moved to nodejs as then we are not maintaining 2 different code bases representing about 40% of the same stuff, so in this case we can re-use a large portion of our TESTED and PORTABLE code between platforms, meaning less development time, less maintenance time. Yes granted this means 0 to the consumer but if we can turn around features and keep the system stable easier then its a win for everyone in the long run, if my ONLY worries are pages popping a bit then that is pretty good going.

    But to be fair, my list of 'useful' things added in 5 consists of manifest and... well there's... uhm there's... well there's manifest for making crapplets.
    I am sure you are happy with HTML 1 spec, however the rest of us moved on and wanted to let the web do more, why have a noddy application you need to install to do job X when you could move it to the internet and access it anywhere with backed up cloud based services and then even access it on your mobile phone. Web based applications are surging in popularity these days because web *DEVELOPERS* have been given the tools to make the web do more, the angle you come from is web *DESIGNER*, and that is a valid perspective, however both perspectives often need to meet in the middle.


    I have reached my allotted internet discussion quota for this morning at this point so I shall bow out here and maybe come back later in the hope that there is another gem for me to view.

  11. #11
    Join Date
    Mar 2012
    Posts
    1,641
    Quote Originally Posted by xelawho View Post
    can you guys stop arguing with the OP, please? It's not like they're going to redesign their entire project based on the fact that a couple of strangers on the internet have differing development philosophies. If he'd asked if we thought this was a wise approach this discussion may be valid, but to me it seems like you're butting heads pointlessly.
    Fair comment. However, given the nature of the system, I think that it is beneficial to discuss it in a wider context: Is this the future of web-delivered systems? So I'll just make the following observations, then I'll butt-out...

    @ grofit

    Looking specifically at the following comments:

    However we were looking at SEO based improvements and as we have a splash screen and everything is loaded via async calls google and other bots struggle to index it and find links to other pages (As they wont have loaded when they scan).
    The main high level stakeholder requirements were:

    - System to manage the input, import, export and persistence of documents
    - System to allow collaboration on the documents and conversations around the documents with traceability and document data embedding
    - Ability for plugin developers to augment the system functionality and styles

    From a technical point of view the requirements were:

    - Clearly separated client views
    - Data consumed and exposed via web service
    - Service contract sharing between all platforms (nodejs, browser, phonegap)
    - Event driven architecture for plugins to hook in and operate seemlessly
    There seems to me to be three fundamental errors in the above:

    1. If SEO matters to the viability of the system (which it appears it does), the ability of bots to evaluate the pages should be a major requirement, not an after thought!

    2. There is no response time requirement.

    3. The ability to hook in plugins should be a "nice to have" that is contingent on meeting 1 and 2 above.

    Can you honestly say that if 1 and 2 had been requirements, and 3 was contingent on them, that you would have adopted the design that you have?

  12. #12
    Join Date
    Jul 2014
    Posts
    11
    I would not say this is the future of ALL web delivered applications, it is just a way which we have created ours, if there was no need to external augmentations then you could probably remove a lot of the dynamic loading (we can still do so during this optimisation phase, but every time we do an optimisation to this we make it harder to maintain, so its a balancing act). You can easily have a more static version, and this is possibly why people do not make sites which can be modified at runtime. You could easily use Knockout and all the other techs we have used in a one page app, or as a full website without any external templates, we did it as it makes maintenance easier and means we can run the system without any web servers (i.e mobile devices, which can only load HTML and do not have servers to graft partial views together etc).

    - SEO like any optimisation should be an after thought not a design goal in my opinion, it is important, as it should be to all people, however we tried to put functionality first ahead of design and search engines. Which yes in hindsight may not have been the best of decisions but we have the flexibility to alter the way a lot of the system is put together as it is very flexible and separated. This is one of the reasons this conversation came about because we have met our functional goals for the initial rollout, however we are now looking at optimising and improving certain aspects. One other KEY thing to mention here is that our SEO is mainly poor because there is little content on the applications pages, its all functionality so even if we didnt have the splash screen there would only be a few more links for the SEO bots to read (granted that makes a difference) but this is not a content heavy site, it is a functionally heavy site (which is why design is such a nightmare).

    - Response time was not a hard requirement as it is based upon lots of varying factors, such as our current web host is not the best but as this is a prototype there is not big bucks being spent on infrastructure yet. Also the initial response with header and body etc is VERY quick, so the user gets a page almost instantly as its like 4.2kb, then the page is enriched which adds the functional components to it which takes about a second. We deem that fast is fast enough, we can shrink the page load time by grouping icons into iconsheets, making certain libraries at the start outside of the dynamic loading framework (which is something we are looking at currently). We are planning to move to a far better server shortly and look at other techniques at the web host level of optimising out page load times, however we are lucky as we have a LOT of things we can improve.

    - If plugins were not a requirement the system would have been design differently, and originally it was. A long time ago it was a purely ASP MVC app without a web service, then it became a web service with MVC app, then it became an MVC app with some rich clientside stuff, then it became mainly clientside and the MVC layer was removed entirely and the client went straight to the web service. So it has gone through multiple iterations to become what it is now. However the plugins are one of the aspects that will differentiate us from our competitors and give the community more input on how they want to consume the system. As currently most web apps give you a fixed functional offering, you can possibly integrate with 3rd party systems which consume your data in some way, but hardly any give you the ability to modify the actual application. It may not be a success, who knows I just do as I am told however I must admit it is something I have never seen before and has been exciting to work upon and from the users point of view can mean they have almost endless possibilities for augmenting the system (assuming people adopt plugin development) so everyone wins.

    Like I say above we are now reaching out *optimisation* phase, so we are streamlining our current architecture for the back end and we are also looking at improving overall design (look and feel) and SEO wherever possible, but we can get by with the SEO from the primary site which has all the content, it would just be nice to add any quick wins into this bit as no one likes splash screens, but in this scenario it was added to solve a usability problem, not as a core feature. I do not really think that altering your functionality to get a few more SEO points should be that important, its like making food look nicer but it tastes poor, granted more up front money doing it that way though

  13. #13
    Join Date
    Jul 2014
    Posts
    2
    I just registered just to comment on this thread.... WTactualF guys...

    top ten list of how not to build a website last decade
    If your basing anything off of a top ten list from the past you have issues, big fat retarded ones. The web is moving so fast not pushing boundaries on new builds is dangerous, Henry food famously said “If I had asked people what they wanted, they would have said faster horses.”, and OP isn't even talking about revolutionizing or train blazing with some tech no browsers support.

    you have to keep in mind the unwritten rule of JavaScript -- "If you can't make a site work without JavaScript FIRST, you likely have no business adding JavaScript to it!"
    No, javascript is here to stay, deal with it. Search engines are starting to spider post javascript execution and even the smallest devises support it, accessibility wise even the free NVDA screen reader is happy to play with SPA's never mind JS heavy web apps.

    ... there is so much I could rant about regarding many many points, but I'm going to stop myself before I find I have worn out my keyboard through rage typing.

    Talk about stifling progress and innovation!

  14. #14
    Join Date
    May 2014
    Posts
    1,020
    Quote Originally Posted by grofit View Post
    I dare not post a link lest you send your html zealots to destroy it and build a church dedicated to bad practices and classic ASP upon it.
    Funny since what you're doing is what I've learned is bad practices. It's kind of funny to be on the recieving end for a change, since most of what you're accusing me of is what I spend most of my time on forums accusing others of.

    Quote Originally Posted by grofit View Post
    Now what you term as *craplets* (its not an applet by the way, that is a java only embedded thing)
    No it isn't -- we used to call VB applications crapplets -- bloatware that comes with proprietary OS installs crapplets -- almost a decade before Java was a twinkle in James Gosling's eye. Hell, first time I think I ever heard the term was in reference to what people were slapping together with hypercard on the Mac... Though it VERY quickly came to refer to most anythign built with Visual Basic by the '90's.

    Crapplet is any in-house application of dubious functionality and even more dubious construction techniques; see the train wreck known as Metro apps for a slew of what most certainly qualifies as a "crapplet".

    Quote Originally Posted by grofit View Post
    and view the entry on HTML 5 Features.
    Which is full of "truthiness" since most of what's listed as features HAVE JACK **** TO DO WITH A MARKUP SPECIFICATION; The only things listed there that qualifies is CANVAS, and that's JUST because it has a "tag for no reason". (literally there's no reason for it to even have a tag), MANIFEST (ooh, one attribute), and probably CONTENTEDITABLE.

    The rest is JavaScript -- no, scratch that -- ECMAScript (let's use the right term) or CSS3 -- and news flash, there's NOTHING stopping you from using the rest of it in the previous document models because *NEWS FLASH* they are not MARKUP!

    Though it might help to read your own links...

    Not all of the above technologies are included in the W3C HTML5 specification, though they are in the WHATWG HTML specification
    ... and the reason they're not included is they have exactly two things to do with writing markup...

    Quote Originally Posted by grofit View Post
    There are a lot of JS view based libraries, and I would say you are MORE likely to see a trainwreck of ineptitude and/or ignorance without using some form of convention and pattern when interacting with HTML and JS.
    Assuming said form or convention has ANYTHING to do with how web technologies work -- assuming you aren't using a fat bloated 100k library WITH 10k of your own code to do what 10k or less of code without the library can do... which is usually what you end up with using off the shelf librarys slapped together.

    NOT saying "you don't need js" -- I'm saying you don't need the massive pointless frameworks for the simplest of tasks like data exchange.

    Reminds me of the late 70's garbage I used to deal with in DiBol or FOCAL, where people were charging by the K-Loc so they padded out their code with extra bloat just to increase their paycheck -- I made a decent chunk of change just by going around and charging to REMOVE the bloat from software written by others.

    But then that was my bread and butter in the late '90's and early part of the previous decade -- going around and cleaning up other people's messes.

    Quote Originally Posted by grofit View Post
    often using best practices for separation such as MVC and MVVM.
    assuming they are best practices and not just being bantered about like sick buzzwords -- or worse, best practices from OTHER languages/delivery methods that are NOT best practices with a web technology. MVC in particular suffers from this with most "frameworks" for doing it again wasting megabytes of code to make it more complex, slower, and generally more code to deal with than if you just wrote it using the native functions of whatever language you have under the hood. PHP sees this a lot; most of the people finding things like "

    Quote Originally Posted by grofit View Post
    however I fear you do not grasp the problem these libraries seek to solve
    More like I dont' grasp why people turn something simple into a problem by using them. Making more work and slower sites or even applications is great long-term battle-plan... NOT.

    I've been programming for well over three and a half decades -- I'm getting sick of seeing people making the same mistakes over and over again, and calling it the future... Take HTML 5, which people call the future, and so far as being a markup specification is concerned (which sets aside 99%+ of what you're talking about) reeks of the worst of pre-strict 1997 style development practices. For all intents and purposes it's "the new transitional".

    She's alone in the... new pollution...

    Quote Originally Posted by grofit View Post
    however I would not seek to influence others usage of good patterns and practices because of your own lack of education on the subject, not knowing something does not mean that thing is not worth knowing.
    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)

    Quote Originally Posted by grofit View Post
    You asked for this information, I provided it.
    WHERE? I just re-read the whole thread, nowhere to be found. Also that blurry screencap doesn't help a whole lot, since you didn't scroll down and paste together the rest so we can see all 35 files -- and would help if you didn't blur the EXTENSIONS -- and would help if your waterfall was done properly with caching disabled to see first-load impact and full sizes since 304's aren't a true waterfall -- BUT

    It looks like you haven't leveraged CSS sprites, you've got more separate js files than is probably necessary, and you've used the disastrously bad "bootstrap" the last of which results in more CSS, presentational markup, and massive code bloat -- much less the size of the garbage frameworks involved delays rendering as it's more to parse -- which is why looking at what you have there I suspect I could recreate the same functionality in a third the code and half the file-count.

    Seriously, developers are dumber for bootcrap even existing. Do yourself a favor and get a stick to scrape that off your boot with! You want the page to load smoother and update better when you manipulate the DOM or plug in InnerHTML, don't use a CSS framework as it's more rules that have to be applied delaying the render!

    Also, avoid innerHTML if you can as it's a major contributor to the behavior you're complaining about -- hence why jQuery's way of plugging in content is often crap -- though if you have to (and there are cases where appendChild/createElement just isn't up to the job) do it to a new element (like a DIV) not attached to the DOM, then plug that element into the DOM. That way you are only parsing that one element and it's child in a non-render context, then adding it to the DOM so you don't have a total page reflow.

    Again, not saying you can't use scripting, just don't trust how frameworks do things! Most people using and writing frameworks don't know enough about the underlying language for anyone to be taking advice from them! (same goes for a lot of off the shelf CMS and blogging systems -- view source what most turdpress themes vomit up and call markup for proof enough of that -- or worse, actually look at wordpress' source and it's "security, what's that" development practices)

    ... to be continued (10k post limit is ridiculously tiny... but then there's a reason I can't use Twitter)
    Java is to JavaScript as Ham is to Hamburger.

  15. #15
    Join Date
    May 2014
    Posts
    1,020
    Quote Originally Posted by grofit View Post
    Each page is different, they all load the same basic libraries and frameworks, but generally each page has its own unique css file and js file, so its another 2 calls.
    Two calls shouldn't be a big deal if everything else (all those libraries and frameworks) is already cached... have you set up cache-control? Usually I consider manually dicking with the browsers caching models to be sweeping bad developer habits under the rug... That really shouldn't be an issue with pop-in... though again, a proper page-load instead of ajaxing in content might actually render smoother. Then you can pull the content from the DOM in your scripting.

    ... though that's assuming you're ajaxing in the content instead of using a normal page-load. That's what I was talking about -- it's usually faster to let HTML do what HTML does, then enhance it with scripting than it is to AJAX in stuff; that's the real laugh of it is the die-hard AJAX zealots claim it's somehow magically faster when the reality is... well... dubious.

    If you insist on that route, have you considered trapping onload for the new JS and CSS and waiting to add the new content until after. It would physically take longer, but often placebo's users into thinking it's faster. (hanging the render, something Google says not to do with "blocking" scripting, can often have the same effect despite their "pagespeed" tool's claim to the contrary!)

    Though a multi-request can sometimes actually be faster. Request a small file that says what JS and CSS is being included in addition to the content, then start loading those (by slapping them on the DOM) while the content download is still in progress -- the extra handshake can be worth it if you're only loading in three or four new files as you can start the extra ones sooner. Parallelism -- gotta love it. Just hold onto the content response until after the CSS for it is loaded. If you are lucky, the new JS and CSS will load before the content finishes downloading...

    Though cutting down on the number of existing CSS rules would probably pay bigger dividends.

    Again though that's assuming you're using AJAX to load the content -- which would be the only real reason for the issues you're having. Again, I'd build it server-side as proper markup with a real page-load and then only use scripting to dynamically update it and/or save changes.

    Quote Originally Posted by grofit View Post
    One thing to note, is that some of the includes are from loading freshdesk widget (to allow users to search knowledge base or report issues/get help), then at the bottom a large amount are images.
    Still, since many of those images appear to be tiny icons, leveraging CSS sprites could reduce the handshake count. Remember "real world" guesstimates put each handshake past the first 8 at an average of 200ms apiece, though it can range anywhere from 90ms (best case sitting on top of the server) to a massive full second each. Suddenly that 35 files is taking 20 seconds for some people. ...and before the peanut gallery chimes in with the "but it's fast for me" crap -- how nice for YOU. Too bad what it does for YOU is NOT what it does for everyone else! -- Sorry, pet peeve.

    Quote Originally Posted by grofit View Post
    However 362kb for a page is not a mammoth amount, and also if you look 349kb of that is cached anyway so takes little overhead.
    It's big, but certainly NOT as bad as most... though probably does NOT count any AJAX requests towards it -- part of what makes diagnosing what you are asking difficult.

    Quote Originally Posted by grofit View Post
    there is some data entry and dynamically loaded things it would pop in once the web service has fed the data down
    Is it at ALL possible to pull that on the server and send it as part of the page load? Maybe cache the pull server-side if it's dynamically generated content so it loads faster?

    That would be my biggest advice -- having the scripted pull is fine if it's data that updates frequently while the visitor is on the page, and I'd consider doing that in addition to server-side processing -- but if it's at all possible plug it into the markup BEFORE you send it client-side... and if possible, when it's different pages on the same site, just use a normal page request instead of the AJAX.

    Quote Originally Posted by grofit View Post
    Do you actually write web applications or do any data driven activities?
    In terms of web apps I've written some -- it's why I'm not wild about them; the piss poor performance even when fully optimized, battery draining hell on mobile devices, and general inaccessibility that goes hand-in-hand with them doesn't really blow my skirt up; particularly since as a USER I've found most of them to be pretty much crippleware.

    In terms of data driven activities, I spent most of the '80's and '90's writing corporate databases, and still maintain a double entry accounting system that multiple-users can access in real time that is very popular with mortuaries (It's all about finding a niche) -- which five years ago I moved from being an old Paradox for DOS program -- some people STILL use that version -- to an online accessible one.

    Quote Originally Posted by grofit View Post
    if you do not want to have service contracts with your data layer how else can you separate it and have other consumers adhere to a standard.
    ... and that's what I meant by marketspeak; that reads like someone taking technical advice from the pages of Forbes, which to be frank is akin to taking financial advice from Popular Electronics. You might as well have thrown "proactive" and "paradigm" in there for good measure.

    I'm not sure what the hell a service contract even has to do with a data layer -- and after some 30+ years of database programming it sounds to me like you mis-used half the words in that sentence.

    Quote Originally Posted by grofit View Post
    If I tell you there is a web service out there for you to connect up to and retrieve your user data for your app, how are you going to interact with it?
    I would assume it uses a standard data format like CSV, XML, JSON or ASCII control -- in which case what's the issue?!? Those are moronically simple, if you need help in the form of some framework to deal with those you probably have no business dealing with those. GET and POST requests aren't hard... return data usually isn't hard. People MAKE it hard by over-working the plumbing.

    Quote Originally Posted by grofit View Post
    I am sure you are happy with HTML 1 spec
    HTML 4.01 STRICT or XHTML 1.0 STRICT actually -- which is why HTML 5 pisses me off since as a markup specification it seems carefully crafted to undo the past fifteen years of progress in terms of ease of development, and instead seems designed for the people who never embraced strict, and up until a few years ago were vomiting up HTML 3.2 and slapping 4 tranny on it. Now they slap 5 lip-service around the same broken, outdated practices and get to call it "modern" and "the future"? Colour me unimpressed. The pointlessly redundant "structural" tags, the elements that are scripting only and as such have no business in a markup specification (they belong in the scripting specification), the loosening of structural rules back to the worst of pre-strict behaviors, adoption of tags that were rejected a decade ago as redundant... It has to be one of the dumbest changes and the ONLY real reason it seems popular is it being a media darling and being thrown about as -- again -- a sick buzzword akin to "web 2.0".

    ... and again, most of the cool stuff people call HTML 5 has not one blasted thing to do with writing markup, and as such is NOT HTML.

    Quote Originally Posted by grofit View Post
    Web based applications are surging in popularity these days because web *DEVELOPERS* have been given the tools to make the web do more, the angle you come from is web *DESIGNER*, and that is a valid perspective, however both perspectives often need to meet in the middle.
    Ooh, dem's fighting words!

    See, to me "designer" has a severe negative connotation attached to it, as most people who call themselves that are PSD jockeys pissing out goofy pictures of what a website might look like without enough knowledge of HTML, CSS, emissive colourspace or accessibility norms to be "designing" jack ****. I lump them alongside all the other nube predators like the snake oil doctors who run SEO as a business or the scam artists who sell "templates" on TemplateMonster/ThemeForest, or build websites just to sell them on Flippa. There's a comparison I often make that I now can't here -- last time I did I got a warning from the moderation staff; Let's just say I consider them the lowest of the low...

    We just have a different development philosophy -- even for what you describe it sounds like you took something simple and made it hard; a common mistake amongst those who don't take the time to learn whatever underlying language is being used, and dove instead right for the code bloat that are frameworks.

    But again, wild guess.
    Java is to JavaScript as Ham is to Hamburger.

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