5 ms·

I agreed with you until you mentioned that the problem stemmed from people want[ing] to author documents (not apps) that are more complicated..., thus implying

by oliv__ 9y ago

I agreed with you until you mentioned that the problem stemmed from people want[ing] to author documents (not apps) that are more complicated..., thus implying that to make "pretty, fancy" web pages you need to complicate the process of creation: I totally disagree with that premise and think that it's entirely possible to create complex looking and behaving web pages without complex code or processes. However, for the sake of convenience (mostly), people have accepted the use of 15 different toolkits as the normal prerequisite to creating websites. Why add a one liner JS script in the head when you can npm install it, etc... Writing html and css like the old days is just as possible today as it was back then, and you now even have better tools to do so (Html 5, CSS 3). It's just a matter of actively choosing to do so.

jasode 9y ago
>, thus implying that to make "pretty, fancy" web pages you need to complicate the process of creation: [...], people have accepted the use of 15 different toolkits I wasn't implying that nor endorsing the use of toolkits to complicate process of creation. Yes, the vast majority of other comments in this thread have focused on overuse of "tools" and "frameworks" but my point was about his first frustration mentioned... the syntax itself becomes more complex to achieve richer (non app) web documents. Yes, the author mentioned "npm" and "react" but his first paragraphs were the exasperation of syntax TABLE "<TD><TR>" to CSS float. Staying with that theme, his subsequent paragraph emphasized the increase complexity of syntactic foundations before accounting for any toolkits and HTML generators: >My point is that the foundations are now sufficiently complicated enough on their own that it seems foolish to go add more optional complexity on top of it. I’ve kept my examples to the most basic of web implementations, and I haven’t touched on Javascript, animation, libraries, frameworks, pre-processors, package managers, automation, testing, or deployment. Whew. My point (which is based on the universal phenomenon of increasing complexity in other document layouts languages such LaTeX, Postscript language, etc,) is that the small and simple HTML example he cited isn't full-featured enough for modern web documents. I learned to code "plain HTML" by hand in 1990s but my beginner's knowledge of a few HTML tags in my brain isn't enough to replicate a Wikipedia page. If I decided to do it, it wouldn't matter if I used Dreamweaver, or used a Javascript static site generator, or typed HTML5+CSS3 by hand in Notepad ... the end result would still be a more complicated set of illegible syntax that continues the exasperation of <TABLE> to CSS flex float. For example, one desirable feature of a modern document (not app) layout would by dynamic resizing of page components depending on big desktop vs tiny smartphone screen. Every example out there to accomplish that (whether multi CSS files, or single CSS file dynamically changed by Javascript) will look more complicated than his "hello world" HTML. For any new feature "X", there's a minimum Kolmogorov complexity to accomplish it which makes the syntax grow in complexity. [1] https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity
graycat 9y ago
GOOD! Thanks, I needed that! For the Web pages for my startup, I just started with what I wanted the pages to look like. Then I calculated where everything should be. I looked at this as a special case of layout in word processing, e.g., D. Knuth's TeX. Then I turned to HTML and saw tables. Okay, the HTML table constructs are nice, sorry D., nicer than in TeX. So, I decided to use tables. I heard about CSS, but I saw only a little need for that. Eventually I wrote a few lines of CSS. So, sure, I discovered that I could have separate CSS files, but that seemed like a way to slow the upload to the users. So, I just copied the CSS into the HTML code of the relevant Web pages. For the rest, I saw how to use the Microsoft .NET ASP.NET to create and send the pages with the appropriate dynamic content, e.g., the results for the user. I heard about JavaScript but saw no big need for it and so far have written not even a single line of it. Eventually I discovered that somehow ASP.NET writes a little JavaScript for me, maybe having something to do with cursor positioning -- maybe convenient and nice but not really necessary. For the page designs, they are simple -- high contrast, large fonts, simple parts and pieces easy to understand right away, each page exactly 800 pixels wide, no icons, pull-downs, pop-ups, roll-overs, or overlays. There are some links, but each one is just a word in English. The pages all have both horizontal and vertical scroll bars and should still be usable in a window only 300 pixels wide. So, the pages, without change, should look good on everything from a smartphone to a high end desktop. The user just needs a Web browser up to date as of maybe 10 years ago -- so, there should be no compatiblity problems. And, there are no user IDs, passwords, logins, or use of cookies! JavaScript is optional! There really are some really simple, really successful Web pages on the Internet. So, sometimes simple can be good enough!!!

by oliv__ 9y ago

jasode 9y ago

>, thus implying that to make "pretty, fancy" web pages you need to complicate the process of creation: [...], people have accepted the use of 15 different toolkits I wasn't implying that nor endorsing the use of toolkits to complicate process of creation. Yes, the vast majority of other comments in this thread have focused on overuse of "tools" and "frameworks" but my point was about his first frustration mentioned... the syntax itself becomes more complex to achieve richer (non app) web documents. Yes, the author mentioned "npm" and "react" but his first paragraphs were the exasperation of syntax TABLE "<TD><TR>" to CSS float. Staying with that theme, his subsequent paragraph emphasized the increase complexity of syntactic foundations before accounting for any toolkits and HTML generators: >My point is that the foundations are now sufficiently complicated enough on their own that it seems foolish to go add more optional complexity on top of it. I’ve kept my examples to the most basic of web implementations, and I haven’t touched on Javascript, animation, libraries, frameworks, pre-processors, package managers, automation, testing, or deployment. Whew. My point (which is based on the universal phenomenon of increasing complexity in other document layouts languages such LaTeX, Postscript language, etc,) is that the small and simple HTML example he cited isn't full-featured enough for modern web documents. I learned to code "plain HTML" by hand in 1990s but my beginner's knowledge of a few HTML tags in my brain isn't enough to replicate a Wikipedia page. If I decided to do it, it wouldn't matter if I used Dreamweaver, or used a Javascript static site generator, or typed HTML5+CSS3 by hand in Notepad ... the end result would still be a more complicated set of illegible syntax that continues the exasperation of <TABLE> to CSS flex float. For example, one desirable feature of a modern document (not app) layout would by dynamic resizing of page components depending on big desktop vs tiny smartphone screen. Every example out there to accomplish that (whether multi CSS files, or single CSS file dynamically changed by Javascript) will look more complicated than his "hello world" HTML. For any new feature "X", there's a minimum Kolmogorov complexity to accomplish it which makes the syntax grow in complexity. [1] https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity

graycat 9y ago

GOOD! Thanks, I needed that! For the Web pages for my startup, I just started with what I wanted the pages to look like. Then I calculated where everything should be. I looked at this as a special case of layout in word processing, e.g., D. Knuth's TeX. Then I turned to HTML and saw tables. Okay, the HTML table constructs are nice, sorry D., nicer than in TeX. So, I decided to use tables. I heard about CSS, but I saw only a little need for that. Eventually I wrote a few lines of CSS. So, sure, I discovered that I could have separate CSS files, but that seemed like a way to slow the upload to the users. So, I just copied the CSS into the HTML code of the relevant Web pages. For the rest, I saw how to use the Microsoft .NET ASP.NET to create and send the pages with the appropriate dynamic content, e.g., the results for the user. I heard about JavaScript but saw no big need for it and so far have written not even a single line of it. Eventually I discovered that somehow ASP.NET writes a little JavaScript for me, maybe having something to do with cursor positioning -- maybe convenient and nice but not really necessary. For the page designs, they are simple -- high contrast, large fonts, simple parts and pieces easy to understand right away, each page exactly 800 pixels wide, no icons, pull-downs, pop-ups, roll-overs, or overlays. There are some links, but each one is just a word in English. The pages all have both horizontal and vertical scroll bars and should still be usable in a window only 300 pixels wide. So, the pages, without change, should look good on everything from a smartphone to a high end desktop. The user just needs a Web browser up to date as of maybe 10 years ago -- so, there should be no compatiblity problems. And, there are no user IDs, passwords, logins, or use of cookies! JavaScript is optional! There really are some really simple, really successful Web pages on the Internet. So, sometimes simple can be good enough!!!