Hacker News Reader

>I think JavaScript is a suboptimal programming language because it has too many features, and on top of that they tacked on yet more features recently.

No, that's not what makes a programming language "suboptimal".

(In fact following this logic to the inverse would make something like Brainfuck the optimal language).

It's not the number of features that makes a language problematic (of which Javascript, even ES7, doesn't have more than Python or Ruby do, and those are considered quite OK languages).

It's suitability to the task (e.g. you wouldn't want to use Fortran for text processing), how well the features play together (you don't want conflicting behaviors and edge cases a la C++), expressibility, aesthetics, coherence (and of course, tooling, speed, ubiquitness, etc).

>I wouldn't call CSS lousy either

But CSS is lousy. It was overdesigned in parts nobody cares about, underdesigned where it would matter, an ad-hoc model for styling, and even mis-named, as it not only styles, it also layouts. And in that area it has been horrible, failing for decades to provide the most basic blocks to build layouts, and having people use hacks like "floats" to do so.

> (In fact following this logic to the inverse would make something like Brainfuck the optimal language).

You can reduce any argument to an absurd extreme. It's fair and fine to disagree with every single opinion I express, but I don't recognize your impression of that particular point as something I wrote.

My point was, and I'm sorry if I failed to get this across, that in my opinion there are bad parts in JS which could have been stripped away, making it better for an admittedly arbitrary as-defined-by-Udo's-mood-today value of "better".

Every single thing about this discussion, including the original article, is a matter of opinion. I agree with much of what you said about CSS and the need for a language to fit a purpose, and I don't want you to get the impression that I'm trying to say everything about HTML/CSS/JS is awesome.

>You can reduce any argument to an absurd extreme. It's fair and fine to disagree with every single opinion I express, but I don't recognize your impression of that particular point as something I wrote.

You're right on this.

On my end though, I accept the other extreme of what I said: a language can have the most features any other language has times two, and still be great.

That is, number of features is not really relevant as to whether a language is good or not.

People seem to think for example "oh, adding this and that would make Java too complicated and too hard to learn etc". At the same time nobody complaints against C# who has twice the number of features or even more. In fact most people find programming in C# is a joy compared to Java.

>[CSS] has been horrible, failing for decades to provide the most basic blocks to build layouts, and having people use hacks like "floats" to do so.

Co-sign every word of this. When I first started developing I hated JavaScript, but in the end it's fine if you have jQuery and some other libraries handy. CSS, however, is a cryptic alien language--translating layout ideas into it requires multiple PhD's.

> But CSS is lousy.

I'm conflicted about this. On the one hand I can certainly agree that CSS tends to cause as many problems as it solves, at least where it affects my everyday work building web applications. But I can't say with confidence that this is an inherent flaw in the language, and not just the consequence of having to rely on the one CSS expert in the department, or my own limited knowledge of CSS and web UX/UI when he is not available.

I will say (with confidence) that using Bootstrap has been a great experience, and I can't imagine going back to plain CSS layouts without it.

>But I can't say with confidence that this is an inherent flaw in the language, and not just the consequence of having to rely on the one CSS expert in the department, or my own limited knowledge of CSS and web UX/UI when he is not available.

Well, after 15 years of working with CSS, I can tell you that no, it's not a result of your limited knowledge. CSS does suck as a layout language. Flexboxes at least solves this somewhat (at least when they become widely available).

I hope the next logical step implied here after this is NOT going back to native applications for everything.

Out of curiosity, why? I always thought the model of static documents was a conceptual fit for the web, thinking of it as a file server. The move towards SPAs and real-time apps is really showing the browser's inner-platform effect, and the rough edges of the APIs thereof.

Since we are using techniques to create a full parallel OS runtime inside the browser, I wouldn't be surprised if a surge of interest from web developers emerged into simply using the host OS again.

By and large I believe the ideal of the browser as being the universal WORA platform to be largely bunk, in that cross-browser compatibility has always been grueling, with the reliance on polyfills and all sorts of ECMAScript and browser API incompatibilities persisting to the point where entire tables and guides are being drawn about them.

In hindsight this should have been unsurprising. Just like the Unixes diverge, so do the browsers.

Unless there is a vendor neutral standard for applications you get into the situation where only a few vendors get massive power dictate to everyone (users, developers, manufacturers) the terms in which they get access to the platform.

Now the web isn't perfect but it's the closest thing to a commercially successful vendor neutral software platform in existence.

The vendor neutral standard for Unix-likes is POSIX, and by some extension Windows to the degree it has compatibility, or that it can be bolted on to via Cygwin or whatnot.

Windows itself is a proprietary platform, but it has no central software repository, so developers distribute their software through all sorts of means. Market share means influence on OEMs is exherted, but is it not also the case that if, e.g. Chrome, becomes a dominant browser that they do not exhibit de facto diktat over many aspects of the web?

Android's central platform is Google Play, but you are under no obligation to use it. You may opt for F-Droid or fetching lone APKs.

It seems to me the only platform where central curation is so ingrained that alternatives become impractical, is iOS.

Not to mention the web, despite being ostensibly vendor neutral, comes with a big problem of its own. Now every single page you interact with, no matter how primitive, is behind the scenes potentially a distributed, unobservable, multi-tier networked application with who knows how many layers of caching proxies, CDNs, ad trackers, analytics, data processing pipelines, etc. etc. with no way of knowing what's changing.

Another problem with the web is that every application has a massively different look and feel. I'm not just talking colors here, but some forms validate inputs as they are put it and others don't respond until you hit submit. Etc. There is no common UX for the web and IMO that sucks.

I think you are mistaken -- the web is more consistent that, say, the Windows GUI ever was. Yes, there are small quirks like the one that you describe, but in general, most users don't need to learn how to use a webpage. Have you ever seen a novice wrestle with a native GUI? It's horrific.

The vendor neutral standard for Unix-likes is POSIX

And look how well that turned out!

POSIX only covers the API's not the ABI's the software will run on. Also, that still leaves them running on a vendor specific CPU architecture.

Your naive if you believe Microsoft and Google don't hold all the cards with thier platforms. More and more of Android is being swallowed up by Google Play Services. Windows does have a central software repository called "Windows Store". Let's not forget about how users have to put up with thier shenanigans because they are the gatekeepers to apps.

I would want very much to go back to "native apps for everything", but it seems we went too far to be able to turn back. So this idea is for some better world where communism wins and everyone lives happily. Or whatever.

Let's recap what was there in the previous series…

1. Some folks made a network out of several computers and saw that they can now exchange information without sending mail and picking up a phone. Cool.

2. Some guys invented a simple protocol to assign address to every piece of information we would like to exchange. They invented HTML, to be able to put these addresses in the body of the document. Also, why don't we make several keywords to make that information a bit more structured? We'll use SGML as a base, because it's trendy.

3. More programs to use these protocol and markup language appear, markup transforms further to be able to add images to the body of the document and so on.

4. Somebody comes up with the idea that markup should give a structure to the information, and there should be another document — stylesheet — to describe what that stuff should look like. It also has to be cascade, because he's smart.

5. At this point things are pretty bad already, because there are many programs to interpret this protocol, and they are fighting with each other over the audience. But if back then people would make HTML and CSS "good enough" the idea of separating content and representation would have worked out and we'd have what we are talking about now…

6. …But something more interesting happens, and instead of plain simple document-exchange system we now have plugins, then applets, then javascript, then web2.0, ajax, interactive applications right in the browser. It isn't possible anymore for markup to be content and for everything else to be representation, because both are changing in real time, as user pushes buttons. And there're even more browsers to interpret this madness, and they are fighting with each other as never before.

7. Also, now we have some major evil corporations, that have lots of money to shape the technology world as they want, and they want to own all our data, which means making as many useful apps as possible server-side: which means moving all major client-side apps to the browser.

8. Now every site is fancy app, drawn by designers in Photoshop, then painfully re-created in html, css and js. Thousands of libraries and "frameworks" are made to make this "creating app in the browser" process comfortable, but they don't succeed. Although it's now somewhat easier than making native apps, because hardly anyone cares about them anymore.

We achieve a point when HTML — no longer actually relevant thing in this world of interactive madness — seems to be "good enough" to stop evolving. We look back at #5 — browser as an app to show simple documents — and sigh. It would be good, but the whole world uses our in-browser-apps now. It is what customer is used to. We can't make our "simple" stuff, because nobody cares about simple.

On the other hand, the browser provides a ubiquitous, consistent-enough runtime across basically every consumer computing device, and people who are interested can get up and running with developing basic apps for it in a matter of days, using only tools that cost zero dollars.

Can you imagine what the designed-by-committee-for-that-purpose version of a universal runtime would've looked like?

(hint: the answer is it looks like the Win32 or Java platforms/APIs and has just as many warts if not more)

> We almost never phase anything out, and that's a problem

Is it though? HTML etc started as a way to publish and link documents. Phasing shit out makes old documents less accessible. Nobody is going to install a creaky old insecure copy of Netscape Navigator to go visit perfectly good HTML documents authored in 1996

>I think JavaScript is a suboptimal programming language because it has too many features, and on top of that they tacked on yet more features recently. I wouldn't call CSS lousy either, and the API of the DOM even got better over the years.

Huh? What were the overwhelming number of language JS had pre-es6? It was actually a sparse language that led to the need for a lot of libraries for you to have a chance at being productive.

Trying to do proper positioning with DIVs is proof enough that CSS has.. issues.

>But if the point is that whatever comes next probably won't come out of a committee that sounds about right.

The alternative seems to be some kind of unilateral action, and I have yet to see that working for the web. The reality of the matter is that Microsoft, Mozilla, Google and Apple all need to agree on whatever happens next. That's a committee.

Good things came out of unilateral action: XmlHttpRequest, innerHTML, document.write, asm.js, WebRTC, JavaScript itself...

I wouldn't put "document.write" in there.

But also: Canvas, CSS 3D, etc.

> I wouldn't put "document.write" in there.

innerHTML isn't awesome either, but that's from today's point of view. It's good that we moved on, even though at the time it was important they existed.

this is what makes a fast browser hard to write - scripts can mess up your document

so in fact browsers kind of assume nobody is crazy enough to do document.write

and then when it gets called they redo all the work rendering the page

Obviously that train has left the station ages ago.

We now have dynamic documents were scripts are MEANT to mess with the page constantly, and even create it's contents from scratch in some cases.

No, you don't understand. What you're talking about is after the page loaded scripts execute and modify the page. That's completely fine. I'm talking about page load time. A script potentially can force you to reparse the page.

A script can insert something like </div><div class="something"> into the page in a random spot, completely wrecking the layout you just made. Adding a new div at runtime on top of the other parts of the page is easy. Something that can actually make all the positioning on the page completely change is much more evil.

So in fact, browsers usually get the HTML, parse it, get the CSS, position/style things while getting the JS (hopefully you have optimized it so the CSS loads before your scripts). Now if the JS file has document.write you have to reparse the HTML because the current tags could be a lie! The document.write could have closed a tag and opened a new tag.

Compared to that, just setting the innerHTML of a tag is much less expensive. You just need to potentially reflow its size and its parents. The rest of the page may not be affected. document.write may force you to tear everything down and start all over again