4 ms·

Sorry, but web UI in general is an industrial dumpster fire. I'm of the strong opinion the "layout engine" should be on the server and that the browser should b

by tabtab 8y ago

Sorry, but web UI in general is an industrial dumpster fire. I'm of the strong opinion the "layout engine" should be on the server and that the browser should be a dumb x,y,z coordinate polygon plotter. The layout "math" should all be on a server. That way we could pick and choose layout/style engines that fit our domain and shop preferences: OOP, FP, set-theory, declarative, whatever you wish; NOT the viewpoint of Tim Berners-Lee, a drunk standards committee, or whoever. And it would mean we (developers & testers) are dealing with one engine instead of the myriad engines one is facing with a combinatorial explosion of browser brands and versions and OS settings. I've seen web UI "testing labs" with 20 PC's and Macs, and that wasn't enough. The only people who like the current state of affairs are UI/UX specialists; it keeps their wallets fat. Bicycle science was turned into rocket science, and the rockets often crash and burn.

goto11 8y ago
> I'm of the strong opinion the "layout engine" should be on the server and that the browser should be a dumb x,y,z coordinate polygon plotter. OK...so if you search for something on google you need to know the coordinates for every pixel in the rendering of the text you are looking for?
- tabtab 8y ago
  Who is "you" in your scenario? It would be similar to printer formatting languages. The printer driver translates a document into lines, vectors, and polygons, and sends those to the printer as page coordinates, except the page length is not limited to paper's limit. (We'd probably have to add event triggers on designated polygons to handle UI interaction.) The equivalent of the "printer driver" is the rendering engine on the server that takes your document or data and formats it using whatever formatting/layout engine YOU choose. The "input document" could be HTML even. We don't have to toss away HTML to use it. The difference is it doesn't have to be HTML. In some ways it would be closer to working with PDF documents, except it wouldn't be based on "paper" conventions. The width would typically be dictated (or requested) by a particular device (client), and the length would be whatever the renderer decides is needed, typically based on the content being rendered. Office workers love PDF because it's WYSIWYG. Browsers don't butcher their original vision. But, keep in mind the layout engine does not have to be WYSIWYG. The key point is your shop decides, NOT a standards committee. Layout engine FREEDOM! Hallelujah!
  - goto11 8y ago
    My question was, how would Google index pages and make them searchable in this system?
    - tabtab 8y ago
      My main focus is on "productivity" applications and CRUD, not so much documents. One doesn't typically index applications in a Google-esque way. I don't propose we throw out all the Web, but rather create (or extend?) standards for the things HTML/DOM/CSS do poorly. My apologies for not making the scope clearer. (Maybe that's why I got a "-1" score.) And, there may still be a markup language with text as text and other semantic info. The new standard may be able to use existing HTML tags, but add supplement attributes to control precise placement, and other features HTML/CSS lacks. By the way, Google can index PDF documents reasonably well, depending on how the PDF was created. This is evidence that precise control over layout doesn't necessarily prevent indexing and summarizing of text and content. I will also point out that many graphic designers are frustrated with CSS also because they envision a concept, but have a hard time getting web pages to do what precisely what they envision. It's why Flash was popular with them: the proverbial paint strokes wind up exactly where you put the brush down on the canvas. The artists may still want their work to adjust to the end-user screen size, but they want to control precisely HOW it adjusts: they want to write the size adjustment formulas themselves (or select among multiple API's), not rely on browser programmers and their variation on the CSS engine, which often differ across browser brands and versions.
      - goto11 8y ago
        Can't you already do everything you propose with the HTML canvas element then? But I can't see why you would want to render something as mundane as a CRUD UI through such a complex and slow scheme. For perhaps a game or some truly unconventional UI, it makes sense to use SVG or canvas to render it. But then you also want the rendering logic on the client (in JavaScript) because it would be far too slow to round-trip to the server for each mouse movement. Btw. Google can index PDF files only because the PDF format contain text in the form of character strings, not as drawings or bitmaps, as you suggest.
detaro 8y ago
So I need to wait for a network roundtrip for all tabs if I resize my browser? So sites can freely ignore my styling settings (it's bad enough already)? ...
- tabtab 8y ago
  I'll agree that resizing delay is probably a weakness. But I'd gladly trade that away for simplicity everywhere else. Also, because it wouldn't need gobs of CSS and JS for formatting, the re-render code (vectors) would not be that big and thus transfer relatively quickly. Remember, we are simplifying what the client needs to do and know. Excellent observation, by the way.
tabtab 8y ago
Re: web UI in general is an industrial dumpster fire... I should have qualified that. It has done a great job of sharing textual information. However, it provides convoluted, unnatural, and inconsistent control over format, graphics, and screen real-estate. We should not have extended it for tasks that need graphic-intensive control, but instead provide an alternative to the standard. At least explore alternatives as an industry.

by tabtab 8y ago

goto11 8y ago

> I'm of the strong opinion the "layout engine" should be on the server and that the browser should be a dumb x,y,z coordinate polygon plotter. OK...so if you search for something on google you need to know the coordinates for every pixel in the rendering of the text you are looking for?

tabtab 8y ago
Who is "you" in your scenario? It would be similar to printer formatting languages. The printer driver translates a document into lines, vectors, and polygons, and sends those to the printer as page coordinates, except the page length is not limited to paper's limit. (We'd probably have to add event triggers on designated polygons to handle UI interaction.) The equivalent of the "printer driver" is the rendering engine on the server that takes your document or data and formats it using whatever formatting/layout engine YOU choose. The "input document" could be HTML even. We don't have to toss away HTML to use it. The difference is it doesn't have to be HTML. In some ways it would be closer to working with PDF documents, except it wouldn't be based on "paper" conventions. The width would typically be dictated (or requested) by a particular device (client), and the length would be whatever the renderer decides is needed, typically based on the content being rendered. Office workers love PDF because it's WYSIWYG. Browsers don't butcher their original vision. But, keep in mind the layout engine does not have to be WYSIWYG. The key point is your shop decides, NOT a standards committee. Layout engine FREEDOM! Hallelujah!
- goto11 8y ago
  My question was, how would Google index pages and make them searchable in this system?
  - tabtab 8y ago
    My main focus is on "productivity" applications and CRUD, not so much documents. One doesn't typically index applications in a Google-esque way. I don't propose we throw out all the Web, but rather create (or extend?) standards for the things HTML/DOM/CSS do poorly. My apologies for not making the scope clearer. (Maybe that's why I got a "-1" score.) And, there may still be a markup language with text as text and other semantic info. The new standard may be able to use existing HTML tags, but add supplement attributes to control precise placement, and other features HTML/CSS lacks. By the way, Google can index PDF documents reasonably well, depending on how the PDF was created. This is evidence that precise control over layout doesn't necessarily prevent indexing and summarizing of text and content. I will also point out that many graphic designers are frustrated with CSS also because they envision a concept, but have a hard time getting web pages to do what precisely what they envision. It's why Flash was popular with them: the proverbial paint strokes wind up exactly where you put the brush down on the canvas. The artists may still want their work to adjust to the end-user screen size, but they want to control precisely HOW it adjusts: they want to write the size adjustment formulas themselves (or select among multiple API's), not rely on browser programmers and their variation on the CSS engine, which often differ across browser brands and versions.
    - goto11 8y ago
      Can't you already do everything you propose with the HTML canvas element then? But I can't see why you would want to render something as mundane as a CRUD UI through such a complex and slow scheme. For perhaps a game or some truly unconventional UI, it makes sense to use SVG or canvas to render it. But then you also want the rendering logic on the client (in JavaScript) because it would be far too slow to round-trip to the server for each mouse movement. Btw. Google can index PDF files only because the PDF format contain text in the form of character strings, not as drawings or bitmaps, as you suggest.

detaro 8y ago

So I need to wait for a network roundtrip for all tabs if I resize my browser? So sites can freely ignore my styling settings (it's bad enough already)? ...

tabtab 8y ago
I'll agree that resizing delay is probably a weakness. But I'd gladly trade that away for simplicity everywhere else. Also, because it wouldn't need gobs of CSS and JS for formatting, the re-render code (vectors) would not be that big and thus transfer relatively quickly. Remember, we are simplifying what the client needs to do and know. Excellent observation, by the way.

tabtab 8y ago

Re: web UI in general is an industrial dumpster fire... I should have qualified that. It has done a great job of sharing textual information. However, it provides convoluted, unnatural, and inconsistent control over format, graphics, and screen real-estate. We should not have extended it for tasks that need graphic-intensive control, but instead provide an alternative to the standard. At least explore alternatives as an industry.