If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

thanks for the suggestions, I'll review them. Ideally I'm looking for something 'active'; the game I linked to *works*, but is just a lot of code for a beginner to wade through when I'm still just trying to see how things fit together. Something with the same type of functionality, only much smaller, would be ideal.

There is a series of 12 tutorials starting at http://javascriptexample.net/anim11.php that build on three objects ($B, $E, and $O) to make elements move around on the page. You might find that a simpler starting point to see how to create and use objects in JavaScript.

OOP isn't a very good paradigm for small/basic applications. OOP imposes a lot of structural overhead that helps mid-sized to large applications stays organized during development, but doesn't provide nearly as much benefit to small apps (<10k LOC). If you only have a few interaction points, a procedural approach is typically much less code to maintain. with jQuery, an event-driven approach is very easy to absorb and impliment, and it lends itself nicely to a functional approach whilst later expanding the app.

OOP isn't a very good paradigm for small/basic applications. OOP imposes a lot of structural overhead that helps mid-sized to large applications stays organized during development, but doesn't provide nearly as much benefit to small apps (<10k LOC). If you only have a few interaction points, a procedural approach is typically much less code to maintain. with jQuery, an event-driven approach is very easy to absorb and impliment, and it lends itself nicely to a functional approach whilst later expanding the app.

On the downside of 3rd party libraries:
1) they eliminate the learning curve of the basics
2) they encourage the inclusion of unnecessary code for many apps, thus increasing overhead and bloat
3) they create a 'black-box' mentality

It's my view, but, a beginner should start with the basics, master them, and then consider alternatives. You don't always need to use jQuery, though many people seem to think they do.

On the downside of 3rd party libraries:
1) they eliminate the learning curve of the basics
2) they encourage the inclusion of unnecessary code for many apps, thus increasing overhead and bloat
3) they create a 'black-box' mentality

It's my view, but, a beginner should start with the basics, master them, and then consider alternatives. You don't always need to use jQuery, though many people seem to think they do.

1. is a good thing. learning is expensive and painful, and lacking experience, noobs often focus on the wrong things trying to get basic accomplished. A noob shouldn't have to learn the diff between e.target and e.srcElement or elm.textContent and elm.innerText. Much of the low-level stuff like that is half-obsolete anyway, i say let jQuery et al cover-up the stench of IE8 while it dies in the corner. I learnt a ton of crap 5 years ago that won't mean anything five years from now...

2. maybe, but if you want to support IE8, you're gonna have to double-code a lot of custom code, so you won't save as much as simply tossing the jQuery lib might suggest, and your dev time ramps up. use zepto instead of jQuery if you want to save some space. jQuery can be abused by designers, but programmers, even newer ones, tend to be me judicious in thier plugin-shopping. That, and the fact that JS is 20X faster than it was in 2009 means that we can now have more luxurious and less performant code than we did a short while ago. Look at the MVVC frameworks taking off, they are all internally quite clogged and slow, but they sure make coding easier.

3. much of the dom is soo bad it deserves to be in a black box at the bottom of the sea. i can meet you half-way on the first two points, but we don't need to stick-up for early mistakes. I also feel that using a blackbox here or there to handle the complicated and boring stuff allows more development time for cool and fun stuff like improving UX, performance, and responsiveness, all of which pay off greatly yet take up a lot of coder testing and time.

but yeah, there's a dozen sides to every coin in JS and it's good to give the issues a though airing. thanks for your follow-up on my posting, good points all-around.

There is a series of 12 tutorials starting at http://javascriptexample.net/anim11.php that build on three objects ($B, $E, and $O) to make elements move around on the page. You might find that a simpler starting point to see how to create and use objects in JavaScript.

You're welcome, and just to set things straight..re 1) I enjoy banging my head against the keyboard...gives me an excuse to have some medicinal Bordeaux

Fascinating discussion here. yeah, I'm teaching myself here, never had a class, and so I feel like for sure there are multiple blind, dead alleys I have traveled up.

I realize that I should develop my understanding of procedural code further before getting into OOP. Question is: how do I identify that benchmark?

I'll confess a strong bias toward this the text-adventure genre. I grew up playing them, and am largely motivated from a hobbyist perspective as I work full time in human services. Funny thing: I found one beginner's tutorial on them, written procedurally, and it was immediately obvious, even from what little I know, that an OOP approach would be better.

Lastly, I do take the point that OOP is better suited to larger applications. BUT... you gotta start somewhere. I'd like to study a system with 10 moving parts before I study one with 100. Even if a procedural approach would be better suited for the 10 part application, it would be very useful to see how it works OOP style.

I realize that I should develop my understanding of procedural code further before getting into OOP. Question is: how do I identify that benchmark?

As someone (maybe me) once said, "You'll know it after you've seen it" It doesn't matter...benchmarks are for critics, statisticians, and politicians. If you want to learn, try everything... none of it will make sense at first, even after you say "Oh yeah, I know that" you'll learn you really don't... keep plugging away

[quote[ Funny thing: I found one beginner's tutorial on them [/quote] If you've still got the link, post it...I'm a sucker for that stuff.

I'd like to study a system with 10 moving parts before I study one with 100. Even if a procedural approach would be better suited for the 10 part application, it would be very useful to see how it works OOP style.

I agree. And, from a learning point of view, I think everyone else would also.

... it's incomplete, broken, buggy, and I'm certain doesn't follow any sort proper programming practices. Nonetheless it's about the right size for my brain at the moment, and is the only example I have yet found that tries to show a "second-tier-noob" application for this type of thing.

Seems like some enterprising individual could create an excellent tutorial series on how to gradually scale a text-adventure application. Maybe a couple years from now that'll be me