6 ms·

While I certainly agree that there is tons of room for improvement with HTML/CSS/JS, I get confused when people start discussing it in such hyperbolic terms. It

While I certainly agree that there is tons of room for improvement with HTML/CSS/JS, I get confused when people start discussing it in such hyperbolic terms. It's not that bad. Most data on the internet fits really nicely into the document metaphor.

knieveltech 15y ago
Normally I immediately bridle when someone offers criticism without including proposals for improvement[1] but in this case it really is that bad. It really, really is. And while I would be willing to agree provisionally that most data (by volume of unique URLS) on the web does fit the document metaphor, if page views is your metric I'm not at all convinced. For example, is it logical to even attempt to reason about a Facebook wall containing recent updates from $n individuals in terms of authorship? Is this even relevant information given the entire contents of the page will have changed in 12 hours? The document metaphor made perfect sense 15 years ago but it breaks down quickly in the face anything dynamic, as is evidenced by the need for any credible web developer to have a minimum of 7 largely unrelated technologies[2] committed to memory to do their job effectively. Markup 15 layers deep? 2000+ lines of code to tell the browser how to render a website? Vendor-specific dynamic rendering engines to sidestep the limitations of native web languages? Surely this is not what success looks like? [1] Unfortunately I have no idea how to fix this mess. [2] HTML, CSS, JavaScript, a JS Framework (typically jQuery), at least one back-end language, SQL or similar and API stuff (SOAP, JSON, etc).
- fooandbarify 15y ago
  Hmmm. I appreciate the way you laid out your argument, I'm not sure I understand it entirely though. I agree that the concept of authorship is not very logical in the context of your example, but I don't know of any HTML spec which requires defining an author for each document? I think my point was that it's pretty easy to mark up data in a semantic-enough way using the current tools. A wall post doesn't need to be a document of its own, it can be an item in a list of wall posts that make up part of a bigger page. I agree that "document" is sort of a silly metaphor for that use case, but that doesn't make HTML any less useful. We could use XML, but that would basically be the same thing. We could use JSON, but again... it's just another way of drawing the same relationships. I suspect that I've completely missed your point though, in which case I apologize and please be patient with me! With regard to the rest of your comment (7 unrelated technologies, deep layers of markup, huge numbers of LOC, etc) I agree, but as you said - how could it be fixed? The reality is that the web performs a complicated function. It would be nice to abstract the nuts and bolts behind it away cleanly, and I don't think it's unreasonable to believe that could happen in our lifetime, but it's also not unreasonable to expect that developing for a complicated platform will be complicated.
- einhverfr 15y ago
  I think it is this unrelated technologies bit that is driving things like NoSQL. Interestingly, with LedgerSMB, you have to know: HTML, CSS, Javascript, Tempalte Toolkit, Perl, SQL (including PL/PGSQL), LaTeX That's only 7..... When we standardize on an AJAX API framework, I guess that will mean 8. However LaTeX is only required by some specialists (customizing printed check and PDF invoice templates), and a lot of the current approach is to hide the AJAX stuff inside TT widgets, meaning no more than 7 for most developers. And since the LaTeX stuff is a specialty (customizing higher-end printed templates and printed checks), that leaves only 6 for most developers. And since the SQL stuff can be easily handed off to others in the community (because the db API is defined through SQL, mostly through a procedural interface), it means 5. The perl is thin glue, and probably should hardly count (unless you are engineering the framework). A few master them all. Most work with the framework we provide. So here you have to know 4 well to do basic customizations, but 7 well to do the most advanced. Works pretty well, actually.

knieveltech 15y ago

Normally I immediately bridle when someone offers criticism without including proposals for improvement[1] but in this case it really is that bad. It really, really is. And while I would be willing to agree provisionally that most data (by volume of unique URLS) on the web does fit the document metaphor, if page views is your metric I'm not at all convinced. For example, is it logical to even attempt to reason about a Facebook wall containing recent updates from $n individuals in terms of authorship? Is this even relevant information given the entire contents of the page will have changed in 12 hours? The document metaphor made perfect sense 15 years ago but it breaks down quickly in the face anything dynamic, as is evidenced by the need for any credible web developer to have a minimum of 7 largely unrelated technologies[2] committed to memory to do their job effectively. Markup 15 layers deep? 2000+ lines of code to tell the browser how to render a website? Vendor-specific dynamic rendering engines to sidestep the limitations of native web languages? Surely this is not what success looks like? [1] Unfortunately I have no idea how to fix this mess. [2] HTML, CSS, JavaScript, a JS Framework (typically jQuery), at least one back-end language, SQL or similar and API stuff (SOAP, JSON, etc).

fooandbarify 15y ago
Hmmm. I appreciate the way you laid out your argument, I'm not sure I understand it entirely though. I agree that the concept of authorship is not very logical in the context of your example, but I don't know of any HTML spec which requires defining an author for each document? I think my point was that it's pretty easy to mark up data in a semantic-enough way using the current tools. A wall post doesn't need to be a document of its own, it can be an item in a list of wall posts that make up part of a bigger page. I agree that "document" is sort of a silly metaphor for that use case, but that doesn't make HTML any less useful. We could use XML, but that would basically be the same thing. We could use JSON, but again... it's just another way of drawing the same relationships. I suspect that I've completely missed your point though, in which case I apologize and please be patient with me! With regard to the rest of your comment (7 unrelated technologies, deep layers of markup, huge numbers of LOC, etc) I agree, but as you said - how could it be fixed? The reality is that the web performs a complicated function. It would be nice to abstract the nuts and bolts behind it away cleanly, and I don't think it's unreasonable to believe that could happen in our lifetime, but it's also not unreasonable to expect that developing for a complicated platform will be complicated.
einhverfr 15y ago
I think it is this unrelated technologies bit that is driving things like NoSQL. Interestingly, with LedgerSMB, you have to know: HTML, CSS, Javascript, Tempalte Toolkit, Perl, SQL (including PL/PGSQL), LaTeX That's only 7..... When we standardize on an AJAX API framework, I guess that will mean 8. However LaTeX is only required by some specialists (customizing printed check and PDF invoice templates), and a lot of the current approach is to hide the AJAX stuff inside TT widgets, meaning no more than 7 for most developers. And since the LaTeX stuff is a specialty (customizing higher-end printed templates and printed checks), that leaves only 6 for most developers. And since the SQL stuff can be easily handed off to others in the community (because the db API is defined through SQL, mostly through a procedural interface), it means 5. The perl is thin glue, and probably should hardly count (unless you are engineering the framework). A few master them all. Most work with the framework we provide. So here you have to know 4 well to do basic customizations, but 7 well to do the most advanced. Works pretty well, actually.