On this page

  1. …in which I complain about Elixir syntax
  2. Erlang is dead. Long live E…?
  3. Javascript: Fatigue vs. Stockholm syndrome
  4. Designing for <anything> with Erlang
  5. Putin: 2×2
  6. A case for QuickCheck for Elixir?
  7. Ok, W3C and WHATWG, don’t die, but…
  8. W3C and WHATWG should die a quick and horrible death

…in which I complain about Elixir syntax

Apr 01 2016 12:00
published in:
elixir

Originally posted on Medium

I kinda like Elixir. I even think that Elixir is a huge leap towards the future and all the right things that should be happening in the Erlang world (see related post here). I still get irritated by it :)

What follows is a highly opinionated … erm … opinion. I am right and you are wrong ;)

It’s not the syntax that’s important, it’s the consistency

I will be hanged out to dry for this, then brought in and hanged dry again. But here goes.

Let’s start with Erlang. Erlang has one of the most concise and consistent syntaxes in programming languages.

Erlang syntax primer

1: A sequence of expressions is separated by commas:

Var = fun_call(),
Var2 = fun_call2(), Var3 = fun_call3(Param1, Param2)

2: A pattern match after which we return a value is followed by an arrow. From a programmer’s point of view, there’s no difference if this is a pattern match introduced by the function declaration or by a case, receive or if

function_declaration(Param1, Param2) -> 
  Var = fun_call(),
  Var2 = fun_call2(), Var3 = fun_call3(Param1, Param2),
 
  receive
     {some, pattern} ->
         do_one(),
         do_three(),
         do_four() %% the value of this call will be returned
  end.

3: Choices are spearated by semicolons. Once again, there’s no real difference (at least to the programmer) between choices in function heads (we choose between different patterns) and choices in case, if or receive:

function1({a, b}) ->
  do_a_b();
function1({c, D}) ->
  case D of
    {d, e} -> do_c_d_e();
    {f, g} -> do_c_f_g()
  end.

4: There are also blocks, and a block is terminated by an end (there’s a bit of inconsistency in blocks themselves: begin...end, case of...end, try...catch...end, if...end). E.g.:

function() ->
  begin
    case X of
      b -> 
         if true -> ok end
    end
  end.

What of Elixir?

And here’s my problem with Elixir: You have to be always be aware of things and of what goes where when.

do..end vs ->

def f(a, b) do
  case a do
    {:c, :d} ->
      do_a_b_c_d()
    {:e, :f} ->
      receive do
        {:x} -> do_smth()
        {:y} -> something_else()
      end
  end
end

What? Why is there suddenly an arrow? In a language where (almost) everything is a do...end the arrow is jarringly out of place. For the longest time ever I honestly thought that the only thing separating pattern matches in a case statement is identation. Which would be weird in a language where whitespace is insignificant.

There’s an argument that these are individual patterns within a do...end block separated by newlines and denoted by arrows (see here). cond, case and receive all use that. The argument is moot, however.

Here’s how you define an anonymous function in Elixir:

a_fun = fn x -> x end

This is an even weirder construct. It’s not a do...end. But it has an arrow and an end. Moreover, regular functions are also individual patterns within a do...end block:

defmodule M do
  def x(:x), do: :x end
  def x(:y), do: :y end
end

And here’s how you define similar constructs with arrows:

a_fun = fn :x -> :x
           :y -> :y
        end

result = case some_var do
           :x -> :x
           :z -> :z
         end

If arrow is just a syntactic sugar for do...end, why can’t it be used in other places? If it’s used for sequences of patterns, why can’t it be used for function declarations?

There’s definitely an argument for readability. Compare:

## arrows
case some_var do
  :x -> :x
  :z -> 
    some
    multiline
    statement
    :z
end

## do..end as everywhere
case some_var do
  :x, do: :x
  :z do
    some
    multiline
    statement
    :z
  end
end

But then… Why not use the more readable arrows in other places as well? ;)

## regular do..end
defmodule M do
  def x(:x), do: :x end
  def x(:y) do
    some
    multiline
    statement
    :z
  end
end

## arrows
defmodule M do
  def x(:x) -> :x
  def x(:y) ->
    some
    multiline
    statement
    :z
  end

So, in my opinion, arrows is a very weird incosistent hardcoded syntactic sugar. And it irritates me :)

Moving on

Parentheses are optional. Except they aren’t

One of the arguably useful features of Elixir is that function calls do not require parantheses:

> String.upcase(“a”)
“A”
> String.upcase “a”
“A”

Except that if you want to keep your sanity instead of juggling things in your mind, you’d better off using the parentheses anyway.

First, consider Elixir’s amazing pipe operator:

## instead of writing this
Enum.map(List.flatten([1, [2], 3]), fn x -> x * 2 end)

## you can write this
[1, [2], 3] |> List.flatten |> Enum.map(fn x -> x * 2 end)

Whatever is on the left side of the pipe will be passed as the first argument to the whatever’s on the right. Then the result of that will be passed as the first argument to the next thing. And so on.

However. Notice the example above, taken straight from the docs. List.flatten, a function, is written without parentheses. Enum.map, also a function, requires parentheses. And here’s why:

> [1, [2], 3] |> List.flatten |> Enum.map fn x -> x * 2 end
iex:14: warning: you are piping into a function call without parentheses, which may be ambiguous. Please wrap the function you are piping into in parentheses. For example:foo 1 |> bar 2 |> baz 3Should be written as:foo(1) |> bar(2) |> baz(3)

This is just a warning, and things can get ambiguous. That’s why you’d better always use parentheses with pipes. It gets worse though.

Remember anonymous functions we talked about earlier? Well. Let me show an example.

Here’s how a function named flatten declared in module List behaves:

> List.flatten([1, [2], 3])
[1, 2, 3]
> List.flatten([1, [2], 3])
[1, 2, 3]
> [1, [2], 3] |> List.flatten
[1, 2, 3]

Here’s how an anonymous function behaves:

> a_fun = fn x -> List.flatten x end
#Function<6.54118792/1 in :erl_eval.expr/5>> a_fun([1, [2], 3])
** (CompileError) iex:17: undefined function a_fun/1> a_fun [1, [2], 3]
** (CompileError) iex:17: undefined function a_fun/1iex(17)> [1, [2], 3] |> a_fun
** (CompileError) iex:17: undefined function a_fun/1
 (elixir) expanding macro: Kernel.|>/2
 iex:17: (file)

Wait. What?!

Oh. Right. Anonymous functions, what a nice joke. Let’s all have a good laugh. An anonymous function must always be called with .()

> a_fun.([1, [2], 3])
[1, 2, 3]
> [1, [2], 3] |> a_fun.()
[1, 2, 3]

Because parentheses are optional, right. And functions are first class citizens, and there’s no difference if it’s a function or a variable holding a function, right? (In the example below &List.flatten/1 is equivalent to Erlang’s fun lists:flatten/1. It’s called a capture operator.)

> a_fun = List.flatten
** (UndefinedFunctionError) undefined function List.flatten/0
 (elixir) List.flatten()> a_fun = &List.flatten
** (CompileError) iex:19: invalid args for &, expected an expression in the format of &Mod.fun/arity, &local/arity or a capture containing at least one argument as &1, got: List.flatten()> a_fun = &List.flatten/1
&List.flatten/1> a_fun([1, [2], 3])
** (CompileError) iex:21: undefined function a_fun/1> a_fun.([1, [2], 3])
[1, 2, 3]

Yup. Because parentheses are optional.

If you think it’s not a big problem, and that anonymous or “captured” functions are not that common… They may not be common, but they are still used. An empty project using Phoenix:

Every time you use a “captured” or an anonymous functions, you need to keep the utterly entirely useless information: they are invoked differently than the rest of the functions, they require parentheses etc. etc.

> 1 |> &(&1 * 2).()
** (ArgumentError) cannot pipe 1 into &(&1 * 2.()), can only pipe into local calls foo(), remote calls Foo.bar() or anonymous functions calls foo.()> 1 |> (&(&1 * 2)).()
2

Local. Remote. Anonymous. Riiiight

Compare with Erlang:

1> lists:flatten([1, [2], 3]).
[1,2,3]2> F = fun lists:flatten/1.
#Fun<lists.flatten.1>
3> F([1, [2], 3]).
[1,2,3]

Before we move on. Calls without parentheses lead to the unfortunate situation when you have no idea what you’re doing: assigning a variable value or the result of a function call.

some_var = x  ## is it x or x(). Let's hope the IDE tells you

And yes, this also happens.

do..end vs ,do:

This has been explained to me here. I will still mention it, because it’s annoying the hell out of me and is definitely confusing to beginners. Basically, it’s one more thing to keep track of:

def oneliner(params), do: resultdef multiliner(params) do one two result end

Yup. A comma and a colon in one case. No comma and no colon in the second case. Because syntactic sugar and reasons.

Erlang is dead. Long live E…?

Feb 19 2016 12:00
published in:
erlang

Originally posted on Medium

Disclaimer: I love Erlang. From 2005 to 2015 I ran erlanger.ru (mostly alone, as editor-in-chief, content creator, developer — you name it). It is my favourite language, and this isn’t going to change any time soon. Exactly because I love it, I see problems with it.

Problem statement

Other languages are getting better at being Erlang than Erlang is getting better at being other languages.

Ericsson’s Baby

Erlang is first and foremost Ericsson’s baby. Thus, enterprise and telecom are the two things that influence Erlang the most. It is Erlang’s greatest strength and it’s greatest weakness.

Enterprise side of things made sure that Erlang has got to be one of the most stable languages out there:

Telecom side of things made sure that Erlang is also probably the language that got more things right from the start (or nearly from the start) than any other language:

The problem, however, this no longer matters.

A Brief, Incomplete, and Mostly Wrong History of Erlang

Java is the new Erlang

This may be hard to swallow, but Java is the new Erlang. And other languages either piggyback Java, or are fast developing to provide competition in many areas.

Let’s look at the most common tools that everyone uses or knows about in areas where Erlang is supposed to shine: Hadoop, Kafka, Mesos, ChaosMonkey, ElasticSearch, CloudStack, HBase, <insert your project>.

For every single of your distributed needs you will take Java. Not Erlang.

In other rapidly developing fields such as IoT, there’s Java again, C/C++, Python. Rarely, if ever, Erlang.

And the trend will only continue. Server management and monitoring tools, messaging and distribution, parallel computing—you name it—sees an explosion of tools, frameworks and libraries in most languages. All of them encroaching on space originally thought to be reserved for Erlang.

Erlang Is the New … Nothing, Really

While others are encroaching on it’s territory, Erlang has really nothing to fight back with.

Even today Erlang is a very bare-bones language. An assembly, if you will, for writing distributed services. Even if you include OTP and third-party libraries. And, as a developer, you have to write those services from scratch yourself. Not that it’s a bad thing, oh no. But in a “move fast and break things” scenario having to write lots of things from scratch may break you, and not others.

Erlang is a language for mad scientists to write crazy stuff for other mad scientists to use or to be amazed at (see my lightning talk from 2012)

Anything else? Well,

This leaves Erlang… well, in limbo.

Is There Hope Yet?

I really really don’t know. I really hope though.

Due to its heritage Erlang will evolve slowly. It’s a given, and it’s no fault of the brilliant people who develop Erlang.

Other languages for the Erlang VM? Maybe. As we have seen with Elixir, in three years it’s got more development (both in the language itself and in the available libraries) than Erlang got in 10 years. We can only hope the drive will not subside. Will there be a “Hadoop.ex” to rival the Java Hadoop? I don’t know.

Incidentally, a lot of the praise that now comes towards Elixir mentions Erlang only in passing. As in “compiles to Erlang” or “runs on Erlang VM”. And may be this is exactly what Erlang needs: become for (Elixir|LFE|Efene|…) what JVM became for (Scala|Clojure|Groovy|…)?

Erlang is far from dead. It’s alive and kicking (some butt, if need be). Will it do that for long? In a “let’s choose between languages A, B, and Erlang for scenario X” will there remain a scenario X where Erlang will remain relevant and/or a valid choice?

I don’t know. I sure as hell hope.

I’m trying to do some good myself. I’m not bright enough to create something like the libraries mentioned here, but there’s neo4j-erlang and pegjs for what it’s worth.

Javascript: Fatigue vs. Stockholm syndrome

Feb 15 2016 12:00
published in:
javascriptrantsweb

Originally posted on Medium

Programmers are the worst. They will vehemently defend the tool of their choice even though it’s the worst tool in the universe. See any vs in the programming community. Tabs vs. spaces. Emacs vs. vim. C++ vs. PHP. You name it.

tl;dr: Javascript fatigue is real. If you deny it, you have a case of Stockholm syndrome. The problem isn’t new, see these two excelent blog posts: http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/ and http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ for a calmer discussion.

A little true story

All joking aside, I think that Javascript programmers are even worse than the worst. Here’s a little true story that happened to me three weeks ago.

We have a project which started way before Webpack was in any useable shape or form. So, it uses Grunt. It’s all been fine, and Grunt has been chugging along quite happily (chugging, because, well, you need to concat all/some/some magic number of files before it can figure out what to do with them. Yes, concat. Sigh). Until we imported a small three-file component which was written in — wait for it — ES6.

ES6 is the next version of Javascript (erm, ECMAScript) which is supported in exactly zero browsers, and exactly zero versions of any of the Javascript virtual machines. Through the magic of transpilers it can be converted to a supported version of Javascript. Therefore half of the internet publishes their code in ES6 now.

Oh my. I know what we need! We need Babel! The best tool to convert pesky ES6 into shiny ESwhatever-the-version (I’m told it’s 5).

Install Babel. Run.

>> ParseError: ‘import’ and ‘export’ may appear only with ‘sourceType: module’
Warning: Error running grunt-browserify. Use — force to continue.

Ok. Bear with me. Babel, whose job 99% of the time consists of transforming ES6 code into ES5 code no longer does this out of the box. I have no idea if it does anything out of the box anymore.

But it comes with nice presets! One of them does the job! It’s even called, erm, es-2015. Whatever. Specify it in options, run grunt be happy.

>> ParseError: ‘import’ and ‘export’ may appear only with ‘sourceType: module’
Warning: Error running grunt-browserify. Use — force to continue.

Ok. Bear with me. A preset is an umbrella name that specifies a list of plugins Babel will apply to code. If these plugins are not present, Babel will fail silently.

Oh, it doesn’t fail in your particular setup? Oh, how so very nice to be you. The problem is: there is exactly zero info on which of the moving parts of the entire system silently swallows the error.

Let’s step back for a second, and consider:

All in all the whole toolchain to produce a Javascript file is grunt -> grunt-browserify -> browserify -> babelify -> babel. And someone in that chain decides that babel missing all of its specified plugins is not a reason to throw an error, stop and report.

Unwind. Relax. Breathe. Solve differential equations in your head. Install whatever’s needed for babel. Run grunt.

>> ParseError: ‘import’ and ‘export’ may appear only with ‘sourceType: module’
Warning: Error running grunt-browserify. Use — force to continue.

Oh, Jesus Christ on a pony! What now? Ok. I’m a smart developer. I can figure this out. I mean, if I cannot debug my own toolchain, what good am I?

So, grunt has a -d option which means debug. Awesome.

Ok. Bear with me. The debug option passed to grunt does not propagate through the mess of twig and sticks called a toolchain. Grunt does not pass the debug option to grunt-browserify does not pass the debug option to browserify does not pass the debug option to babelify does not pass the debug option to babel.

You have to provide separate debug options to every piece of the toolschain and pray to god that this piece provides such an option and does not ignore it.

Let’s add debug: true to babelify.

>> ParseError: ‘import’ and ‘export’ may appear only with ‘sourceType: module’
Warning: Error running grunt-browserify. Use — force to continue.

Exactly. Was the debug: true option ignored? Or is this all the debug info I can get? I have no idea.

Ok. Bear with me. Grunt has a specific list of files and components it needs to process. I can only assume that the broken ladder of crap called the toolchain gets this list from Grunt with instructions: “These are the files. Process them.”

Despite all that, Babel by default does not process files from node_modules. Even when invoked from grunt-whatever-theplugin-is-i-dont-care will not process them, and will silently skip them. You have to explicitly provide a separate global: true option to all places in grunt->grunt-broswerify->babelify config where you think that code from node_modules may be imported/invoked/whatever.

No, it’s Stockholm syndrome

I’ve been told that this article is a valid argument against “Javascript fatigue”.

It’s not. It’s Stockholm syndrome.

Nothing can excuse the terrible horrible mess that the state of Javascript development is in right now. Step back, and look at your tools. Really look at them. There is a reason we have a million “webpack starter packs”. Because nothing works unless you invoke a number of semi-arcane incantations with increasingly inane combinations and versions of options.

loaders:[{
   test: /(\.css)/,
   loader: "css-loader?module&localIdentName=[path][name] — -[local] — -[hash:base64:5]"
}]

Really?!

I will not even go into how half of these tools don’t support recursing directories or globs. Or how another half of them doesn’t support monitoring the file system and recompiling stuff on the fly (what? recompiling on the fly with dependency tracking wat?).

Why are you supporting this?

I’m not lazy. I don’t not want to learn

It’s been said that “Javascript fatigue” appears because developers are lazy.

It’s been said that “Javascript fatigue” is because developers don’t want to learn anything new.

These arguments are null and void. If you read the first part of the story, you’ve seen that:

The time I spent trying to figure out the exact motions of all the moving parts I could spend on learning something genuinely new.

Instead, I now have a build toolchain that I have exactly zero confidence in (because it will break unexpectedly at the very next update of any of the fourteen hundred moving parts in it).

And yes, I will be removing some of those moving parts. It doesn’t mean that I will enjoy it or learn anything remotely useful from it.

(imgur style): send me your **-starter-packs :)

Designing for <anything> with Erlang

Feb 05 2016 12:00
published in:
erlang

Originally posted on Medium

No, this is not really a post about the upcoming Designing for Scalability with Erlang/OTP. Erlang is nearly unique among other programming languages in that almost all of the books on it are in the good to great range. This book is going to be no exception.

No, this is not about Erlang per se, as other languages have the same problem. But Erlang is a poster child for “scalable distributed 99.999999% cloud developer-to-user ratio <insert the next current rave here>”.

Recently I twitted:

Every single book on #Erlang spends 99% of text on reiterating the same basic principles. Most of them are worse than LYSE

Where LYSE is, of course the excellent Learn You Some Erlang For Great Good.

This is a bit harsh. May be not 99%. And not necessarily worse. So, what do I complain about? Most books mostly concern themselves with “draw some circles”. Reality is quite often “draw the rest of the owl”. There is almost no info on the intermediate steps in between.

Scalability is the capability of a system, network, or process to handle a growing amount of work, or its potential to be enlarged in order to accommodate that growth.

To scale horizontally (or scale out) means to add more nodes to a system, such as adding a new computer to a distributed software application.

To scale vertically (or scale up) means to add resources to a single node in a system, typically involving the addition of CPUs or memory to a single computer.

So, in the case of Erlang, which is described as, praised for being, marketed as being scalable, distributed, durable, resilient etc. etc. it would be really nice to read up on at least some of these things:

Funnily enough, in an out-of-the-box Erlang:

Unfortunately, most existing books emphasize beyond measure only one single aspect of Erlang: OTP. Even though OTP is no doubt essential to creating robust scalable distributed applications, people looking for the answers to questions above already grok OTP :) They already know how to draw the circles.

If you’re looking for answers, though, the landscape in Erlang books is quite bleak.

Among the commercially available it looks like only “Mastering Erlang: Writing Real World Applications“ doesn’t fall into the trap of spending all of it’s chapters on OTP with only one or two chapters dedicated to something else. (Update: I’m not even sure this book exists. It looks like it’s been “Coming soon” since 2010. Except perhaps here)

The other notable exception is the excellent “Erlang in Anger” which answers quite a lot of the questions above.

We’re quite ready to move beyond drawing circles. Some of us are not yet ready to draw the entire owl ;) Hjälp!

Putin: 2×2

Sep 29 2015 09:37
published in:
jokestranslations

Originally published as a gist

Translation of a Russian joke about Putin's answers in his yearly press-conferences.

Q: Vladimir Vladimirovich, what is two times two?

A: I'll be brief. You know, just the other day I was at the Russian Academy of Sciences and had a discussion with many scientists there, including young scientists, all of them very bright, by the way. As it happens, we touched upon the present problem, discussed the current state of the country's economy; they also descibed their plans for the future. Of course, the number one priority for them is the problem of relevancy; also, just as important is the question of housing loans, but I can assure you that all these problems can be solved and we will direct all our efforts to their resolution in the nearest future. Among other things this also applies to the subject you raised in your question.

A case for QuickCheck for Elixir?

Apr 24 2015 12:00
published in:
elixir

Originally published on Medium

Recently I got into a shouting match about QuickCheck implementation for Elixir.

My original reaction:

Why? Quckcheck is for companies only. Elixir is used by zero companies (except maybe 2 startups)

My highly non-scientific view of Erlang/Elixir world is something like this (don’t get offended by circle sizes, I’m bad at Venn diagrams):

If there is a company that sponsored the development of QuickCheck for Elixir, it’s great (both for the company and Quviq). However, it offers almost zero value to the rest of us for obvious reasons:

So that’s the main problem I have with this announcement and presentation: you’ve whetted our appetites. Now what?

What I would really love to see instead is just a clear licensing mechanism. Let’s say something like this:

Then the “Testing concurrency with Elixir” presentations will be “oh, cool, I can use it” instead of “meh, I can’t use it, because I don’t even know how much it costs or whether I can afford it”.

Hence my reaction ☺ But it’s me, and I’m always bitter

Oh. By the way. If you think that I’m spreading some imagined hate about Elixir… go and take a cold shower.

Ok, W3C and WHATWG, don’t die, but…

Jan 08 2015 12:00
published in:
rantsweb

Originally published on Medium

I’ve received a fair amount of responses to my previous text. Time for a follow up.

What’s up with the rant?

The most valid complaint is: less rant and rage, more sense. But hey, what’s internet without rants? ;) However, the complaint is oh so true. Less rant in the follow up, I promise.

Oh. I also have much less gripe with WHATWG, than with W3C ☺ HTML5 and even DOM are kinda ok ☺

Breaking changes are hard

Another valid point: it’s very hard to introduce any breaking changes to the web and get people to adopt and to adapt. This fear is especially true for browser implementers, because implementing a breaking change may cast their browser away, to the sideroads. However…

So, it’s still risky, but not impossible to introduce major/backwards incompatible/breaking changes to the web… In a gentle way. Keep the old stuff working, actively promote and ecourage the new stuff. Yes, some of the old sites may never die. But don’t forget the 80/20 rule. It might be beneficial to the entire web eventually leave only the absolute minimum support for some old features (hey, remember the <blink> tag?).

It’s not impossible to imagine a backwards incompatible CSS4 with a separate renderer that:

So, render old stuff with the old renderer, render the new stuff with the new renderer.

I wouldn’t worry about the standard being picked up, provided it does away with the cruft, bloat, legacy and inconsistencies of the old standard. Even sites with huge user shares eventually drop support for older browsers (see, e.g. Facebook: 1, 2, 3) and pick up new features. Also, nowadays browsers are updated rather quickly.

Also, we are at a weird point in time when browser implementors and vendors more or less agree with each other. Can I Use is a testament to that. There’s actually hardly a specification without wide or upcoming support.

Why would browser implementors want to get rid of their current implementations?

Because they are programmers.

This is not a scientifically backed up argument, but still: no one wants to work on an old, complex (and getting increasingly complex) code. Especially if it’s millions of lines of code. Especially if it’s a system that gets burdened with more and more layers of rules on top of each other (hey, kids, how do you reconcile css3-align with css3-grid-layout in a css3-flexbox in a float in a …). There’s rules in rules on top of rules hampered or overriden by other rules and so on. And it has to be insanely fast. And it has to be correct, for some definition of correct, as there’s no reference implemetation, only tests (which are woefully incomplete and may target outdated versions of HTML: 1, 2).

BTW, the lack of tests is not a jab at their authors. The sheer amount and complexity of the specs make it impossible to create enough tests (css3-align in a css3-grid-layout in a… you get the point). I’m half expecting CSS to finally adopt C++’s approach and add “implementation-dependent” or “undefined” clauses ☺

Hey, this funny guy makes fun of my title

One problem I have with some/many/most of the specs that come out of W3C and WHATWG is that I don’t feel they are made by people who are doing any serious frontend web-development, or at least haven’t done it for a looooong time.

The main reason for thinking so is that it’s very hard to find evidence of any authors doing any of the (let’s call it) modern web-development. Yes, they hold high positions at various companies/groups/ universities/committees, they hack specs/work on web standards, they work on browser code. But what of actual frontend web-development?

I mean, have you ever developed a complex and/or beautiful website? There are quite a few of them around: Facebook, Gmail, Asana, Google Docs/iCloud, Medium, CSS Zen Garden, various Tumblr designs, Pinterest, Rdio — you name it.

Because if they’d ever develop such a site, we wouldn’t end up in a situation when a simple menu requires 4-level nesting of <div>’s to display a simple menu even on the web-site dedicated to promoting CSS3:

<div class="main">
  <div class="content_holder">
    <div class="menu_search">
      <div class="menu">
        <ul>...

(W3C own site manages to do it with only 3 nested divs. Medium needs 4, and each element is another div. Well, you get the picture)

As an aside: I was told that Facebook is a trivial site to implement in CSS. But have you actually looked at what a Facebook page is? There’s multiple layouts, panels, panels within panels, buttons and drop-down menus everywhere, floating content, fixed content, pop-ups, highlights, embedded content, tigers, and lions, and bears, oh my. It’s not trivial.

Another reason I don’t believe they are doing any serious web-development is the time it takes some features to appear (if ever).

Cases that stuck in my mind.

In an extended Twitter conversation I was told that most of the discussion is driven by the browser implementers. Maybe that’s the reason behind the weird specs, late or non-existent features and the continuing unsuitability of CSS for anything but the most basic layout. People who are good at implementing browser code might not necessarily be good frontend web-developers (or web-developers at all).

Join, review, speak up

It was suggested (and this is also a very valid point) that anyone who has anything to say on the matter, should join the mailing lists, speak up, and review the specs.

However, I must confess: I don’t believe in this approach. The problem with too many people having an input is that:

I would rather like to see a smaller, more focused group of people working to implement a lean and mean standard than a thousand people debating whether a particular fringe/weird case is relevant.

Questions, do you ask them?

Any and all specs by necessity contain only the simplest examples. A single floating div. Four divs in a grid. And so on. The real web is much more complex than that.

I’m not too familiar with W3C’s or WHATWG’s discussions, but I wonder if people ever ask questions beyond simple examples?

And so on. Replace Facebook with any website (or even Sencha’s examples), rinse, repeat. Until you get an actual pragmatic solution. Ditch the fringe cases. Ditch the theoretical “I can imagine when x could be useful”. Go for pragmatic.

Also, look at what people are doing to improve CSS (or HTML/DOM for that matter) (jQuery, SASS, LESS, Grid Style Sheets) and go and standardise those. These are the things that people want and need.

W3C and WHATWG should die a quick and horrible death

Jan 07 2015 12:00
published in:
rantsweb

Originally published on Medium

Note: there’s also a followup.

tl;dr: W3C and WHATWG are a useless bloated bunch of people who don’t care in the least about making the web a better place. Both W3C and WHATWG should die a quick and horrible death, and the development of web standards should be given to a lean and mean group of people, all of whom are actual web developers.

For the sake of all that’s good and holy: why?

Web-developers have the worst ever Stockholm syndrome ever in the history of the world ever. Whatever inconherent inconsistent overlapping multi-million-page abomination of a spec spewn from either of the two committees we cheer them on and ask for more.

And this just goes on.

Why do we keep believing that these self-aggrandizing bloated useless monstrosities work to make the lives of developers easier? Or the web better? What evidence is there?

{ vertical-align: fuck off, any-align: fuck-off }

(Original tweet by Lewis King lost, here's just a quote from it)

We have landed a robot on a comet 317 million miles from Earth and yet we still can't vertically align things easily in CSS.

Yes, it’s true, folks. In the age of SOA applications, and facebooks, and twitters and mediums, there’s still no way to align anything against anything.

Good fucking grief.

Please, do visit these two links, read, and weep: %% units and “flow” attribute. Unlike W3C and WG, the author of these extensions uses them in commercial software that is actually used to build UIs. These extensions cover, oh, I don’t know, 80–90% of a web-developer’s needs?

So, here’s the story. %% units and the “flow” attribute were proposed to W3C. Can’t find the discussion now (it was 7 years ago, at the very least), but the proposal was shot down. Fast forward 7 years, and lo and behold: flexbox, grid-layout and multicol. Bloated, inconsistently named and overlapping each other. And yes fringe cases.

See, folks at W3C and WG act as if they were pure academics.

“Hey, guys, I have this purely theoretical problem which will look nice in a book somewhere. What do you think?”

“Awesome! Bring it on. No, bring two or three of those”

Just as an illustration, http://css-tricks.com/snippets/css/a-guide-to-flexbox/

.container { flex-direction: row | row-reverse | column | column-reverse; }

Can you name/find a single person on this Earth who would need *-reverse directions? Yes, there could be a few: writing books and tutorials that will include this utterly useless piece of garbage. However, since this is a theoretical fringe case, it no doubt was discussed at length and included at the incsistence of “prominent members” of the W3C community.

Damn them all to hell.

Instead of solving real-world problems they play in a nice academical theoretical sandbox, solving non-existing problems. Look at each and every steaming pile of horse manure that they produce: all this bloat, all these insane attributes and measurements stem from the fact that someone somewhere produced an insanely convoluted theoretial example of a non-existent problem and produced a solution to it.

Obviously, it’s not constrained just to alignments. It’s 2015 and it’s still easier to make sites based on exact pixel measurements than sites based on relative percentages. It is impossible for any sane person to create a responsive site without the use of CSS Frameworks (which are themselves bloated and limiting — out of necessity, not by choice). Whole articles on how to vertically align elements or create proper three-column layouts still exist. And the list just goes on and on and on and on…

Do you want to build a sand castle?

Yes. Sand castles.

There’s not a single reference implementation for any of the specs coming out of W3C and WG

Re-read that sentence, and let that sink in. All these specs are purely theoretical constructs that are unleashed on browser implementors and then on web developers.

Hey, you thought Acid tests where the reference implementation? No. Those, too, are theoretical constructs created on a theoretical basis. No wonder browser developers often cheat to make sure their browser passes an Acid test, and only the Acid test, the actual spec implementation be damned.

I’m not even sure the people who come up with the crap they call specs even do any serious web development. I mean, look at W3C’s and WG’s web sites. That’s exactly the type of site you can build using their specs.

I’ll leave this as an excersise to you: go through specs, find their authors, and what they do. Look at their websites, demos etc. You’ll see what I mean. I kid you not, there’s a guy whose job description is “spec hacker”. Jesus…

Is there a way out?

Of course.

Nuke W3C and WHATWG out of existence. As soon as possible. Leave a small team of people (10, maybe 15, tops) to implement a backwards incompatible lean and mean CSS 4:

Last step:

Dig W3C and WHATWG out of their graves, kill and bury them again.

Don’t forget to read the followup.