• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

book for making UI component using JS

 
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I'm thinking of making my own UI component, but still confused about the best practices to do this using JS. anyone know any good book?
thanks
 
author & internet detective
Posts: 40746
827
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From scratch? Most books focus on a framework. Like extending jQuery to create a custom widget.
 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well, if possible I want a book that focuses on naked Javascript from scratch, so the widget would perform faster and less dependency on framework. And also, it would deepen my understanding about javascript. I believe I must understand the real thing before start using frameworks. thanks
 
Sheriff
Posts: 67590
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So you have no JavaScript experience at all? What about HTML and CSS?

Also see this releated topic.
 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I do have javascript experience, but not at the level of creating a UI widget from scratch.
HTML and CSS is not a problem. I've used them quite extensively. thanks
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Go to www.w3schools.com . It is very good to learn HTML, CSS, JavaScript from scratch

thank you
 
Bear Bibeault
Sheriff
Posts: 67590
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, w3schools is not very well regarded, and it certainly will not have tutorials targeted at what the OP is asking for.
 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
so, any good book on this subject? thanks
 
Bear Bibeault
Sheriff
Posts: 67590
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I know of no book that matches the criteria you have set out.
 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
okay, in that case, I'll just have one quick question related to this issue, is extending native element the way to go? I've known 2 problems with this approach:
1. IE<8 doesn't expose Element or Node, but I'm not too worried about this limitation since it's already 2014. I'm willing to show "crashed" application in those dinosaurs' browser if just to give them a wake-up call "Upgrade your OS already".
2. method name collision, okay, this one is a little bit valid, but then again, if I prefix my methods with "my", pretty sure browser's developers won't create such name for their method right? so no collision there.
or are there any other reasons why we shouldn't extend native elements in 2014?
Thanks
 
Bear Bibeault
Sheriff
Posts: 67590
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

David Spades wrote:1. IE<8 ...


I take a very hard line on supporting outdated browsers: I don't. If someone visits one of my webs apps with IE8 or earlier, they get a notice to either upgrade their browser, or install the Chrome frame. There is no valid reason that anyone should be using IE8 or earlier¹.

2. method name collision, okay, this one is a little bit valid, but then again, if I prefix my methods with "my", pretty sure browser's developers won't create such name for their method right?


Prefixing names is a poor approach. Rather use namespaces. The incursion into the global space should be minimized.

Either that, or adopt an AMD loader such as RequireJS.

or are there any other reasons why we shouldn't extend native elements in 2014?


Can you elaborate on exactly what you are asking here?



¹ Until recently, corporate organizations with Luddite IT departments may have been stuck on IE8 because they were standardized on Windows XP. With Microsoft terminating support of XP, there is no longer any valid reason for anyone using IE8.
 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
can you show me how to extend native object (adding method) with namespace?
as for the last question, I meant that is there any other con as to why we shouldn't extend native object directly?
thanks
 
Bear Bibeault
Sheriff
Posts: 67590
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

David Spades wrote:can you show me how to extend native object (adding method) with namespace?


Most basic approach:

Limits the incursion into the global namespace to bear, the "module" name.

A more advanced approach using immediate functions:


Making no incursions at all into the global namespace is best served the realm of AMD (like RequireJS).

I meant that is there any other con as to why we shouldn't extend native object directly?


Still not grokking what you are asking.
 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
what are the side effects of extending the native objects directly?
so something like

thanks
 
Bear Bibeault
Sheriff
Posts: 67590
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah, yes. I'm not a much of a fan.

That's the approach Prototype took -- as opposed to jQuery's hands-off approach -- that soured me on Prototype. It all comes down to expectations of behavior. If the way a native object behaves is changed, then other modules (and what nontrivial web app uses just one library these days?) can trip over that extended/changed behavior.

Well-known shims do this in a predictable and well-mannered way, and are well-tested. I'm not a fan of doing it in other code.
 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
so, jquery way is the preferred way? thanks
 
Bear Bibeault
Sheriff
Posts: 67590
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Interesting conclusion. What I specially said is that I prefer jQuery's hands-off approach to making no changes to the native elements (by utilizing wrappers), rather than Prototype's approach of making wholesale changes to native elements (which bit us in the keester big-time at a previous job).
 
Bartender
Posts: 2968
6
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

David Spades wrote:best practices to do this using JS. anyone know any good book?



Nothing related to UI components in particular but after scanning over this thread ...

Bear Bibeault wrote:Limits the incursion into the global namespace to bear, the "module" name.

A more advanced approach using immediate functions.



Lots of stuff like this can be found in JavaScript Patterns - Build Better Applications with Coding and Design Patterns
For example: How to use the Module Pattern in JavaScript

And of course Bear is probably too polite to mention Secrets of the JavaScript Ninja which in essence is a distillation of the design wisdom that went into jQuery.

David Spades wrote:so, jquery way is the preferred way? thanks



"Secrets of the JavaScript Ninja - Chapter 6.2 Gotchas" talks about the pitfalls of "extending" Object and Number - so it doesn't take that much of a stretch of the imagination to come to the conclusion that you are risking undesired side effects when you "extend" JavaScript objects that are not your own.

Open-Closed Principle: "open for extension but closed for modifications"

Now I'm not a fan of coercing JavaScript into the "Classical OO" paradigm (my opinion - "don't do it") - it is its own beast and one should treat it as such to get the most out of it. Nonetheless I think that the "Open-Closed Principle" does apply here. The problem with "extending" native JavaScript objects (or DOM objects) is that you are actually "modifying" the native or prototype object - so we read "extend" but we mean "modify the native/prototype object". So in my opinion in the spirit of the "Open-Closed Principle" "extension" in JavaScript should refer to wrapping the original object, meanwhile adding anything to the original object or it's prototype should be classified as a "modification" (and therefore should be avoided).

There is a 2010 discussion about extending DOM objects Perfection Kills - What's wrong with extending the DOM that you may find of interest.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic