7 ms·

I completely share the thoughts of the author of this article. However, I'm not sure if his proposed solution would work for most people. It's not that I want o

I completely share the thoughts of the author of this article. However, I'm not sure if his proposed solution would work for most people. It's not that I want or like to use npm etc. - I'm forced to use them as it's the new default way of working with almost anything useful in today's web development work. An alternative would be to start from scratch - and then reinventing all these things again, making another full circle. There could be another solution. A lot of today's complexity of the web stems from the fact that we're trying to design (web) apps using (HTML) documents. It's like building user interfaces in Word (without VBA). You can, but there are much better ways to do it. Why not to define a set of APIs for creating GUIs? Yes, I mean something like XUL which failed because nobody except Mozilla cared. Make it standard, make it easily themeable, and we can finally throw away this mess of ugly hacks used now to create intricate GUIs for which we have dedicated widgets on the desktop and which we have to reimplement on the web, with mixed results.

Nition 9y ago
Yeah, I agree with both you and the article. The biggest problem with website design seems to be that it's all layers on layers on a base that wasn't so great for design in the first place.
deleted 9y ago
[deleted]
mattmanser 9y ago
Crikey, even the 'reasons' are circular. People were saying that was the problem 10 years ago. Those exact words. Apps aren't docs. All you need to do now is propose a new language and call it XHTML. Or maybe make markup extensible and functional, we could call it, ummmmmm, XSLT.
- grndn 9y ago
  I came here to say the same thing. :) The fundamental problem is that you want one piece of (semantic) content to be presented on many different platforms with very different design approaches. The current approach uses if-then-else conditions in CSS, and when that fails, if-then-else conditions in JS, and when that fails, complex JS to transform the DOM. The XML/XSLT approach, although clunky, might actually be better in many cases.
  - skrebbel 9y ago
    You can't honestly propose XSLT as a programming language in a thread where half the comments are about how shitty JavaScript is. I mean, JavaScript isn't God's gift to mankind, but XSLT? I have a very hard time coming up with a worse programming language than XSLT, across all dimensions. INTERCAL, maybe? If XSLT had been proposed as a satirical esoteric programming language, people would've laughed and believed it. And probably made better tooling for it than the serious crowd ever did, just for the lulz.
    - hnzix 9y ago
      But XSLT is functional so that makes it awesome right? XSLT 2 was actually usable. 1 on the other hand... it really did feel like a twilight zone sick joke.
    - always_good 9y ago
      It's simply a way to brandish your nerd cred.
    - guitarbill 9y ago
      > I have a very hard time coming up with a worse programming language than XSLT What a straw-man argument. He clearly says "[t]he XML/XSLT approach", which is not advocating that XSLT is the best thing ever, but that we ought to consider that the people who developed XSLT had a similar problem to solve, thought hard about it, and came up with that. Many years later, it isn't out of this world that we could come up with a better solution. Arguably now there's more interest in such a solution than ever. For example, there are companies who have made generating PDFs for reports or bills their business model, because it's hard to do reliably with standard web tech. ePUB too? That would be all kinds of awesome. So let's not dismiss XSLT and simply go back to the dysfunctional way it's currently being done. That said, of course XML et al are clunky, old and too enterprise-y - by trying to cover every use-case ever or having big corporations pushing their use-cases during the spec design this tends to happen. This seems to be a problem with the W3C in general, but they have to get their money somehow, and standards that nobody will use don't help either. Somehow we still ended up with JSON for the data serialisation use-case, which is pretty good. So there's hope. (The irony of JSON being at least inspired by Javascript does not escape me.)
DanBC 9y ago
The other problem is we're doing this weird kludging an app to do something on the web even when we don't need to - even when we're just presenting text. I know people have different needs, and that reasonable people can make reasonable choices and end up in very different places. What I don't understand is how anyone could end up in a place where this kind of website is ok. Give me a pdf; give me plain html and css. https://fermatslibrary.com/s/shelling-out-the-origins-of-money https://fermatslibrary.com/s/shelling-out-the-origins-of-mon...
- Piskvorrr 9y ago
  Website, ha! There's a webpage pretending to be a programming IDE; even though it needs GBs of memory just for its overhead, it's hugely popular. shrug (Ditto anything else electron-ish)
BjoernKW 9y ago
I disagree with the often-heard premise that HTML is a somehow inferior tool for creating GUIs that we somehow ended up with despite better choices beings available. Yes, native GUI frameworks and widget toolkits like Swing, Qt, Cocoa and MFC have their place but it's precisely the nature and features of HTML (most notably: The link) that enabled most of the innovation we've seen on the web. If building web apps was just about recreating the desktop experience but on the web doing that with HTML indeed would be a fool's errand. However, web applications today are so much more than their desktop equivalents from the 80s and 90s both in terms of what's possible with them and as to how accessible they are to developers. Sure, developing a web app today is not as easy anymore as "View source", edit and see what happens but it's still a lot more accessible than developing desktop-style applications. In my opinion, instead of throwing the baby out with bathwater and replacing HTML with something else (which frankly and fortunately won't happen anyway because let's face it: HTML is here to stay for some time whether you like it or not) we should try and think about how to make web development easy and accessible again. I think tools like StackBlitz ( https://stackblitz.com/ https://stackblitz.com/ ) are good first steps in that direction because they allow you to quickly try out and prototype stuff without having to care about setup and tooling. What I'd love to see is the web equivalent of the C64 BASIC prompt, which provided you with an empty canvas to create something with right away.
- laythea 9y ago
  HTML is inferior than a technology that is purpose built. It was not originally designed to handle the job it does today. It is possible to create a much better user experience with eg. C# using some network code to talk to the server than trying to shoe horn an application over HTML just because it hides the low level complexities of E.g C#/C++ communicating with a server. This is a classic case of HTML/web apps are easier to produce (does that even make them inferior?) than custom built software, but it is more efficient to develop a web app, and therefore that is what business/industry has done.
  - BjoernKW 9y ago
    HTML is not inferior it's different. In the late 90s some people said the same about Java and Java applets in particular. The UX of those however often was significantly worse than that of roughly equivalent (but at that time less dynamic) web applications. Apart from the usual benefits like being able to easily link to and consume resources HTML affords you a great deal of flexibility. Desktop UIs for very good reasons both follow OS-specific style guides and if cross-platform capable also have to settle for the lowest common denominator. As for your last point: Absolutely. Being accessible and easy to create perhaps is the single most important feature of HTML.
TheAceOfHearts 9y ago
There aren't much better ways of doing it. At least with existing alternatives. Have you genuinely tried the alternatives? I think the web has a lot of shortcomings, but it's still pretty great. We have a set of APIs for creating GUIs. It's called the web platform. It's all standardized with multiple independent implementations, and easily themeable. You're forgetting the many different targets that the web platform has. How should different widgets look and behave when handling different input types and screen sizes? Trying to get vendors to agree on anything of this scale is like trying to herd cats.
usernam 9y ago
You're trying to conflate document design with UI design. By the writing of the author, he is clearly doing just fancy documents. He didn't even touch the problematic issues you normally face in web development. You can do pretty neat things with trivial html/css these days, where you needed quite a bit of JS just 5 years ago. Platform GUI toolkits are designed for controlling an interactive program from the start, a very different usage scenario. They were never designed to be documents to be read from top to bottom. Traditionally, GUI toolkit almost never included fancy text layout boxes just for text display. To give you an example, a simple text label to be used next to a button almost universally could be of a single font with the same style throughout. I wouldn't even consider this a limitation, because on toolkits with advanced theming (GTK/QT), this allowed for a very consistent layout across all programs, which is clearly a much better user experience for the user as opposed to styled individual applications. Somehow, this crucial bit of /actual/ usability /design/ was lost. The irony? Current GUI platform toolkits are actually copying the document model of web pages instead, so that your layout skill set can be more easily transferred across systems. So you can finally style your button's label to your hearth's content. XUL is probably the first example of this. As if "layout" was the major issue in desktop user interfaces (HINT: it's not). Now we have GUI toolkits which are basically web views that maybe call some native code. In my opinion: a huge failure in engineering and user experience.
- BigJono 9y ago
  I guess it really comes down to the trade-off between customization and familiarity. IME in any given company there's plenty of people going to bat for the former, and hardly anyone that cares about the latter. On the "sliding scale of giving a fuck" [0], there's usually plenty of graphics designers and managers whose job revolves around giving an '8' for customisation and branding, and most devs seem to consider usability at about a '5' relative to their other work, so they don't offer up a lot of resistance. [0] http://blog.capwatkins.com/the-sliding-scale-of-giving-a-fuck http://blog.capwatkins.com/the-sliding-scale-of-giving-a-fuc...
- taeric 9y ago
  I've had the feeling that modern gui toolkits copy the dom not due to any superiority, but because of the massive developer base it has.

Nition 9y ago

Yeah, I agree with both you and the article. The biggest problem with website design seems to be that it's all layers on layers on a base that wasn't so great for design in the first place.

deleted 9y ago

[deleted]

mattmanser 9y ago

Crikey, even the 'reasons' are circular. People were saying that was the problem 10 years ago. Those exact words. Apps aren't docs. All you need to do now is propose a new language and call it XHTML. Or maybe make markup extensible and functional, we could call it, ummmmmm, XSLT.

grndn 9y ago
I came here to say the same thing. :) The fundamental problem is that you want one piece of (semantic) content to be presented on many different platforms with very different design approaches. The current approach uses if-then-else conditions in CSS, and when that fails, if-then-else conditions in JS, and when that fails, complex JS to transform the DOM. The XML/XSLT approach, although clunky, might actually be better in many cases.
- skrebbel 9y ago
  You can't honestly propose XSLT as a programming language in a thread where half the comments are about how shitty JavaScript is. I mean, JavaScript isn't God's gift to mankind, but XSLT? I have a very hard time coming up with a worse programming language than XSLT, across all dimensions. INTERCAL, maybe? If XSLT had been proposed as a satirical esoteric programming language, people would've laughed and believed it. And probably made better tooling for it than the serious crowd ever did, just for the lulz.
  - hnzix 9y ago
    But XSLT is functional so that makes it awesome right? XSLT 2 was actually usable. 1 on the other hand... it really did feel like a twilight zone sick joke.
  - always_good 9y ago
    It's simply a way to brandish your nerd cred.
  - guitarbill 9y ago
    > I have a very hard time coming up with a worse programming language than XSLT What a straw-man argument. He clearly says "[t]he XML/XSLT approach", which is not advocating that XSLT is the best thing ever, but that we ought to consider that the people who developed XSLT had a similar problem to solve, thought hard about it, and came up with that. Many years later, it isn't out of this world that we could come up with a better solution. Arguably now there's more interest in such a solution than ever. For example, there are companies who have made generating PDFs for reports or bills their business model, because it's hard to do reliably with standard web tech. ePUB too? That would be all kinds of awesome. So let's not dismiss XSLT and simply go back to the dysfunctional way it's currently being done. That said, of course XML et al are clunky, old and too enterprise-y - by trying to cover every use-case ever or having big corporations pushing their use-cases during the spec design this tends to happen. This seems to be a problem with the W3C in general, but they have to get their money somehow, and standards that nobody will use don't help either. Somehow we still ended up with JSON for the data serialisation use-case, which is pretty good. So there's hope. (The irony of JSON being at least inspired by Javascript does not escape me.)

DanBC 9y ago

The other problem is we're doing this weird kludging an app to do something on the web even when we don't need to - even when we're just presenting text. I know people have different needs, and that reasonable people can make reasonable choices and end up in very different places. What I don't understand is how anyone could end up in a place where this kind of website is ok. Give me a pdf; give me plain html and css. https://fermatslibrary.com/s/shelling-out-the-origins-of-money https://fermatslibrary.com/s/shelling-out-the-origins-of-mon...

Piskvorrr 9y ago
Website, ha! There's a webpage pretending to be a programming IDE; even though it needs GBs of memory just for its overhead, it's hugely popular. shrug (Ditto anything else electron-ish)

BjoernKW 9y ago

I disagree with the often-heard premise that HTML is a somehow inferior tool for creating GUIs that we somehow ended up with despite better choices beings available. Yes, native GUI frameworks and widget toolkits like Swing, Qt, Cocoa and MFC have their place but it's precisely the nature and features of HTML (most notably: The link) that enabled most of the innovation we've seen on the web. If building web apps was just about recreating the desktop experience but on the web doing that with HTML indeed would be a fool's errand. However, web applications today are so much more than their desktop equivalents from the 80s and 90s both in terms of what's possible with them and as to how accessible they are to developers. Sure, developing a web app today is not as easy anymore as "View source", edit and see what happens but it's still a lot more accessible than developing desktop-style applications. In my opinion, instead of throwing the baby out with bathwater and replacing HTML with something else (which frankly and fortunately won't happen anyway because let's face it: HTML is here to stay for some time whether you like it or not) we should try and think about how to make web development easy and accessible again. I think tools like StackBlitz ( https://stackblitz.com/ https://stackblitz.com/ ) are good first steps in that direction because they allow you to quickly try out and prototype stuff without having to care about setup and tooling. What I'd love to see is the web equivalent of the C64 BASIC prompt, which provided you with an empty canvas to create something with right away.

laythea 9y ago
HTML is inferior than a technology that is purpose built. It was not originally designed to handle the job it does today. It is possible to create a much better user experience with eg. C# using some network code to talk to the server than trying to shoe horn an application over HTML just because it hides the low level complexities of E.g C#/C++ communicating with a server. This is a classic case of HTML/web apps are easier to produce (does that even make them inferior?) than custom built software, but it is more efficient to develop a web app, and therefore that is what business/industry has done.
- BjoernKW 9y ago
  HTML is not inferior it's different. In the late 90s some people said the same about Java and Java applets in particular. The UX of those however often was significantly worse than that of roughly equivalent (but at that time less dynamic) web applications. Apart from the usual benefits like being able to easily link to and consume resources HTML affords you a great deal of flexibility. Desktop UIs for very good reasons both follow OS-specific style guides and if cross-platform capable also have to settle for the lowest common denominator. As for your last point: Absolutely. Being accessible and easy to create perhaps is the single most important feature of HTML.

TheAceOfHearts 9y ago

There aren't much better ways of doing it. At least with existing alternatives. Have you genuinely tried the alternatives? I think the web has a lot of shortcomings, but it's still pretty great. We have a set of APIs for creating GUIs. It's called the web platform. It's all standardized with multiple independent implementations, and easily themeable. You're forgetting the many different targets that the web platform has. How should different widgets look and behave when handling different input types and screen sizes? Trying to get vendors to agree on anything of this scale is like trying to herd cats.

usernam 9y ago

You're trying to conflate document design with UI design. By the writing of the author, he is clearly doing just fancy documents. He didn't even touch the problematic issues you normally face in web development. You can do pretty neat things with trivial html/css these days, where you needed quite a bit of JS just 5 years ago. Platform GUI toolkits are designed for controlling an interactive program from the start, a very different usage scenario. They were never designed to be documents to be read from top to bottom. Traditionally, GUI toolkit almost never included fancy text layout boxes just for text display. To give you an example, a simple text label to be used next to a button almost universally could be of a single font with the same style throughout. I wouldn't even consider this a limitation, because on toolkits with advanced theming (GTK/QT), this allowed for a very consistent layout across all programs, which is clearly a much better user experience for the user as opposed to styled individual applications. Somehow, this crucial bit of /actual/ usability /design/ was lost. The irony? Current GUI platform toolkits are actually copying the document model of web pages instead, so that your layout skill set can be more easily transferred across systems. So you can finally style your button's label to your hearth's content. XUL is probably the first example of this. As if "layout" was the major issue in desktop user interfaces (HINT: it's not). Now we have GUI toolkits which are basically web views that maybe call some native code. In my opinion: a huge failure in engineering and user experience.

BigJono 9y ago
I guess it really comes down to the trade-off between customization and familiarity. IME in any given company there's plenty of people going to bat for the former, and hardly anyone that cares about the latter. On the "sliding scale of giving a fuck" [0], there's usually plenty of graphics designers and managers whose job revolves around giving an '8' for customisation and branding, and most devs seem to consider usability at about a '5' relative to their other work, so they don't offer up a lot of resistance. [0] http://blog.capwatkins.com/the-sliding-scale-of-giving-a-fuck http://blog.capwatkins.com/the-sliding-scale-of-giving-a-fuc...
taeric 9y ago
I've had the feeling that modern gui toolkits copy the dom not due to any superiority, but because of the massive developer base it has.