Welcome to the Lounge

Michael Breeden3-Feb-14 5:15

3-Feb-14 5:15

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.

User 48350473-Feb-14 5:32

User 4835047

3-Feb-14 5:32

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 Smile | :)

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.

Michael Breeden3-Feb-14 5:50

3-Feb-14 5:50

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.

User 48350473-Feb-14 6:10

User 4835047

3-Feb-14 6:10

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.

Dennis E White3-Feb-14 9:11

3-Feb-14 9:11

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

you want something inspirational??

Michael Breeden3-Feb-14 9:36

3-Feb-14 9:36

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.

Dennis E White3-Feb-14 10:24

3-Feb-14 10:24

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??

Michael Breeden3-Feb-14 10:55

3-Feb-14 10:55

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.

Dennis E White3-Feb-14 13:12

3-Feb-14 13:12

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??

Michael Breeden3-Feb-14 23:49

3-Feb-14 23:49

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.

Dennis E White4-Feb-14 10:25

4-Feb-14 10:25

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??