|
It was the eyebrow plucking that took the time...
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Unobtrusive Javascript is bad... OK, that should get the conversation started. To make it short, the proposition here is that you should bind events with code in an external file so that you can have purity of semantic coding is worse than a goto statement. A goto statement is at least a follow-able link. External binding is a fashion with no more benefit than any other fashion. I can buy that you should keep the majority of your javascript in external files, but putting the event binding externally, is to hide or at least obscure what the program flow and what the program is doing.
So, what do you think the upside and downside of putting your event bindings in the HTML? "Purity of code" is not going to impress me... any. I live in the trenches.
I expect some difference of opinion on this based on experience and role. I would expect that developers that have done a lot of trouble shooting and maintenance have a different opinion than those that write code that they do not have to maintain. You might mention this type experience when replying.
|
|
|
|
|
Member 7980583 wrote: Unobtrusive Javascript is bad
- very bad!!!
However unobtrusive not only talks about separation, but also states that your page will work without that JavaScript present at all!
So, if you go unobtrusive, then you must separate JavaScript form HTML (and CSS)!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
modified 3-Feb-14 8:21am.
|
|
|
|
|
Ya know, you have an interesting point. I have written web apps with noscript capability. I understand the principles, but how often are you going to do that? Some security contexts might need to have javascript turned off, but most of the time, I would be inclined to just say too bad. Isn't the web about HTML5, javascript and responsive CSS? I cannot see working within that restricted environment. Sorry Charlie, but I write web sites that are too high performance to work without javascript. It's like telling me that we need a ditch dug, but you have to use your hands rather than a shovel.
|
|
|
|
|
I have some project - military/police related - where the absence of JavaScript is a demand...
Very annoying...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
I have done pages that had to work without javascript and it is not that the javascript can't be in the page, it is that the page can function without it. The funny thing about using the "noscript" tag (so to speak) is that you shouldn't need it. You get a lot of things that are submits instead of javascript actions, but they become javascript actions if the javascript works to make them so. Really nasty.
|
|
|
|
|
What Me Worry?
I do what needs to be done - move things around when it seems sensible and keep them together when it doesn't.
Aside from my personal JavaScript libraries (=generally useful functions), if a file is too big, move out the excess, and if not, and everything fits nicely in a small and readable file, then leave it there.
A lot of how this is done (size and selection) is personal taste on how the logic flows and the reader (particularly yourself) visualizes.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Consider the element id to be the Goto label.
BTW how is declaring the events in the element going to help you?
You can search for the event function or for the elementID.click. I don't really see the big difference.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
"You can search" ... That's the difference. So do you search on every id in the page to see if something has been attached somewhere? It might have been attached by class even or heaven forbid, by element. It is a waste of time in any case.
"Consider the element id to be the Goto label." ... It might be or might not be, usually it is not one. You have to investigate to find out. Makes maintenance more difficult, but I still haven't heard any advantage. yet. Remember, typically the cost of maintenance of an application is higher than the development. That will just raise the time/cost of maintenance as well as hide the functionality.
|
|
|
|
|
Well, badly written applications usually do obscure functionality. So you suggest to declare the events within the elements?
How about properties, is CSS also hindering maintenance?
modified 20-Oct-19 21:02pm.
|
|
|
|
|
I am less of an expert at CSS to feel like offering an opinion, but thinking about it, I have thought that putting location information where the element is as part of the element might be appropriate. I do complicated stuff where adjusting the location by pixel distances is important sometimes. That would not be document wide whereas say font or other appearance styling would be. So put appearance styling in a CSS file, but perhaps element location information in the style of the element.
|
|
|
|
|
How about, you write a Javascript object for form validation that can be reused for different forms?
I'm actually playing around with such a thing.
Or a menu object that can be configured with a JSON object for different purposes?
You cannot know in advance what elements will be hooked up with the events 
But otherwise, yeah, going through thousands of lines of badly written code is a pain.
However it is hardly the unobtrusive Javascript to blame.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Validation is something that should be generalized and probably from a library. Both should be in an external file, the attachment though should be at the element that is to be validated (IMO).
If you are sending JSON for configuration or data, then it is javascript that is doing the responding. The element might request the information, but the element cannot (normally) read JSON. The JSON may setup the event, but by then you had better be keeping track of what you are doing. Really, you point to the larger sphere of this issue. When you attach an event at an element, you are actually placing meta data - "when this type event happens, do this". So instead of specifically saying that "a javascript event should be attached where the element is declared", it should be "there should be meta data at the element describing that an event of such type is attached here and will so something like this". It is also known as documentation or self-documentation, the mark of a professional programmer.
Once you are doing configuration with JSON it is your responsibility to let the maintenance developer know what you had in mind... and something about what is expected from the server... another goto blind situation.
|
|
|
|
|
Once you are doing configuration with JSON it is your responsibility to let the maintenance developer know what you had in mind
^I agree with that
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Member 7980583 wrote: "Purity of code" is not going to impress me... any. I live in the trenches.
I certainly hope that this statement doesn't lump in everyone else who plays a role in product sustaining as a software developer. Just because you have made the code more readable for you does not mean you have improved it.
Member 7980583 wrote: So, what do you think the upside and downside of putting your event bindings in the HTML?
Simply put the answer is performance.
The upside is that you improve the performance of your web page and the downside is that by not doing so you degrade it's performance.
The less that you clutter your page means the faster that it loads. By moving your CSS and javascript content into a separate file that lowers the content of the page that the browser must load. Thus you get an improvement in performance.
This becomes even more of a fact when you take into consideration the simple fact that the browser will cache javascript and css files. so that file where all of your javascript exists... well it's already loaded and the browser won't have to sacrifice a few hundred milliseconds for loading that content on each and every page.
I would recommend a reading of Steve Souder[^] and performance tuning your web site.
Member 7980583 wrote: I would expect that developers that have done a lot of trouble shooting and maintenance have a different opinion than those that write code that they do not have to maintain. You might mention this type experience when replying.
I have worked in both areas and personally took some offense to this statement. It is in my opinion best to question why things are done a certain way and hope to learn something as a skill building experience in furthering and enhancing your abilities. However, this statement comes across as almost to say that one group knows better or more than the other??
Member 7980583 wrote: "Purity of code"
You could say purity of code but you could also say purity of using the design pattern being modeled. In this case since we are talking about MVC and assuring that code from either M, V or C doesn't get co-mingled with the other. This generally helps in code maintenance..
you want something inspirational??
|
|
|
|
|
The code functionality has not been improved, but the maintainability has. A lot of people seem to neglect maintainability, which I consider to be part of professionalism.
Performance, give me a break. I clearly said that I was talking about the code attaching the event which doesn't take "a few hundred milliseconds for loading" if you have at least a 14.4 K modem. Ignoring, missing or manipulating that critical point makes me think you don't have a valid reason. I doubt very much that Steve Souter maintains code. That task goes to the sergeants, not the officers.
Well, I do bet that developers that maintain code have far more knowledge of what makes code maintainable or not than do developers with no experience maintaining code. That is much of my point, we have a current fashion that I think is promoted by people that do not maintain code and so they do not promote coding practices that take maintenance into account. I am giving an opportunity here for anyone that wants to support the other position and you sir, have failed badly.
|
|
|
|
|
Member 7980583 wrote: I doubt very much that Steve Souter maintains code. That task goes to the sergeants, not the officers.
You clearly don't know who you are talking about. Taking into consideration the fact that you are willing to sacrifice any level of performance goes to show you support your version of readability versus the fact of performance.
Member 7980583 wrote: I am giving an opportunity here for anyone that wants to support the other position and you sir, have failed badly.
I pointed out facts identified and used by all of the major web companies. You have pointed towards your preference of how to read the code and minimized the fact of performance by saying somehow that it's minuscule.
There are so many other groups and organizations that support the idea of unobtrusive javascript. There is the The Web Standards Project[^] manifesto on this subject as well.
But hey if you want to ignore site performance and web standards then by all means please continue to do so. I wonder how you would present ignoring facts like performance and web standards to a customer or potential employer?
you want something inspirational??
|
|
|
|
|
Quote: you are willing to sacrifice any level of performance
and you are clearly willing to sacrifice maintainability... so there... Besides "any level of performance" is just another exaggeration. You invalidate yourself that way.
Quote: minimized the fact of performance by saying somehow that it's minuscule.
It is minuscule and I pointed out that your claim that it was "hundreds of milliseconds" was so absurd that I felt it invalidated your argument.
Quote: I wonder how you would present ignoring facts like performance and web standards to a customer or potential employer?
I would point out that when I put the topic up on the Code Project site for discussion, the only argument against it was something about that less than 100 characters could cause a performance hit. It made no sense. Also, since it is considered standard that code be commented for maintainability and no one seems to do it, then standards, like maintainability, seem to get short shift when people feel like it. Further, I would point out that most comments on Code Project supported my position as has discussion with other senior developers that I work with. Employers always like it when I say that I write for maintainability more even than efficiency, unless appropriate.
|
|
|
|
|
Member 7980583 wrote: willing to sacrifice maintainability ...
properly coding to design patterns like MVC and the Document Object Model are sacrificing code maintainability?
interesting thought you have there. I have never heard someone say that properly using code and design standards goes against making the code maintainable. I would say your argument against patterns, standards and performance invalidates you even further.
Member 7980583 wrote: Further, I would point out that most comments on Code Project supported my position as has discussion with other senior developers that I work with.
so the handful of people who you say that are supporting your claims are going to invalidate the even larger handful of experts that work at companies like google and yahoo? or that these same set of people are also going to invalidate specific experts like Steve Souders (considered the expert in web performance).
you want something inspirational??
|
|
|
|
|
Where in the world did MVC come into this? FYI, that is almost exclusively a server thing and javascript events can only be in the View (Love that MVC). My main point was that not having the events bound to html elements where the element exists, makes for something akin to a goto statement, only worse. Where I come from, goto statements are considered a bad thing.
Where did the DOM come into this. The DOM is the playing field. I'm talking about the players and field gear that works on the DOM. You need to either clarify your mind or your communication... or are you just throwing out terms?
Quote: interesting thought you have there. I have never heard someone say that properly using code and design standards goes against making the code maintainable. I would say your argument against patterns, standards and performance invalidates you even further.
It does not conflict with patterns. You have not supported that it hurts performance. It is the standards that I am questioning and that you have completely failed to defend.
Here is the problem that you seem to fail to get.
Quote: like Steve Souders (considered the expert in web performance).
Yes, he is an expert in web performance, but my question was about maintenance, which is typically 50% of the cost of any commercial website and with the efficiency of MVC for development, I expect that percentage to be higher. My experience and the experience of a number of people that work day in and day out with javascript is that using that goto pattern is a bad idea. Again, your experts do not do the work I do. Worker bees often have practical realities that leadership does not deal with.
This by the way is why I also commented on the experience of the respondent. You sound very enthusiastic, but I have to wonder if you have spent the years maintaining code that are the reason I have asked this question on this forum. You have given two reasons to refute me. One is the standards that I am questioning and the other is performance, that you failed to support and gave a silly reasoning for. Put it this way. TCP/IP sends data packets. To add 5 onclick="doSomething(this)" statements in the html would be unlikely to require an additional packet being sent, let alone take your "hundreds of milliseconds" of performance hit. What I am rejecting is your "hundreds of milliseconds" of performance statement and so far, that is your only reasoned support for your argument. Defend that if you can and quit repeating authority. It is that authority that I am questioning with reason. Defend your argument with reason.
|
|
|
|
|
Member 7980583 wrote: Where in the world did MVC come into this? FYI, that is almost exclusively a server thing and javascript events can only be in the View (Love that MVC).
You clearly don't even know what you are talking about when it's come to Javascript. Might I recommend that you go read up on angular, backbone, ember and other javascript frameworks. MVC is a pattern widely used in Javascript and purely from the running context of the clients browser.
It is not exclusively a server thing as you are calling it.
As I said earlier take your lack of knowledge in certain areas as an opportunity to learn something. Just because your way makes the job easier for you in maintenance does not mean that it's the right way.
All of what you have said in support of your arguments are your own opinions. I have submitted not only my opinions based on over 20 years experience but expert advice on the very subject of web performance.
I personally tend to lean towards expert advice on subjects however you can believe whatever you choose.
you want something inspirational??
|
|
|
|
|
I'm with you, especially now that I've done some development with angularjs. Binding to expressions that run on your model is pretty damn sweet. That combined with directives, it's a very powerful framework that does so much right that I don't mind using a framework, and I generally hate frameworks.
|
|
|
|
|
Beth: I wonder if the groundhog saw his shadow?
Tim : I don’t care; it’s stupid; leave the groundhog alone
Beth: It’s just fun
Tim : Take those people dressed in monkey suits and have them poke a bear. Now that would be fun!
Beth: You’re sick.
|
|
|
|
|
Not for the bear.
I'm pretty sure it would be shot before it had managed to kill them all... 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
poor bear 
he just wanted to Play with them
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
