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.
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.
> "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.)
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.
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.
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.
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.
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 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.
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.
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 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).
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.
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.
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.
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.
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.
[+] [-] crimsonalucard|10 years ago|reply
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.
[+] [-] wz1000|10 years ago|reply
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.
See also: https://www.destroyallsoftware.com/talks/the-birth-and-death...
[+] [-] tnorgaard|10 years ago|reply
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.
[1] See Effective Java Puzzlers. [2] Project Jigsaw might change that.
[+] [-] MCRed|10 years ago|reply
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.
If you're interested in this, follow: https://github.com/nirvana/nirvana or @NirvanaCore on twitter. Or if email is your thing, check out http://nirvana.io
(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.)
[+] [-] isaiahg|10 years ago|reply
[+] [-] vatotemking|10 years ago|reply
[+] [-] pg_is_a_butt|10 years ago|reply
[deleted]
[+] [-] founderling|10 years ago|reply
You can make all kinds of magic happen in a simple text file. In an intuitive way. Want to tell something? Just write it:
Want to show an image? Just a few keystrokes: Want to style it? Here we go: Want to change it programmatically? Easy: Deployment? Instantly. Developer tools needed? A text editor. Compatibility? Runs everywhere. Speed? Im often shocked, how fast stuff runs these days.I think we created a paradise. And I enjoy "living" in it every day.
[+] [-] wz1000|10 years ago|reply
For example, in ClojureScript:
becomes All in one nice, consistent programming language. Code is data and data is code. XML/HTML is just a watered down Lisp with less parenthesis and more superfluous syntax and text.[+] [-] afarrell|10 years ago|reply
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.
[+] [-] gbersac|10 years ago|reply
CSS is one of the reason I hate web developement (javascript being so tolerant to error is another one).
[+] [-] kayamon|10 years ago|reply
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.
[+] [-] copperx|10 years ago|reply
[+] [-] mattmanser|10 years ago|reply
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.
[+] [-] crimsonalucard|10 years ago|reply
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.
[+] [-] Udo|10 years ago|reply
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
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. 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.
[+] [-] jnbiche|10 years ago|reply
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.
[+] [-] hliyan|10 years ago|reply
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.
[+] [-] shakethemonkey|10 years ago|reply
[+] [-] at-fates-hands|10 years ago|reply
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?
[+] [-] peterashford|10 years ago|reply
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.
[+] [-] javajosh|10 years ago|reply
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.
[+] [-] leoc|10 years ago|reply
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.
[+] [-] intrasight|10 years ago|reply
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.
I do agree with your other points.
[+] [-] misuba|10 years ago|reply
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.)
[+] [-] nly|10 years ago|reply
Eh? What stops you from publishing a free app with ads?
[+] [-] pourhhd|10 years ago|reply
[+] [-] forrest92|10 years ago|reply
[+] [-] harigov|10 years ago|reply
[+] [-] gbersac|10 years ago|reply
qt >>> html/css
But javascript made event handling easier in web than in qt (which event handling is a little bit tricky).
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] serve_yay|10 years ago|reply
[+] [-] nkozyra|10 years ago|reply
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.
[+] [-] bradhe|10 years ago|reply
[+] [-] krapp|10 years ago|reply
Yet if I were to call coffeescript an overly complex javascript framework, people would probably strenuously disagree. But that is what it amounts to.
[+] [-] isaiahg|10 years ago|reply
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.
[+] [-] jdub|10 years ago|reply
Do you spend more of your time on the web using applications than you do reading documents?
I kind of doubt it. Maybe. But probably not.
It may be that you spend more time making web applications than documents. That's understandable.
But is the web primarily for you as a developer, or as a user?
[+] [-] jokoon|10 years ago|reply
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...
[+] [-] intrasight|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] jph|10 years ago|reply
(Currently this is accomplished by munging the tags for cite, article, author, and jumping through some small hoops for microformats.)
[+] [-] ivanhoe|10 years ago|reply
[+] [-] agumonkey|10 years ago|reply
[+] [-] bpicolo|10 years ago|reply
[+] [-] wtetzner|10 years ago|reply
[+] [-] cbr|10 years ago|reply
[+] [-] pacomerh|10 years ago|reply
[+] [-] Kenji|10 years ago|reply
[+] [-] PretzelFisch|10 years ago|reply
[+] [-] briholt|10 years ago|reply