Related
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.
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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Quick question. Beginner web designer, please tell me how sites like this one:
http://workwankers.com/ have "automated" source code. What I mean is, as I interact with the site, the code will change. The above example is perfect; as you scroll, new things transition and come into play. Is this one technique/language? Is this multiple languages being used together?
Very confused, I do not see how this can be done in html and css alone.
It cannot be done using HTML and CSS alone.
The techniques you see are usually done using Javascript, or one of the many Javascript libraries out there.
If you'd care to learn more about web design, you might consider this link:
http://www.codecademy.com/tracks/web
Additionally, if you'd like to learn Javascript, you might try this one:
http://www.codecademy.com/tracks/javascript
The effects you see can be accomplished by the manipulation of HTML's DOM through the mixed use of CSS, JavaScript / jQuery, and AJAX.
HTML
(H)yper
(T)ext
(M)arkup
(L)anguage
HTML is the main markup language for creating web pages and other information that can be displayed in a web browser.
DOM
(D)ocument
(O)bject
(M)odel
The DOM is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML and XML documents. Objects in the DOM tree may be addressed and manipulated by using methods on the objects. The public interface of a DOM is specified in its application programming interface (API).
CSS
(C)ascading
(S)tyle
(S)heets
CSS is a style sheet language used for describing the presentation semantics (the look and formatting) of a document written in a markup language. Its most common application is to style web pages written in HTML and XHTML, but the language can also be applied to any kind of XML document, including plain XML, SVG and XUL.
jQuery
jQuery is a multi-browser JavaScript library designed to simplify the client-side scripting of HTML. Used by over 65% of the 10,000 most visited websites, jQuery is the most popular JavaScript library in use today.
jQuery is free, open source software, licensed under the MIT License. Its syntax is designed to make it easier to navigate a document, select DOM elements, create animations, handle events, and develop AJAX applications. jQuery also provides capabilities for developers to create plug-ins on top of the JavaScript library. This enables developers to create abstractions for low-level interaction and animation, advanced effects and high-level, theme-able widgets. The modular approach to the jQuery library allows the creation of powerful dynamic web pages and web applications.
The set of jQuery core features — DOM element selections, traversal and manipulation — enabled by its selector engine (named "Sizzle" from v1.3), created a new "programming style", fusing algorithms and DOM-data-structures; and influenced the architecture of other JavaScript frameworks like YUI v3 and Dojo.
AJAX
(A)synchronous
(J)avaScript
(A)nd
(X)ML
With AJAX, web applications can send data to, and retrieve data from, a server asynchronously (in the background) without interfering with the display and behavior of the existing page. Data can be retrieved using the XMLHttpRequest object. Despite the name, the use of XML is not required (JSON is often used instead), and the requests do not need to be asynchronous.
AJAX is not a single technology, but a group of technologies. HTML and CSS can be used in combination to mark up and style information. The DOM is accessed with JavaScript to dynamically display, and allow the user to interact with, the information presented. JavaScript and the XMLHttpRequest object provide a method for exchanging data asynchronously between browser and server to avoid full page reloads.
To be more accurate that would be what we call Asynchronous Javascript and XML (AJAX). This uses the Document Object Model (DOM) which is a tree that is built from the elements in the web page (think of them as HTML tags if you will). When the events are triggered the AJAX code can the modify this tree directly which in turn affects the code, somewhat.
Also, I would be a fool not to mention jQuery which is a library that sits on top of AJAX and allows for very easy manipulation of the DOM.
I'm currently evaluating the use of Backbone.js along with Aura.js for building an enterprise scale SPA.
I have a nice Javascript architecture mapped out that provides abstraction, consistency, flexibility and no dependencies on any base libraries.
As I see it, in using any MV* pattern (and in particular Backbone), markup generation could be scattered throughout views via a combination of direct dom manipulation and external html templates.
I would like to apply the same principles to the html markup in my views as I have with my Javascript architecture.
Abstraction - Ideally I would like to provide developers with a simplified API for producing markup, potentially shielding them away from the css classes/markup structure being used.
Consistency - I would like to promote and control consistency in the markup produced within a team of developers.
Flexibility - I would like to avoid having to find and completely rewrite all instances of certain markup if there comes a need to change either the css classes/markup structure being used. Ideally I'd like any changes to be made in one place, that will propagate throughout all uses within the system.
As a practical example of how this can be achieved server-side, we currently use a suite of custom HtmlHelpers within ASP.NET MVC (similar in design to KendoUI). These helpers provide a nice fluent API for developers to use and centralise control of the markup that is generated.
However as we're moving towards client-side UI generation I'm not sure how to gain the same benefits that are available in server-side markup generation.
I appreciate templates can provide re-usable widgets throughout the UI, however that does not completely address the issues outlined above, which apply when creating those templates and the layout to contain them.
So to summarise my question...
What practices can be employed to achieve control and consistency in markup generation within a team when developing enterprise scale SPAs?
Since your question is limited to Backbone.js and Aura, I'm not sure this qualifies as an answer, but I would definitely check 3 things
AngularJS and AngularUI - the concept of directives, resembles the notion of Web Components (a work in progress W3C standard for web controls)
If you like typed coding, and likes to live on the bleeding edge, check Dart Web UI it also uses a pretty much similar concept
If you have to stay in Backbone land, then I would check Backbone UI of course
I believe the first 2 have a better chance of answering your 3 requirements.
It seems the most common aproach to web design is to use HTML/XHTML & CSS in conjunction with other technologies or languages like Javascript or PHP.
On a theoretical level, I'm interested to know what other languages or technologies could be used to build an entire site without using a single HTML tag or CSS style for styling/positioning?
Could a website be made only using XML or PHP alone, including actual styling and positioning?
Presumably Flash sites are till embedded in HTML tags?
Thanks
There are actually several solutions that allow you to nearly completely avoid CSS and HTML.
GWT: Google Web Toolkit
Written in Java and will allow you to build both server and client code in Java. Used to build Google Wave.
Cappuccino and Objective-J:
Objective-J is to JavaScript as Objective-C is to C. It extends JavaScript with many near features, including type-checking, classes and types.
Cappuccino is like Cacoa (Mac OS X GUI toolkit).
Using these two you can build incredibly rich and desktop like webapps. They run mostly on the client side and you can use whatever you want on the server.
A good example is 280slides
SproutCore is similar to Cappuccino, but it uses pure JavaScript instead. Apple is using SproutCore to make me.com.
I should also mention that knowledge to HTML, CSS, JavaScript is a good skill to know, just like understanding your compiler is a good skill.
EDIT:
As said above Adobe Flash can also be used.
You can make a website with out a single html tag. Just give folder read access to all your directories, have sensible file names. From here you user will be able to browse images , read text files, download videos and depending on the content he may or may not come back ever again, but you do achieve the goal of setting up a "website" with out a single line of html or css or any other code for that matter.
:-) :-) :-)
You can host a telnet server with anonymous access and a specialized shell that restricts the user to doing whatever it is you want the site to do. ;)
Lets make the distinction between what is required by the web browser, and what you as a developer use to create that markup.
Remember that HTML nowadays is xml. You could use any markup language you like and convert that to HTML using XML.
eg ASP.NET uses markup such as which is converted on the server to .
As long as the content going down the wire to the browser is HTML, or generates HTML through script, you can use any approach you like.
However these approaches have mostly failed as developers prefer having direct control over the markup. It makes css as well as scripting much easier when you are certain what the html is going to be.
ASP.NET MVC is a product created in response to criticisms leveled at the ASP.NET webforms model.
Also, this is another answer because it's a completely different technology, but you can write an application in XUL and it'll run in Mozilla-based browsers without any HTML.
There's also XML. You can create websites with XML only. A well known one is World Of Warcraft. Check the page source. An XSL is used as stylesheet. There exist even XML based web frameworks like OpenLaszlo. You can let it serve either DHTML or Flash on reqeust out of a single XML template.
The Wt C++ Web Toolkit.
You can write your web application in C++ using Qt-style widgets (input boxes, buttons, tabs etc) and hook up client-side events to C++ code on your server. All without writing any HTML or CSS.
A sample application from their website (you may also want to look at this excellent tutorial):
HelloApplication::HelloApplication(const WEnvironment& env)
: WApplication(env)
{
setTitle("Hello world"); // application title
root()->addWidget(new WText("Your name, please ? ")); // show some text
nameEdit_ = new WLineEdit(root()); // allow text input
nameEdit_->setFocus(); // give focus
WPushButton *b = new WPushButton("Greet me.", root()); // create a button
b->setMargin(5, Left); // add 5 pixels margin
root()->addWidget(new WBreak()); // insert a line break
greeting_ = new WText(root()); // empty text
/* when the button is clicked, call the 'greet' method */
b->clicked().connect(this, &HelloApplication::greet);
}
void HelloApplication::greet()
{
/* set the empty text object greeting_ to greet the name entered */
greeting_->setText("Hello there, " + nameEdit_->text());
}
Curl (requires a browser plugin)
Wikipedia article
A webpage looks like this:
{curl 1.7 applet}
{value
let b:int=99
let song:VBox={VBox}
{while b > 0 do
{song.add b & " bottle(s) of beer on the wall,"}
{song.add b & " bottle(s) of beer."}
{song.add "Take one down, pass it around,"}
set b = b - 1
{song.add b & " bottle(s) of beer on the wall."}
}
song
}
Source
Since browsers view HTML, I'm assuming you mean create a site without ever having to edit/write HTML/CSS. The framework/app environment/whatever taking care of everything for you - yet still allowing you control over the presentation layer.
Seems like that is certainly possible on a theoretical level.
I ran across Noloh (not one line of html) a while back. Was intrigued, but never actually tried it out.
From various places on the Noloh site:
Because NOLOH does not rely on HTML or pages, maintaining complex rich Internet applications is significantly easier than with other methods.
Developing applications with NOLOH only requires using a single, unified language: a superset of PHP that completely maintains all aspects of server-client communication for you!
I think you could build a site entirely in SVG.
The front page of emacsformacosx is almost entirely SVG, for example.
Downsides: It wouldn't be viewable in IE (at least through version 8). And last I looked, text support, like flowing and justification, was weaker in SVG. (You could embed HTML inside an SVG element when you needed sophisticated text features, but that would violate your no-HTML rule.)
You'd probably still want to use CSS with SVG, because it's a good idea there for the same reason it's a good idea with HTML, but it wouldn't be necessary.
A website is always viewed through a browser (at least always if you are human :)). Browsers understand HTML. Whatever the technology - you have to basically render HTML. Even in cases with rich technologies like flash, the flash object that is rendered by a browser plugin is embedded inside the HTML.
In theory it is possible to do it without HTML, but the question becomes how much does the product diverge from the definition of a website...
One really short, simple answer... you can't :D
Flash requires an embed tag, an image requires an embed tag etc, so you'd have to use HTML in some method or another.
PHP is an embedded language, it is used to generate HTML on which the browsers renders, with XML, well technically a browser like Ie or FireFox will render it in it's own way for readability, but I would not class that as a website.
The major developments in the world of web technologies involves the development of HTML and CSS to improve them, there isn't any need for an alternative. In fact we're pushing towards a standard, what point would there be in introducing a new language to negate these standards. The whole IE saga would simply get worse.
Like the others have suggested, you could directly load an image or a flash file, but an image is useless on it's own, and a flash interface throws up loads of problems like SEO, accessibility etc, not least it's very heavy and usually completely misused. In my mind I wouldn't even class this method as a website, it just doesn't tick any of the boxes (IMO).
I think you can have an URL pointing directly at a hosted Flash (SWF) file, I've certainly done this though I don't know if all browsers work.
Anyhow, I tested this when developing MyDinos.
e.g: http://mydinos.com/home.swf
You can use Emscripten and its SDL subset.
You could try using quickstatic. You can code HTML templates from Python3. What is super cool about it is the fact that if you put in a for-loop for a certain item, you can generate that many items (maybe even use it to print items from a directory or quickly serve thousands of links).
Simply put, MVC is the pattern for separating contents (model) from presentation (view), and having a mechanism in place (controller) defining how to gather both.
If you already see where I am going at, I am very interested to hear your opinion on the matter. Of course, MVC applies to serverside mechanics and all, but think out of the box here with me for a second.
"Visitors" of the web, both human and robot/Google will be likely to see HTML and what comes with it. Writing structured and meaningful HTML, together with separating it from presentation using CSS has become more important over the years, and future technology such as HTML5 only contributes to this separation by offering a more content-focused set of elements, and mechanisms for working with the pure visual representation.
Considering all this, I was wondering if it would be correct in some way to say that the MVC paradigm applies to the front-end as well, where:
The model would be HTML, as in the pure httpwise contents that it has become
The view being CSS; it makes your content be presented a certain way
The controller being the webserver and all that lies underneath, it is what gathers and separates the model and view, and does all the decision making
Makes sense? Not?
VonC pointed me to an article that definitely changed my thoughts on the controller part. The browser takes up a major part of the controller too, as it handles a great deal of user interaction and how the model and view work together.
You can generally find MVC in anything if you look hard enough.
I would agree, although one can argue about the controller.
Jeff illustrates that point in his post, with ZenGarden
With:
Model = HTML
View = CSS
Controller = Browser (which is more 'front-end' than the web-server)
Actually, this is a valid perspective from the client-side.
From the server side (a server more complex than a simple html-page server), MVC would be different.
With ASP.Net for instance;
Model = all of your application logic that is not contained in a view or a controller. The model should contain all of your application business logic and database access logic. For example, if you are using LINQ to SQL to access your database, then you would create your LINQ to SQL classes (your dbml file) in the Models folder
View = HTML markup and content that is sent to the browser, plus scripts
Controller = responsible for controlling the way that a user interacts with an MVC application. A controller determines what response to send back to a user when a user makes a browser request.A controller is just a class (for example, a Visual Basic or C# class).
That is a services-ide perspective of MVC
No, sort of...
Your HTML is also at your presentation layer (View), although your CSS should contain the presentational specifics like fonts, colors etc.
Your Model must contain your data + business logic, and I really don't hope that you'll want to store these in HTML - that's for real programming languages, stored procedures and a DBMS to handle. And these should be at server side.
But to follow your line of thinking, I would suggest:
Model: Server side programs + DBMS
View: HTML+CSS
Controller: Webserver
I can see your point, but I think I would describe HTML-CSS-Server/Browser more as Document-Viewer rather than MVC. If all of the content is static then it is an expression of the model, true, but the model is embedded in mark up. Even though I can override it with CSS, CSS is really just a filter on the underlying presentation described in HTML. The HTML describes a view of the data as well as the data itself. To wit, I can turn off CSS and I still have a view of the data. In MVC, this is not possible.
There is also a close coupling between your HTML and your CSS -- both need to be very aware of the other. This violates a key paradigm of MVC where the components are loosely coupled. In particular the view enforces no constraints on the model (other than the restriction that the data be viewable). HTML designers are constrained to operate within the domain of the CSS or to modify the CSS to make it applicable to the domain of the HTML.
Further, HTML has no way of operating on the data to make persistent changes. A key aspect of the model is the ability to enforce business rules. HTML does not do this with static content -- the web designer does by the choice of the HTML encoding.
This doesn't make it bad, or not useful. Not everything has to be MVC. MVC simply describes one particular way of organizing your data and code. It has some particular advantages with respect to decoupled architecture and testability, but that doesn't mean that it is the only valid architectural pattern available.
Static HTML content, in my opinion, isn't MVC and doesn't need to be.
[EDIT] I am not arguing that you can't use MVC in the design of a browser, or that MVC isn't applicable to the the display of static content in a browser. I'm really looking at this from the perspective of the content provider, not the browser programmer. MVC could be a perfectly logical choice for browser design.
CSS is definietely not the view. Rather the rendering by the browser (which combines HTML/DOM and CSS input into a 2d layout) is the view. The HTML/DOM is the model. The controller is halfway built into the browser UI, but can be extended with javascript.
It is true that CSS is considered the presentation layer when talking about the content/presentation seperation - however that is a different (orthogonal) model.
In MVC, CSS is part of the model along with HTML/DOM because it is the underlying data which can be rendered in different views. For example, a print layout is a seperate view based on the same model.