Here are some of the languages one currently might use and integrate when making a webpage, and also a few of the things that a browser needs to have added to be able to support the whole world wide web:
Silverlight (not extremely popular)
So for the next incarnation of the web, I recommend combining the best features of all of these into one language.
1 is to use a procedural command to output XHTML (defined as a literal string, for the purposes of this question) to the screen. This can be a print statement, perhaps shortened as ? (after BASIC), although it would be more consistent to use the function that changes the contents of a DOM element, as it has to exist anyway for dynamic content. (The top-most DOM element, representing the whole window, would always exist by default.) We could make a print statement that can take a target, although if we do that then one should still be able to change content using a DOM-object-bound function, because those objects will already have a set of functions so that function should be included for completeness, so that makes the print statement somewhat redundant. But it *might* also be more convenient.
2 is to have separate sections of the document for code and XHTML. We still need 1 for dynamic content.
3 is to use a template language. Using a template language could be a pain, because who wants to keep having to escape lines of code? But then we'd still have 1 to work with, because you can't target a specific DOM object using the template way, AFAIK. Well, maybe you can but only by putting the template code within a DOM object so the object would have to be hard-coded into the page.
None of these options are mutually exclusive.
We could make web 4.0 backward-compatible with Web 1.0 or Web 2.0 (and that would imply Option 2), but then we have sort of defeated the purpose because instead of replacing 7 languages with 1 we have added 1 to make 8. Actually, though, web browsers would most likely support Web 1.0 and 2.0 as well as 4.0 because of the need for transition, so it's just a difference of whether they would support them in the same page or not. The real issue is that if we don't give the new language enough important features, people will still have reason to continue expanding development of, and making new websites in, the old languages, and then we would have defeated our purpose.
Security concerns would imply whether or not something is executed client-side or server-side. They obviously do anyway, but I mean automatically instead of manually. Certain objects could be demarcated as "no-read", and then those objects will not be sent to the client. Certain objects could be demarcated as "no-write" and then their value can't be set by the client. An example of a "no-read" object would be someone else's password. An example of a "no-write" object would be an SQL string. We may need to put consideration into what to do about objects and parameters whose values are determined from no-read objects but aren't the objects themselves and about no-write objects and parameters that are determined from other objects, because we don't want to make it easy to create subtle security leaks, but perhaps it would just be a no-brainer on the part of the programmer to make those objects no-read and/or no-write too.
Other considerations need to determine how the code is relegated too, though.
1. CPU bandwidth issues. Is the client likely fast enough? Would the server be too overloaded to process that information for each client?
2. The cost of client<->server communication: the issues of latency and bandwidth. Code could be delineated to minimize object transference. This might perhaps be possible to do automatically - delineate code by tracking information dependincies. But then information that depends on information from both sides is not always determinable because the compiler can't predict program flow and you don't know which variables are going to be asked most for. It's determinable for depencies in loops but not depencies in conditions, and not for groups of loops with different side-of-dependency ratios and dynamic loop counts (this raises Issue 3). This issue could be mitigated though because information gotten from server-side calls comes very fast and information that can only be gotten from the client side is slow and infrequent, because it requires user interaction, so we can always be biased toward running code on the server side where information from both is required.
3. How finely does it granulate its delineation? When does it put one code block on one side and one on the other, vs. when it would stick them together?
So we probably will need to provide a convention for manually determining which side code executes on, and that might make automatic security-based delineation pointless, but not necessarily if the convention is used infrequently.
I would personally recommend a modified version of Python for this unified www language. I may just sound like a Python fan, but it's just that I've noticed that, at every turn, Guido picks the design implementation that's simple enough for novices and yet powerful enough for veterans or even language theorists, facilitates simplicity and consistency, is very consise, and borrows the best features from every other language, all the while being extremely elegant-looking and about as readable as pseudo-code. (And where there's a balance between those features he always seems to know the best middle-ground.)
It's also almost the fastest scripting language, although it seems to be significantly slower than Java and that concerns me because I'm not sure if it could do some things like those fire simulations or ripple-in-water effects that some of those Java applets do. I guess we could always have another Java but with Python-like syntax and language features, or just have RPython.
One feature this language definitely needs to have is the ability to download parts of code, widgets, dialog boxes, etc. to the client on-demand, but in a way that's easy for the web developer, perhaps even automatic. The point is that if you load a very complicated and customized interactive page, you shouldn't have to wait a long time for it to load, because that would just put people off of Web 4.0.
BTW, The reason I call it Web 4.0 is that I already have Web 3.0 reserved; it's the idea to have Java applets have this load-on-demand feature and for websites to not only be dynamic, but to use Java to behave just like regular applications, with all the freedoms implied (except for the security restrictions, obviously).