Web 3.0 brainstorming
-
In another thread there were complaints about how the web as an application framework, being a mash-up of different essentially incompatible protocols and languages, is essentially broken. So, let's fix it!
Let's use this thread to brainstorm problems with the web and possible solutions.
I'll seed some issues; feel free to discuss them or disagree with them. Maybe you could add your own....
Issues:
- Linking. Unquestionably, the popularity of the web stems from the ability to link to other forms of content or applications. Web 3.0 should therefore have some means of uniquely identifying content or applications and transferring the user to that content or application.
- Should content and interactivity be firmly integrated, or should they be permanently separated?
- Regardless of integration or separation, content and interactivity should be accessed by a single execution platform, i.e. a browser.
-
Currently, we have: Documents (using mostly (X)HTML+CSS, maybe a bit of Javascript for Eyecandy and Navigation); embedded interactive Objects (Flash, Java, ActiveX, etc.) and "real" WebApps using (X)HTML, AJAX, DOM etc., which are characterized as being higly interactive.
In Web 3.0, we should focus on the last item in my list. This is where the problem of "being a mash-up of different essentially incompatible protocols and languages" is most evident. Of course we can build some frameworks to hide the dirty details of "how to workaround some bug in browser x version y", but the constant need to upgrade those frameworks leads to a constantly instable and time-consuming situation.
What we needs are well though-out, well-defined standards for building such highly interactive apps, and of course some browsers to implement those standards.
Like a well-written HTML document works in all browsers without browser-specific twists, it should be possible to write a web application that works on any Web3.0 compliant browser.
-
Maybe OS's should be standardized, so one can access Web Applications that make full use of the computers capability.
When there is more bandwith, one can access games trough the web without downloading/installing them.
The browser will be nothing more than a window, in that window the same things can be done that are done by Native Applications.
The browser will not be a document viewer anymore, the browser will become obsolete as it is integrated into the OS.
Ofcourse this is speculation.
-
@Ice^^Heat said:
Maybe OS's should be standardized, so one can access Web Applications that make full use of the computers capability.
When there is more bandwith, one can access games trough the web without downloading/installing them.
The browser will be nothing more than a window, in that window the same things can be done that are done by Native Applications.
The browser will not be a document viewer anymore, the browser will become obsolete as it is integrated into the OS.
Ofcourse this is speculation.
What you talk about is nearly 10 years old, it's called "Windows + Internet Explorer + ActiveX" .
-
I ask that someone makes a copy of the TABLE tag and calls it LAYOUT so we can all carry on with life. Also, bring CSS into the age where webpages aren't just blobs of text with nice formatting applied to them. Am I the only one that thinks that CSS is trying very hard to keep everything in the same "feel" as it was when textfiles ruled the world? Websites are just as much about fancy presentation nowadays as they are about communicating information.
I personally think that the whole separation of presentation/content is flawed right now. CSS took a nice stab at it, but it utterly failed because you've still got elements one after the others. Short of doing everything absolutely positioned, which sucks for stretchy layouts and defeats the ability of putting something where something else ends, there isn't really a good way of precisely conveying your layout without the CSS being directly dependant on the HTML. First one to point to Zen Garden gets shot.
What I'd like is a kind of client-side databinding that works something like XML+XSLT (if anyone ever cared about XSLT), or what can also be achieved with AJAX, but built into the process. You'd get your content entities in a XML feed, which then select a HTML+CSS "template" that has placeholder markup that explains how the XML should be rendered. This is loaded, and the information is displayed in it. This way you have 3 distinct things: Content (XML), Presentation (CSS), and Layout (HTML), rather than just Content (HTML) and Presentation (CSS).
Link navigation would call up new XML feeds, that would bind into the templates. Templates could be cacheable and reusable. You could have different templates for printing, screen readers, etc. All the browsers should agree on this markup, and uniformly interpret the "back button" as "go back to the last XML feed". Then you'd have some scripting ability to control the loading of XML into specific placeholders, like what's done with AJAX nowadays.
Now you get visualizable XML feeds that can be consumed by browsers, desktop applications, webservices, and anything else you like. Give me that, and I'll be happy to advance my Web counter up to 2. :)
-
Some interesting ideas in this thread, but please, please, PLEASE stop saying "Web 3.0".
-
@iwpg said:
Some interesting ideas in this thread, but please, please, PLEASE stop saying "Web 3.0".
<Ernie-the-Muppet-snicker />
I hate Web 2.0 as much as you likely do... I just couldn't help it. :D
-
Observation 0: HTTP mostly works. Actions can either change state (POST) or query state (GET).
Observation 1: Applications, as opposed to static pages, require some form of remote procedure calls or distributed objects, often including support for callbacks. Callbacks cannot be implemented well over HTTP.
Observation 2: For latency reasons, applications require live code to run on the client. For privacy and security reasons, that code cannot be allowed access to information outside the application other than that provided by the user.
Observation 3: The current balance of power between designers and users is probably good, because it pisses off both designers (who want more control over the user's experience) and users (who want to be able to "fix" bad design decisions, such as tiny fonts, themselves). Any replacement layout mechanism must maintain this balance, or justify changing it.
Axiom 0: Distributed applications are a hard problem.
-
I have a couple of revisions I'd like to see in CSS. First off, classes should be able to be nested.
Instead of having:
html {
attribute1: value;
}body {
attribute2: value;
}html body div.contentDiv {
attribute3: value;
}you should be able to write:
html {
attribute1: value;
body {
attribute2: value;
div.contentDiv {
attribute3: value;
}
}
}This would give you greater flexibility with nested styles, and would ease using selectors. Color coding would make it easier to read.
Secondly, why is css its own syntax? Now that the information is all nested, it could be better expressed in HTML, as in:
<html attribute1="value">
<body attribute2="value">
<contentDiv attribute3="value"></contentDiv>
</body>
</html>
***Of course this would still go in its own file, to separate display information from content.***
One of the biggest benefits of structuring the display information into html is that this "stylesheet" could even be opened in a browser, giving you one place to preview all your styles!
Lastly, the "style" attribute should go away as a valid attribute, and the valid styles for each tag should become valid attributes for that tag.
-
I sure hope we can get away from HTML/CSS in the "3.0" timeframe. HTML is about 'marking up' 'hypertext', the fact that we've stretched that format out a long way doesn't mean it's any more appropriate for, say, full 3d experiences. In general, the whole problem with calling it "The web x.y" is that it tends to confuse web pages with 'the internet' instead of seeing one as a specific protocol/file format built on top of the other.
But, there's a lot of things I'm eagerly watching...
- I'm really interested in the concept of 'augmented reality' where digital information is overlayed on top of the actual environment you're in (whether that's through some sort of 'virtual light' glasses or some other mechanism).
- I like the idea of 'dynamic documents' that reform themselves according to the needs of the reader (imagine wikipedia except able to dumb-down or smarten-up it's content depending on the actions of the user).
- I think that we need some sort of authority who is able to establish the truthfulness of statements that are made as truth.
- There's a lot of power to mobile processes (if you want to make your head hurt, take a look at the pi calculus) in which not only the data moves around the network, but the software acting on it does as well.
- There are systems like Cyc, aimed at constructing knowledge in ways that can be reasoned against ontologically, which could help drive "just answer my question" type scenarios of interaction with data. (They want to create a true artificial intelligence...don't know about that so much, but along the way they are solving some interesting problems)
Some of these are technological problems, some are computation/scientific, some are social... but I think that's the sort of thing I'd like to see in 'the generation after this'...not just an upgraded way of specifying how to render text.
-cw
-
this is yet another reason why I hate M$, if M$ had of stuck to the standard, we wouldn't have as much compatibility issues and we wouldn't need to reinvent the wheel every time M$ hasn't stuck to the standard.
-
@rmr said:
I have a couple of revisions I'd like to see in CSS. First off, classes should be able to be nested.
This would give you greater flexibility with nested styles, and would ease using selectors. Color coding would make it easier to read.
Secondly, why is css its own syntax? Now that the information is all nested, it could be better expressed in HTML, as in:
One of the biggest benefits of structuring the display information into html is that this "stylesheet" could even be opened in a browser, giving you one place to preview all your styles!
Lastly, the "style" attribute should go away as a valid attribute, and the valid styles for each tag should become valid attributes for that tag.
It would be [i]extremely[/i] impractical to place style information in a duplicate of your XHTML code. If I'm reading your proposal right, your idea is no better than adding style attributes to the HTML everywhere, which completely nullifies the point of stylesheets.
There is a slew of CSS selectors available, and only one of them (1!) is aimed at tying styles to specific element names. The others ( space, >, +, #, ., [=], [~], to name a few) are designed to be applicable to any element.
How does your idea allow for the proper expression and application of all CSS selectors?
I agree with the death of the style attribute. All it achieves is mixed syntaxes, when CSS properties are conceptually on the same level as element attributes. But as the style attribute should be avoided like the plague as much as possible (exceptions possible), the issue is not that big.
====================
The first thing I'd like to see changed in current webdev is the amount of languages required to control a reasonably dynamic site:
- XHTML;
- CSS;
- Javascript;
- an AJAX or JSON library for javascript;
- a server-side language, preferrably being skilled in [i]multiple[/i];
- SQL;
The main issue is that all these languages have a well-defined purpose, and they all came into existance as valid solutions to a problem or some lacking. It's going to be hard to try and consolidate these a little bit.The first one to go may be SQL. I've always found it a bit odd to build strings of a weird human-like syntax, and send that off as a short-lived carrier, especially since the nonstandard data format returned by your DB driver is converted into a language-friendly format by your own library anyway. The idea of using only language-native constructs to query data has much merit -- even if those constructs are just an API around building SQL queries and calling SPs (isn't it true that RoR comes with such a lib by default?)
But then again,
SQL is language-agnostic. If you can do SQL, you have less to figure out about some new server-side scripting language: just look up its method of shootingqueries to the DB and you're good to go. So in that respect, SQL has its place. Still, I think it'd be a decent idea to try and put SQL into the scripting language itself, and forget about SELECT FOO FROM TABLE.
-
I find it odd you want to throw away SQL. It might not be the prettiest 'language' that is currently 'required' to do webappl development. But it surely is the one that most vendors have implemented almost corrrectly.
-
See?
Hard.
But that "almost correctly" goes for most languages. :)
IE has an "almost correct" implementation of X(HT)ML and CSS and JS, for example.
-
@dhromed said:
See?
Oops, you got my 'almost correct' wrong. I ment the basic functionality is the same, without difference, for all large vendors.Hard.
But that "almost correctly" goes for most languages. :)
IE has an "almost correct" implementation of X(HT)ML and CSS and JS, for example.
The basic "SELECT X FROM Y WHERE Z = '1';" queries work almost everywhere ;) (so far I've seen 1 sql 'engine' that chocked on almost everything, which was a WTF on it's own)
In HTML, not even the table tag is the same trough browsers.
-
@dhromed said:
It would be [i]extremely[/i] impractical to place style information in a duplicate of your XHTML code. If I'm reading your proposal right, your idea is no better than adding style attributes to the HTML everywhere, which completely nullifies the point of stylesheets.
Actually, you didn't read my proposal right at all. :)
Let me be very clear. I do not want to add style information to an exact copy of the XHTML. This would be unspeakably stupid.
*** What I would like is to have a seperate HTML page with one of each type of element on it.*** This page would represent the hierarchy of actual content pages by nesting style definitions within each other.
For instance, I frequently have two types of div's. One, unique to each page is (in standard CSS) the #contentDiv. Another is the #contentDiv .contentItem (ie. a content item div class inside the content div). Each page of mine has one one content div, but typically several contentItem divs. I could then style this simply with the following:
<div id="contentDiv" attribute1="value">
<div class="contentItem" attribute2="value" />
</div>This would instruct the html renderer to find anything with the id of "contentDiv" and set attribute1 to value on that item. Then it would find all items with a class of "contentItem" and set attribute2 to value for those.
Notice now that selectors are not necessary! After all, the selectors in CSS are simply a way of providing information about html structure. There is no reason why they can't be expressed simply by representing the structure in this summary way. Furthermore, not all selectors are supported by all browsers, which rapidly leads to CSS nightmares. I see absolutely no reason why we aren't better off without them. In this example, we have expressed information conveyed by the #, < and . selectors.
Finally, if we wanted to apply a style attribute to every type of an object, regardless of its nesting location, this syntax allows that too. Simply place the style definition at the top level. So, if we wanted to style all spans on the entire page with attribte3="value" we could simply add, at the top level of the page:
<span attribute3="value" />
-
Honestly, I think the "Web" and HTTP are great.
Web apps would be better off if we stepped back for a second and stopped trying to re-invent HTTP in JavaScript. XHTML is a good markup format. CSS is a good style tool. JavaScript is a good scripting language for making XHTML more dynamic. HTTP GET is a good protocol for retrieving information. HTTP POST is a good protocol for sending information.
-
@djork said:
Honestly, I think the "Web" and HTTP are great.
Web apps would be better off if we stepped back for a second and stopped trying to re-invent HTTP in JavaScript. XHTML is a good markup format. CSS is a good style tool. JavaScript is a good scripting language for making XHTML more dynamic. HTTP GET is a good protocol for retrieving information. HTTP POST is a good protocol for sending information.
How often do you have to debug a reasonably complex web application?
-
@djork said:
Honestly, I think the "Web" and HTTP are great.
Web apps would be better off if we stepped back for a second and stopped trying to re-invent HTTP in JavaScript. XHTML is a good markup format. CSS is a good style tool. JavaScript is a good scripting language for making XHTML more dynamic. HTTP GET is a good protocol for retrieving information. HTTP POST is a good protocol for sending information.
Web programming is an absolute nightmare. In order to create a halfway professional looking page you need to learn: XHTML, CSS, JavaScript, AJAX, DOM and possibly some Flash, as well as at least one of the myriad server side frameworks (ASP classic, PHP, CGI, Ruby on Rails, JWTK, ASP.NET). Then, you have to check all of this to make sure it works across the major browsers. Which it never does. To quote Steve Yegge:
"I mean, I'm all in favor of MVC, but I think Common Sense and its kissing-cousin Conceptual Integrity will both tell you that M, V and C don't need to be three separate languages. And the manifest and build information needn't be a fourth and fifth, respectively. And i18n a sixth. And the XPCOM system services an effective seventh. And the server-side languages Nth through Zth. It just doesn't make any sense."
http://steve-yegge.blogspot.com/2006/09/bloggers-block-3-dreaming-in-browser.html
Edit: Oh, and how could I forget! You can't do crapola without knowing SQL and relational databases.
-
@ammoQ said:
@djork said:
Honestly, I think the "Web" and HTTP are great.
Web apps would be better off if we stepped back for a second and stopped trying to re-invent HTTP in JavaScript. XHTML is a good markup format. CSS is a good style tool. JavaScript is a good scripting language for making XHTML more dynamic. HTTP GET is a good protocol for retrieving information. HTTP POST is a good protocol for sending information.
How often do you have to debug a reasonably complex web application?
Every day. That's my job. I do sites in a rather large and complex custom framework using ASP.NET for the web portion. I'm a little disillusioned with ASP.NET after having done "raw" web programming for a good long while. I think that the main reason for ASP.NET's success is not necessarily that it is good (which it is), but its low barrier-to-entry in a business sense. It's Microsoft, so it's safe to run on a business' servers. It's Microsoft, so there are certifications to hire people based on. It's Microsoft so there are plenty of people around who know it.
Good ASP.NET applications are great. But if I was going to build a new application from the ground-up, I can handle something a little more bare-metal, since I actually do know HTML, CSS, JavaScript, and many server-side languages pretty well.
-
@rmr said:
Web programming is an absolute nightmare. In order to create a halfway professional looking page you need to learn: XHTML, CSS, JavaScript, AJAX, DOM and possibly some Flash, as well as at least one of the myriad server side frameworks (ASP classic, PHP, CGI, Ruby on Rails, JWTK, ASP.NET). Then, you have to check all of this to make sure it works across the major browsers. Which it never does. To quote Steve Yegge:
"I mean, I'm all in favor of MVC, but I think Common Sense and its
kissing-cousin Conceptual Integrity will both tell you that M, V and C
don't need to be three separate languages. And the manifest and build
information needn't be a fourth and fifth, respectively. And i18n a
sixth. And the XPCOM system services an effective seventh. And the
server-side languages Nth through Zth. It just doesn't make any sense."Edit: Oh, and how could I forget! You can't do crapola without knowing SQL and relational databases.
XHTML: check, CSS: check, JavaScript: check, "AJAX": check, DOM: check, Flash: why? ASP 3.0: check, PHP: check, CGI: check, Ruby on Rails: check, ASP.NET: check, SQL: check. But you don't need to know ALL of those to write one web application. I'm going to say the first 3 are necessary, and then pick a server-side language. If your server-side choice requires SQL, then you need that to, otherwise you're good to go.
Really, though, you missed a HUGE part of what you need to understand to build web applications: HTTP GET/POST, cookies, session concepts, and web servers.
-
@rmr said:
@dhromed said:
It would be [i]extremely[/i] impractical to place style information in a duplicate of your XHTML code. If I'm reading your proposal right, your idea is no better than adding style attributes to the HTML everywhere, which completely nullifies the point of stylesheets.
Actually, you didn't read my proposal right at all. :)
Let me be very clear.
[i] [ splanin' ] [/i]
Okay, sounds rather fair. Converting CSS syntax to HTML would allow you to use the tree features of HTML for those selectors that revolve around it. You'd bring it into the family of MLs like XSLT.
What about the + and attribute selectors? What about selectors that aren't tied to a specific tag? It's fairly rare to always specify a tagname with a selector. ".newsitem" is common, "div.newsitem" is rare. Maybe an <elem> tag in the "CSS-ML" would address that.
-
@dhromed said:
@rmr said:
@dhromed said:
It would be [i]extremely[/i] impractical to place style information in a duplicate of your XHTML code. If I'm reading your proposal right, your idea is no better than adding style attributes to the HTML everywhere, which completely nullifies the point of stylesheets.
Actually, you didn't read my proposal right at all. :)
Let me be very clear.
[i] [ splanin' ] [/i]
Okay, sounds rather fair. Converting CSS syntax to HTML would allow you to use the tree features of HTML for those selectors that revolve around it. You'd bring it into the family of MLs like XSLT.
What about the + and attribute selectors? What about selectors that aren't tied to a specific tag? It's fairly rare to always specify a tagname with a selector. ".newsitem" is common, "div.newsitem" is rare. Maybe an <elem> tag in the "CSS-ML" would address that.
I have a really bad opinion of attribute and adjacent selectors, probably because 99% of the time that I see them they're used as part of some browser compatibility hack. So if rewriting the standard were up to me, I'd get rid of them (along with the horrid ',' selector), and web developers could just deal with it. :) However, I do see where they might be useful, and they definitely pose a problem for my css revision. The <elem> would certainly help for the attribute selectors.
Also, I use css like "div.newsitem" pretty much everywhere because I hate it when I have to hunt to find what style is being applied to an element, so I try to be as specific as possible. Is that not standard?
-
@djork said:
@rmr said:
Web programming is an absolute nightmare. In order to create a halfway professional looking page you need to learn: XHTML, CSS, JavaScript, AJAX, DOM and possibly some Flash, as well as at least one of the myriad server side frameworks (ASP classic, PHP, CGI, Ruby on Rails, JWTK, ASP.NET). Then, you have to check all of this to make sure it works across the major browsers. Which it never does. To quote Steve Yegge:
"I mean, I'm all in favor of MVC, but I think Common Sense and its
kissing-cousin Conceptual Integrity will both tell you that M, V and C
don't need to be three separate languages. And the manifest and build
information needn't be a fourth and fifth, respectively. And i18n a
sixth. And the XPCOM system services an effective seventh. And the
server-side languages Nth through Zth. It just doesn't make any sense."Edit: Oh, and how could I forget! You can't do crapola without knowing SQL and relational databases.
XHTML: check, CSS: check, JavaScript: check, "AJAX": check, DOM: check, Flash: why? ASP 3.0: check, PHP: check, CGI: check, Ruby on Rails: check, ASP.NET: check, SQL: check. But you don't need to know ALL of those to write one web application. I'm going to say the first 3 are necessary, and then pick a server-side language. If your server-side choice requires SQL, then you need that to, otherwise you're good to go.
Really, though, you missed a HUGE part of what you need to understand to build web applications: HTTP GET/POST, cookies, session concepts, and web servers.
Sorry that I left some stuff out, but the point is, it is silly to have to learn that gigantic list of things in order to call yourself a web developer. Is it impossible to learn all of those things? Obviously not. Is it more difficult than it needs to be? Yep. Does the quality of websites suffer because of it? Absolutely.
Unfortunately I don't see it getting any better anytime soon; web technology is diverging at an extremely rapid pace these days.
-
Let's put things in perspective a bit.
What do you need to know for normal application development?
- the programming language
- the quirks of your compiler (aren't there several C(symbol) compilers?)
- the system API
- knowledge of drivers
- knowledge of hardware (which can be broken down further into separate disciplines)So maybe webdev [i]isn't[/i] so bad, because there's a similar list of requirements for standalone programming.
-
@dhromed said:
Let's put things in perspective a bit.
What do you need to know for normal application development?
- the programming language
- the quirks of your compiler (aren't there several C(symbol) compilers?)
- the system API
- knowledge of drivers
- knowledge of hardware (which can be broken down further into separate disciplines)So maybe webdev [i]isn't[/i] so bad, because there's a similar list of requirements for standalone programming.
No, really not. For doing a simple application, knowledge of Java is enough. Of course you need to know the libraries, but they are well-documented and in almost all cases, they work as expected.
I do not care about compile quirks, I do not care about drivers and I definitely do not care about the hardware. I do not even care too much about the system API, since the java libs contain all I need. My Java programs do not contain native API calls. And I'm pretty confident that people using VB or C# enjoy the same level of comfort.
-
@ammoQ said:
No, really not. For doing a simple application, knowledge of Java is enough. Of course you need to know the libraries, but they are well-documented and in almost all cases, they work as expected.
I do not care about compile quirks, I do not care about drivers and I definitely do not care about the hardware. I do not even care too much about the system API, since the java libs contain all I need. My Java programs do not contain native API calls. And I'm pretty confident that people using VB or C# enjoy the same level of comfort.
Okay. :)
-
@ammoQ said:
I do not care about compile quirks, I do not care about drivers and I definitely do not care about the hardware. I do not even care too much about the system API, since the java libs contain all I need. My Java programs do not contain native API calls. And I'm pretty confident that people using VB or C# enjoy the same level of comfort.
C#... ditto. And, at any point when I do need to worry about some low-level like that, I look for someone that's already abstracted it for me. But then, I take the same tact on my web development...
- ASP.NET with C# for the server-side.
- NHibernate for data access. There went the need to write SQL in all but some interesting edge cases. You could make the case that I then need to know the mapping language...
- Dojo, ASP.NET AJAX, and Script# for "ajax" stuff. That takes care of any reasonably hairy ajax needs.
- XHTML for presentation. This is a good gripe, I haven't met many tools that do a reasonable job of letting me just drag stuff around on a screen and end up looking nice on all browsers / screen resolutions....
- CSS. This is still the part that stumps me the most. Well, this combined with how various browsers support or don't support certain elements. Truly fluid multi-column displays get sucky the minute you need to account for IE6 as well. I am definately not a CSS-fu master.
-
My short "Web 3.0" checklist would be:
- Create regulations that make non-standards-compliant browsers illegal to use in the public sector (government agencies etc.) or otherwise legally enforce standards compliance instead of relying on the good will of manufacturers.
- Make the use of XUL more widespread.
- Integrate the ability to comment, tag or rate the HTML documents by users into the protocol layer, thus creating something of a folksonomy.
- Provide a single architecture for implementing user accounts on web sites (so I don't have to type in my data whenever I sign up on a site). Make all the settings customizable offline, from the browser.
- Write an internet worm that exploits a vulnerability in IE or Outlook to download and silently install a modified version of Firefox that fakes IE look and then alter the shortcuts on the desktop. :-D
- Standarize electronic banking interface to permit browser integration.
- Abolish pop-up, pop-under and Flash advertising.
- Create regulations that make non-standards-compliant browsers illegal to use in the public sector (government agencies etc.) or otherwise legally enforce standards compliance instead of relying on the good will of manufacturers.
-
@webzter said:
@ammoQ said:
I do not care about compile quirks, I do not care about drivers and I definitely do not care about the hardware. I do not even care too much about the system API, since the java libs contain all I need. My Java programs do not contain native API calls. And I'm pretty confident that people using VB or C# enjoy the same level of comfort.
C#... ditto. And, at any point when I do need to worry about some low-level like that, I look for someone that's already abstracted it for me. But then, I take the same tact on my web development...
- ASP.NET with C# for the server-side.
- NHibernate for data access. There went the need to write SQL in all but some interesting edge cases. You could make the case that I then need to know the mapping language...To this point, I'd say we are on the same level with WebForms and WinForms. If the application is database-driven, we need NHibernate (or ADO.net) in both cases.
- Dojo, ASP.NET AJAX, and Script# for "ajax" stuff. That takes care of any reasonably hairy ajax needs.
- XHTML for presentation. This is a good gripe, I haven't met many tools that do a reasonable job of letting me just drag stuff around on a screen and end up looking nice on all browsers / screen resolutions....
- CSS. This is still the part that stumps me the most. Well, this combined with how various browsers support or don't support certain elements. Truly fluid multi-column displays get sucky the minute you need to account for IE6 as well. I am definately not a CSS-fu master.And this is the part that makes web development harder than GUI programming.
-
Wasn't java sort of designed for this sort of thing? what's wrong with having content being displayed by java?
from what i can tell what everyone already does with webpages can be emulated or made better by just implementing it in java, from text display to fancy GUIs.
AMIWRONG?
-
- XHTML for presentation. This is a good gripe, I haven't met many tools that do a reasonable job of letting me just drag stuff around on a screen and end up looking nice on all browsers / screen resolutions....
There are plenty of WYSIWYG editors, if you don't care what the code looks like. I mean Dreamweaver doesn't REALLY let you do it like that, but i have seen applications that will let you literally drag stuff onto a pane, and then put text around it (Copied from any RTF-esq program, i think), under it, over it, whatever you want. and no matter what browser you look at it on (within reason, i think) it will always look the same.
I sorta like using notepad to edit pages, but i really got in to dreamweaver because of the templates, and now i use it exclusively. I don't mess with CSS much (but i can), or xhtml, or anything like that. personally, i really prefer WEBPAGES to be read like books, and any interactive content to be seperate. Slashdot, thedailywtf, theonion, the guardianUK... these all read extremely well and i wouldn't have them any other way.
For the other stuff, Flash has its uses, and so does Java (like on broadbandreports.com under the "speed tests" section..) Dumping a java applet into a webpage is cool, but doing an entire website in java would be cooler. if i cared, or had enough time to relearn java, i might consider putting up a demo, but alas, i don't, and i don't, so i won't.
-
@GeneWitch said:
Wasn't java sort of designed for this sort of thing? what's wrong with having content being displayed by java?
from what i can tell what everyone already does with webpages can be emulated or made better by just implementing it in java, from text display to fancy GUIs.
AMIWRONG?
Other than the fact that Java's GUI toolkits (AWT/Swing) suck, no, you're not wrong.
But what about hyperlinking?
-
> And this is the part that makes web development harder than GUI programming.
True. There is no all-encompassing interface library/framework for websites.
If you program a desktop application, you'll usually instruct it to use the OS shell elements, which Just Work™, and when you do it properly, you'll have an app that works Just Fine™.
But for application webdev, you have to reinvent the wheel almost every single time.
-
@GeneWitch said:
- XHTML for presentation. This is a good gripe, I haven't met many tools that do a reasonable job of letting me just drag stuff around on a screen and end up looking nice on all browsers / screen resolutions....
There are plenty of WYSIWYG editors, if you don't care what the code looks like. I mean Dreamweaver doesn't REALLY let you do it like that, but i have seen applications that will let you literally drag stuff onto a pane, and then put text around it (Copied from any RTF-esq program, i think), under it, over it, whatever you want. and no matter what browser you look at it on (within reason, i think) it will always look the same.
But, if you care about what the source looks like, or if you want to ensure that it renders nicely for a screen reader, then there aren't a lot of great solutions. Granted, on some level, this isn't really worse than Windows GUI dev, but it could be a lot nicer.
-
@GeneWitch said:
Wasn't java sort of designed for this sort of thing? what's wrong with having content being displayed by java?
from what i can tell what everyone already does with webpages can be emulated or made better by just implementing it in java, from text display to fancy GUIs.
AMIWRONG?
If your audience already has the JVM installed, this can work, but most users will go on to some other web site rather than download and install that huge thing.
-
@newfweiler said:
@GeneWitch said:
Wasn't java sort of designed for this sort of thing? what's wrong with having content being displayed by java?
from what i can tell what everyone already does with webpages can be emulated or made better by just implementing it in java, from text display to fancy GUIs.
AMIWRONG?
If your audience already has the JVM installed, this can work, but most users will go on to some other web site rather than download and install that huge thing.
I can agree with you there, if JVM installed like flash player or something. How big is the .NET framework? i've never installed it via the upgrade thing (i have VS.NET) so i'm wondering if it's any better...
Also, wouldn't news of people switching to a pure java platform of media on the internet make it so everyone packaged it with their browsers? (i assume microsoft would balk at this, but what don't they balk at anymore)
-
@webzter said:
But, if you care about what the source looks like, or if you want to ensure that it renders nicely for a screen reader, then there aren't a lot of great solutions. Granted, on some level, this isn't really worse than Windows GUI dev, but it could be a lot nicer.
I'm gunna see if i have this software installed... and demo it on my site so you can see how crappy it is (or isn't)
Ah i don't have it locally. but the site is http://www.virtualmechanics.com/products/spinner/ and the main page was created using the software, i guess. the source looks like a mess. Let's write a wysiwyg html editor, shall we? (is coffeecup's WYSIWYG editor any good?)
-
@GeneWitch said:
Also, wouldn't news of people switching to a pure java platform of media on the internet make it so everyone packaged it with their browsers? (i assume microsoft would balk at this, but what don't they balk at anymore)
Until a few years ago, every browser came with a JVM. Then Sun, in a rather hard to understand move, told MS to stop distributing their JVM with the IE.
-
@ammoQ said:
Until a few years ago, every browser came with a JVM. Then Sun, in a rather hard to understand move, told MS to stop distributing their JVM with the IE.
Because it was the MSVM and Sun wanted their own VM to be used exclusively?
-
@dhromed said:
@ammoQ said:
Until a few years ago, every browser came with a JVM. Then Sun, in a rather hard to understand move, told MS to stop distributing their JVM with the IE.
Because it was the MSVM and Sun wanted their own VM to be used exclusively?
Well, Sun didn't want MS to taint Java with Windows-specific "Extensions" which would negate the plattform independence of Java; but then, even with MSVM cleaned up of that, they didn't want MS to include it in IE any more. Probably because it was based on an old version of Java, thus lacking the improvements that came with newer versions of Java. But in the end, given the market share of IE, Java applets mostly vanished from the web.
-
@dhromed said:
@ammoQ said:
Until a few years ago, every browser came with a JVM. Then Sun, in a rather hard to understand move, told MS to stop distributing their JVM with the IE.
Because it was the MSVM and Sun wanted their own VM to be used exclusively?
christ, wasn't that IE 5 that had the MSVM that started the huge chain of incompatibilities with the Sun JVM?
They're on like version 7 now. the sun JVM plays fine with IE, and as far as i know, the MSVM doesn't even exist on my machine (IE java stuff that is actual java won't load without having the Sun JVM installed and working)
JVM and the JSEE has pissed me off to no end in the past... but at least the end-user version isn't a horror to install anymore. click "ok" and wait, these days.
-
@ammoQ said:
Well, Sun didn't want MS to taint Java with Windows-specific "Extensions" which would negate the plattform independence of Java; but then, even with MSVM cleaned up of that, they didn't want MS to include it in IE any more. Probably because it was based on an old version of Java, thus lacking the improvements that came with newer versions of Java. But in the end, given the market share of IE, Java applets mostly vanished from the web.
I'd love to know what these "improvements" are of which you speak. The only good improvement Java has ever had was with 1.5/5.0 -- generics.
Of course! The MSVM didn't have Swing!
Still, I don't know if I'd call that an "improvement".
-
@Whiskey Tango Foxtrot? Over. said:
I'd love to know what these "improvements" are of which you speak. The only good improvement Java has ever had was with 1.5/5.0 -- generics.
Of course! The MSVM didn't have Swing!
Still, I don't know if I'd call that an "improvement".
How about the Collections Framework, introduced in 1.2, for a start? Regex in 1.4?
-
@ammoQ said:
How about the Collections Framework, introduced in 1.2, for a start? Regex in 1.4?
Ok, I'll give you collections. Regex.... sure, why not. Merry Christmas! :D
-
.Net 1.1 was about 22Mb and so was .Net 2.0. .Net 3.0 is about 50Mb. At least these are the redistributable package sizes.
