|
Eye see what you mean. 
|
|
|
|
|
Eye see what you did there!
|
|
|
|
|
(Best pirrate voice) Eye did ye now lad?
|
|
|
|
|
Eye browsed by[^] this post, and eye had to leaf.
Clean-up crew needed, grammar spill... - Nagy Vilmos
|
|
|
|
|
Eye'd ne careful with browse like that!
|
|
|
|
|
Nice to see you're finally getting the hang of using the blush along with the eyeliner, Griff. I'm sure you'll be a hit in the pasture tonight! 
Will Rogers never met me.
|
|
|
|
|
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??
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
