Why HTML/JavaScript/CSS are not becoming compiled languages (or maybe even merge into a single compiled language)? What if browsers were running "Browser Virtual Machine" and html/javascript/css sources could by compiled to a "browser bytecode". Wouldn't it help developers and users a lot?
I can see a few challenges:
What to do with zillions of existing pages? Make this compilation optional, so if you want you can use plain old html. If you want to feed a browser with a compiled page just use .chtml for example.
How search providers would index pages? Make a decompiler that would decompile bytecode into exact original sources (for example like flash can be decompiled). Or search providers can use the same virtual machine and get data they need from there.
How to make it compatible with all browsers? Have one centralized developer (lets say w3c) to develop this virtual machine and then each browser would embed it.
But what about benefits:
Speed.
Size.
No more "loose" and "half-correct" html. It is either correct or won't compile.
Looks the same in every (supported) browser.
If not a bytecode then at least have some native compression going on, html probably is not the most efficient way of data storing. I know there is gzip but why to compress pages every time on a server and decompress in a browser if we can compress it once and feed it to a browser?
So what stops us from taking this road (well, besides a huge amount of effort to make it all happen)?
Ah, but Javascript IS becoming a compiled language. Check out Firefox 3.5 with TraceMonkey. It's insanely fast compared to um you-know-who's browser. It's true that JS will never be C, but it's a much more dynamic language than C is, and in many ways that makes it more expressive and powerful.
As far as HTML goes, I don't think that the lack of validity of HTML is a huge detriment to speed. I think the engines that put together the visual representation and manipulate the DOM need to get a lot better (um, IE, I'm looking in your general direction...). CSS compliance needs to get better, and CSS itself needs to get more powerful. (Get on the bus with CSS 3 people!)
But I do think that speed is going to get better on Firefox and Chrome to such an extent that people really ARE going to start using it for mainstream application development. It's funny. Adobe seems to be selling Flash as their platform for dynamic web content, MSFT is selling Silverlight for dynamic web content, and Google just wants to really improve HTML and Javascript to display dynamic web content. And Google's doing pretty well at it so far, I must say...
Your ideas have validity when they are applied to JavaScript. As others have noted, to one degree or another several vendors are trying to apply those principles to JS even now. Another big step in this area will likely be the Chrome OS Google has announced. However, when it comes to (X)HTML and CSS I think your ideas may be missing the point.
The world wide web is not a buggy and inconsistent application platform but a massive and unprecedented collection of interconnected documents. The power of the web is in the abstraction of the data from the often rigid (and breakable) visual layouts and increasingly complex in-page functionality largely provided via JavaScript. Encoding these pages in (X)HTML is ideal for making them accessible to the widest possible audience both in terms of browsers and in terms of technical knowledge required to author a page.
More and more the web is being used as an application platform - which is a powerful and exciting use of this technology - but we cannot lose sight of the fact that these Ajax-driven "web 2.0" apps are merely documents with extended functionality. Compilation doesn't make sense for a document and compression is already happening (via gzip and the like).
On a more practical note, the W3C moves at a glacier's pace and browser vendors take turns between jumping-the-gun supporting experimental features in unfinished specs and taking their sweet time supporting other specs which have been on the table and in common usage for years. The whole processes is like herding cats. I wouldn't hold my breath for them to make the kind of radical changes you're proposing any time soon.
Since HTML and CSS aren't code they can't be compiled. Google Chrome's V8 engine does actually convert JS into byte code, expect other rendering engines to follow suit!
http://code.google.com/apis/v8/design.html
We recently reworked a php template system I've helped create to use minify to compress multiple JS and CSS into one file each, seeing our file sizes drop to about 20% of the origial combined sizes. Minify also does gzip and caching so it's really amazing for speeding up websites.
http://code.google.com/p/minify/
In short you can't compile non-code, which HTML and CSS are. JS can be compiled and is starting to be, but all depends on what browsers feel like doing.
Browsers just need to be on the ball regarding supporting web standards. The more browsers do this, the less headache us web developers have. I was quite happy with YouTube's very public drop of support for IE6. We need more action like that for the web to move forward.
The V8 javascript engine (also embedded in Google Chrome, but it's open-source and liberally licensed so you're welcome to use it in the next browser you write!) does compile Javascript to native machine code -- of course, it does it "just in time" (like most modern compilers -- Java, C#, etc!), not "ahead of time" (like Fortran did in 1954 when computers were just too weak to handle compilation in the midst of execution). I'd be surprised if other good JS engines, like those in the very latest Firefox and Safari, didn't do the same.
Looks like you're not advocating "javascript as a compiled language" (since it obviously already IS compiled, if you're using a good JS engine), but rather "ahead-of-time" compilation for it (just when most modern languages are essentially abandoning ahead-of-time compilation). Pushing machine code rather than compilable code down the wire sounds like a mostly horrible idea -- much larger size, difficulties in supporting one CPU vs another, security nightmares in properly sandboxing it, etc, etc) with not much in term of compensating benefits.
That said, if you're really keen on pushing machine code to the client, try out nativeclient (as long as the client is an x86 machine - forget every smart phone on the planet, many netbooks, good old macs, etc) -- at least it promises a fix to the security nightmares. If and when you're happy with nativeclient, transforming a just-in-time compiler into an ahead-of-time one is a far easier technical challenge (if you want to keep using Javascript for the sources rather than other languages, of course).
See here for a previous discussion on the matter
Not all of the reasons given are necessarily valid, but one important one is that, unless you're Google, server-side CPU cycles are a lot more valuable than client-side cycles: so it's easier to have the client compile/optimize what is quite often dynamically generated HTML/JavaScript, rather than the server.
Ken
Speed.
You're assuming that it takes significant time to parse HTML. However it might be that that time is insignificant compared to the time required for something else, e.g. the time required to layout the text on the end-user's window.
No more "loose" and "half-correct" html. It is either correct or won't compile.
You already get that, using [X]HTML.
Looks the same in every (supported) browser.
You seem to be saying that there should only be one browser, or that all browsers would support it equally.
Internet standards don't happen by having a single body (the w3c) implementing something and declaring it a standard. Instead, internet standards happen by having multiple independent bodies creating multiple implementations. A consequence is:
Some people have developed something that isn't standard yet (i.e. they're ahead of the standard)
Some people haven't yet developed something that is standard (i.e. they're behind of the standard)
I think your idea is sound, however there's still no way to enforce a standard. Thus if there was a non-supported feature, there's a good chance the entire page would simply not display anything. In the current setup, critical information can still be passed.
Google V8, which is one of many new-generation javascript engines 'compiles' javascript into pseudocode, much like .NET 'compiles' c# on the fly. Nothing magical here. Expect more of it esp. as webapps get heavier and more demanding
HTML
HTML is pretty much XML. DTD'd exist for various versions and developers can check against that at any time.
CSS
CSS is not a programming language, however I do agree that "compiled" CSS could work seeing as compilation would compress it. However with the support that CSS has and with the number of essential hacks any CSS needs to have, you'd never manage to compile it without errors.
JS
As others have mentioned, JS IS becoming a compiled language except the browser compiles it for you and not you yourself.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Like, can I write a business strength application in HTML5 that mimics our current system that contains many highly interactive grids, custom trees and so on.
We have a good working system written in C# WinForms with parts done in WPF and have recently embarked on writing a custom app for the iPad that communicates through WCF with our main server hosts. We now have a very fast custom grid written in C# that compiles to Objective C through MonoTouch and also a cool interactive pie chart.
Now my boss wishes to build a version for Android and I am thinking if we shouldn't really be spending time creating a single HTML5 app that can run on both iPad and Android equivalents.
Thing is - take a grid - my grid on the iPad is fast (re-usable cells etc) - how would I create a grid from a 'dataset' type source in html5? Do I really have to go down creating lots of tags and then submitting them to the browser? Are third party widgets like jqwidgets the answer??
Thanks
This is a bit anecdotal, but my experience has been that HTML5/JavaScript are just not fast enough on mobile devices yet (in 2012) particularly if you are displaying lots of data, especially and you want fast response times with interactive features. Give it another year, and I wouldn't be surprised if this statement becomes outdated as mobile devices continue to evolve.
Mobile web development certainly has its uses currently, e.g., if you want to target the most devices with a single codebase; if you don't have enough development resources and are willing to settle for a non-native experience; if you don't have experience in the languages required for native development, etc.
Given that you already have done the work for the iPhone app, my humble opinion is that it's probably better to move forward with a native Android application -- you will get a much more responsive application for about the same amount of work at this point.
how would I create a grid from a 'dataset' type source in html5?
Depending on what the grid contains, you can do it with plain old HTML tables or with a combination of other elements styled with CSS. There are really many more considerations though-- e.g., does it need to work on small screens (e.g., phones) or just larger screens (tablets). Often, you can't really fit a whole grid on a small screen, so you end up with UIs that aren't really grids anymore. You can take a look at a mobile JavaScript framework such as jQuery Mobile to see how they've done it and maybe even consider using the framework for use in your own application.
The various JavaScript frameworks (eg. JQuery and Dojo) have mobile device-specific widgets of quite high quality. Have a look at http://dojotoolkit.org/features/mobile and http://jquerymobile.com/
How close do these get to native apps developed in ObjectiveC and Java? Not perfect but maybe good enough. You can also use a combination of native and HTML in the same app, some pages native some HTML. I'm doing that kind of thing with IBM's Worklight, but then I would, I work for IBM ;-) Irrespective of specific products I do see folks taking that approach.
In addition to portability, anoyther of the benefits of having much of the app in HTML is that updated versions can be delivered without going via an app-store - this increases agility of functional delivery.
As evidence, I'd say that a lot of Windows 8's apps are just wrapped JS/CSS/HTML, with a few APIs which Microsoft supplies to allow access to hardware/the filesystem.
I wouldn't think that they've gone so far as to make Excel 2013 JS-based...
...however, with that said, they have gone so far as to allow developers to extend their programs with applet views of the data -- those applets are all going to be built on "html5" (again with an MS-Office JS API).
It's not an easy road to go down -- people look to jQuery to be their saviour for these types of things.
This is exactly where jQuery would not be what you wanted, if you were looking to hack together a solution.
For example:
$(".table_cell").click(function () { alert(/*whatever*/); });
People think that jQuery is assigning a delegator to listen to any click on any element containing class="table_cell".
That's really not what it's doing.
It's looping through each one, and attaching an event-listener to each one, directly.
It's these little things that people miss -- people like Twitter, who didn't bother caching references to elements, because jQuery is so easy to hack things together with.
So then you have JS touching (or acting on) dozens or hundreds of individual elements, at all times.
That's not good for anyone.
jQuery isn't bad at all -- it's quite helpful, as a low-level construct to help skirt around browser differences.
Some of its plugins are also all right.
I can't guarantee that they're all high-performing answers to all things.
But some of the plugin-creators understand how to maintain a responsive and well-performing program.
Which ones are right for your exact needs? Who knows, other than you.
Will they perform perfectly, and quickly?
That depends on a lot of different things, of course.
Coming from C#, you might do to look at something like AngularJS.
Angular, itself, uses an internal version of jQuery, to tackle some of the low-level stuff that jQuery has made a solved-problem.
But it allows for data-binding, and pretty simple view templating.
Hammer.js is also a very decent gesture-tracking library.
From there, though, I'd suggest building your own framework, if you want it done the way that you want it to be done.
Nobody knows what your needs are but you, and trying to stuff things into a shoebox, because it's available, isn't always the solution, regardless of what various companies may think...
You can leave most of the node-work to Angular, you can leave the gesture-sensing to Hammer, you can pull out some other basics from jQuery-lite (the no-frills jQ installed inside of Angular, if you don't have jQ on your site), or jQ, itself...
But they're just tools and not answers.
The web can be very responsive if you cache references to elements, rather than querying for them over and over, delegate events, do large structure-changes off-DOM (on cloned-nodes, if necessary), and don't try to treat JS as a traditional inheritance-heavy language, and you remain mindful of how and when to use AJAX (number/frequency of calls versus size of data -- favour fewer calls).
The codebases for modern web browsers like Chrome, Firefox, and Safari (WebKit) are quite large. I am curious about what specifically makes their implementations so non-trivial that they require vast amounts of code.
As a corollary question, if a hypothetical browser only supported strict HTML5 and JavaScript, to avoid compatibility hacks, would the codebase be significantly smaller?
For your first question, consider the things a modern browser needs to implement (some browsers push some of this work out to operating system services):
Several parsers: XML, HTML, JavaScript, CSS, at least.
At least four separate layout systems (CSS box model, flexbox, SVG, MathML).
At least one graphics library; for cross-platform browsers this needs per-platform backends (IE9+ just uses the system Direct2D library; Safari on Mac just uses Quartz as far as I know).
A high-performance virtual machine with a JIT, a garbage collector, a bit of a standard library (growing all the time; see typed arrays and various other recent JavaScript features).
A DOM implementation, including various things like the HTML-specific and SVG-specific DOM interfaces and so forth.
Audio and video processing facilities (again Safari on Mac and IE offload these to the operating system).
Image processing facilities, with support for at least JPG/GIF/PNG. Again, some browsers may be able to offload parts of this to the operating system.
A library for converting byte streams to Unicode characters. Again, sometimes this can be offloaded to the operating system and sometimes not.
For cross-platform browsers, some sort of portability layer that abstracts away the platform-specific bits.
An HTML editor with transactions and a programmable API; think contenteditable.
A plaintext editor for textareas. Some of this can be shared with the HTML editor, maybe.
A spellchecker, which may or may not be offloaded to the OS.
A network library supporting HTTP, maybe SPDY, probably FTP, and maybe a few other protocols. Again, this may or may not be offloaded to the OS.
A cryptographic library to handle SSL and various other cryptography needs. Again, this may or may not be offloaded to the OS.
At least one database implementation (sqlite seems to be popular).
Various code for the actual user interface and whatnot.
Glue code to handle interactions between all these: code that manages calls back and forth between JavaScript and the DOM, code that manages recomputing style and layout information when the DOM changes, code that handles things like document.write injecting strings from JavaScript into the parser's input stream, and so forth. Note that the amount of glue code is generally quadratic in the number of interacting modules.
I'm probably missing a few things, but that's off the top of my head.
In addition to this at least Gecko and WebKit have template libraries for things like strings and arrays (because the C++ standard library ones have various drawbacks).
For the rest... at this point a lot of the "compatibility hacks" are actually part of web standards. So you can't exactly avoid them. Your scenario talks about JavaScript and HTML but not SVG or MathML or CSS. If you really just mean HTML and JavaScript but not CSS or the rest, then you could obviously cut out a bunch of code. If you include all of those, plus the audio and video capabilities of HTML5 and want your browser to perform well, then I doubt you can make it much smaller.
I think modern web browsers are complicated apps. Mainly, they have rendering engines which have to handle different kinds of HTML, ability to deal with not HTML formats (like XML, RSS etc.), CSS handlers, Javascript engines sometimes with a JIT.
Apart from that, they have plugin architectures and APIs, parts to abstract differences between platforms and are usually built using components that other apps use.
This makes them quite non-trivial. As for your collorary, I think so. Lynx is quite small and doesn't support Javascript or fancy HTML.
I am learning how to program and my goal is to build a simple functional prototype...I'm at the very beginning.
I am not concerned with the visual design at this stage, other than as it relates to being able to demonstrate the functionality.
My question is: do I need to worry about ironing out cross-browser bugs in the HTML/CSS, or can I do development on a single browser? (Perhaps a better way of asking this is does the back-end programming have any effect on which browser is displaying it).
If you are at the very beginning and only want a functional prototype, do not worry about cross browser HTML/CSS. In fact forget the CSS altogether and focus on printing just standard HTML. Since the visual design will change, focus on the content, styles can always be applied and switched later.
If you need Javascript/AJAX stuff I would recommend using a library like JQuery that has already solved many cross browser problems for you.
The back-end stuff "Perl, PHP, Python, etc" shouldn't care about the browser as it is simply printing text for the browser to render as it will.
The back-end programming will affect the way a given browser displays your page and there might well be two schools of thought on whether you should be picky about the browser compatibility issues.
On the one hand, if you're just finding your feet in web development it might be asking too much to expect to have a standards-perfect, cross-browser site or application every time. It might be better to focus on actually accomplishing a finished result and learning as much syntax and technique as possible.
On the other hand, it might be argued that it's a good idea to get into the habit of adopting good practices now and recognising the sorts of things that are going to give you headaches... probably when you view your page in Internet Explorer. This takes more time to reach a finished product, but it would teach you good habits up-front.
Really it comes down to your own approach and preferences. Do you want to be detail-oriented and turn out a polished result in a longer period of time, or would you prefer to just get to the finish line and identify issues on a case-by-case basis?
Do car prototypes have a working stereo, leather upholstery, chrome rims, dice, and other random stuff which does not demonstrate the functionality of the newly-designed car?
My rule of thumb is that if it takes you more than 10 minutes to make it look acceptable to others (I'm completely fine with a disgusting design when prototyping), you're spending too much time on the aesthetics and less time on the actual clockwork.
What good does a "pretty-looking" site do if it has no functional layout?
This depends on both your audience and on your tooling. If you are trying to support all users on all browsers, then you will certainly need to do testing on those browsers (although actively developing on those browsers may not be necessary), whereas if you only need to support WebKit-based browsers (Chrome, Safari) or WebKit-based browsers and Firefox, that is less testing that you need to do.
It also depends on your tooling. For example, if you are writing directly in HTML and CSS, then you are much more likely to run into browser compatibility issues. However, if you use a tool such as GWT, which can generate browser-specific output automatically, there are fewer such issues to deal with.
Note that you can use Selenium (aka WebDriver), to automatically test your code on multiple different browsers, even if you only actively develop within a single browser environment. That way, you can know if you've broken something, but not have to constantly manually test in multiple browsers.
I want to make a site from scratch, and Im considering to use Flex to make a R.I.A instead of the standard approach (xhtml + css + some ajax).
The kind of site I want to make is something like e-bay, but less complicated.
But.. I know that 95%+ of the sites like that are built in the previous mentioned techs... so, what are the cons and pros if I want to make a pure Flex site?
Thx.
If you write an entire website in Flash, the entire website lives at one URL. (Short of mucking around with whatever Flash provides to let you offer deeper links.)
Whereas a website written in HTML, unless you go mad with your AJAX, lets people link to the stuff they’re actually interested in, like unicorns:
http://cgi.ebay.co.uk/DESPICABLE-ME-AGNES-Unicorn-Doll-Plush-Character-Doll-/180602861597?pt=LH_DefaultDomain_0&hash=item2a0cc4f81d#ht_1755wt_907
Or for a non-eBay example, Stack Overflow questions:
Flash for business web applications - why not?
HTML also has a pretty standard and understood user interface: links, and form controls. (Mainly links.)
Flash doesn't work on iPhone/iPad. End of story.
Other reasons: not a web standard, often quite slow, not good for SEO, etc.
It requires users to have a proprietary plugin which some users don't want and other users can't have (since isn't available for all platforms (iOS being a key example)).
It also has performance and stability issues on some platforms (OS X and Linux being prime candidates).
While some search engines have started to index Flash content (so long as it exposes the information), the results aren't as good as for content rich HTML sites.
You can do that simply using traditional xhtml + css + jQuery (or any JS framework if you want to increase UX). Flex won't do much in your scenario.
In my experience, performance is not a real issue unless you play video - one can write bad programs in JavaScript, too...
Your pros are mostly on the development side: You can have a great looking site quickly, and you can almost completely forget about browser incompatibilites.
You rely on the customers having the plugin installed, though, and you rely on Adobe's technology for development and playing of the content.
If this is not important to you, and you can afford to do without all iPhone and iPad users, accessibility and standards compliance... go for it!
Flex is good if you want to install as an application using Air. ebay actually has a RIA version, or at least they did for a while.
There are several concerns with a Flash site, some of which Adobe has addressed in the last couple of years.
One is accessibility. It is more difficult to make a Flash site accessible to the visually impaired, who use screenreaders.
Related, people like to be able to copy and paste content, as well as print. With standard web pages, the developer need do nothing to support this, it just works from the browser. With Flash, you'll have to take care to make your text content selectable, and I'm not sure a user could ever select a section of text + images. I've never done it, but I can only imagine that implementing printing ability in your Flash site would be nightmarish, at best.
Another is linking and addressability. For most sites, you can copy or at least get a link that you can share or save to get back to where you want to be. With Flash, you usually go to a single address and then the rest of of your experience happens inside the Flash "window" and the browser isn't actually navigating any pages. It is far more difficult to implement this ability in a Flash site.
A Flash site is usually very slow to load, especially the first time, and page load times are immeasurably important to a site's success.
Finally, you've perhaps heard the furor over the last couple of years about different vendors supporting or not supporting Flash in their products/devices. An all-flash site would be completely inaccessible on any iPhone or iPad, for example, which do not support Flash at all. Furthermore, some employers do not allow plugins like Flash to be installed on work machines, so you'd eliminate that portion of possible traffic, as well.
Nobody has yet mentioned Silverlight.?
I mostly agree with Jay's answer concerning accessibility, but as a further note would like to add that development in Flex/Flash vs HTML/CSS/JS could be more costly not only in terms of money but also for maintenance. Many Flex/Flash devs typically charge a higher price and their dev tools, which are necessary for compilation, usually aren't free, compared to HTML/CSS/JS devs, who often use freely available text editors.
This question has a discussion of progressive enhancement. My question is about the alternative type of web application. If you have a web app in which the UI is constructed almost entirely in Javascript, won't gracefully degrade, has a desktop feel, etc., what is that kind of web application called?
Do you mean this type or the opposite of this type:
"Rich Internet Application" where you could have an application that runs on for example AIR.
to me, what you describe seems to be a JavaScript based fat client ... i see nothing wrong in that ...
the thing is, that everyone forgets is that HTML means hypertext markup language ... it is a format for describing documents and was never designed to capture the functionality that some HTML-based apps offer nowadays ...
the answer "RIA" seems the best to me ... of course that includes flash and silverlight ... but your choice of HTML+JS is completely arbitrary in this case, because you manipulate the HTML DocumentObjectModel with JavaScript as a flash developer would manipulate the flash DisplayObjectModel with ActionScript ...
there are simply web apps, that are document and form based ... they have a CRUD infrastructure for some type of data, that is accessed in a RESTful, or at least RESTish way ... this type of apps can employ progressive enhancement, using HTML to capture its semantics and plain HTTP for all client<->server communication... i'd tend to simply call this kind of web app a web site ... having a bit of funky AJAX won't change that really ... i mean, from a simple guest book, to a forum, to stackoverflow, the basic idea never changes ... and a guest book does not make a web application, does it?
there are web apps, where the state is fully maintained by a much richer client, because these apps do a lot of granular data manipulation, as opposed to the document based CRUD web apps, and to me, this is the type of web application actually deserving the name, but i'd call them RIAs, to emphasize the difference ... in some cases this solution is faster, more lightweight, scalable, usable, easier and faster to develop/maintain/extend, and simply more natural ... this choice is often based on the type of data they deal with, as well as the functionality exposed for manipulating that data ... for example, if you were to implement a game like tetris, progressive enhancement wouldn't be the way to go ... instead, in order to create such apps, willful misuse of HTML is required ... so what? :-D
so, yeah, RIA is the right word, i'd say ... and opposed to others, i think first of all, it is a great, easy and powerful way of deploying functionality ... i mean i get the whole "inaccessible" and "incrawlable" thing ... but the latter is often pointless, and the first one is a problem you can't address properly, unless for example screen readers read whatever is in the DOM, instead of spitting out the original page ... but that's the problem you face with "real", i.e. desktop like, apps ...
greetz
back2dos
Monolithic?
Well, really the opposite of "progressive enhancement" is "graceful degradation", even though they basically achieve the same thing.
Progressive enhancement means you start off with plain old HTML for older browsers, then enhance it in stages, with cross-browser CSS, additional CSS (e.g. CSS3 styles), Javascript and AJAX.
Graceful degradation means you rush headlong into creating a Rich Internet Experience, then tack on alternatives for people without Javascript/CSS.
Anyway to answer your question, I'd probably call it "ungraceful degradation". Alternatives:
Badly designed
Uncrawlable (from search engine perspective)
Inaccessible (credit: Chuck)
Inaccessible.
It just doesn't degrade well.
I'm not sure I'd categorise applications as progessively enhanced, because that inferrs that there is some sort of baseline. How far back should an app degrade before it's considered as 'progressively enhanced'?
At a push, I'd say the app is dependant on certain features of the browser - maybe it is 'edge dependant' or 'modern browser only'?
UI is constructed almost entirely in Javascript, won't gracefully degrade
Arrogant. Presumptive. Illegal (depending on specifics of application and jurisdiction).