4 ms·
I've often had this thought. But I keep coming back to this idea: HTML and CSS are actually a really nice way to describe an interface, for a few reasons: 1. R
by jarrett 13y ago
I've often had this thought. But I keep coming back to this idea: HTML and CSS are actually a really nice way to describe an interface, for a few reasons:
1. Reusable styles plus case-by-case overrides--very important in a world where graphic design is so central to what we do. To me, CSS beats your typical GUI builder any day.
2. Flow. HTML/CSS have a sophisticated model for automatically flowing text and sizing elements to fit. The content below gets pushed down by the content above, automatically and as much as necessary. Other GUI models have similar things, but I prefer the web's take on it.
3. URLs. These are a beautiful concept. A string that uniquely identifies a certain resource, be that resource a document, a certain screen in an interactive interface, a record, whatever.
Now, you might say you could build all these things into your ideal client. But if you did, what would you have? Seems to me you'd have a web browser.
I do agree with your argument about the network protocols, though. We started with TCP, then we put HTTP on top of it to transfer documents. Then we started sending lots of HTTP requests back and forth for interactivity, and even having the client poll the server as a hack for pushing. Like you said, it started to look like TCP on top of HTTP on top of TCP.
But now we have websockets, which in my opinion is a pretty lean and mean protocol on top of TCP. I like to think of it as regular TCP with a few conveniences like negotiation. Granted, it is not in use everywhere, and I still use the TCP-on-top-of-HTTP-on-top-of-TCP approach for most of my stuff, mostly out of technical conservatism. But I think it'll get there.
As to the statelessness of regular HTTP, it still has its place. Sometimes stateless connections can be very beneficial. Imagine a site like Wikipedia. You wouldn't want everyone who's currently reading a page to have an open socket. With HTTP, you open the socket, you transfer the document, and you close the socket. Done. It's unfortunate that we have to open a new socket for every image, CSS file, etc., but I also expect that situation to improve over time.
- yk 13y agoActually I agree, we could do a lot worse than HTML,CSS and JS on the client, and more general I think a lot of the development of the Internet are really fortunate accidents. But there are a lot of potentially useful services, which do not need a GUI, for example a rsync client. Or which would profit from a different metaphor than the newspaper with moving pictures metaphor HTML imposes, for example games.