Website Creation + animations + scaling

[The_dude8080]

Hello. I am learning coding in general by myself. Been into a little of gaming design already and played with javascript, html. I am never done anything related to website design in general. I was wondering what are your approaches on doing it (visually only). Do you use pure javascript and css? How do you handle window content scaling across diferent browsers and screen resolutions? Is it with "%" values on css? And what about complex interactive website animations? Is it css solely?

Sorry if this sounds too broad but would actually help me quite a lot to get some different opinions about all these.

[ClusterAtlas]

Do you use pure javascript and css? 

- yup. but mostly js.

How do you handle window content scaling across diferent browsers and screen resolutions? Is it with "%" values on css?

- varies, to the point that sometimes you use css, and sometimes you use js (ie: on window resize, on browser games.)

And what about complex interactive website animations? Is it css solely?

- javascript, not css.

Maybe try to build a great understand of roles of js & css in browsers, that's a good start  since libraries like phaser or pixi - or whatever - are javascript libraries. css use in modern html5game dev is pretty rare actually.

[Tua]

When I need to set up a responsive website quickly, I use jQuery + Bootstrap. 

To quickly learn the responsive grid system of Bootstrap check this out: http://getbootstrap.com/css/#grid

[mattstyles]

Ha ha, they certainly are broad questions, but good ones I think!

Your approach should depend on what you want to achieve, there are many different types of website all with differing requirements and your approach should differ based on those requirements i.e. a solely client rendered site might well be overkill for a static blog site you want hacked up quickly (although there are nice approaches in this field, check next.js out, its superb and brings a very modern take, and all the advantages of that, to an older discipline).

There really is no best generic solution.

On 28/02/2017 at 11:06 PM, The_dude8080 said:

Do you use pure javascript and css?

Not usually for your average brochure site. It'll be server rendered (probably using JS in my case) and have progressive enhancement using client side JS. CSS, yes, as liberally as possible. CSS is awkward to use but very powerful. They'll be mostly HTML and CSS.

For anything 'appy' then I'd use a JS based solution. I'd use an isomorphic/universal solution (same code on client and server) but it does get complex and not something you'd want to tackle solo initially.

Some libs for you to checkout for JS-heavy solutions: React, Vue, Ember, Angular 2. These libs approach things very differently (although Vue and React are similar, and there are many great alternatives, or React-likes), bear in mind if you want to explore these libs it would take quite a while to learn them all. They all have a fairly steep learning curve. Note also that React and Vue focus on rendering, Ember and Angular are a more 'complete' framework (although many common setups for exist for React based apps, I'm happy to elaborate if/when you want to know more, but you're opening up a rabbit hole, albeit a great one!).

On 28/02/2017 at 11:06 PM, The_dude8080 said:

How do you handle window content scaling across diferent browsers and screen resolutions?

Media queries in CSS usually. Mostly they get you all the way there, but sometimes you need a little computation, so JS, try to avoid this.

% values in CSS can be very useful but it depends if you want a truly 'fluid' site (i.e. any dimensions) or a responsive site, which would render differently based on screen size (and other criteria). Generally speaking solely fluid designs are poor, large landscape screens require differing layout and considerations to small portrait ones and CSS and HTML structure can sometimes only get you so far. Responsive is better, but slightly harder to get right, but you can match elements of responsive with fluid i.e. for a basic page a % of 100% width might be great until you hit a certain width point, you could use `max-width: 1100px` for example, you maybe you implement a break point at 1100px width and change things more dramatically to account for more screen real estate. Check out bootstraps breakpoints for a generic set that tend to work well across the current spectrum of devices, but note they are guidelines, strictly speaking they are called break points because they delineate the points at which your design breaks.

On 28/02/2017 at 11:06 PM, The_dude8080 said:

And what about complex interactive website animations

Favour CSS animations as much as possible, they are powerful and flexible and all browsers will tend to punt these to the GPU or, at least, perform calcs in a separate thread meaning that your solo JS thread is free to do other stuff which should keep your animations smooth i.e. if you use JS based animations and then start loading stuff or performing other calculations then that competes for cycles with your animation code which can result in choppy animations. Having said that, truly complex animations often require JS, but the times when you need that are rare.

You might want to checkout `element.animate` which has a great api (originally very similar to jquery.animate and other animation specifications) with the advantage of offloading animations to the same engine used by CSS and thus should keep your JS thread clear. This works with raw DOM, many JS based frameworks eschew working directly with the DOM so this approach does not work (nicely) if you are using a rich client JS solution.

Note that some animations are more expensive than others, opacity is generally expensive whereas translation (and even scaling) is cheaper. Favour using transforms (i.e. you could translate by changing absolute positions or changing margins, but transforms generally get GPU accelerated whereas the others do not, although browser implementations do differ). For example, try animating a transparent element off screen in IE9, it plain will not work, the element will translate into view but opacity transition is ignored, instead the element will 'blink' to full opacity as soon as it is totally within the bounds of the screen. Thankfully modern browsers generally behave better.

Hope that helps a little!

[The_dude8080]

@mattstyles lol you only helped a "liiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiitle"  

Well I see that there are different websites and to achieve those different types there are different approaches. For what I understood there are very simple websites (like blogs) with a minimalistic interface where the owner publishes his "blog" entries and images in a single webpage and those kind of things. I didn't understand what is the role of the server in those websites if there is any actually. In my mind, exageratting a little of course, server = logic (parse information, gather user stuff ). How does a server rendered website relate to visuals? To the way you see the webpage? Isn't that solely related to front end code? I have little knowledge so sorry if this sounds really noobish...

What do you mean by something more "appy"? I mean what changes from designing these type of websites where you use react,vue, etc to the more simple "blog" websites?

Bootstrap seems interesting. I am not sure if it is possible but I what I would like is to only write the code of a page once. The page should be presented the same between mobile and desktop devices in terms of scaling and visuals, generally talking.

Yeah I think I understood the animations part in terms of more simple animations ( translations, etc; I have used Jquery in the past). What about those websites where the whole website is an animation? Well what I mean by that is for example if there are lots of things moving in the background and you can interact with stuff. Could the whole website be a canvas element for example? Take a look at this one for example : https://fotorator.com/en Really cool interaction

[mattstyles]

14 hours ago, The_dude8080 said:

How does a server rendered website relate to visuals?

Great question again about how the web works in general (you'd be surprised by how many peeps I interview who bag themselves as middle/senior weight but don't have a good handle on this).

If we start with a brochure site i.e. a largely static site. You make a request to example.com and the network routes that to your server, the server generally doesn't really care about domain so it says someone is requesting to view `/` (i.e. the root), someone has programmed me to return the 'homepage' for this url segment, so, it returns a string of html representing the home page. The browser receives this string, turns it into DOM, if it contains any links, like CSS or JS, it makes additional requests and deals with the responses i.e. the browser parses the html (mostly top to bottom), sees a `<link rel='styles.css'/>` in the head and opens a request for that asset, the server receives `styles.css` and grabs (or generates) that file and sends it as a string, the browser knows this is a stylesheet link so parses it as such and implements the CSS. At its most simple there is a file system somewhere with homepage.html and styles.css and all the server does is parse requests and return those files as strings. This is static serving and implementations such as apache, nginx or varnish handle this really well (they cache the results, i.e. store it in memory rather than a slow—ish— file system lookup). If you've heard of a CDN it generally deals with this sort of thing but does it by replicating the assets across the globe to limit the distance between client and server (the internet works, if you're lucky, via fibre cables, and the stuff (photons?) are limited by the speed of light so yes, distance is important).

Moving up from there we get to stuff like blogs. Blog servers have to work harder. They'll generally have some logic which maps url structure to structure on the file system or database where the content actually lives. Blogs will also have a system for managing that content, this is separate from what your client sees. So an `/admin` or something routes the user to a section where they can manage their blog, at its most simplest you could get away with ditching that, for example, you could add files to a file system with a defined structure and your server just routes requests to that file system. Stuff like next.js and I think jekyll and stuff works like that. This was the very first thing I ever created in the web world, so its certainly not too tough to do but there are plenty of parts to it. I'd share it, its out there publicly, but its old and probably not too helpful!

This is all server rendered stuff although there's nothing to change you doing this stuff on the client, you just have to be aware of stuff like performance, SEO, security etc etc (but you have to be aware of it anyway).

Some sort of dashboard is also traditionally server rendered as its related to grabbing data, similarly ecommerce traditionally takes that route, although both of these disciplines are changing rapidly, Samsung (Joyent) are developing a new web platform tool and most of the controls and dashboard are JS rendered, similarly companies like Tesco, Walmart and Uber are working hard on client rich stuff in ecommerce. Even silverstripe (PHP blogging software) has a new admin panel that is client rendered.

A typical journey would be that the server builds the HTML, then the browser requests the CSS and JS to accompany that HTML. This controls what it renders like. The process is the same on the client if you have a client rich JS rendered site but it's the JS building the HTML.

Does that make any sense?

14 hours ago, The_dude8080 said:

What do you mean by something more "appy"?

Any sort of dashboard, control or rich application can now be run in a browser, with the advantages of doing so. I think JS rendering makes a lot of sense in most of those cases, backed by a top-notch RESTful service to provide it with data there are lots of advantages of client rendered stuff, although plenty of challenges too and not everyone will agree that anything on the web should be heavily client rendered. Anything non-static is a candidate for client rendering, but, to be honest, things are changing to dump more and more on to the client, with the rise of isomorphic or universal methods you'll see client stuff more and more prevalent in every site you visit.

For example, every time I hit back on this forum the browser reloads the view I've only just seen, if I have some network issues (on the train perhaps) then it can be slow, even though I've just seen the previous view. Client-rendered could eliminate this user problem by holding as much as possible in memory, it could also preload as much as possible to try and predict what the user will want next (I believe next.js does this). 

14 hours ago, The_dude8080 said:

Well what I mean by that is for example if there are lots of things moving in the background and you can interact with stuff.

You'd be surprised at how far you can get with the DOM and css rendering, although you could well have the background of your site as a canvas.

14 hours ago, The_dude8080 said:

Could the whole website be a canvas element for example?

Technically yes, but practically no.

Stuff like SEO and accessibility would be destroyed by taking this approach, not to mention handling different device sizes is a major ball ache. There are lots of things that the DOM is actually better than canvas at, such as UI and layout (surprise surprise) and these things are generally more of a concern with a typical web site than with a game.

14 hours ago, The_dude8080 said:

Take a look at this one for example : https://fotorator.com/en Really cool interaction

Yep, its neat, but not on mobile! This is part of the problem with interactions like this, they'd actually be better on mobile but typically they get ditched on mobile, presumably because devs ran out of time (or money more likely) to give a good performance on mobile. Mobile traffic already exceeds desktop traffic, particularly for browse journeys, so expect this to change.

[The_dude8080]

Oh I see. I think I understood the server as renderer. In node.js I used to do something like this "jade.renderFile("path")(...)" (I was using jade template). I had no ideia of the whole relation Server <-> frontpage. Was very very clarifying  Yeah heard of CDN before but didn't know much about it. In the same node.js experience I also set different paths that I should the only one able to access. It was something like the one you said actually  "/admin" (pretty common I guess lol) but I never actually made it only accessible be me. It was all on the "public" part since I never really made that web experience public... But the path was still different and If that ever came to public I suppose I had to made that location "private".

I find that website optimization very interesting. When the render process is optimized in a way that it loads the information as fast as possible sometimes, as you said, predicting what is supposed to load before even loading it. Very nice indeed.

Never made a mobile application (tried playing with html5(phaser engine) -> webview using intelxdk) though... not native mobile app but I think I understood what you mean. Your knowledge is astonishing