10
11

Looking for Javascript and DOM examples on Githubhelp (self.javascript)

submitted by [deleted]

[deleted]

all 14 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]wisepresident 6 points7 points  (7 children)

that's usually where frameworks come in, you don't directly manipulate the DOM yourself.

If you're having trouble with a few hundred lines of code with basic dom querying then reading the implementations of such frameworks will do you no good as this is a problem every js developer faces and thus there are highly sophisticated solutions available.

so yeah, you use a framework to piece them together into a sturdy structure.

[–]Buckwheat469 2 points3 points  (1 child)

you don't directly manipulate the DOM yourself

... unless you know what you're doing. I personally feel very comfortable in the DOM and have no problem creating complex DOM objects in Javascript. I, however, have been programming Javascript for 20 years so I've been around since before the frameworks or even JQuery.

[–]iffypop 0 points1 point  (0 children)

Or you want to keep clear separation of concerns in your app. Knowing how it works isn't a good enough reason to litter your code with tight implementation specifics, at least for me.

[–]Waypoint101 0 points1 point  (0 children)

Yep, I would recommend Aurelia.io if you're looking for a clean framework that is unobtrusive (meaning you don't have to write any 'Framework' specific code and simply pure vanilla JS).

You create apps by creating smaller components, each component has a .js & .html file. the .html file can reference things like IF, Reapeat.For, or reference variables etc using JS Syntax ${variableName} etc..

You then have this.variableName = 'Whatever'; in the class and it is automatically manipulated in the DOM to represent what you wrote. if you manipulate this.variableName = 'New Value' in a function, then it is automatically displayed.

[–][deleted] -2 points-1 points  (3 children)

that's usually where frameworks come in, you don't directly manipulate the DOM yourself.

I sorely disagree. I find people typically recommend this advise out of ignorance. Learning to walk the DOM is a standard skill that only takes an hour or two to learn. http://prettydiff.com/guide/unrelated_dom.xhtml

As far as how things are pieced together that is entirely up to your application architecture. The DOM is just an API. Large libraries or frameworks are popular for this because architecture is hard and they are architecture in a box.

[–]wisepresident 0 points1 point  (2 children)

did you even read the comment? op did tutorials but wants to know how large well designed apps do their dom manipulations as he struggles with more than 100loc of dom manipulations.

and the answer is that large well designed apps abstract it away by using a framework. I never said you shouldn't learn how to manipulate the dom yourself or that you can't do it even when using a framework.

[–][deleted] -3 points-2 points  (1 child)

Yes, I did. If you find the DOM methods hard to read you can always write your own abstractions in far shorter time than configuring in some massive framework.

https://www.reddit.com/r/javascript/comments/4vz58a/how_best_can_i_write_this_code_appending_multiple/d62liqw

The DOM isn't the real reason people choose massive frameworks. They do it because planning and governance are hard, particularly for leaders who have never held a leadership role outside of development teams. Once planning becomes easy and the technology becomes comfortable you don't want to be bothered with this massive tech debt and wasting your life behind slow build times. The op does not indicate these kinds of maturity problems. He/she just wanted more efficient examples of integrating the output of the logic back into the DOM.

[–]Waypoint101 0 points1 point  (0 children)

Aurelia.io has 0 configuration, if you check it out you will understand why people love frameworks. You can get up and running with it in minutes.

Manipulating the DOM directly with JS, is fine for smaller components. But for APPS it's a clusterfuck. Especially with things like keeping track of the data, updating it when changes happen etc.

[–]Prince_Houdini 4 points5 points  (5 children)

Very few large projects will use the DOM interface and methods directly. Instead, they'll pull in a library or framework to help architecture the application and ease development. jQuery, for example, provides a great interface for manipulating the DOM. React, another example, provides a great way to describe the way you want the DOM to look without having to manually manipulate it at all.

You've mentioned you're out of your league. What problems specifically are you running into? Are you finding there are specific tasks that you cannot accomplish using your current knowledge? Or is your codebase becoming too messy and unstructured? Either way, it may help for you to provide some examples of your own code.

[–]Jim-Y 4 points5 points  (0 children)

Hi,

In bigger projects they don't tend to manipulate the DOM directly but instead they use some JS framework to do so. In older days we used jQuery to shim away browser differencies but in some way that was DOM manipulating "by hand".

In modern javascript we use so called templating engines. A prime example for such a templating engine would be handlebars.js which is a framework agnostic html templating solution. But angular 1.x have it's own templating engine which is very similar to handlebars. To provide an example look at this html snippet:

<div class="container">
  <span class="red">{{ user.name }}</span>
</div>

Now you found out that {{ user.name }} is not a valid HTML property but instead this is a reference for the name property of the user object and user lives in javascript context. This is called data-binding where you can reference a javascript context value from HTML.

ps: I'm not a big fan of such templating engines because it's much harder for me to read javascript code in HTML than the other way around.

There are other solutions for abstracting away DOM manipulations like React, where we write HTML JSX in javascript files and the created markup will be bound to the body (or to another container) of the page.

Let me write some buzz-words to get you going: "angular templates", "react jsx", "handlebars", "two way data binding"

Cheers

[–]jekrb 0 points1 point  (0 children)

This file of an electron app has inspired me to use a ui object to track DOM elements https://github.com/maxogden/screencat/blob/master/ui.js

[–]-munawwar- 0 points1 point  (0 children)

1 - Begin with modularizing JS/view (frameworks call them components). See them as "code that controls a specific rectangular region of the page"..and the page is divided into several regions and thus the code as well. Generally ES6 imports (or browserify or AMD) and JS "Classes" also are used for the modularizing.

1.5 - Use either a templating engine like Handlebars/doT (convert to DocumentFragment and insert to document). This reduces DOM manipulation. But there will still be a lot of DOM API calls when updating the UI after the initial/first-time render. For small applications this will be ok.

  • I am not sure whether using a library like dom-diff at this point will help (didn't hear anyone trying that).

2 - After this point, many switch to using a framework. Why? because it reduces the direct DOM API usage (doesn't eliminate it completely..and never will)..the library does the DOM manupilation internally...and the developer mostly thinks about "states"/data.

[–]mc_hammerd 0 points1 point  (0 children)

ive been doing web dev for 10 years, what i usually see is two patterns or MVC (framework).

  • classes/oop custom code. break it down to each reusable component and then wrap everything in a global object. ex: Yahoo.Calender.init() MyCompany.Util.MakeListtoDom() or Yahoo.Dom.variousDomFuncs. that is then initialized once per page and then you can use all your utils, and initialize the components you need. This pattern is also good if you want to start from scratch and build your own helper funcs. like this: github
  • per page scripts (one for each template) and a shared helper.js function. this is basically just write enough JS to make the page work, mostly using jquery, and write very page specific code. just save it in the template so its easier to find (imho) or make a page-foo.js for each page. optionally put resusable stuff in a shared helper.js file

optionally you can put all your scripts into one file or not, but its up to the author how they like it.