CODEWITHSUNDEEP
htmlcssuser-interfaceweb-applicationsfrontend
zaloo
zaloo

Reputation: 919

Approach to building a GUI for a web application

First, a short disclaimer. I have next to no knowledge about web applications. I come from an iOS background where I exclusively wrote native code, so if you write your answers like I know nothing outside the shallow parts, that would be great.

I'm interested in learning a stack to develop web applications, but I'm not sure what the right way to build the GUI is. I know that a web front end consists of html and CSS to create the display and javascript as the bridge between the back end and the GUI, but I don't know the best way to put something together.

I know in iOS, you can use the Interface Builder (part of xcode that lets you graphically create the xml that describes the display) to create GUI's without any knowledge of how iOS translates the xml to some rendering, or even what is written in your xml files. Is there any analog to the web front end?

I'm mainly just looking for a list of the accepted ways to develop the GUI for a web application. If I have to learn HTML and CSS, so be it, but I'd like to know what my options are and the tradeoffs between each of them.

Upvotes: 1

Views: 5662

Answers (1)

Myst
Myst

Reputation: 19221

I can answer shortly stating that (technically) you can design web pages without coding in HTML or CSS, or even Javascript - although, you would be somewhat limited in your creative abilities and applications.

You can read about WYSIWYG html editors on this link, or try out ckeditor (someone said it's good)...

...I think a bit of background will help you reach a correct decision...

so here goes:

The Long Answer

I would start by trying to put the world of web programming and design into concepts that correlate with iOS coding.

If we look at the whole of a web app from an MVC perspective, then the browser is the view, the server is the controller and the database is the model... although this is very simplified.

Just like in iOS, each of these can be (but doesn't have to be) broken down into sub-MVC systems.

Just like any model in MVC, the view (the browser) can talk to the model (the database), but really it shouldn't. that's just bad practice.

If we break down the main-view (the browser) to a sub-MVC system, I would consider the HTML as the model, the CSS as the view and the browser (through links and javascript) as the controller.

It's not all that clear cut, but thinking like this helps me practice better and cleaner coding.

The HTML is the view's model for the web-app - it contains the data to be displayed or used.

HTML is a variation on the XML format and it contains data organized in a similar way to an XML file.

The basic HTML file will contain:

<html>
  <head>
  </head>
  <body>
  </body>
</html>

this should look familiar to you if you read any XML.

The CSS (cascading style sheets) is the view - it states HOW the html DATA should be displayed.

if your web app does't have any CSS, it will use the browser's default CSS/styling to be applied on the data in the HTML.

This "language" makes me think more about dictionaries in iOS (I think that's what they're called in Objective C). They have properties and values (like key-value pairs) that determine how the HTML data is displayed (if it's displayed).

They could look something like this:

body
{
  color: white;
  background-color: black
}

The browser is the web-app's view's controller - it makes it all work together and serves it up to the screen.

Javascript and links help us tell the controller what we want it to do, but it is the browser that acts (and willfully at times).

You can have a whole web app that acts without javascript, using only the default actions offered by links - in which case the browser will usually ask the server (the main controller) what to do.

Javascript helps us move some of the legwork from the server to the client, by allowing us to have a "smarter" controller for our view - just like in iOS.

The issue of the errant main-view / browser

Not all views are created equal, and not all browsers are the same.

Because the browser is used as the controller for the web-app's view, and because some browsers act differently then others, we web coders have the problem of working around someone else's idea of how our view's controller should behave.

You might see us complaining about it quite a lot (especially complaining about Internet Explorer).

These days, this issue is not as big of a problem as it used to be... it's just that some people don't update their computers...

WYSIWYG web editors

There are website builders and editors that try to work like X-Code does, by allowing us to build the website much like we would write word documents.

But, unlike X-Code which codes only the graphical interface of the view, these website builders write the model as well and usually add javascript into the mix.

When we use these tools (which I avoid), the whole MVC model breaks apart.

We can use them as a starting point for dirty work, but then we take their code apart and adjust it to our needs - usually by taking the code we need for the view (CSS) and applying it where we need it (and discarding much of the nonsense they add to the code and the HTML).

To summarize

As you can tell, HTML and CSS (and Javascript) are only a small part of a web app - as they all relate to the main view of the web app.

To write the controller and models for web apps, we use other tools (such as Ruby, PHP, js.node, MySQL and the like).

Coding the HTML and CSS isn't as hard as you might think, although it might be harder then I present it to be.

You can avoid writing code for web apps and use applications that offer WYSIWYG (What You See Is What You Get), but that would limit your abilities and will take away from your control over what you want to create.

Upvotes: 1

Related Questions