On the backend the developer chooses his universe. Whether it'd be ruby, python, mongo, postgresql, nodejs, haskell, go, whatever. If the universe sucks people can change everything. If you hate the mopho stack (mongo and php), that's ok, you got other options.
With the browser everyone is stuck with one universe. The only thing that changes are front end frameworks which offer some flexibility. Still, if html sucks we're stuck with it. If you hate html or javascript then you hate the entire front end. You exist outside of that universe because Nothing can change it. End of story.
I don't know how it could be done while keeping things secure, but it would be awesome if the browser universe was as flexible as the backend. If I could swap between html and any other kind of media based declarative language as easily as I can swap between python and ruby on the backend, it would change the face of frontend development and make it more accessible. In fact what if I wanted to develop my own language that interfaces with the rendering engine? The browser should permit that, because the Web is too broad to be dominated by a single language(HTML).
Isn't this problem solved by having HTML/JS/CSS as a compile target, which is what we are heading to now, with languages and technologies like CoffeeScript, PureScript, Elm, ClojureScript, ghcjs, emscripten etc.
Even on the backend, in the end you have to run native machine instructions. HTML/JS/CSS substitute for that on the front end. Of course, x86_64 may be a better compile target, but the advantage of the existing languages over any new system is that there has been a lot of work that has already gone into making them fast, backwards compatibility, all browsers already implement them, and there are a lot of things that can target them now.
Personally to me that's "ugh." HTML and CSS as a compile target? What's the lowest level primitive in html? A div? A span? ew. It should be compiled to something that has access to primitives such as lines, polygons or pixels.
Compiling to js is ok as that language is as close to the metal as you can get on a vm anyway. So long as performance isn't affected then it's really no different to the developer. Still the platform would be more elegant if it didn't compile to some intermediary high level language.
Of course you can go lower, but there will be sacrifices. Brendan Eich actually addressed this same topic in response to some other thread I started a while back. I quote him below:
"Apart from syntax wins, you can't get much lower-level semantically and keep both safety and linear-time verifiability. Java bytecode with unrestricted goto and type confusion at join points makes for O(n^4) verification complexity. asm.js type checking is linear.
New and more concise syntax may come, but it's not a priority (gzip helps a lot), and doing it early makes two problem-kids to feed (JS as source language; new syntax for asm.js), which not only costs more but can make for divergence and can overconstrain either child. (This bit Java, pretty badly.)"
Sure. And I know about these. The original poster was talking about languages with HTML+CSS+JAVASCRIPT as compile targets, not canvas, svg or webgl. I'm simply addressing his comment.
Either way, WebGL/canvas operate as child elements in an html page, you still need to use javascript, and SVG isn't GPU accelerated. It's still, overall, an ugly mess. But definitely, with improvements, canvas, svg and webgl are all candidates for my aforementioned "next steps."
How is it that much different than using OS APIs to do common tasks like text, windows, buttons, scroll bars, etc? If you really want to do pixel level stuff, there is canvases and images and SVGs.
How would I replace html in the browser? Create a new rendering api in canvas? Can it be done? Sure. Will it be pretty? Not so sure.
Imagine your operating system can only compile one single language: Perl. And with perl the only way you can render anything on the screen is with a QT api and QT UI primitives.
Programmers can still do anything within this ecosystem. Technically you can have perl as compile targets for any other language. Lets also pretend that QT has this little UI element called canvas that has a api allowing you pixel level control.
While technically you could do anything in a platform like the one I described above, I'm sure you can easily see why it's still bad.
It might be bad example, but if the Java SE runtime libraries was just a dependency like any other mvn artifact (module), Sun / Oracle would for example have been in a position to introduce immutability to the Collections framework and fix crazy other stuff[1] without breaking backward compatibility. But now we are stuck with those legacies forever[2], since they standardized on a too high level abstraction and choose fewer layers. For Java's, luckily they had layer underneath - JVM byte code, which is why I predict Java is still relevant for many years going forward.
The next generation of WWW needs to a very low common abstraction, e.g. bytecode. Something similar to X Windows.
You don't see the inherently 'open' nature of HTML and common accessories to be a huge benefit? Sure, they can get messy, but are still bound to be more parseable and tow people along to the transformative idea of a giant shared graph with dev tools (inspection) support, compared to byte streams. Over time Flash, Java applets and other approaches have come along but been deprecated, which I'd considered to be emblematic of searching for a more transparent information commons outside one technical requirement (even if the logical conclusion of a 'semantic web' has been elusive so far). The fact that "view source" is available in all major browsers is to me incredibly meaningful and positive compared to alternative visions.
Or would your byte code blaster have similar properties?
I think we can build it however closed or open we would like it to be. The sharing of source code I suspect is more social than technical, therefore I don't expect much change.
Java Applets, Flash, SilverLight always was at a disadvantage, not being native to the browser runtime. Startup time and the need for a "plugin" hurt them. And they all kinda sucked in their own way. I hoped for a long time that Dart / native DartVM to Chrome could make a stride, but sadly they were fighting uphill battle against the sheer volume of JS developers resisting change. I'm convinced that it's never about the language[1], but the VM and it's abstraction layer. We need a layer that we can compile JavaScript(/HTML/CSS), Scala, Haskell, C#, F# etc. down to, not more languages.
I wonder how many man-years has been wasted on vertically aligning div's inside a div. :)
> "If I could swap ... language as easily as I can swap between python and ruby on the backend, it would change the face of frontend development and make it more accessible. In fact what if I wanted to develop my own language that interfaces with the rendering engine?"
I'm building this. I've been working on a side project that was my idea of the ideal internet platform, and for a long time I believed that the front end was a lost cause. I've recently figured out the solution. Had quite a eureka moment, in fact. This will be open source but it may be a startup and I'm not going to talk about it until I have a proof of concept... but let me give you an overview:
-- Works on all browsers made since 2013ish
-- You can do absolutely anything you want, in any language you want (though a bit of glue will be necessary to a lower level framework)
-- Initially there will be a basic implementation on a well known and well supported development platform that will bring this close to WYSIWYG and let you write code in more than one language
-- There is a spec for UI elements and you can throw out that initial implementation and write your own complete implementation. This is a non-trivial project, but much easier than creating a browser.
-- The UI can be easily implemented in native forms for native applications. So the "page production code" can be the same for all platforms, web and native, and the "client" code merely translates into the local platforms UI elements (or re-creates the spec's UI elements when there isn't a mapping.)
-- It might suck. This is highly experimental right now.
-- It's no longer a side project, it's my full time obsession.
(ignore what's in that repo right now, the work is happening elsewhere until it's usable for people to start building stuff with. At that point it will be easy enough to wrap your head around that outside contributions will be appreciated. I have a group of hackers I'm working with now, and it's clear things aren't far enough along... yet.)
Why not speaking about it ? It will give you contribution (you can refuse if you don't like it) and no one is going to steal your idea : https://news.ycombinator.com/item?id=9663203
I'm not afraid of someone stealing it, and I am speaking about it. Just not publicly. It's too difficult to discuss such things in a forum like this. Too much emphasis on voting and threads and it doesn't lend itself to a good technical discussion. Especially about a concept that is still being developed.
What would be really nice is something similar to .Net's virtual machine CLR. It would offer the flexibility to design in whatever language you want and possibly a performance boost as well.
The CLR isn't really very flexible. Most languages that run on it are pretty similar. If you try to implement a language like Haskell on top of it for example, it quickly becomes obvious that it isn't a good fit - because the CLR has no support for higher kinds, typeclasses, laziness, parametric polymorphism etc. Sure, you can implement a Haskell interpreter/compiler that converts to .NET, but there certainly won't be any performance boost by boxing everything into objects and having several layers of indirection to simply invoke a function (and not really any advantage over writing such interpreter in say, JS).
A more ideal VM would be one which doesn't force a particular paradigm on you, but just abstracts over the CPU, using capabilities to restrict which instructions can be invoked. The CLR lacks such capabilities. Perhaps something like SafeHaskell would be in the right direction, where side-effects are limited, and the user can optionally allow websites to invoke trusted modules.
Java applets and Silverlight were attempts on this idea but both failed quite miserably. Not necessarily because the idea itself was bad, in the Java case the execution was bad and the .net case came in a time where moving away from flash was the latest trend and the fear of proprietary lockin from MS too high.
That only addresses the language component though, right? You'd still be stuck with HTML and CSS. I'm okay with javascript although I'd love to see another language supported in a similar first class fashion. It's HTML and particularly CSS that feel too overloaded, document-centric, and just plain hacky. I think something a little closer to XAML, or possibly like AML, would be a great addition. It'd be great to have support for a responsive layout without having to deal with responsive design as it exists today (amazing as it is).
A Lisp gives you all of this and more in a single, consistent, powerful programming language. I fail to see why we need three vastly different, intricate and complex technologies when we could have done with just one simple, elegant language. Languages like Scheme are mind bogglingly small, yet amazingly powerful.
I think this is more of a side-effect of familiarity rather than any inherent differences in readability between the two forms.
Lisps do tend to look foreign to most people because their first languages usually have C-like syntax, and Lisp vs C is a much more dramatic difference than say Python vs C.
Being able to write code that also happens to be valid data structures has some very tangible benefits though.
For instance, in the HTML example, you can replace the strings or keywords in it with variables and it will be evaluated and output into the final HTML. You can also take that HTML element, pass it into any number of map, filter, reduce functions and programmatically transform it in literally any way you want.
This means when you write HTML this way, you can use ClojureScript as your template language, and I think it's safe to say that ClojureScript is a much more powerful and well-designed language than any template language out there designed for HTML.
> Personally, I prefer the HTML version over the ClojureScipt version. It is shorter and to me it is much more readable.
That is only because this is Lisp that generates HTML. Also, in the example you had given, there are no closing tags. Closing tags are just superfluous visual clutter and are not actually needed. To take an example from http://c2.com/cgi/wiki?LispVsXml
This XML
<dictionary>
<email>electronic mail</email>
<html>hypertext transport language</html>
<xml>extensible markup language</xml>
</dictionary>
That is only because this is Lisp that generates HTML.
Ok, so it is not the way you initially stated '<img id=animal src="my_kitten.jpg"> becomes (html [:image {:id "animal" :src "my_kitten.jpg"}])'. You rather showed an example of how to create html elements programmatically. Then you should compare it to JS:
Yes, my second example which translated XML to equivalent Lisp would be better at illustrating my point.
With a Lisp, you don't need HTML as there is no distinction between code and data. Your Lisp is rendered and displayed on screen. It doesn't emit an intermediary language. How do you programmatically manipulate this "data"? Within Lisp itself. Lisp acts as both HTML and JavaScript. Lisp programmers regularly do this with the power of Lisp macros. I suggest you read the "Lisp vs XML" page I linked to in order to understand this better. Lisp directly exposes its syntax tree to the programmer and allows them to manipulate it to their liking.
So do you propose to make the separation of content and behaviour go away? Because that is one of the key features of the HTML+CSS+JS structure.
I like the content/presentation/behavior separation from a developers point of view and from a users point of view.
As a developer, I love to know what I am currently working on. In HTML, I define the structure of the content. In CSS, I define how it looks. In JS I define the behaviour. Lovely.
As a user, much of the time I browse the web without JavaScript. Because I am only interested in the content. Not in popups that beg me to join newsletters, animated things that make the page more "fun" or ads that try to grab my attention. Also I often disable the pages stylesheet so I get a nicely readable big font with good contrast to the background.
> So do you propose to make the separation of content and behaviour go away? Because that is one of the key features of the HTML+CSS+JS structure.
No, only thing that goes away the cognitive burden of keeping in mind the original HTML, CSS and the JS representation/modifications of HTML and the interaction of all three.
As many websites are currently designed, content if often loaded and inserted into the HTML by JS. The separation of concerns enforced by this system is extremely blurry.
You could also tell the interpreter to not evaluate macros and just display the content as is.
> As a developer, I love to know what I am currently working on. In HTML, I define the structure of the content. In CSS, I define how it looks. In JS I define the behaviour. Lovely.
You can do all three in the same language and still maintain separation of concerns, like is done in most other languages and with native apps.
> As a user, much of the time I browse the web without JavaScript. Because I am only interested in the content. Not in popups that beg me to join newsletters, animated things that make the page more "fun" or ads that try to grab my attention. Also I often disable the pages stylesheet so I get a nicely readable big font with good contrast to the background.
Again, you could tell the interpreter to ignore style elements, or write a reader macro to do it yourself. That is the beauty of lisp :)
The lisp is not "rendered", it is executed. Any language that can implement a recursive-descent parser/generator could be the basis for this -- it does not require lisp or lisp macros. Think about what a render would have to do, and you realize that the model of using embedded rewrite rules (macros) might be slightly more convenient, but not a really a distinct advantage over executing code which renders or outputs instructions to render later.
The problem is most definitely not that you have to output an intermediate language, the problem is that HTML/CSS sucks. It is originally designed around presenting static text documents, and the committees involved were not smart enough to figure out a way to depart from that over a decade ago when pixels became important to the web.
In python, I can read code and reason about what it will do because I have a mental model of how that language works. the same used to be true of C and probably still is, but I'm out of practice.
I've been trying to build a coherent mental model of how layout in HTML+CSS works since 2008 and still haven't really been able to. If you gave me an html file and CSS file, I'm not at all confident I could draw they would interact. Conversely, if you showed me an HTML page, I don't think I could write HTML and CSS to reproduce it without continually refreshing my browser to check it. I have been trying to determine why I can't seem to learn this.
It's a visual thing. Frontend isn't very similar to programming for the backend (except for high quality javascript). Most people who can do wonders for frontend tend to be more like designers.
Ugh. Before the advent of CSS3 and canvas, I would have rated myself an 8 out of 10 in terms of "frontend knowledge/skills" compared to other frontend developers I'd met. I was never the cream of the crop (as a backend "expert"), but I could take a photoshop and replicate it, and knew most of the browser compatibility issues and how to work around them.
With all the CSS transforms, animations, canvas, 3d libraries, etc., I'm now utterly lost. I've gone from being an intermediate frontend guy to a 6/10 on the core necessities (all that earlier knowledge is still the foundation), but like a 1/10 or 2/10 with all the new stuff. I could probably get to 4/10 if I put in the effort, but I have a very strong gut feeling that I simply do not have the... faculties... required to be an intermediate frontend guy in 2015.
All that to say... codepens like these I've seen blow me away. I don't even bother trying to dig into the CSS. It's just beyond me. ;)
CSS is the one of the trickiest technologie I had to deal with. Something as easy as centering a div is a hell to do. You find many different way to achieve it on the web, but some work in few cases and don't other time. The reason why is still a mistery for me and my other skilled colleages.
CSS is one of the reason I hate web developement (javascript being so tolerant to error is another one).
You're absolutely right that it's a pretty good way to build text/image-based documents and show them on a page (well, ignoring CSS and it's many quirks).
But a lot of people wanting to do web-things don't want to just show documents. If you want to build programs, it's not as convenient any more.
The open question remains of should we be trying to improve the web ecosystem to compete with desktop applications, or should we accept that maybe web browsers are best at document reading, and we should leave both to their respective areas.
You quite obviously don't know what you're talking about.
Try and write something complicated in js and you'll hit performance problems far quicker than other languages even today in 2015.
HTML is a complete disaster.for any thing other than documents and woefully inadequate for applications. You can't even do something as basic as encapsulate a snippet as a control to reuse.
And CSS is plain stupid, the very foundation of it is quite obviously broken. The precedence of operators is a constant annoyance. And let's not even get started on how it lacks basic inheritance, making it a nightmare to maintain.
I can't understand how any programmer who had actually used the alternatives could claim such things. I suspect you have little experience in programming so aren't even aware of the alternatives.
What if I want to use html+css+js to dynamically draw a 1024x1024 picture of a cat with pixel level detail? I'm sure it can be done. But wow. That code would be ugly.
Or how about dynamically drawing a diagonal line or swirl across the page?
I apologize for the lack of an example, but I'm sure you can imagine how much harder that would be in html and css then it is with a renderer that has bezier curves and lines as primitives.
I said pixel level. That's vector level. Also by html+css+javascript I thought you meant strictly primitives within that domain like spans and divs. While svg is part of html5 people typically don't think of svg when someone says to write something in html+css+javascript.
I don't have a problem with that. Never said I did.
The OP said html+css+javascript, which I assume means html primitives like div and span with css and javascript sprinkled all over it. Canvas and svg exist a little bit outside of that ecosystem and I assumed the OP wasn't referring to that, because sure... with WebGL you can literally program anything into the browser. If someone used webGL as an example it would sort of render his question pointless.
The point of the article seems to be that HTML is done because it's "basically OK", and everything around it is done because it's awful and can't be salvaged anyway. I hope the next logical step implied here after this is NOT going back to native applications for everything.
The browser-as-a-platform is based on a lousy programming
language addressing a lousy object model and using a lousy
stylesheet language for visuals.
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.
We almost never phase anything out, and that's a problem, but I think the core issue causing suckage within the 3 pillars (4 if you count the DOM separately) is that they have been explicitly designed to not work together very well. While you can - and often are forced to - extend CSS and HTML with JavaScript, they didn't make the interplay between them especially synergistic.
As for
HTML? Not perfect, but plenty good enough.
no, I don't think so, especially if we're discarding JS and CSS as garbage, HTML does not deserve to get a free pass.
Even if we wanted to improve it, there are no obvious candidates to do the work.
I don't get why we're all of a sudden in an arbitrarily constructed situation where the whole web platform can never be iterated on again. Ever. But if the point is that whatever comes next probably won't come out of a committee that sounds about right.
I agree that some of the frameworks mentioned exist to work around the issues we created in the browser platform. Especially the functionality of React should be considered for an adoption scenario, maybe not the exact React API, but something along those lines that makes working on (or at least applying) diffs easier. The same goes for handlebars-like templating. I would rather see some of these adopted than the effort that goes into giving classes to JavaScript.
>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.
>[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.
> (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.
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.
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.
>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.
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.
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
I lean toward languages with static typing for application development, but now that there is ES6 and typed arrays, JavaScript is a pretty nice language to program in. And there are a number of very powerful APIs available to browser JS that many people still aren't aware of/don't use to their full potential: WebRTC, Web Audio, WebGL, Transferable Objects in Web Workers, and so forth.
I've now stopped using jQuery for DOM manipulations, and use plain JavaScript in most cases involving simple manipulations (I do use React for complex applications).
CSS has some problems that grid and Flexbox should help alleviate.
But all in all, I'd say the Web is in a pretty good state.
I agree. As a C++ developer of ten years (before switching two years back), trust me when I say: JavaScript is not a bad language at all. Six years ago I used to laugh at the language. It has come a long way since then (or I've learned more). So much so, it is now my favorite language.
As a side note: do try to not convert JavaScript into a static language -- there are certain types of boilerplate/generated code that I could never eliminate with C++ due to static typing. With JS, it was a breeze.
That's not generally true. Another C++ dev here. I wish Dart had more success... If I were forced today (to do front-end) at least it should be TypeScript.
Until we can write truly robust versions of everyday productivity applications, such as editors or spreadsheets, without resorting to <canvas> underlayment, it simply isn't true that the web is in a good state. Flexbox improves the layout situation (as present CSS is astonishingly terrible at simple layout), but it won't elevate to anywhere near the point of making aforementioned productivity applications.
>> But all in all, I'd say the Web is in a pretty good state.
Agreed.
Not sure why people are always trying to fix something which isn't broke.
Ok, yeah, we could fix some things, when you start to micro manage all the tools and technologies people use to build things these days for the interwebs. But seriously, is it really that bad?
The basic problem can be described quite simply. HTML was designed for the World Wide Web - a matrix of hyperlinked documents. For that purpose it more or less has succeeded (some people were more ambitious about what authoring hypertext should have achieved but I'll ignore that wrinkle). However, these days people want to do things with the web other than write hypertext - they're wanting applications on the web in just the same way we want applications on our computers or apps on our phones. And for THAT purpose, HTML / CSS / DOM is utter gobshite. If I want to write an application, the bottom of layer of that shouldn't be "now convert that into something that perverts document layout of the browser to look like something that hasn't been laid out like an HTML document".
We need a technology that is suitable as a compilation target: a virtual machine. It can be optimised to hell (better than JS which necessarily is always compromised by having to be JavaScript and not byte code) and we need a suite of basic machine systems - sound, graphics, storage. We're not really all that far off from these things with what is supplied with HTML 5 it just sucks that the core of the affair - HTML/CSS/JS - is rotten through and through.
I think UI really shines using the Web stack because it was built using async tools from the very beginning. UI development should be async from the get go. In other non-webby systems you do UI using async but you're still using blocking tools (for example by using Java's mixture of async for UI but blocking for other stuff). JavaScript on the other hand, and all of its libraries, are entirely async which makes it a pleasure to work with - it's a much more natural environment to be doing UI in (single thread and everything is there to be used without multi-threading complicated stuff).
This is a big insight that JS and other webby-tools have given to the UI world, and I strongly believe something entirely async needs to exist for the desktop/mobile world as well - fortunately there is in the form of node.js/electron/nw.js.
Now in terms of how that's handled behind the scenes, I don't really care (use a nice VM, use a whatever mixture of whatever you want). Just give me a fully-async toolset to build my app in a single thread and I'm happy.
I can't agree that UI via JS async is a pleasure to work with. I can't think of a UI technology I've found less pleasurable to work with. No - there was an ancient C GUI that used all C Macros to compose - that was worse... but only just.
Tim Bray or not, it's irresponsible to point out a pile of shit without pointing to a shovel. (And for the record I disagree that there is a pile of shit. I see a bazaar of indy components.)
The browser exists in open opposition to iOS and Android, technically, culturally, and stewardship-wise. No-one in their right mind is going to pick a web host that charges you 30% of revenue. And yet, that's what Apple has managed to get (and they just control the BLOB distribution channel, they don't even provide runtime servers!).
The whole shebang is sorting itself out and I for one think it's going to be very, very cool.
> it's irresponsible to point out a pile of shit without pointing to a shovel.
That's not true in general, but since in this case Tim Bray seems to be implicitly proposing an alternative of sorts (never mind whether it's in fact any better) that isn't really relevant. For what it's worth, this https://news.ycombinator.com/item?id=2119057 is the correct solution.
I disagree that it is irresponsible - only because it is much easier to point out the pile than to point out a shovel. The old generation can say "we built a pile of shit" and ask the next generation to do a much better job - I find that totally reasonable. And I suspect that the next generation will do so. I'm pretty sure that in a lab or basement somewhere there is a growing seed.
I think that if Motif and Motif Tools had not had such restrictive licenses, then we never would have ended up with this pile. We would have started from a much better place, and been further along by now.
> it's irresponsible to point out a pile of shit without pointing to a shovel.
Nope, try another metaphor: you have the right to flinch away when something stinks, even if you don't know where the nearest rose garden is.
(That said, I think he's wrong. JavaScript has a hell of a lot going for it right now, and CSS and the DOM are starting to take advantage of the effects of that.)
People pick that "web host" because the platform you think is so great sucks ass.
People have said this morass of nonsense was sorting itself out since gmail came on the scene. Things have been sorting out for web apps before mobile was even a viable thing.
What frustrates me about these kind of articles is that they ignore things other than technical perfection. Yes, the web platform isn't the ideal work environment, but at least its got mass adoption and has some kind of standard. Its much easier to program a web front end than it is to program and distribute a gui application using qt. Yes, the web development area needs improvement. JS, CSS, etc. aren't perfect, but improvements are being made, the technology is being pushed forward with every new version number.
I disagree when you say that its easier to program web front-end than Qt/GUI application. Although improvements are being made, they are mostly patches rather than rethinking the design given the current usage. I do agree with the author in that there are many broken tools and languages.
I look at web development tools this way, It is still easier to write an application on NeXTSTEP (edit: machine web was developed on) with its tools than a modern web application. HTML is ok for documents, but I hoping something better comes along in the next 10 or so years.
Distribution seems like an easy problem to solve... App stores or software repositories. Am I missing something here? In 2015 all the major platforms have or the other other.
Turnaround for updates to a website is seconds, at most. Turnaround for updates to an third-party repository can be anywhere from weeks (Apple App Store) to years (Debian, RHEL, Ubuntu LTS, etc.). If you care about those platforms and you care about iterative deployment, web apps are so much better in that regard than native apps.
Of course, there are use cases where you don't care about those platforms or you don't care about iterative deployment. For, say, PuTTY, which releases roughly once every two years and primarily targets a single platform, these concerns don't apply and PuTTY in fact is a native app. But that's far from all use cases.
Exactly. For every web startup or established player, there's an equivalent native app running on a mobile phone, or also on the Desktop (from Facebook, and Twitter to Skype etc).
I found developping gui with qt far easier than with html/css. It took me few hours to understand layout concept of qt.
I am not offently doing css/html, but after few years I still don't understand css layout. Things as trivial as centering a div is a nightmare. In qt it is easy.
qt >>> html/css
But javascript made event handling easier in web than in qt (which event handling is a little bit tricky).
I have only programmed in Ruby and Java and Javascript (and the first two only a little). ES5 and before js does seem worse than the other languages I've experienced, but not by much. And ES6 is sort of a joy to write. Leaving callbacks behind for promises and writing in a largely functional style is very satisfying in js right now.
Popular javascript frameworks exist to "work around" problems with javascript and CSS frameworks exist to "work around" problems with CSS?
There's no magic with Angular or Bootstrap, they're codifying an approach using 100% native JS or CSS. Even SASS and LESS are just alternative ways to produce CSS. This is not novel in computing.
But, your analogy is flawed; the situations are incomparable.
You're not forced to use Rails for your server application, many other software exists as well as Rails: Django, PHP, etc. However you /are/ forced to use Javascript, CSS and the DOM; Unless you're a Big Browser Vendor and can try and coerce support (and even so, the amount of websites made in something like Dash is pitiful afaik). People made frameworks and libraries that make it bearable (SCSS, JQuery, etc), but that doesn't mean everything is solved...
That's a totally different analogy altogether. The argument expressed on that page isn't that there is a lack of choices, but that the choices are inherently flawed (and somehow "fixed" by frameworks that lie on top).
This seems to basically be the argument for preferring compile-to-js languages over vanilla javascript, even though by definition any advantages in the former have to exist in the latter.
Yet if I were to call coffeescript an overly complex javascript framework, people would probably strenuously disagree. But that is what it amounts to.
Purescript compiles down to javascript but helps save programmers from themselves by introducing a better type system as well as great data structures, and functional paradigms
Typescript adds static typing and OOP
CoffeeScript...is syntactic sugar? (okay maybe I agree with the coffeescript sentiment)
Although I don't entirely agree that compiling a statically typed language into javascript really helps much, since the end result is still... javascript in a browser.
But the last time I tried to defend that I got almost universally disagreed with, so I'll concede that the process might have value I just don't see.
I happen to like JavaScript but I agree about HTML, CSS, and the DOM. Actually I would like them to die. It doesn't take a PHD to see that we've moved beyond what the original platform was designed to do. It was designed for documents and styling those documents, but very little of what we do today is making documents. Webapps are king now and designing them means having to work around this outdated platform built for documents. It's so bad that now we require books such as JavaScript the Good Parts to explicitly tell us how to avoid these warts.
Instead of iterating further on HTML I think a new open platform should be built that specifically targets interactivity and building applications. Keep HTML for documents, what it was meant for, and begin focusing on something that can address the current needs of developers.
I would say a substantial amount of time is spent by most users using applications. For instance, Facebook might eat up more than 50% of some users time on the internet, which I think falls under the category of application. Or Youtube, Gmail, etc.
There may be a small minority or users who spend a lot of time reading documents (and I applaud them!), but most users are interacting with web applications.
Of the three examples you gave -- Facebook, YouTube, and Gmail -- you could make a good case that only Gmail is actually an application: it's a mail client that runs in the browser. YouTube is arguably almost as document-centric than Hacker News is; it's simply that the documents in question are built around embedded videos and their comments. Facebook is somewhere in the middle. It's accreted application-like qualities over the years, but at its core it's assembling a list of text and image items -- i.e., documents -- into a master timeline.
I'd submit that an awful lot of web sites that people spend time on have been made very JS-heavy and "application-y" despite being fundamentally document-driven. In part I'm sure this is due to the rise of native mobile applications -- have your server just use a JSON API and make your "web page" a JavaScript application that talks to it the same way your iOS and Android apps do. That development model has become the hammer web developers are using to hit an awful lot of things that maybe really aren't that nail-like.
I definitely spend more time using applications, and for the general population I'd bet even more. Webapps are what people are flocking too and that's where the industry is heading. Depending on your definition of application, arguably reddit, gmail, youtube, Stack Exchange, and Facebook are all webapps.
I'd argue that forum sites are primarily document based.
We've managed to emulate the functionality of a 1990s (or 80s!) dial up BBS and scale it up 100x (now instead of a thread having 200 replies it may have 20k replies), at and we are only needing a few thousand times the bandwidth and CPU power to do it!
It's the same problem XML has. It's bloated and unreadable for a human. YAML is much better in that regard, and I wonder if one could build a document language with a syntax that resemble json.
Have you ever opened the html content of any common webpage ? It's insane, in size and indenting, it's impossible to make sense of it, it would make much more sense to have an open binary format and let developers deal with it. HTML has way too many attribute that stacked on each others. People will defend its openness, but I pity the guys who write html parser for internet browsers.
HTML thrived because its openness allowed to bypass microsoft and its closed solutions, but other than that...
They are all "done" in that it is unlikely that anything will replace them any time soon. We don't event have, AFAICT, anything on the horizon. But there's a reason for that, and that is that the HTML/JS/CSS stack is the "virtual machine" or "assembly language" of UI development, and as such, we can't any more say they suck than does programming in assembly language. Assembly language is the "given" - unless you build your own CPU. This stack is likewise the "given" at the moment, and developers build an amazing array of tool, services, and billion dollar companies on this VM. Nobody controls this VM, so nobody can engage in rent-seeking behaviour. This has the pleasant effect also that most libraries built on top of are also open-source, and we end up with a very Darwinian landscape. We are now in the Cambrian Explosion, and the body plans that evolve must, by that way of thinking, be the best adapted for their environment.
HTML has many areas to improve still -- for example HTML-next can make it easier to do hypertext markup to a list of articles, including article title, author, date, contact links to social sites, and some summary text.
(Currently this is accomplished by munging the tags for cite, article, author, and jumping through some small hoops for microformats.)
Different people have different problems. For a web dev HTTP is "basically OK" as author says, but for a network engineer it is very much not (to the point that 2.0 was created to be completely different). I personally don't see how some new html/js/css dialect could efficiently solve the problems for everyone out there. How do you make both CoffeeScript and Dart user happy with a single syntax? I prefer to have a bunch of specialized high-level tools to choose from depending on a situation, than forcing them all into some one-size-fits-all mishmash (which almost always fails)
Joking about how html6 should be p,a,li,h,span only I googled it. And some people are pretty serious about a massive future version http://www.html6.io/
As long as there are very common things that you can only do with JavaScript, HTML is not done. With declarative syntax the browser can be so much faster.
He's not saying "HTML is done" as in "over" or "not to be used". He seems to mean something along the lines of "feature complete" and suggests further efforts focus on parts of the web that are lacking (JavaScript, DOM, CSS).
There needs to come a point where we let html and javascript exist for static linked documents. And build something better for our applications. Java and Silverlight have failed spectacularly at this so that future does seem quite bleak. There is still some hope with chrome plugins I think.
With CSS, the concept of differentiated HTML tags basically became obsolete. The purpose of HTML now is just to break apart and identify the content fields in an XML format. The only tags I really use in the HTML body are div and a - and I only use a because I can't add a href attribute into a div. Some people have tried to argue against this way of doing things ("divitus") but as far as I can tell their criticisms are pedantic, not practical. If some one has a good practical argument for specialized HTML tag names, I'd love to hear it.
The argument against this approach is that it's not always humans accessing web pages. And even if it is humans, sometimes they need computer assistance to interpret the content.
http://en.wikipedia.org/wiki/Semantic_HTML
As the article says, this is equivalently achieved by naming div classes and IDs (or some other attribute like itemprop a la schema.org). Also I'd say a completely style-free HTML scheme with open-ended semantic tag names (XML) styled by CSS is equivalent. The point is HTML doesn't serve a useful styling purpose.
I don't have a strong opinion on whether browsers should provide default styling, as it's trivial to override (although many web pages do rely on it). I agree that HTML tag names don't serve a very useful styling purpose, but they provide a useful structural purpose that cannot be easily replaced by using open-ended tag names or classnames. Custom Elements (http://w3c.github.io/webcomponents/spec/custom/) are in the process of being implemented, but I don't think that's an argument for throwing out the standard, structural elements that provide a common API for interpreting document structure.
I'd be all for a free, semantic naming scheme - which we basically already have with the exception you mentioned; it's discouraged, but you could absolutely make documents that way today.
I think overall it's a good thing to have certain tags that are associated with default behavior. We could weed out some unneeded ones aggressively, but overall I think it's okay to be able to write a basic CSS-less HTML page that is not a formless mass by default. This mechanism also has traditionally benefited accessibility agents.
So, it basically comes down to the question of whether it's time to remove the default rendering properties of tags. What we're left with then is decisions about the special attributes, as you mentioned. Some of these we could get rid of, too, and some could be made more general. We have painted ourselves a bit into a corner with the href attribute specifically. If we didn't sometimes have to use it for completely different things, it would be totally fine to declare every tag having an href attribute to have link-like behavior.
> If some one has a good practical argument for specialized HTML tag names, I'd love to hear it
It can matter in ways for SEO. Having an <h1> helps the robots figure out what your page is called; using <link>s can help explain the organization of your pages; having a <nav> can help influence what your sitelinks[1] will be (if you're enough of a baller to be getting them).
With the browser everyone is stuck with one universe. The only thing that changes are front end frameworks which offer some flexibility. Still, if html sucks we're stuck with it. If you hate html or javascript then you hate the entire front end. You exist outside of that universe because Nothing can change it. End of story.
I don't know how it could be done while keeping things secure, but it would be awesome if the browser universe was as flexible as the backend. If I could swap between html and any other kind of media based declarative language as easily as I can swap between python and ruby on the backend, it would change the face of frontend development and make it more accessible. In fact what if I wanted to develop my own language that interfaces with the rendering engine? The browser should permit that, because the Web is too broad to be dominated by a single language(HTML).
I think this should be the next step.