Javascript Data Binding
Copy link to clipboard
Copied
Probably the wrong forum but I'm trying to get some views.
If we are to use these new data binding javacript frameworks are we supposed to forget any possibilty that javascript may just be turn off. (I'm really not that concerned as that will apply to a small minority)
But of particular interest, is server-side validation a thing of the past - we used to do both client-side validation (the pretty stuff) and then run it through the more robust server-side validation.
Is there still any point in using a fall back server-side validation solution if what we see on the front end (assuming someone has javascript turned off) is some kind of rubbish like the below where data should be bound:
{{ formSubHeading }}
{{ showError }}
{{ responseMessage }}
The problem gets even worse if one uses a button to submit because that wont work.
<button v-on:click="submitForm">Submit</button>
Any one got any views about it?
My thoughts are if we didnt use javascript data binding but just javascript - no binding the page would still look ok and no-one would notice any difference.......it degrades gracefully and the server-side validation is in place to take over, no weird shite gets written to the page.
Maybe there is a way of hiding the {{}} in such circumstances.
My real question - is client side validation now considered to be just as robust a solution as serve-side validation given that no one gives a toss about the minority that may not have javascript. Can I just move on and forget server-side validation or if not how are you guys that are using data-binding getiing around the possibility of this {{ blahblah }} stuff being plastered all over the page plus elements that are hidden/shown using true or false:
<div v-if="showError">This is and Error</div>?
showError: false;
Well its going to show if no javascript, that could apply to numerous elements - what's so good about these frameworks, the more I delve into them they seem to me to be a bit flawed. I think they are good BUT only if they are pretty water-tight which means they need to be reliable in 99% of situations, are they?
Os
Copy link to clipboard
Copied
WolfShade wrote
osgood_ wrote
I DID prefer using a button, like many, BUT now I'm having second thoughts. If a form submit input makes it 100% sure should we not be using that......regardless of the minority who may have js disabled.....humm.
I don't rely upon that just in case a user is using an older browser that doesn't support HTML5 specs (which, yeah, I know, you'd have to go back pretty far, for that.. but there _could_ be a user in another country that doesn't have access to newer browsers.) And just because I'm old and stubborn, and my OCD brain makes me take things like that into consideration, and then I get all paranoid and want to support as many _major_ browser (IE, FF, Chrome) iterations as I can. And I just don't like using "required" and type="phone" or type="date" or any of that, and I prefer to (even though it's re-inventing the wheel) manually hard code requirements because I'm just that dang pedantic.
V/r,
^ _ ^
I get it. I'm more or less the same - paranoid.
Copy link to clipboard
Copied
Sorry to catch the train running...
while reading this thread, I must confess that I have trouble understanding,
in fact I can't grasp what the real substantive question is, let me reformulate because it seems to me that there are various questions that intersect?
1 - must the sites rely on a server-side content generation (PHP) or on a client-side dynamic generation (JS)? Pros vs Cons?
2 - then, if a client-side generation is used, what to do for users who disable javascript?
3 - finally, is the use of the NOSCRIPT tag a must and an obligation?
am I correct ?
Copy link to clipboard
Copied
https://forums.adobe.com/people/B+i+r+n+o+u wrote
Sorry to catch the train running...
while reading this thread, I must confess that I have trouble understanding,
in fact I can't grasp what the real substantive question is, let me reformulate because it seems to me that there are various questions that intersect?
1 - must the sites rely on a server-side content generation (PHP) or on a client-side dynamic generation (JS)? Pros vs Cons?
2 - then, if a client-side generation is used, what to do for users who disable javascript?
3 - finally, is the use of the NOSCRIPT tag a must and an obligation?
am I correct ?
The real question is/was:
Should we/I push ahead and use current workflows and ignore the small minority who possibily have javascript disabled.
I'd possibly in the near future like to include some of the new data-binding workflows which can be found in frameworks such as vue.js BUT Im concerned about the page if js is disabled - should I be concerned and why?
What is your opinion?
If I start using the below workflow and js is disabled, nothing will appear on the page:
<div v-for="(holiday, index) in holidays" >
<h2>{{ holidays.destination }}</h2>
<h4>{{ holiday.departure }}</h4>
<p>{{ holiday.description }}</p>
</div>
if I use a php loop through, as I normally do, then its pretty stable.
Am I just being a trendy git and stupid to use data-binding?
Copy link to clipboard
Copied
thanks OS for your clarification, this helps me to better understand the basic subject
it is also true that I should have read the object first, but well... discussions often get out of hand and sometimes we are far from the main topic
so if we're talking about dynamic data management only, and only as far as I'm concerned... and I don't present that as THE solution, I personnaly use NodeJS.
but that's only going backwards to jump better because one then have to move our point of view on two other important aspects...
the first being that if we use JS to dynamically manage the data, it goes without saying that once the user will interact with these data, they will very often have to react accordingly and therefore shape themselves, even modify and therefore load new values... so even if NodeJS, like PHP, only returns data formatted HTML... it will be necessary to use JS again
the second is implicit somewhere... because if we manage data dynamically, it goes without saying that the interfaces that host them are themselves dynamic and use interface components that are mostly managed by JS as well.
so the question becomes unique... what do we do about users who disable JS?
Copy link to clipboard
Copied
https://forums.adobe.com/people/B+i+r+n+o+u wrote
so the question becomes unique... what do we do about users who disable JS?
Shoot them maybe? That should not account for many rounds
Firefox doesnt even allow you to disable js any longer as far as I know so should'nt it just be a standard default that you can't disbable it, given that more and more websites are becoming js centric?
Copy link to clipboard
Copied
osgood_ a écrit
Firefox doesnt even allow you to disable js any longer as far as I know so should'nt it just be a standard default that you can't disbable it, given that more and more websites are becoming js centric?
about:config
javascript.enabled turn it false
Copy link to clipboard
Copied
https://forums.adobe.com/people/B+i+r+n+o+u wrote
osgood_ a écrit
Firefox doesnt even allow you to disable js any longer as far as I know so should'nt it just be a standard default that you can't disbable it, given that more and more websites are becoming js centric?
about:config
javascript.enabled turn it false
But how many normal web users will ever touch such settings?
A more accurate estimate, (and it would still only be an estimate)would be to know how many people have installed plug-ins/extensions that block or selectively disable js.
Copy link to clipboard
Copied
pziecina a écrit
But how many normal web users will ever touch such settings?
the same number as those who were used to disable JS.... unlike many comfort settings, disabling JS is a fierce and really deliberate will.... so those who have this habit, and this choice, as soon as they updated FF and discovered that it was no longer possible to disable JS, at least as easily as the drop-down menu allowed, for sure they searched for an alternative.......
Copy link to clipboard
Copied
Just looked at the downloads for the top 2 firefox extensions to disable js, (completely and selectively) and they total just over 25000.
Not a significant number, but also not a number to be ignored if it is representative of all browser type users, and one increases the total to represent browser usage, (more for chrome, less for safari desktop).
Copy link to clipboard
Copied
pziecina wrote
Just looked at the downloads for the top 2 firefox extensions to disable js, (completely and selectively) and they total just over 25000.
25k downloads in the UK or Worldwide? Both arent even worth worrying about if that is the true representation of the scale of the issue. Its likely to be far less as not all downloads are adopted.
Copy link to clipboard
Copied
osgood_ wrote
pziecina wrote
Just looked at the downloads for the top 2 firefox extensions to disable js, (completely and selectively) and they total just over 25000.
25k downloads in the UK or Worldwide? Both arent even worth worrying about if that is the true representation of the scale of the issue. Its likely to be far less as not all downloads are adopted.
Thats why I said it is only an estimate.
I think we have reached the point of simply saying that if js is disabled, providing the end user with the info that the site requires js to work correctly, is all we can do. Though I still think sites that require js for everything are just as bad as using flash was.
Canvas based sites discussion anyone?
Copy link to clipboard
Copied
I think youre right, we have come to the conclusion that the small minority who have js disabled is not worth worrying about. As for the message, l agree, but l think they would probably already know given the volume of websites using js, it would be more difficult these days to find a reasonable one that doesnt.
I will need to think long and hard as to if l go down the vue js route, maybe initially for small brochure style websites and SPAs but it they are heavily data driven l will probably stick to php for now.
Copy link to clipboard
Copied
osgood_ wrote
As for the message, l agree, but l think they would probably already know given the volume of websites using js, it would be more difficult these days to find a reasonable one that doesnt.
I will need to think long and hard as to if l go down the vue js route, maybe initially for small brochure style websites and SPAs but it they are heavily data driven l will probably stick to php for now.
The message may be worth providing, mainly because a desktop computer may be used by more than one person, (probably with lots of annoyance when one disables js and others do not).
As for applications or pages that must function in a similar manner, where js is absolutly essential, then end users must accept its use. I wonder if the rise in js frameworks had more to do with the increase of device specific apps, (such as those from app stores) and has become a 'carry over' to web sites, especially now that browsers are capable of doing almost everything that previously required a device specific app?
Copy link to clipboard
Copied
pziecina wrote
I wonder if the rise in js frameworks had more to do with the increase of device specific apps, (such as those from app stores) and has become a 'carry over' to web sites, especially now that browsers are capable of doing almost everything that previously required a device specific app?
Yes, definitely. We now call one page websites, which were frowned upon not so long ago, single page applications and they have suddenly become fashionable because of the word application when really all they are is no more than the old frameset used by some developers who objected to a page reload.
Copy link to clipboard
Copied
osgood_ a écrit
I will need to think long and hard as to if l go down the vue js route, maybe initially for small brochure style websites and SPAs but it they are heavily data driven l will probably stick to php for now.
perhaps give a try to NodeJS... you will be surprise... well under Node, look for Express... ok there are plenty interesting tools out there... but I really like Node + Express
Copy link to clipboard
Copied
https://forums.adobe.com/people/B+i+r+n+o+u wrote
osgood_ a écrit
Firefox doesnt even allow you to disable js any longer as far as I know so should'nt it just be a standard default that you can't disbable it, given that more and more websites are becoming js centric?
about:config
javascript.enabled turn it false
As Paula pointed out realistically that's not going to happen unless you're trying to be malicious. Normal users arent even going there unless they are maybe a minority group with special needs, perhaps but they will expect some funny stuff to happen if they start to reconfigure the 'default' settings.
I think we are moving away form the real question - developers, like it or not, are adopting new modern js techniques which will fail if js is disabled - why?
To me there can only be a few aswers:
1) It's now considered not important to cater for users who disable js because they are so few and far between
2) I've been using js solutions for donkies years which dont work if js is disabled, so what if I add another modern js data-binding workflow which compounds the issue.
3) Sorry I didnt know using these modern techniques would have those concequences
Copy link to clipboard
Copied
osgood_ wrote
if I use a php loop through, as I normally do, then its pretty stable.
Am I just being a trendy git and stupid to use data-binding?
2nd point first - yes, trendy git (joke). Using the new js frameworks may be 'trendy', especially when we still do not know which will eventually 'win the race' and become the most popular, (will the other then disappear?). That said using them is no different than my use of modern css to build lightboxes, carousels etc. Except that I can rely on the css versions being supported by browsers, and possibly improved upon for many years to come, (something that cannot be said for frameworks).
The 1st point - If you can present the end user with a solution that will always work, then why use a solution that may not?
Copy link to clipboard
Copied
pziecina wrote
osgood_ wrote
if I use a php loop through, as I normally do, then its pretty stable.
Am I just being a trendy git and stupid to use data-binding?
2nd point first - yes, trendy git (joke). Using the new js frameworks may be 'trendy', especially when we still do not know which will eventually 'win the race' and become the most popular, (will the other then disappear?). That said using them is no different than my use of modern css to build lightboxes, carousels etc. Except that I can rely on the css versions being supported by browsers, and possibly improved upon for many years to come, (something that cannot be said for frameworks).
Point taken about css for stuff like slideshows, modals, navs etc but css is limited in what it can do of course. I think I'm getting paranoid because I currently use javascript for stuff like allowing visitors to choose how many passengers will be travelling and then populating the page with boxes based on the number chosen, etc. So in a sense that is no different to using data-binding really, it wont work if js is disabled. I use javascript/ajax to enhance user experience for the majority. I could use php and reload the page but there is a possibilty of ugly redraw, although not much, its still is not as smooth as no page re-draw.
I guess if one is concerned about those with js disabled you would'nt use it much for anything at all, slideshows, modals, navs, etc but I dont see much, if any evidence of that, at all. It would limit you to basics or using a server-side language and accept page re-draw. It's a matter of choice I personally think - if you are concerned there are large number of users with js disabled then aviod it, if not then I think its ok to use data-binding because the website is probably not going to be any more unusable if the rest of your website already relies heavily on js to function correctly.
Copy link to clipboard
Copied
osgood_ wrote
I guess if one is concerned about those with js disabled you would'nt use it much for anything at all, slideshows, modals, navs, etc but I dont see much, if any evidence of that, at all. It would limit you to basics or using a server-side language and accept page re-draw. It's a matter of choice I personally think - if you are concerned there are large number of users with js disabled then aviod it, if not then I think its ok to use data-binding because the website is probably not going to be any more unusable if the rest of your website already relies heavily on js to function correctly.
We actually come back to a previous discussion about the use of analytics programs. The use of a good analytics program would help in deciding if a js solution is preferable over a simple server side solution, as it would tell you if end users a blocking js in any way, (not just a complete turning off of js).
ajax still requires a partial page redraw, which does present a problem for accessibility when not done correctly, though the w3c and WCAG have tried to 'fix' the problem I have not seen many frameworks that actually incorporate the standards by default. But again, a good analytics program would also help in deciding if the extra work involved is worth the time and cost of support.
I think what all of us forget in such discussions, is that we are all developing for different types of uses, with different types of sites, and in different countries and locations.
Copy link to clipboard
Copied
pziecina wrote
I think what all of us forget in such discussions, is that we are all developing for different types of uses, with different types of sites, and in different countries and locations.
Actually the real problem, even today, is its no less complicated than what it was 15 years ago when we were trying to accomodate different browsers. Yes, if time stood still an we only had the workflows we had say 6/7 years back then today would be a breeze, but time marches on bringing daily new more complex workflows, which we have to now make a decison on if to include and if to go forward or stand still.
Copy link to clipboard
Copied
pziecina wrote
We actually come back to a previous discussion about the use of analytics programs. The use of a good analytics program would help in deciding if a js solution is preferable over a simple server side solution, as it would tell you if end users a blocking js in any way, (not just a complete turning off of js).
You can't analyse something which doesn't yet exist. If you are updating a current website then that is possible.
Copy link to clipboard
Copied
Just as an example the site below is made with vue js but nothing works if you disable js:
Home | Academy of Scrapbooking and arts
One below is even worse, visit it with js enabled and then disabled
Official Wizz Air website | Book direct for the cheapest prices
A nice blank page:
Copy link to clipboard
Copied
None of those sites actually requires js, and all effects could be done using just html5 and css. I suppose they just show that for many developers now, not knowing what html and css can do is normal. After all why develop something the easy way, when you can make it complexed.
The first site linked to should come with a warning, (have those developers never heard of the rules regarding animations?).
Copy link to clipboard
Copied
pziecina wrote
None of those sites actually requires js, and all effects could be done using just html5 and css. I suppose they just show that for many developers now, not knowing what html and css can do is normal. After all why develop something the easy way, when you can make it complexed.
The first site linked to should come with a warning, (have those developers never heard of the rules regarding animations?).
Well that's really my point - why are developers using 'unneccessary' techniques that arent supported when js is disabled....they must have a good reason for doing so UNLESS they just havent even considered it. Maybe its not even worth considering.......thats what I'm attempting to get to the bottom of.
Copy link to clipboard
Copied
The problem with asking me Os, is that I would probably be bankrupt within a year if I had to develop sites such as yourself and Ben, (as examples) develop.
I've become so use to developing for 'blue chip' organisations, that normal cost considerations for other types of sites, do not even come into consideration for me. I still do not understand why anyone would make development complexed though, no matter what type of client they have, or type of site they are developing.
And I certainly cannot understand why any framework would be used over the use of web standards, (html, css, etc) if the same can be done using web standards, (I have yet to see anything that cannot, js disablement not withstanding).

