Page 1 of 2

Client side design frameworks

Posted: Fri Dec 04, 2009 9:33 pm
by alex.barylski
I'm not sure I agree with the concept that blueprint CSS is a framework, but I suppose that is just a personal definition getting in the way.

I like the idea of re-using CSS, for a developer who specializes in backend development, anytime I can remove myself from photoshop, CSS' HTML, etc I'm happy. I takes me way to long to get things moving on the client side.

extJS - this is awesome. I love this library but it's not open source and it's quite complex and I don't think it's focus is on degradation. Ideally I would prefer a toolkit like jQuery UI where you build the tables statically using HTML or menus using lists and CSS, and apply the jQuery plugin to dynamically spruce up the statis HTML. This way you could use the plugins on the front end without concern of mucking up SEO, etc.

I have searched the net and found several jQuery plugins, such as tree controls, grid controls, menu controls, etc but Ideally I would get all these controls from a single source.

Does anyone know of a project (other than extJS) which does something similar?

Cheers,
Alex

Re: Client sideédesign frameworks

Posted: Thu Dec 10, 2009 10:45 pm
by JAB Creations
You should never use a framework except for optional aspects of a site that are not required for critical or important use period. It's gotten so bad that I'm seeing jQuery in half the results for MySQL questions I type in to search engines and they have absolutely no direct correlation! Worse even it creates dynamic dependencies meaning people will be scared to update their version of jQuery in example because it'll break an older browser but then something will break in a newer browser...and their whole concept is based on the idea that jQuery is JavaScript when it is not. The same thing goes for serverside frameworks, a lot of people create tons of unnecessary server load because they don't understand how to do things with PHP and MySQL directly. In example I've seen cases where people would put a DELETE query in to a loop instead of looping a part of a single DELETE query and then executing a single query. I also see vBulletin list over 30 queries per page loads sometimes.

Really, truly, honestly...master what you do and keep working at it over and over and over! As you refine your own scripts and CSS you'll end up reusing your own techniques written in the language directly. That is what I've done. The 29th version of my site uses tons of AJAX though the entire site only uses two AJAX functions total. I have complex UI using XHTML, CSS, and JavaScript that I can replicate in a couple of minutes swapping out a string here and there then creating something entirely unique. Constantly refining one's own practices makes frameworks obsolete because a framework is intended to fit as much as possible where as each designer/developer has to adapt to specific situations to which their code must adapt to. I can't stress the word dynamic enough.

In regards to JavaScript sniffing for DOM objects to determine if you can do the standard else IE can be reduced if you know what objects to use and how to apply them. There is no need to invent a framework to achieve something that can be done with a few extra characters typed out and eight seconds added to the initial load time for folks still surfing with dial-up (and there are plenty out there without the option to make it a very important concern to this day).

Re: Client sideédesign frameworks

Posted: Fri Dec 11, 2009 11:41 pm
by josh
JAB Creations wrote:You should never use a framework except for optional aspects
Sorry but you don't know what you're talking about! It doesn't break backwards compatibility because the programmers of those frameworks are often smarter then us, and have been doing it for 40 years, and write automated test suites. Your entire argument is a fallacy because even using PHP itself makes your application depend on a lot of other people's code.

Perhaps there are some frameworks out there you should not use, but until you have used them all don't tell me there aren't good ones. JQuery rocks. Sounds like you just got a really bad case of not invented here syndrome.

Even your release number methodology shows you aren't very versed in the concepts of forwards/backwards compatibility.
(Hint: Major Minor Bug http://en.wikipedia.org/wiki/Software_versioning)

Since it seems like you spend the majority of your time working on your personal site I don't think you've had the need to learn about backwards compatibility though. When you start re-using code across projects using SVN externals, you will learn.

PS > I didnt take jquery serious either until the 2 other guys on my team at the time started using it and I started asking how they were building such neat stuff so quickly

Re: Client sideédesign frameworks

Posted: Fri Dec 18, 2009 12:47 am
by daedalus__
josh wrote:
JAB Creations wrote:You should never use a framework except for optional aspects
Even your release number methodology shows you aren't very versed in the concepts of forwards/backwards compatibility.
(Hint: Major Minor Bug http://en.wikipedia.org/wiki/Software_versioning)
ouch

Re: Client side design frameworks

Posted: Fri Dec 18, 2009 1:02 am
by JAB Creations
No, I have a bad case of not accepting jQuery as an all-out replacement for JavaScript. I have an issue with people asking JavaScript questions and accepting jQuery as the answer as if jQuery was JavaScript itself.

And I most definitely have issues with people throwing DELETE, INSERT, and UPDATE queries in to loops drilling their own web servers because they're depending on frameworks before they've learned to optimize the base languages first.

...and as far as my code goes the 28th version of my site works renders way better then most sites do (albeit not perfectly) in IE4 and Opera 4 and the bulk of the JavaScript in that version is dynamic versus the static junk most sites have so if forced to reuse 2.8's code I'd still have a pretty reasonable amount of flexibility.

Re: Client side design frameworks

Posted: Fri Dec 18, 2009 1:25 am
by daedalus__
JAB Creations wrote:because they're depending on frameworks before they've learned to optimize the base languages first.
hehe i was thinking about that today. i like saying people are framework crazy and that nobody writes their own code anymore.

oh and by the way i downloaded blueprint to see what the fuss was about and i think its a big piece of bloatware. i've decided to use about 30 lines of it.

Re: Client side design frameworks

Posted: Fri Dec 18, 2009 1:36 am
by JAB Creations
Now that is what I'm talking about! I don't have an issue with frameworks for being frameworks, I have an issue with people treating them all-out language replacements!

You can't framework (X)HTML and CSS, that's a bit silly. You could try using existing solutions if there are any though frankly every time I've worked with third party modules there are endless shortcomings.

Really, truly, honestly, you've got to figure this stuff out...and really truly honestly it's cake especially with PHP and MySQL as there is very little to learn from visually. I dislike concept work but the rest I enjoy. There are millions of websites and ripping off ideas (so long as you don't do the equivalent of taking a screenshot and uploading it via FTP) is a great way to start.

...and if you have a hard time doing stuff or figuring out what you could do to improve there are plenty of methods.

First public opinion...or at least when you first start off look at sites and think about how you would do it. You'll develop your own style and taste eventually but making something work even if it's not that original will help you learn by just doing it.

Then there are validators for (X)HTML and CSS. Ignore CSS warnings, they're pretty much all hogwash.

You know what you need from the client so start with that. Build your forms and start giving things background-color values even if they're basic selectors. A funky example but it works...

Code: Select all

form fieldset label {border: #f0f dotted 1px;}

Re: Client side design frameworks

Posted: Fri Dec 18, 2009 1:47 am
by daedalus__
i disagree with ignoring css warnings. it is easy to write standards compliant css.

Re: Client side design frameworks

Posted: Fri Dec 18, 2009 2:15 am
by josh
JAB Creations wrote:And I most definitely have issues with people throwing DELETE, INSERT, and UPDATE queries in to loops drilling their own web servers because they're depending on frameworks before they've learned to optimize the base languages first.
But those same frameworks are architected in such a way that it can be changed in one place. You may praise yourself for using pure javascript, but lets say you wanted to do something like add a "loading" indicator for every ajax action in the application, exactly how hard would that be to do if you didn't have the foresight?

And your arguments, such as "ripple loading" which is what you describe here, has no correlation with wether or not you write your own framework or choose someone elses. Irrational arguments. You are implying that every framework has this problem or something. If you want to say "dont use doctrine because it has ripple loading" that is one thing (even though thats an irrational argument since it matters more wether the programmer abstracts that so it can be changed from one spot). But to go even further and say we should not use any framework simply makes no sense whatsoever. Sure most frameworks suck, you should not use most frameworks, but there are some good ones too.

The word "framework" is a buzz word even. Framework means nothing to me. to me it seems your problem is with using other people's code, which kind of leaves you doomed to repeat other people's mistakes since you never work with other people's code. Some clever developers wrote entire applications on mysql and then found out about some postresql feature. Those that were using the database abstraction frameworks have the options of over 11+ different open source database frameworks all without changing any code, while those who hard coded mysql_query() calls all over the application have thousands of lines of code to change (and, debug).

No matter what you do your code will either contain duplications or dependencies. There is no getting around that. But that really is off topic

Blueprint and the other CSS frameworks are nice, but I do not like them (and notice I state a rational reason) because they use class names that are non semantic. There are ways to work around that with javascript but I prefer to hand code my CSS rather then deal with that.

Re: Client side design frameworks

Posted: Fri Dec 18, 2009 2:24 am
by daedalus__
ugh all those classes that came with it drove me crazy. what do you guys think about grid based layout systems?

Re: Client side design frameworks

Posted: Fri Dec 18, 2009 2:48 am
by JAB Creations
Josh, I'm not debating frameworks, I'm debating how they are treated. We don't answer, 'OMG HURRY I NEDE HPLE NOW GIVE FERE ANSWER HEAR!' titled threads for a reason. The issue is how quickly people refer to frameworks for a quick fix for the smallest of solutions to the point where basic JavaScript method and property queries on search engines are beginning to be overwhelmed in many various contexts when I have sought clarification. For goodness sakes I saw someone suggesting to another person to use jQuery just to change classes!

Code: Select all

function change(id, newClass) {if (document.getElementById(id)) {document.getElementById(id).className=newClass;} else {alert('Error: the id \''+id+'\' was not found or has not yet been imported to the DOM.');}}
You could technically chop that down to this if you don't care about error handling...

Code: Select all

function change(id, newClass) {document.getElementById(id).className=newClass;}
That's 80 characters! jQuery compressed is 40KB! Can you at least in the context that I have just shared agree that if you are concerned about things like having 20% of paying customers using dial-up that you'd want a fast loading site so tackling on 36K=4.7 max DL/sex 8.5 rounded to nine seconds minimal just for a framework alone to load? Haven't there been studies that show most people leave after seven to ten seconds if a site does not load?

Now obviously not everyone is stuck with dial-up and unlike most sites that puke up quarter megabyte plus sized page loads per page for every page that some businesses aren't concerned about low-bandwidth visitors.

You point out that some frameworks and (perhaps flavors of?) languages even have their limitations. Yes, it can be easier to do things with jQuery though it should not be an automated reply to every frigin forum question asked about JavaScript! 8O

daedalus, not sure what you mean by grid based though I'm personally embracing CSS3 as it is slowly allowing web designers to clarify and differentiate ourselves from graphic designers. I have this pet peeve that was spawned while in "college" where one teacher expected me to crap out 12 megabyte Photoshop table based web pages about five years ago...and of course broadband was not as wide spread then as it is now (though I still consider it a very valid concern unless you start throwing broadband related content). I use tableless layouts (and tables for tabular data); Gecko has supprted border-radius since Gecko 0.8, WebKit added it with Safari 2 I think? Opera will have it with Presto 2.3 and they actually announced earlier today that Opera 10.5 will debut so we'll likely see Vega (which will bring us border-radius in Opera finally) next Tuesday (FRIGIN WOOHOO!) and even Microsloppers has showed us that they've added border-radius. Oh and just out of spite the work they showed off took three weeks...so three weeks of extra work on IE8 and we could have had full CSS3 selector support. Just saying. :roll:

Re: Client side design frameworks

Posted: Fri Dec 18, 2009 3:54 am
by daedalus__
http://www.alistapart.com/articles/outsidethegrid

you dont need to read that just look at the pictures

now look at this:

http://960.gs/

blueprint has one

http://www.webhostingsearch.com/article ... ystems.php

:| the first time i saw one of these i said to myself: how much faster does css need to get? haha

css3 is really great and even though there are only so many features that have been implemented i find them to be a joy. i remember making css to make shadows. some of them are kind of silly (like resize: wtf?) but box sizing is great and border radius is fun but a little useless.

it'd be nice to do gradient backgrounds without images using only css.

Re: Client side design frameworks

Posted: Fri Dec 18, 2009 2:03 pm
by JAB Creations
Alex, are we going too far off topic? :|

Actually resize is one of my favorite CSS3 properties! My LCD's native resolution is 1920x1200 so why should I type 11px sized text in a 100x50 pixel textarea? 8O Thing is I'm not sure when Gecko gets it and no WebKit browser fits my taste for surfing (I hate ads!)

Actually you can do gradient backgrounds in Gecko 1.9.2! That's Firefox 3.6+ and they've implemented -moz-linear-gradient and -moz-radial-gradient. The main issue for me is that the FPS takes a massive hit for large dynamic elements so they're only truly useful in smaller sized elements. To truly be able to utilize them we'll have to wait for GPU acceleration I'm afraid and even with every browser vendor working hard towards that goal we'll still have to wait a year or two before every browser has debuted a version that supports it and even then we'll have to deal with older browsers that don't...and you should know exactly what I'm talking about. But it doesn't diminish the fact that CSS3 is only getting increasingly more and more awesome! :mrgreen: :mrgreen: :mrgreen:

I think WebKit supports gradients too but I haven't looked it up of late.

Re: Client side design frameworks

Posted: Fri Dec 18, 2009 2:09 pm
by daedalus__
i suppose that makes it useful but if someone is creating pixel based layouts without thinking about how that will look across different resolutions they are being bad. sorry for the thread jack! :D

Re: Client side design frameworks

Posted: Sat Dec 19, 2009 2:40 am
by josh
Well I'm not even sure what's being discussed anymore, first you said "you should never use a framework", now you say something different.