Anyone else just HATE styling?

[purbeast0]

Zips may be a bad idea, if this is all in a small location.

However, those radio buttons, with their Charles Dickens novels, look awful. Can you break that down into some sort of zones, and possibly have a small [?] or something that brings up a modal with a list of the cities included. It just really makes the page look bad.

if he doesn't go the zip route, i'd make a dropdown or combobox and let the user select/enter the city. the radio button design does look terrible.

 

[Carson Dyle]

Do most people here do some kind of tandem arrangement? Front end person paired with a back end person?

Only in competent, well-managed teams. Why would anyone expect a good DB developer to be able to write interface code? And why would anyone expect a good interface developer to do web page and graphic design?

Plenty of people do it all on smaller projects. But not many people do them all well.

 

[Cogman]

fbb, The site looks really good, but Cerb is correct, it takes a really long time to load.

There are several things you can do to improve the load speed. The main thing would be to concatenate and (if necessary) minify all of your CSS and javascript files. Most clients have a maximum of 6 tcp connections that they can option. On top of that, TCP has what is known as "slow start" which means that each of those requests can be somewhat costly to make. Putting all of the css and js into a single file limits the number of round trips needed to load the entire site (it also can make the gzip compression more efficient).

You've also got javascript before css. A huge no-no This prevents the CSS from loading in parallel which gives you the worst of every world. Javascript should always follow CSS. (this is because javascript is executed immediately, which means the js could at that point modify the the header or what CSS files are going to download. In the end, the browser can't guarantee that the next css file loaded won't be monkeyed with by the JS, so it does everything synchronously).

Finally, you have a bunch of css files that just aren't used on the page. animate.css, bootstrap-formhelpers.css, etc. You can simply remove all of those.

You can get all of this information from a chrome audit of the page. I would highly recommend doing that before going live with this (if it isn't already live).

Also, btw, I would highly suggest using something like this https://developers.google.com/speed/libraries/devguide for stuff that you are using (jquery for example). The http connection restriction is per domain, so you can get 6 or so files from google and minify the rest of your files. This would be much faster than the current setup.

 

[Red Squirrel]

What I hate is having to deal with all the stupid versions of IE that do things differently. IE6 is probably the worse of the bunch. I don't waste too much time dealing with IE though, I just tell people to use a real browser.

Though I recently did a website for a local business, not something I usually do but it was family. In a situation like that I'm kind of forced to support IE too. I did mange to more or less get it to work though but it looks better in any other browser. IE seems to screw up on how it handles borders, padding and other similar properties. It also messes up PNGs but I noticed Firefox does the same thing too now, so next sites I make I make sure to either stick to jpeg or all PNG but not mix formats, or colors don't "line up". Ex: jpg logo on top of PNG background, the background portion will not match up with the logo which has part of the same background art in it. It's dealing with those kinds of quircks that I hate.

When stuff works I find it's fun to do though. I tend to whip something up real quick and concentrate on the actual back end code then come back and make it look nicer.

 

[Leros]

I'm a full stack developer, but I can barely do CSS. I can eventually lay out a page, but I'm not good at design. When it comes to making things look pretty, I usually hand off my basic UI to our UX team.

 

[Ken g6]

I'm a full stack developer too. Oddly, I frequently enjoy CSS. :devil: I'm not good at design at all, but given a design I'm quite good at turning it into CSS. Having to support IE is the worst part - I was very happy when we dropped IE7 recently.

@FBB, Try the Firefox YSlow plugin. I see you have...2MB of JavaScript!

@Red Squirrel, have you tried box-sizing: border-box?

 

[Red Squirrel]

@Red Squirrel, have you tried box-sizing: border-box?

Oh I always try all sorts of things, it's a game of pulling hair each time. I don't do websites enough to remember specifics on each one. That does sound familiar though.

Also I find that using a CSS "reset" file helps too as it ensures that all the defaults are set and not just assumed as some browsers use different defaults. For example in IE if a picture has a link it has a border or the padding is not the same in some situations as others in other browsers. A CSS reset fixes a lot of these things. Essentially I just use it as a base CSS file for the website and add my own stuff to it.

 

[beginner99]

fbb, The site looks really good, but Cerb is correct, it takes a really long time to load.

Yeah it's unusable. On top of what Cogman said all these js and css files aren't cached so fo every single page load they are downloaded again. This is also pretty terrible.

To improve on this I would use a CDN for all JS files were one exists.

For the location just use an auto-complete input type. User can start typing and gets a list of suggestions.

 

[fuzzybabybunny]

I'm a full stack developer too. Oddly, I frequently enjoy CSS. :devil: I'm not good at design at all, but given a design I'm quite good at turning it into CSS. Having to support IE is the worst part - I was very happy when we dropped IE7 recently.

@FBB, Try the Firefox YSlow plugin. I see you have...2MB of JavaScript!

@Red Squirrel, have you tried box-sizing: border-box?

Yeah... 2MB.

I've always wondered about this - what's a good size target to shoot for? Like for the JS or a web page as a whole, including photos and all that?

 

[Red Squirrel]

To be real honest, I despise Javascript intensive sites that use it just for the sake of using it. I actually got a blank page until I had to allow it in noscript. At least there's only 1 domain though, so that's not so bad, I hate it more when there's like 20 external domains. So if you keep all your JS on one domain it's not as bad, but you have to ask yourself, is it even necessary to use JS for everything? You should use regular html/css/php to generate the page, and JS only for the interaction. Ex: The site should look the same and be generally functional without JS enabled. Any interaction will not work obviously but one should be able to at very least view and read the immediate content. IMO of course.

 

[Cogman]

To be real honest, I despise Javascript intensive sites that use it just for the sake of using it. I actually got a blank page until I had to allow it in noscript. At least there's only 1 domain though, so that's not so bad, I hate it more when there's like 20 external domains. So if you keep all your JS on one domain it's not as bad, but you have to ask yourself, is it even necessary to use JS for everything? You should use regular html/css/php to generate the page, and JS only for the interaction. Ex: The site should look the same and be generally functional without JS enabled. Any interaction will not work obviously but one should be able to at very least view and read the immediate content. IMO of course.

It depends on what the site is doing. The current undercurrents seem to be towards highly interactive sites with loads of javascript to support everything. The likes of Angular and Ember are paving the way towards that.

While highly static web pages will always find their place, I think their days are numbered.

That being said, I do agree that it is probably good practice to at least show SOMETHING when someone hits your page with a javascript disabled. Even if it is to say "Looks like you don't have javascript, we really need that".

 

[fuzzybabybunny]

It depends on what the site is doing. The current undercurrents seem to be towards highly interactive sites with loads of javascript to support everything. The likes of Angular and Ember are paving the way towards that.

I have been coding exclusively in Meteor, which does both client and server side JS. It's, to put it bluntly, amazing.

 

[Cerb]

if he doesn't go the zip route, i'd make a dropdown or combobox and let the user select/enter the city. the radio button design does look terrible.

Agreed. The person using the form doesn't need to know about those separate zones.

Yeah... 2MB.

I've always wondered about this - what's a good size target to shoot for? Like for the JS or a web page as a whole, including photos and all that?

Good question. I have 1.5MB for Nitrogen's total JS footprint, which is basically JQuery, some glue code, and a JS/Erlang translator component. But, how much of it is needed in any given page? Isolate that, and only load that, for any single page. Some frameworks do that automatically, to varying degrees of effectiveness. If a page will have a bunch of interactive parts, it may need ever more, so it's hard to say there is really a target, I think.

 

[Graze]

Jesus Christ why does that page need 2 mb of javascript to function?!
It takes forever to load. Was loading time not even a consideration in the design of this thing? People would leave the page assuming it was broken before it comes up!

 

[Cogman]

Jesus Christ why does that page need 2 mb of javascript to function?!
It takes forever to load. Was loading time not even a consideration in the design of this thing? People would leave the page assuming it was broken before it comes up!

Depending on your internet connection speed, the 2mb isn't the problem here. It is more a problem of too many assets on the page and that there is a javascript header in front of the css. This is preventing the page from downloading the css/js in parallel.

The page could load much faster if all assets were combined.

*edit* though it does look like fbb is working on cutting things down.

 

[Graze]

Depending on your internet connection speed, the 2mb isn't the problem here. It is more a problem of too many assets on the page and that there is a javascript header in front of the css. This is preventing the page from downloading the css/js in parallel.

The page could load much faster if all assets were combined.

*edit* though it does look like fbb is working on cutting things down.

I am on a 32 megabit down connection and it still took way too long to load.
Ah ok guess its a work in progress

 

[Cogman]

I am on a 32 megabit down connection and it still took way too long to load.
Ah ok guess its a work in progress

Again, it isn't the connection speed that is a problem. Each HTTP request requires the browser to send a request to the server and wait for a response. Since there is a javascript module in front of all the css, that means that the page has to do this sequentially and not in parallel. Because of this, whatever the latency is between you and your server, you effectively add double that to each of your load requests.

So, if it takes 100ms to get to the server, that means you will have a 200ms round trip between you and your server. If you have 30 files (roughly what fbb has) that means you increase your load time by 6 seconds (you have to make the request and then wait for the server to respond). This is without even mentioning anything about file size, this is purely due to latency. Now couple this with the fact that requests aren't instantly parsed, files aren't instantly loaded on the server (or caches accessed) and all around you can see why the server would be slow.

If, on the other hand, you combined everything into 2 files, 1 for css and 1 for javascript, then you would make 2 requests (Which could be done in parallel if the javascript follows the css). With the same 100ms latency you could load the very same page in 200ms, or 400ms depending on where your js is on the page. It is a huge difference.

But it has to be noted, that even with a pretty low latency of 50ms, 30 resources will slow a page down by 3 seconds.

 

[Cerb]

Jesus Christ why does that page need 2 mb of javascript to function?!
It takes forever to load. Was loading time not even a consideration in the design of this thing? People would leave the page assuming it was broken before it comes up!

I did exactly that, before reading replies in the thread. Making it so that it renders almost immediately would help, regardless of size or file count.

 

[smackababy]

I didn't notice anything as broken. I just thought it was a slow loading website. Or, maybe I am not spending enough time for it to full render? IDK now.

Either way, the radio button options look awful in an otherwise decent looking page. Do something, even if it is only North [?], South [?], East [?], and West [?] with the question mark bringing up the actual cities in each zone.

 

[Markbnj]

Jesus Christ why does that page need 2 mb of javascript to function?!
It takes forever to load. Was loading time not even a consideration in the design of this thing? People would leave the page assuming it was broken before it comes up!

Fuzzy is just learning, so the fact that he got all that put together and working is a significant accomplishment. Now he just needs a little optimization...

 

[beginner99]

Again, it isn't the connection speed that is a problem. Each HTTP request requires the browser to send a request to the server and wait for a response. Since there is a javascript module in front of all the css, that means that the page has to do this sequentially and not in parallel. Because of this, whatever the latency is between you and your server, you effectively add double that to each of your load requests.

So, if it takes 100ms to get to the server, that means you will have a 200ms round trip between you and your server. If you have 30 files (roughly what fbb has) that means you increase your load time by 6 seconds (you have to make the request and then wait for the server to respond). This is without even mentioning anything about file size, this is purely due to latency. Now couple this with the fact that requests aren't instantly parsed, files aren't instantly loaded on the server (or caches accessed) and all around you can see why the server would be slow.

If, on the other hand, you combined everything into 2 files, 1 for css and 1 for javascript, then you would make 2 requests (Which could be done in parallel if the javascript follows the css). With the same 100ms latency you could load the very same page in 200ms, or 400ms depending on where your js is on the page. It is a huge difference.

But it has to be noted, that even with a pretty low latency of 50ms, 30 resources will slow a page down by 3 seconds.

Question is if the current way of doing it is a limitation or requirement of meteor? No idea never used it. It's also not helping that none of the resources are being cached or alternatively using a CDN for libs like jquery.

GET http://hpp.meteor.com/assets/plugins/jquery-2.0.3.min.js?_=1410340372489 200 OK 500ms

The ?_=1410340372489 forces a reload and circumvents normal caching of such files. Pretty bad idea.

also with 2mb per page load and lots of users you will run into bandwidth and data cap issues on the server quickly. It will cost a lot more. One of the main reason to use a CDN.

 

[TridenT]

ROFL WTF.

 

[Leros]

All the JS files might not be too bad if it was compiled and minimized into a single JS file. That's just another step in the build process.

One of my work projects includes over 100 JS files totaling a few MBs, but the compiled minified JS is only a single 200kB file.

 

[TridenT]

All the JS files might not be too bad if it was compiled and minimized into a single JS file. That's just another step in the build process.

One of my work projects includes over 100 JS files totaling a few MBs, but the compiled minified JS is only a single 200kB file.

The problem is that each one of those get requests is sequential. They go out and wait to be finished. That's why it takes so long.

 

[Leros]

The problem is that each one of those get requests is sequential. They go out and wait to be finished. That's why it takes so long.

Right, so you compile your JS into a single file. Instead of pulling down 50 files in sequence, you pull down one.