Javascript Data Binding

[osgood_]

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

[WolfShade]

osgood_  wrote

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.

IMHO, no, server-side validation should never be ignored.  Hackers and script-kiddies can do some pretty malicious stuff if you rely only on client-side.  Keep doing both, or if you're in a bind for time use only server-side.  Server-side also has the benefit of using masks and whatnot to make sure that user-submitted values are properly formatted, and if you're using something like ColdFusion (either ACF or Lucee) you can use canonicalize() to decrypt encoded input, and even throw an error if nested or multiple encoded input is submitted.  (VERY nice.)

But definitely use oWasp ESAPI on your server for stuff like that.  I know that HTML5 introduced a lot of things like making fields required and default show an error if it isn't, or input type="phone" or type="date" and whatnot, but I don't rely on any of that.

HTH,

^ _ ^

[osgood_]

WolfShade  wrote

osgood_   wrote

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.

IMHO, no, server-side validation should never be ignored.  Hackers and script-kiddies can do some pretty malicious stuff if you rely only on client-side.  Keep doing both, or if you're in a bind for time use only server-side.  Server-side also has the benefit of using masks and whatnot to make sure that user-submitted values are properly formatted, and if you're using something like ColdFusion (either ACF or Lucee) you can use canonicalize() to decrypt encoded input, and even throw an error if nested or multiple encoded input is submitted.  (VERY nice.)

But definitely use oWasp ESAPI on your server for stuff like that.  I know that HTML5 introduced a lot of things like making fields required and default show an error if it isn't, or input type="phone" or type="date" and whatnot, but I don't rely on any of that.

HTH,

^ _ ^

Yeah I was so consumed I forgot about those, was just editing my post when you posted:

Edited. I guess I ought to include the serverside anyway just for bots/spammers (forgot about those) BUT is anyone really concerned about the page presentation or maybe not being able to click a button to submit........that's my real concern. I dont care about malicious attempts because I don't care what they see.?

I guess for the few its just bad luck - gotta move on I guess and use current workflows.

[osgood_]

osgood_  wrote

WolfShade   wrote

osgood_    wrote

Keep doing both, or if you're in a bind for time use only server-side.  Server-side also has the benefit of using masks and whatnot to make sure that user-submitted values are properly formatted, and if you're using something like ColdFusion (either ACF or Lucee) you can use canonicalize() to decrypt encoded input, and even throw an error if nested or multiple encoded input is submitted.  (VERY nice.)

I think its a case of igonring the possibilty of the minority who might not have javascript but still including server-side to prevent malicious attacks. If the page looks a mess to either so be it.........I guess.

[pziecina]

As you say, probably the wrong site to ask such a question, but as far as js frameworks are concerned, it depends on which you use. Some such as angular and node also work on the server, so client side and server side validation can still be done using them. As for hiding the js code you could still use the script / noscript tag, and angular presents the user with an html page served from the server, as it works much the same as wordpress but using js instead of php.

The only reason I can see for using such js frameworks is if you are happier or more skilled using js than a traditional server side language such as php or c#.

[osgood_]

pziecina  wrote

As you say, probably the wrong site to ask such a question, but as far as js frameworks are concerned, it depends on which you use. Some such as angular and node also work on the server, so client side and server side validation can still be done using them. As for hiding the js code you could still use the script / noscript tag, and angular presents the user with an html page served from the server, as it works much the same as wordpress but using js instead of php.

The only reason I can see for using such js frameworks is if you are happier or more skilled using js than a traditional server side language such as php or c#.

I dont really see the point in using the noscript tag as it wont improve anything really - only maybe to hide the {{ blahblah }} rubbish but if some information needs to be seen and it is integral to the layout it wont be either way, if js is turned off..........hummm.

I guess my next question is are these js data-binding frameworks like angular, react, vue etc just a load of old tosh or do they actually bring something to the playng field other than being trendy?

I quite like how vue works but I have to convince myself to forget the possibilty of a javascipt-less user coming to visit. I think its only because I can guarantee better blanket coverage if not using the data-bindings approach BUT couldnt the same be said about the possiblty of a user who's broswer doesnt support flexbox or grid.........humm I seem to be spending more time thinking these day than actually doing anything

Im better at php and its guaranteed solid but I also need to consider the user experience not that data-binding adds anything to the user experience it just make me feel current but I'm concerned its not as water tight as other tried and trusted approaches.........dont even get me onto securing a page with a front end framework when php can do it in about 3 lines of code.

I've yet to read a convincing article about the benefits of data-binding stuffing up the code with copious amounts of directives and I'm not so sure vue is any less spaghetti like than jquery or vanilla js is once you start fleshing out the component you're building.

[pziecina]

I've not used vue so cannot say anything about it. For me all these new js frameworks bring nothing to the table that we do not already have, which is why I think they are primarily for js coders, they solve no problems but only add to them.

The main difference between a spec such as flexbox not being supported and js being turned off, is that fallback for a w3c spec, (none js api) is not a 'show stopper', but js being turned off would be for a js framework if it is used for layout, styling and functionality on the client side.

[osgood_]

pziecina  wrote

I've not used vue so cannot say anything about it. For me all these new js frameworks bring nothing to the table that we do not already have, which is why I think they are primarily for js coders, they solve no problems but only add to them.

Problems dam right there...........I think web-developers don't really feel fulfilled unless they are solving problems, mostly those of their own making

pziecina  wrote

The main difference between a spec such as flexbox not being supported and js being turned off, is that fallback for a w3c spec, (none js api) is not a 'show stopper', but js being turned off would be for a js framework if it is used for layout, styling and functionality on the client side.

Well it could be a right mess.......even more so using data-binding and that's my real concern BUT I think its only a concern because there are workflows which can avoid the possibilty BUT how great is that possibily, pretty slim but its still a nagging doubt for me currently.

[pziecina]

Lets take your form validation -

If you use a js framework and js is turned off = no form validation

If you use html5 form validation and js is turned off = form validation still works.

Data bindings, (if you must use them) do require js, but why use a js framework, (sledgehammer approach) when good old 'vanilla' js will work?

https://gist.github.com/austinhyde/4321f22a476e1cbee65f

[osgood_]

pziecina  wrote

Data bindings, (if you must use them) do require js, but why use a js framework, (sledgehammer approach) when good old 'vanilla' js will work?

Thats the question I'm asking....why are we being presented with a lot of half cocked ideas, workflows which partly work and only If senarios........it makes zero sense to me. I'm just tyring to work through what has to me become a chaotic mess and make sense of it all......I'm failing miserably.

I dont think anyone really knows what they are doing any longer, its mostly become all bullcrap.

[pziecina]

osgood_  wrote

....why are we being presented with a lot of half cocked ideas, workflows which partly work and only If senarios........it makes zero sense to me. I'm just tyring to work through what has to me become a chaotic mess and make sense of it all......I'm failing miserably.

I dont think anyone really knows what they are doing any longer, its mostly become all bullcrap.

The web development workflows, frameworks and methods employed to justify there use, now has nothing to do with the end result, (what the end user sees and uses). If time and cost are the major priority, then the developer(s) now will often choose the cheapest and simplest method, even if they have no idea what they do, or how they work. If quality of the code and/or keeping up with what is possible, (and presenting the end user with a unique, individual and quality experiance) then knowledge of specs and there use is paramount.

Whilst both are not exclusive 'OR' choices, how you work and achive them is. Using a framework gives the developer the feeling they are using something modern, and that it must be 'the best way possible' given the time and cost limitations, a feeling thatonly works until the next big thing comes along. The workflow itself should I think, always be kept as simple as possible.

[pziecina]

Thought you may be interested in the 'Rant', in this article -

https://www.wintellect.com/data-binding-pure-javascript/

[osgood_]

pziecina  wrote

Thought you may be interested in the 'Rant', in this article -

https://www.wintellect.com/data-binding-pure-javascript/

That's one of the articles I pulled up a few weeks back when I started my exploration into js framework data-binding workflows as I tried to unravel why or if I should even be giving it the time of day. I think the rant is pretty near the truth and how I feel about the whole thing.

I've now build all the usual components which one would use in a website, navigation, gallery-modals, slideshows, forms, etc as vue js snippets. I must say there is nothng much out there in terms of really good vue resources to show you how to do this. Most of the resources and material that I can across where pretty crap and I had to piece the components together from bits of this and bits of that plus my own tinkering around. Yeah everyone can open a modal from a single button, its not rocket science, but try and find something that informs you how to pass an attribute in vue, you end up just using vanilla javascript which kind of defeats the objective of using vue - I eventually found $event which passes some rubbish around where I could eventually pick off the attribute I needed and at least keep the whole thing vue likish.................oh well its been worth investigation, I think.

[pziecina]

osgood_  wrote

......oh well its been worth investigation, I think.

If you don't investigate, then you cannot have a valid opinion

[WolfShade]

I also prefer to use JS to actually submit the form, avoiding the input type="submit" in favor of using <button></button> with an onClick set to a function that will validate the data, then use document.formName.submit() if everything passes muster.  This way, if someone DOES have JS disabled, the form won't submit.

HTH,

^ _ ^

[osgood_]

WolfShade  wrote

I also prefer to use JS to actually submit the form, avoiding the input type="submit" in favor of using <button></button> with an onClick set to a function that will validate the data, then use document.formName.submit() if everything passes muster.  This way, if someone DOES have JS disabled, the form won't submit.

HTH,

^ _ ^

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.

[Nancy OShea]

I test my sites with JS disabled.  If JS is essential for more than just eye candy,  I add a <noscript> warning to the top of  the page.   I think it's the least we can do to minimize failures and user frustration. 

[osgood_]

https://forums.adobe.com/people/Nancy+OShea  wrote

If JS is essential for more than just eye candy,

It runs most of the web, I think. Bring down 100 random pages from Google and see how many use javascript. Do we even need to bother about the limited number of users with js disabled. Its like asking if its worth developing for IE8. In that context I guess using using data-binding is no different......yes a few wont see the content but the rest will.

[Nancy OShea]

osgood_  wrote

Bring down 100 random pages from Google and see how many use javascript.

True.  But they likely have some fallbacks in place for the people who don't have JS enabled.

Do we even need to bother about the limited number of users with js disabled. Its like asking if its worth developing for IE8.

It's not the same thing.

I have no sympathy for people who refuse to upgrade their browser.   If they insist on using IE8, that's their cross to bear.   But I make sure they can see content even if it's not pretty.

Insofar as JS, I don't use it for everything.  User mentality shifted significantly after the Facebook data scandal which effected 87 million people.  Since then, the majority of my friends & family actively use script & tracking blockers,  incognito and other safeguards to make their Internet experience less intrusive.   Do these measures break web pages?  Yes, they sometimes do.   Can we really afford to ignore users who try to protect themselves on the web?  I don't think we can.

Your milage may vary.

[BenPleysier]

https://forums.adobe.com/people/Nancy+OShea  wrote

Can we really afford to ignore users who try to protect themselves on the web?  I don't think we can.

I think we should ignore users that have JS switched off, it's much like removing all road vehicles to reduce road trauma.

In each case (using the web or driving a car) we need to take care without taking drastic measures.

[Nancy OShea]

Script blocker add-ons are selective & can be programmed to allow some, all or no scripts on selected sites.   The point is, we must inform users when/if JS is essential.  If JS is not essential, I don't really care if they block scripts or not. 

[osgood_]

https://forums.adobe.com/people/Nancy+OShea  wrote

The point is, we must inform users when/if JS is essential.

That just a 'head in the sand' approach. IF a user isnt using JS they are hardly likely to switch it on just to view your website UNLESS its so unique they can only get the information they require from your wesbite. In that case they will probably ring you. I think you're still stuck in the 1990s persaonally.

Its like yeaterday all over again saying 'This website is best viewed in IE'

Ok if you have a very small part of the website using js like a slideshow then maybe it wouldnt prove too much of an issue for the visitor but when these days 90% of websites can rely on js, particulary if you use data-binding, your solution is unworkable, in my opinion.

[osgood_]

https://forums.adobe.com/people/Nancy+OShea  wrote

https://forums.adobe.com/people/Nancy+OShea  wrote

True.  But they likely have some fallbacks in place for the people who don't have JS enabled.

Well I dont know what fallback they have - if js is not enabled the page just isnt going to work as expected. If a slideshow works by js, modal, nav etc, they will fail. I dont see many websites these days that even use the <noscript></noscript> to server up alternative content or god-forbid as I said we are moviing into websites which are soley based on js to serve most of the content,  they will look pretty ugly I suspect, certainly not usable to any extent.

https://forums.adobe.com/people/Nancy+OShea  wrote

I have no sympathy for people who refuse to upgrade their browser.   If they insist on using IE8, that's their cross to bear.   But I make sure they can see content even if it's not pretty.

But thats saying I dont care about users who use IE8. You CAN cater for them IF you want to use old workflows. I see no difference when I say should we really still be concerned about the few who have javascript disabled. I can cater for them if I use old workflows.

https://forums.adobe.com/people/Nancy+OShea  wrote

Insofar as JS, I don't use it for everything.  User mentality shifted significantly after the Facebook data scandal which effected 87 million people.  Since then, the majority of my friends & family actively use script & tracking blockers,  incognito and other safeguards to make their Internet experience less intrusive.   Do these measures break web pages?  Yes, they sometimes do.   Can we really afford to ignore users who try to protect themselves on the web?  I don't think we can.

I cant comment on that BUT I can comment on the march towards js driven SPAs and even full websites. This has always been the case BUT more so recently, with the coming of the newer, accessible to many, frameworks.  Do I like it no, but if you want to be current I dont think you can ignore it. I think the use of progress outweighs the small disadvantages, users with js disabled must have been considered significantly unimportant. Maybe in 5-10 years we will see the error of our ways, I dont know.

[WolfShade]

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,

^ _ ^

[pziecina]

WolfShade  wrote

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.)

The problem with that is, that I would advise anyone using a browser that does not support html5, to turn js off, as it was/is the prime method of spreading viruses and hacking, and they have not had any security updates for years.