Running a compiler in the browser in production will never be a good idea. If you care about the speed that your website displays -- and you should -- the slowdown caused by parsing, processing, and concatenating large amounts of CSS will dwarf over-the-wire time. People who seriously care about the usability of their sites have been spending a lot of effort recently figuring out how to get load times as fast as possible, and this is a leap in the wrong direction.
"Running a compiler in the browser in production will never be a good idea."
Well, it's way too late for that. You need to send that statement back to mid-1990s.
Or does your processor natively execute Javascript text?
That dogmatic declaration is nonsense. Compilers are just code. Certain programming language compilers are very slow due to the immense complexity of their task but there's nothing intrinsically slow about compilers/interpreters next to any number of other normal tasks. I've even sped code up by replacing large swathes of ad-hoc hard-coded crap code with a nice small interpreter that was small enough to be feasibly optimized, rather than the mass of code that was previously there that everybody was afraid to touch.
The really slow part would be the parsing, really, and if Less.js doesn't already have a "straight from JSON" mode, it would be easy enough to add one, then you could actually use the "native" Javascript parser and compiler.
You're right, that was too broad a statement. However, it is undeniable that in-browser compilation of CSS will always be slower than precompilation, as long as the compilation outputs CSS. For some people, this speed hit will never be negligible. But for those who don't need to squeeze every bit of performance out of their sites, it's sufficient that it only be an order of magnitude or two faster than the HTTP request.
However, that's not the case right now. Maybe in the future Javascript's string parsing will become dramatically faster, but in my benchmarks elsewhere on this thread, it's clear that for large files less.js is pretty slow relative to HTTP.
As for serving it up as JSON: no one wants to write stylesheets in JSON. The reason Less became popular as an alternative to Sass was that it had a CSS-like syntax.
"As for serving it up as JSON: no one wants to write stylesheets in JSON."
You don't have to. You can use a compiler to generate JSON to feed to the system, retaining the flexibility of having the compiler running but skipping the parsing step. Why not compile straight to CSS? Well, why not? For simple sites that may be just fine. For more complicated sites it might be desirable to screw with the CSS before compiling.
My real meta-point here is that compiling isn't that scary. The idea of load you may get from g++ or GHC is not generally applicable. And as JS gets closer and closer to C-speeds it'll matter even less. (Not saying it will reach them, but you don't have to.) And there are already quite a few compilers in the mix; every web language has one (JS, CSS, HTML, SVG) and adding another is not like an enormous scary step. I suppose this is another consequence of the continuing deplorable move away from having compilers be a required class for a degree; truly it is one of the most powerful techniques of computer science that is relatively difficult to fully encounter outside of a formal education. (Like everything else in programming, it isn't impossible, but as it is very easy to walk away with a degree without ever having encountered one, so much moreso it is easy to not encounter one in informal education too.)
I was assuming compiling to JSON wasn't an option since the point of the post was the usefulness of avoiding a manual compilation step. With such a step, yes, you could avoid all the parsing headaches. I'm not sure how useful it would be to manipulate the JSON client-side, but there are probably a few clever things one could come up with.
I'm certainly not afraid of compilers. I write Sass, so I'm pretty intimately familiar with what's going on. My point was not that compilers are inherently scary and/or slow (although I stand by my original point that if it's compiling to CSS it will always be at least somewhat slower). I was just making the claim that the current speed of less.js is too slow for practical production use.
When people talk about how Javascript is going to approach C-speeds, I have to wonder how much cross-browser development they have actually done. Recently at work, we found that while Chrome handled using the jQuery UI 'buttons()' to style all of the buttons one of our pages, it was taking IE8 a full 8 seconds. After removing it to improve page rendering times in IE8 even Chrome felt snappier.
It depends on the constraints. The C-like speeds for pure numerical computation are being obtained by a number of other JIT compilers too. As you get more complicated you tend to lose the advantages.
However, I would submit that string bashing also ought to be amenable to JIT optimization. What will kill you in the browsers is interacting with the DOM/browser itself, and that's not going to go away as that code is increasingly already as optimized as it's going to get. However, CSS already has that problem, so if you can dynamically snap some CSS together on the client side and then feed it to the usual CSS processes, it doesn't have to be a large loss.
I also expect the browers to continue to work towards support more of this stuff being done dynamically; if you can better hook into the page generation process, you can help the browser avoid extra stupid work, like starting to layout the page with the entirely wrong CSS. We're still a ways from this entire process being optimized; I feel we've finally left the stupid ages in the browser world, but we're still working.
Less.js will cache the CSS on modern browsers after the first load using HTML5 local storage, so subsequent loads aren't an issue. First load is also very fast and won't make a huge difference. Like you, I wouldn't normally recommend running the compiler live but the performance here is really impressive. Please don't assume how fast Less.js is before you try it.
The first load is the important thing: it's when people first see your website. I've done plenty of speed testing of less.js, and on large CSS files it's seriously slow. I'll post the exact numbers elsewhere in the thread.
The article makes it sound like the author expects in-browser processing to be the only way it'll be used:
"Less.js is a JavaScript implementation of LESS that’s run by your web browser. As any JavaScript, you include a link to the script in your HTML, and…that’s that. LESS is now going to process LESS code so instead of including a link to a CSS file, you’ll include a link directly to your LESS code. That’s right, no CSS pre-processing, LESS will handle it live."
No mention that that would be ineffective for a production site. In fact, he claims that live processing won't have noticeable lag, which is just false.
I demand a benchmark. Saying that something is just false without numbers to back it up is not something I have high trust in, and is the start of the gossip that causes internet wars.
Fair enough. I'm running less.js from the command line using node.js on my old-ish MacBook pro:
A trivial CSS file (foo {a: b}) takes about 0.11s. This is probably mostly time spent spawning Node and loading the JS.
The combined CSS for GitHub, about 160K, takes about 1.6s. This is already longer than most HTTP requests.
The doubled CSS for GitHub (the same CSS twice in a row), about 316K, takes about 4s. This is quite large, although there are few sites that have this much CSS.
I tried to run it against the minified CSS for caring.com, but after 2m it hadn't terminated so I gave up. It's likely that this is due to a bug in the implementation rather than slowness.
This is real CSS handwritten by real people. It's not compressed, it's just not in a fully-expanded style. If your parser is slow for reasonably formatted CSS, then your parser is slow. The best case can be as fast as you want, but real-world use is what matters.
For what it's worth, -O2 brings the compile time for github.css down to about 1.5s.
No it's not. Look at it: it's one-selector-per-line, which is a very common style for handwritten CSS. If it were compressed, it would have no line breaks.
It's impressive that your benchmark compiles that quickly. However, as I mentioned elsewhere, the real issue is how fast real-world code compiles. My benchmark uses real-world code, and it's slow.
As it's cached, it's only the first load that will have the lag. I'd guess it will be quite small as well. If the CSS makes heavy use of mixins and the nesting ability then the lag may even be smaller than the time to transfer the compiled CSS.
First load is where it counts! This is when users first see your site: their first impression. This is an important time that should be kept as fast as possible. Subsequent loads, for most sites, are likely not as important speed wise.
Remember, we have to design our sites as if the user is poised over the back button.
I can imagine a scenario where the bandwidth is so slow, and the client CPU is so fast, that theoretically sending a small file that is expanded into CSS would result in a faster page load. The use of JS Web Workers might further this.
In addition, with more mobile internet providers capping monthly usage, every byte counts.
I'm assuming that these CSS compilers generate larger output CSS files than their input.
This is a red herring. Any compiler that is implemented in JavaScript can be run both in the browser at run-time (very convenient for developers), or once at deploy-time using one of the many server-side JavaScript platforms (better performance for deployments).
In fact this is exactly what we do with Objective-J, and if Less.js doesn't already then I expect they will soon.
I agree. I'm objecting to the implicit suggestion in the article and more explicitly in comments here that this is in fact fast enough for production. Running it server-side is an excellent solution.
I agree with your last point, but things like extensive jQuery and TypeKit usage are demonstrating there's an appetite to do a lot of semi-essential rendering and event processing in JavaScript nowadays. I can't wait to see some benchmarks, but I can't imagine Less.js would affect page load times as severely as Typekit seems to sometimes.
The Sass compiler was (is?) more mature, and the language feels more consistent (see the '&' operator in Sass vs the :hover special case in Less). The editor/tool support was quite a bit better too.
Sass doesn't have a javascript in-browser implementation (afaik), but for rapid development it can watch a folder/file for changes and automatically recompile to static CSS files.
FYI, Less.js isn't just a javascript port. It adds new features, and the "&" selector is among them.
That said, I agree that SASS is more mature. I've used each on at least two projects now, and, with the release of SASS 3.0's and SCSS, I'm committing to SASS. This client-side parsing is a cool trick, but it's easy to do my CSS generation at the same time as my javascript minification. I just don't need it.
Interesting. I tried both and now use LESS with the More plugin in my rails app. I'm a huge fan of HAML, but I haven't fallen in love with SASS yet. The big upside to LESS is it still looks like CSS. Compass is interesting though, from the SASS side. http://github.com/chriseppstein/compass
The latest version of Sass (3.0) has CSS syntax:
The compiler supports both variants - the file extension (.scss vs .sass) denotes which you want to use.
Provided HN was meant to be a non-discriminatory democracy, but it to my knowledge was not. Any news site not systematically filtering content to suit a specific, targeted demographic will sooner or later inevitably converge against Digg (or die like the usenet).
I cranked out something similar to this years ago called in Lua and C called moonfall, actually more powerful because it was extendable, even got on smashing magazines "best of the month" or something like that, and I'm pretty sure it didn't obsolete CSS. Actually I don't think anybody used it, not even me. Maybe because Lua didn't have the buzz that javascript has now. http://moonfall.org/
Ideas like this could, eventually, actually obsolete CSS as we know it. All it would take is for subsequent revisions of the CSS standard to include support for some of these features, and for browsers to support more complicated CSS.
With Less, SASS and similar tools becoming more popular recently, I wouldn't be surprised to see Chrome or Firefox experimentally include their own implementations.
I hope they still maintain the ruby gem version of LESS.
LESS is beautiful as it is. But processing LESS code in the browser would mean that I can't use LESS.js for mobile web apps. Although there are mobile devices with 1ghz processors already out in the market, there is still a lag in rendering mediocre-weight pages that contain js on mobile devices.
I don't know. As a fan of CSS I don't really "get" Less.js ... Sure I understand the benefit of defining certain properties, but are the benefits good enough to warrant depending on an additional javascript library for something like this? What happens if people block javascript?
I don't know. It's not bad, but it's not for me. But going as fas as to say it will obsolete CSS, that's just too much.
> are the benefits good enough to warrant depending on an additional javascript library for something like this? What happens if people block javascript?
Nothing, in production you'd use the compiled ver. The article should make this clearer though.
That depends. The "new" version they talk about in the article does require Javascript, since it does on-the-fly compiling. For the current version you're right.
I understand the thing they just released allows on-the-fly compiling. I'm just suggesting is that since the existing options remain available, you can still use them.
I can see it being somewhat useful as a server-side technology or as an authoring tool that you can then "compile" to CSS. CSS is so straightforward and simple to use as-is, however, that I don't really think it needs something to make it even easier, although the support for variables is quite nice.
Having said that, I have the same problem with LESS.js that I have with various other JavaScript layout techniques - I simply don't like relying on JavaScript to control the look and feel of a web page. I think it's awkward, inefficient, and just asking for trouble. Mostly, I also think it's completely unnecessary.
CSS is far from easy to use correctly. CSS is very poorly designed. Aside from all the browser hacks it's core constructs often times contradict each other (think float vs position). We do need something better but I'm not sure if LESS is it. I would much rather see something built into browsers directly.
I hear this all the time and I really just don't see it. I'm not trying to be argumentative, I just don't understand. Yes, it is poorly designed, no question about that and there are certainly things that could be done better, and one shouldn't have to use all of the "hacks" to begin with. But I do find it incredibly easy to work with, and I'm often doing very complex layouts that have to work in everything from IE6 up. CSS is just a matter of memorization.
So I still don't think something like LESS or SASS is the answer. My point was CSS is, despite its poor design, fundamentally easy to understand in terms of how it's supposed to work. No, it doesn't always work like it's supposed to and sometimes you have to work around that, but at its core, the syntax, the structure, and methodology behind it are dead simple. Building something like LESS/SASS to run on top of/underneath CSS to then generate said CSS markup seems redundant, when instead what needs to happen is that the focus needs to be on fixing the flaws of CSS, not adding another layer of abstraction.
And how does LESS/SASS handle all of those hacks? You still have to do them. You just write them a bit differently. So really, besides variables, what added value does it provide?
The value it provides is it simplifies CSS, helping maintainability and preventing repetition. It's not a replacement for CSS, it's just a way to make dealing with CSS easier. The syntax is easier and since it's a superset of CSS, you can keep on using plain old CSS syntax if you want. It adds more options and more flexibility.
Variables alone make LESS/SASS worthwhile, but even putting those aside, let me give you an example of added value: importing other files. With LESS/SASS you can import different files, and they get compiled into one CSS file. With CSS if you use @import, you've got an additional HTTP request, which negatively impacts performance. LESS/SASS gives you additional flexibility in organizing your CSS. In LESS/SASS you can just go to the individual file that deals with typography, as opposed to the tricks designers have used to find things in a large CSS file (e.g. putting a table of contents at the top of the CSS in comments, with a unique string for each section, which you then use Ctrl-F to look for to find the section of rules you're interested in.)
I'd recommend trying it out on a small project if you haven't already, to see for yourself.
I've tried css-dryer, which is similar in concept to server side LESS and SASS. I found it to be problematic on a large project because even though the CSS was compact in its source form, what actually got compiled ended up getting huge. It was slow to download and inefficient for the browser to process. The brevity of the source language ended up being an invitation to use CSS in a style was extremely verbose upon compilation. It also added operational complexity to have to deal with compiling the css. For example we wanted to use CSS in some of our javascript tests and then we had to deal with running the dryer from the test server. We eventually ripped it out at fairly great cost and went back to vanilla css, where it was clear to everyone what everything meant and we didn't have to worry about a huge inflation of the code. Maybe there's something smarter about these frameworks that avoids these issues?
Sensationalist headline but I can't wait to try this. When you start representing everything as JSON trees, web programming gets so much more consistent, compact, and easier.
Also see:
MongoDB - save data in BSON (binary JSON) And query with JSON
Node.js - Build an entire smoking fast server side web app with JavaScript objects. Bonus: run a node app on Heroku to compile and varnish cash less.js if you are worried about performance
Mustache.js or Pure - JavaScript templating to turn JSON into HTML
V8, tracemonkey, Nitro - blazing fast JS interpreters everywhere that will .eval JSON
Nonsense about obsoleting CSS aside, I've downloaded this Javascript version and I've been using it as a standalone program with Node. The command-line tool is a lot less mature than the Ruby version, but it's so much faster. The Ruby one was really painfully slow. It was really frustrating to have to wait a whole five seconds for it to regenerate your CSS files every time you make a small little change. This one will regenerate your CSS in comfortably less than a second. It's much better.
One thing puzzles me: If LESS is essentially a template language specialized for CSS, why not reuse the template engine that you use in your application anyway?
That way, you'd also have the benefit of defining often-used attribute values (e.g. colors) in a variable, and you could also group often-used combinations of attributes together in a variable or sub template.
I wonder why there is no general "template" language that you can use on any text/source file. For example, I'm writing a lot of AutoHotKey code lately, and I find myself wishing I had some of the expressive power of Python so I wouldn't have to repeat things.
I'm seriously considering writing a Python-based "Preprocessor" language which lets me drop in Python code on any file, and deals with transforming it into the final "compiled" file.
BTW, I personally use the XSLT template language. It is language independent, but still extendable with user-defined functions written in the programming language of your application. Note that despite its name, XSLT does not only provide for XML output, but handles text output and HTML as well. In Python, you can find a excellent XSLT processor in the 4suite package:
By the way, I really think that to work (i.e. become usable, maybe even popular), this needs to be built on an existing and popular language. Otherwise it's too steep a learning curve.
Ideally, I'd like to be able to put in code in the text file wherever I want, be able to put the value of expressions in the code, and that's it.
I also have issues with the "box model." Judging by the popularity of grid layout systems like blueprint and 960 I think others also do.
The box model is fine when you just need to "flow" things around things, like text around images, and typical blog designs, but when you develop complicated interfaces it really shows its limitations and costs many hours of frustrating effort.
The CSS3 UI module is a candidate recommendation. Setting:
box-sizing: border-box;
essentially puts the CSS box model render mode to where it was in IE5 (which is, frankly, the only sensible way to do it). Right now, it is available with Mozilla, Webkit and Microsoft prefixes (as are most of the UI module properties).
In each case, this is partly due to limitations in the underlying model, but also partly due to having limited syntax.
In each case CSS3 modules may improve things somewhat if and when they are widely supported, but even the best proposals there aren't even close to the power of a good DTP tool or the control of a native application. When the web is trying to take over from both, CSS isn't a good tool, it's just the best we've got right now.
There are plenty of problems with CSS. You can't specify the width of an inline element, for one. That alone prevents a lot of reasonable layouts, like tables. Also problematic is a standards body that ignores this use case! In this case, they protect the writer from over-filling some boxes with more boxes. But that would at least be visible - in this case, the workarounds end up far worse.
I run into plenty of situations where I have multiple lines, and I'd like the respective elements to align. It's not limited to tabular data, but it's the easiest example
That was primarily in the context of "Also problematic is a standards body that ignores this use case!" part of your comment.
Besides if you don't care about antiquated browsers (eg IE6), the inline-block is a viable option. In IE it will require some massaging, but it can be made to work quite easily.
The lack of a proper layout system causes a huge number of problems, and is the reason the "tables vs. css" argument can still occasionally pop up. The nuts box model has already been mentioned.
I agree for the most part, but as the "only" problem, it's a seriously gigantic one. CSS is cool but this limitation is so frustrating, especially once your style sheets start getting really big.
Users running noscript are typically prepared for any site to look broken or not work as expected. They also comprise a tiny majority of visitors, so for all practical intents and purposes accommodating their case is not really a development priority.
I understand your point of view. But you will agree that a CSS preprocessor in Javascript is a problem:
(1) It's useless. Just pre-process the style sheets statically. No need for PHP, Ruby or any server side dynamic scripting whatsoever. It's simpler, and yields less requirements for everyone.
(2) It exclude users. Not only the paranoid ones that run noscript and adBlock, but also the ones that just don't have Javascript like Dillo users. (Dillo is interesting for old, weak computers.) That's still a tiny minority, but they do exist.
Something useless that exclude users clearly isn't the best tool for the job. Unless punishing noscript users is a feature… Now, of course javascript is more capable than (pre-processed) CSS alone. But the article didn't seem to use those capabilities.
Is this really solving a problem? I mean CSS itself has issues but wrapping a developer centric toolkit around it doesn't seem to help. In my view CSS is a necessary evil but it is also primarily used by designers. Forcing them to use variables and learn classes and adhere to another syntax would seem counter productive to most of the gains.
Does the preprocessor generate raw (i.e. conventional) CSS, which it then convinces the browser to evaluate or re-evaluate as necessary, or does it actually apply the styles itself with JS? i.e. something equivalent to jQuery('.heading').css("color", "red").
Admitedly, I'm a relative n00b when it comes to development but seriously "I do not get it". There doesn't appear to be much in the way of reduced syntax, at least not in the example provided. Can someone explain why this is better or clearer than CSS?
There is genuinely a tiny benefit because you don't need to declare colors etc more than once, everything else about it is trying to wedge ideas from other areas of programming into a language that contains so many abstract concepts as to not benefit from it at all.
I've worked as a UI developer for 12 years now and I wouldn't go near something like this because there is no value. At least the server side version you can pre-process and package up for live after your developers have saved literally minutes by using it. You need to know CSS inside out, so you have to then unlearn and relearn different parts just to do something you can already do with find + replace.
And worse, you are even including and downloading files that the browser cannot even interpret itself without relying on another download of JavaScript as well, so you're giving something that works 100% of the time (assuming someone has CSS on) another point of failure. Most of my time in UI has been in public sector education trying to push standards and quality from various suppliers to the Govt and seeing things like this from said suppliers (I've seen worse to be fair, but I've seen something like this before) is always an unpleasant experience.
Let me give an example use case, something I've wanted.
Lots of developers will tell you that it's fine to use systems like the 960 Grid System for rapid prototyping, but you shouldn't use them for final, "production" sites. Their argument is that "littering" your code with classes like "grid_4", etc. is not semantic (and they're right).
So here's what I would love to do: use a system like 960 in development, but instead of using names like "grid_4", use actual, semantic names. But behind the scenes, I'll use less to "inherit" the grid_4 properties into the semantic name.
E.g., assuming I have: "<div class="grid_4 article_header>", I'll remove grid_4, but use less to make "article_header" inherit grid_4's properties. That way my html remains semantic, but I get the full power of systems like 960.gs.
I'll give another example with mixins: clearfix. I've seen webpages littered with class="clearfix" all over the HTML. That doesn't do anybody any good. With a CSS preprocessor you can define a clearfix mixin and just write it something like:
.class-name
.clearfix
font-size: 1.2em
There are other ways to do it like one long string of selectors followed by the clearfix code, but they're not as convenient or readable.
LESS or Sass are great in specific use cases. They're especially useful when you're using a lot of CSS visuals (where you have to write out about 3-5 lines just for one property because each browser has it's own version, i.e. -moz-, -webkit-, etc). With LESS you can create a mixin that does this thing (e.g. rounded corners) that also takes an argument and just call it in all the places where you need rounded corners. Sometimes you want to re-use the same color over in many different places. If you change your mind, you have to go back and change it everywhere, making sure you don't miss a spot. Nesting makes the code much more organized (you have to try it to see) since you can see which bit of code relates to which area of the page. It's just neater and easier to view. Each of these benefits on its own isn't very big, but when you start saving time here and there they do add up, especially on large stylesheets.
Basically, it's not really about reducing syntax or size of the file (which does get smaller for large stylesheets), it's all about making the stylesheet easier to build and maintain.
There aren't many features, but they fill in various "holes" in CSS (compared to every other programming language).
For one example, you can define "constants". That means you can define a color once with a name (say, LINK_COLOR = #aaa), then use that name over and over. Then, if you ever feel like changing that color, you only have to change it once (where it says LINK_COLOR = ), not every time.
Other benefits are something akin to "functions", and ways of "nesting" your CSS which automatically makes certain classes only apply to nested elements (this is something most people do anyway, they just do it by hand).
It might not seem all that great from the simple example provided, but Compass (http://compass-style.org/, uses SASS) is a great example of how mixins can make your life so much easier.
For example, if you want to make an inline list it's as easy as:
CSS has very flexible selectors, so in a sense it already has some abstraction features. Those differ from what we know from other languages, but they are still very useful and should be exploited.
I was never forced to define important colors more than twice in my CSS style sheets, usually defining them just once. Maybe my document structures are too simple to get into trouble - but maybe that's the whole trick.
(i.e. producing less bloat rather than making bloat more manageable.)
I wasn't arguing that CSS does not stand on its own two feet, or that LESS is necessary. Rather, I was just objecting to the view that one should just improve one's text editing skills instead of learning to use some kind of abstraction.
Complexity is not all bloat. For a given set of data with a given list of goals, there's an optimal level of complexity. More than this and it's bloat — but less than this and you're not accomplishing what you set out to do.
There's still a maximum level of complexity for presentations (here: HTML presentation of a set of data). That level is independent of the content. Anything above that is just irritating for the viewing persons.
This is especially true for web sites which should at least look as simple as possible. So in principle, there should be always a way to produce HTML whose DOM structure isn't too complicated, no matter what the content is.
You can still browse without Javascript. This won't hide any content — you just won't have Javascript gussying up the presentation for you. Which is already the case on a lot of sites that don't use it as a CSS replacement. That is basically your choice if you choose to roll without Javascript.
Obsolete is a verb, but it is a poor choice. A better choice would be obsolesce, as in: "LESS.js will obsolesce CSS". This is because LESS.js won't obsolete CSS, but it may well start the industry on the path. Obsolete has a feeling of immediacy to it, and obsolesce has a feeling of lethargy or a gradual process which is why it's the better choice.
It's an opinion, take it with a grain of salt.
(BTW, I dislike MW because it takes all nuance out of the language and dumbs it down to an inexpressive mess.)
Obsolete is a verb, but it is a poor choice. A better
choice would be obsolesce, as in: "LESS.js will
obsolesce CSS"
"Obsolete" is the correct word because it's a transitive verb (eg, [subject] obsoletes [object]), while obsolesce is an intransitive verb (eg, [subject] obsolesces).
"Mr. Wolfe is in the middle of a fit. It's complicated. There's a fireplace in the front room, but it's never lit because he hates open fires. He says they stultify mental processes. But it's lit now because he's using it. He's seated in front of it, on a chair too small for him, tearing sheets out of a book and burning them. The book is the new edition, the third edition, of Webster's New International Dictionary, Unabridged, published by the G. & C. Merriam Company of Springfield, Massachusetts. He considers it subversive because it threatens the integrity of the English language. In the past week he has given me a thousand examples of its crimes. He says it is a deliberate attempt to murder the — I beg your pardon. I describe the situation at length because he told me to bring you in there, and it will be bad."
MW adds practically any word that someone uses, ever. And Wiktionary? Come on.
If you take a gander at WordNet or even OneLook (searches multiple dictionaries), you'll find that the majority list obsolete only as an adjective, including Webster's 1828.
However, I concur that obsolesce would have been a better choice.
Dictionaries are historians of usage, not legislators of language. If the communication is clear, which in this case I think it is, then I don't see a problem.
