4 ms·

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I loo

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we could talk declaratively at a high level about the kinds of interfaces we want to render and where the data lives. Hopefully I'm wrong and the magic is buried under some Elm tree or a React library or something. Something something get off my lawn...

metadaemon 3y ago
It's a very complex problem to solve and I think a lot of people need to accept that. There will never be a simple solution with a low learning curve that's actually performant for non-trivial applications without a fundamental shift in browser technology.
- myaccountonhn 3y ago
  I think elm showed that it is possible to build a solution with a low learning curve. Sadly elm hasn't really taken off but as far as frontend goes... it is just so simple together with elm-ui.
- rglover 3y ago
  There is. I was frustrated by all of the chaos and built a solution [1]. Not too far off from an RC1 and then a 1.0 (which is being done slowly so I can freeze APIs and avoid the typical JS rug pulls). [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
agloe_dreams 3y ago
The problem is CSS. CSS is so freaking complex with millions of possible outcomes. https://www.w3.org/Style/CSS/all-properties.en.html https://www.w3.org/Style/CSS/all-properties.en.html Building a declarative UI that compiles to that sort of declaration means building that from scratch. We do currently work like that though. React isn't that far and web components built into an element of that.
- deergomoo 3y ago
  I wonder how different things would look if you could opt out of the cascade for CSS. It's great for documents but signifcantly less so for "apps", where the widget is the widget and by-and-large should not be affected by the other bits of interface it's inside. I think that's why frameworks like Tailwind etc. have got so popular -- they're much closer to the traditional native application way of styling. You set all the appearance details on the component and then you reuse the component, styles and all.
11235813213455 3y ago
that's how it is if you're using high-level react components or web components, it's just an XML-like layout, user-friendly. What the article is showing is their low-level implementation, but as a consumer you can just import and use them
mattlondon 3y ago
I think you are talking about web components. Even in the old desktop world someone had to build the button widget (and all the others) that let you just throw stuff together in MFC or Swing or whatever. Same today - someone has to build the web components in order for us to declaratively use them as high-level Lego. Trouble is, there is no real high-level "general purpose" library of components beyond the core HTML elements (they'll get you a long way but there are notable things missing that we expect from apps, e.g. toolbars, menus, tab strips etc), and then the probably reason for their not being a general high-level library is that everyone wants something special for their websites (because historically websites have always allowed a lot of design flexibility, way more than your typical win32 app ever did for example). I have several times really wished to have some solid "desktop style" components to use for things like menus, tool bars etc. That would make prototypes in electron/neutralino/tauri way way way faster to do.
- jacobsimon 3y ago
  There are certainly lots of great component libraries out there for various frameworks that help with this, but I agree with the parent comment that it's still not the kind of progress we should have had by this point. I think it's unfortunate that we have to stick to HTML/CSS as the foundation for everything to maintain compatibility and accessibility, but that's how the web works I suppose. If we were to design the web from the ground up today based on what people use it for, it would look pretty different I think.
  - megaman821 3y ago
    I am not sure it would look that different. It would be more consistent with terminology. Things like SwiftUI and Jetpack Compose look a lot more like HTML and CSS than their predecessors, and there is nothing forcing them to go in that direction. The biggest difference between other major platforms and the web, is that the web doesn't come with a default UI framework. The primitives for building UI on the web are pretty good though.
    - jacobsimon 3y ago
ecmascript 3y ago
I do front end stuff for a living and have been in the javascript space for several years. I do other backend development as well and I can't see why people think like you honestly. Most other GUI libraries is in a much worse state than front end web dev. That is probably also the reason why people use front end tech to make native apps today, because you can customize and make apps much faster than in basically any other way. I think front end gui development is very easy today and very powerful as well and we have progressed a lot. Making stuff with web components isn't event that hard and if you want you can just use one of the many available syntax sugar libraries that exist like Lit and others.
- Devasta 3y ago
  Devs use web frontend tech because it is installed on every machine, will never have anything less than the full backing of the browser devs for the next hundred years, and gets around corporate filters. No need to deal with IT security losers to get your app installed, no need to get ports opened, just everything down port 443 until the end of time. INTERCAL could win with that feature set.
  - ecmascript 3y ago
    If that is the case, why are people writing desktop apps with Electron / other web tech?
  - paulddraper 3y ago
    I think you missed the point. > why people use front end tech to make native apps today Even when you have to deal with IT security losers to get apps installed, implementing it w/ web tech is extremely popular. E.g. the #1 IDE by popularity [1] is a desktop app developed with web tech. (And yes, it was later ported to browsers, but it didn't start there.) [1] https://survey.stackoverflow.co/2022#section-most-popular-technologies-integrated-development-environment https://survey.stackoverflow.co/2022#section-most-popular-te...
- mardifoufs 3y ago
  Exactly. I'm starting to understand the push for web UI now that I've started to use qt for a small GUI. I'm sure qt is good for some type of apps. But for my smaller scale project where the graphic interface is not where we want to spend most of our dev time, I'd rather take javascript/react at this point.
shortrounddev2 3y ago
I'm less cynical about web development. Lots of software engineers bemoan writing web interfaces and pine for the days of native GUI development, but web won because it's extremely accessible to people without CS degrees. There just isn't a good native framework that's as forgiving and easy to learn as HTML, JS, and CSS. I think gtk is pretty decent though
- yCombLinks 3y ago
  Hard disagree, web won because of the deploy story. Users don't have to install anything. Html and css is a terrible API for app layout, because it wasn't designed for that
  - josephg 3y ago
    Given how important the web’s deploy story has been for its success, I’m surprised we haven’t seen more zero deployment application platforms / prototypes appear. Docker is an attempt at something similar on the server, but docker images are huge and docker still separates its docker fetch and docker run steps. Maybe part of the problem is that the web is the only platform where people obsess over the size of deployed artefacts. Websites are certainly getting bigger, but they’re still an order of magnitude smaller than the average snap package or iOS app.
  - shortrounddev2 3y ago
    > Html and css is a terrible API for app layout, because it wasn't designed for that And yet it's so easy and forgiving that millions of 13 year olds learned it for their myspace and tumblr pages over the last 15 or so years. Somehow, despite all the CS graduates and 20 year software engineering veterans bemoaning it, more and more people learn HTML, CSS, and Javascript every day while the number of people learning native GUI development struggles to keep up or outright fades away. I truly believe that most software engineers don't understand what ergonomic software or programming languages look like. They're blinded by their expertise
    - yCombLinks 3y ago
paulddraper 3y ago
Do elaborate on what UI paradigm web browsers ought to use from mid-90s GUI development.
- usea 3y ago
  They said things should be better than they are, not that we should go back to the 90s or even use it as inspiration.
  - paulddraper 3y ago
    Oh well, yes, it would be nice for things to be better than they are. (^ feel free to copy-paste that to any HN thread)
    - aegypti 3y ago
      It would be nice for conversations to be kinder, less snarky, and more curious. Could even edit out any swipes and internet-style cross examination as well.
btbuildem 3y ago
I don't really do FE anymore, but I've worked in that realm long enough to see several frameworks come and go - as well as see the JS ecosystem scale far beyond the limits of its organizing principles. In my opinion, the community is lacking foundations, structure, and principles - something that would otherwise be instilled by formal education. JS is fantastic for exploring how programming works, it makes it easy to stitch things together, and the barrier to entry is basically zero; all you need is a text editor and a browser. The flipside is that people regularly reinvent things, same sets of ideas get formed and re-formed, fall into and out of vogue over and over again. It is true that there is great complexity to be dealt with in this domain, but it feels like whenever the current set of tools and practices matures enough to face some of the hard problems, the instinct in the community is to "start from scratch" and before long some new shiny exciting thing appears. It shows a lot of potential, it's nowhere near facing the hard problems, people jump on the bandwagon, time passes, and the new set of tools and practices arrives at precisely the same place. Web components have been in the works for a long, long time. The inherent competition between the major frameworks divides people into camps, which doesn't help. But, seeing the slow but steady progress in the web components realm indicates to me that they're apart from the patterns I was ragging on in the previous paragraph. They increasingly seem to deliver on the promise of creating advanced building blocks - perhaps one day a developer won't have to choose between a React Table, a Vue Table, a Gobagool Table, etc, but use a plain vanilla standard issue web component table to display their CSVs.
- deleted 3y ago
  [deleted]
brlewis 3y ago
From the article, <Card> <Avatar /> </Card> This is talking declaratively at a high level about the kind of interface to render. Lots of component frameworks look like this example. Thinking "how sad it is that we haven't progressed beyond the state of gluing together low level divs and spans" sounds like a preconceived idea rather than a response to this article. By the way, I come from mid-80's BASIC on 8-bit home computers. You get off my lawn.
- switchbak 3y ago
  You can make the calling interface look like that (that’s definitely good), but the implementations in the example were still very document centric inline html. It all just seems like it’s a lot more low level work than it ought to be. I feel much the same way when using a (bad) orm: there’s just a vague feeling that the solution isn’t quite an appropriate fit to the problem. Maybe this gets better when you’re composing from a library of core components, I don’t know. Again, I’m very much an outsider here. I’m not saying that old GUI component frameworks are vastly superior either. I just imagined that we’d have progressed well past the kind of approach the article is mentioning. It’s a side rant, but I don’t think it’s entirely without merit.
- jacobsimon 3y ago
  Not OP but at the end of the day, custom components like this still have to be rendered down to primitive HTML and CSS, and are plagued by all sorts of browser-specific issues and conventions that make higher level abstraction way more difficult than they need to be. As a random example, HTML specifies that clicking a `<button>` inside a `<form>` automatically submits a POST request to the current URL. We can't change that because it will break a lot of webpages that rely on this default behavior, so now every component system built on top of <form> or <button> needs to prevent the default browser behavior, and there are so many more examples of things like this.
mattgreenrocks 3y ago
The problem with many front and backend web frameworks is they love the medium of the web too much. This might sound absurd, but they leak all sorts of web gunk through and then pile their own concepts on top. A simple example of this is most backend frameworks let you signal an error by throwing an exception. Good choice! Except when you go to throw one, you often have to choose from a bunch of HTTP status codes to bundle with your exception. I want to tell the user that validation failed, that's all. I should throw a ValidationError, not a HttpResponseError. They're not really abstracting anything, just adding a layer of structure, usually via libraries that are glued together. Similarly, I've started to be of the opinion that the ideal HTTP request handler has very few HTTP-specific details in it, as the framework can introspect the types and annotations to determine how to pass data in and out. This is very different from typical frameworks which are happy to hand you raw requests and responses and tell you to do it all. Nothing wrong with that for special cases, BTW, except for people's tendency to mix HTTP, infrastructure (DB/messaging/APIs), and business logic in the same handler. There will always be cases where you need direct control, but I've been moving towards stacks that automate most of this to cut down on the gunky makework feeling I get when doing webdev, and it has been integral to me actually enjoying the tooling rather than feeling like I'm filling out TPS reports. Currently that's Spring Boot + Kotlin, despite the enterprise stigma the JVM and Spring have.
deleted 3y ago
[deleted]
EMM_386 3y ago
> Something something get off my lawn... While I agree, this is what we're stuck with. I have 25+ years of experience. Before JavaScript and CSS existed. Now? I'm on an Angular 16 (moving to 17 SPA). Worked with almost everything else in between. I had all the same feelings. "We're doing what with JavaScript now??". It turns out, it's not all that bad. TypeScript is pleasant enough, for me Angular is logical, and sure at the end of the day it's all just HTML/JS/CSS but what can you do? We're stuck with it, unless WASM totally up-ends the entire thing and we have JIT'd languages like .Net and Java running on the client ... which is ... Well, I'm not even sure what that is anymore. It's not HTML, JS, and CSS!

metadaemon 3y ago

It's a very complex problem to solve and I think a lot of people need to accept that. There will never be a simple solution with a low learning curve that's actually performant for non-trivial applications without a fundamental shift in browser technology.

myaccountonhn 3y ago
I think elm showed that it is possible to build a solution with a low learning curve. Sadly elm hasn't really taken off but as far as frontend goes... it is just so simple together with elm-ui.
rglover 3y ago
There is. I was frustrated by all of the chaos and built a solution [1]. Not too far off from an RC1 and then a 1.0 (which is being done slowly so I can freeze APIs and avoid the typical JS rug pulls). [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick

agloe_dreams 3y ago

The problem is CSS. CSS is so freaking complex with millions of possible outcomes. https://www.w3.org/Style/CSS/all-properties.en.html https://www.w3.org/Style/CSS/all-properties.en.html Building a declarative UI that compiles to that sort of declaration means building that from scratch. We do currently work like that though. React isn't that far and web components built into an element of that.

deergomoo 3y ago
I wonder how different things would look if you could opt out of the cascade for CSS. It's great for documents but signifcantly less so for "apps", where the widget is the widget and by-and-large should not be affected by the other bits of interface it's inside. I think that's why frameworks like Tailwind etc. have got so popular -- they're much closer to the traditional native application way of styling. You set all the appearance details on the component and then you reuse the component, styles and all.

11235813213455 3y ago

that's how it is if you're using high-level react components or web components, it's just an XML-like layout, user-friendly. What the article is showing is their low-level implementation, but as a consumer you can just import and use them

mattlondon 3y ago

I think you are talking about web components. Even in the old desktop world someone had to build the button widget (and all the others) that let you just throw stuff together in MFC or Swing or whatever. Same today - someone has to build the web components in order for us to declaratively use them as high-level Lego. Trouble is, there is no real high-level "general purpose" library of components beyond the core HTML elements (they'll get you a long way but there are notable things missing that we expect from apps, e.g. toolbars, menus, tab strips etc), and then the probably reason for their not being a general high-level library is that everyone wants something special for their websites (because historically websites have always allowed a lot of design flexibility, way more than your typical win32 app ever did for example). I have several times really wished to have some solid "desktop style" components to use for things like menus, tool bars etc. That would make prototypes in electron/neutralino/tauri way way way faster to do.

jacobsimon 3y ago
There are certainly lots of great component libraries out there for various frameworks that help with this, but I agree with the parent comment that it's still not the kind of progress we should have had by this point. I think it's unfortunate that we have to stick to HTML/CSS as the foundation for everything to maintain compatibility and accessibility, but that's how the web works I suppose. If we were to design the web from the ground up today based on what people use it for, it would look pretty different I think.
- megaman821 3y ago
  I am not sure it would look that different. It would be more consistent with terminology. Things like SwiftUI and Jetpack Compose look a lot more like HTML and CSS than their predecessors, and there is nothing forcing them to go in that direction. The biggest difference between other major platforms and the web, is that the web doesn't come with a default UI framework. The primitives for building UI on the web are pretty good though.
  - jacobsimon 3y ago

ecmascript 3y ago

I do front end stuff for a living and have been in the javascript space for several years. I do other backend development as well and I can't see why people think like you honestly. Most other GUI libraries is in a much worse state than front end web dev. That is probably also the reason why people use front end tech to make native apps today, because you can customize and make apps much faster than in basically any other way. I think front end gui development is very easy today and very powerful as well and we have progressed a lot. Making stuff with web components isn't event that hard and if you want you can just use one of the many available syntax sugar libraries that exist like Lit and others.

Devasta 3y ago
Devs use web frontend tech because it is installed on every machine, will never have anything less than the full backing of the browser devs for the next hundred years, and gets around corporate filters. No need to deal with IT security losers to get your app installed, no need to get ports opened, just everything down port 443 until the end of time. INTERCAL could win with that feature set.
- ecmascript 3y ago
  If that is the case, why are people writing desktop apps with Electron / other web tech?
- paulddraper 3y ago
  I think you missed the point. > why people use front end tech to make native apps today Even when you have to deal with IT security losers to get apps installed, implementing it w/ web tech is extremely popular. E.g. the #1 IDE by popularity [1] is a desktop app developed with web tech. (And yes, it was later ported to browsers, but it didn't start there.) [1] https://survey.stackoverflow.co/2022#section-most-popular-technologies-integrated-development-environment https://survey.stackoverflow.co/2022#section-most-popular-te...
mardifoufs 3y ago
Exactly. I'm starting to understand the push for web UI now that I've started to use qt for a small GUI. I'm sure qt is good for some type of apps. But for my smaller scale project where the graphic interface is not where we want to spend most of our dev time, I'd rather take javascript/react at this point.

shortrounddev2 3y ago

I'm less cynical about web development. Lots of software engineers bemoan writing web interfaces and pine for the days of native GUI development, but web won because it's extremely accessible to people without CS degrees. There just isn't a good native framework that's as forgiving and easy to learn as HTML, JS, and CSS. I think gtk is pretty decent though

yCombLinks 3y ago
Hard disagree, web won because of the deploy story. Users don't have to install anything. Html and css is a terrible API for app layout, because it wasn't designed for that
- josephg 3y ago
  Given how important the web’s deploy story has been for its success, I’m surprised we haven’t seen more zero deployment application platforms / prototypes appear. Docker is an attempt at something similar on the server, but docker images are huge and docker still separates its docker fetch and docker run steps. Maybe part of the problem is that the web is the only platform where people obsess over the size of deployed artefacts. Websites are certainly getting bigger, but they’re still an order of magnitude smaller than the average snap package or iOS app.
- shortrounddev2 3y ago
  > Html and css is a terrible API for app layout, because it wasn't designed for that And yet it's so easy and forgiving that millions of 13 year olds learned it for their myspace and tumblr pages over the last 15 or so years. Somehow, despite all the CS graduates and 20 year software engineering veterans bemoaning it, more and more people learn HTML, CSS, and Javascript every day while the number of people learning native GUI development struggles to keep up or outright fades away. I truly believe that most software engineers don't understand what ergonomic software or programming languages look like. They're blinded by their expertise
  - yCombLinks 3y ago

paulddraper 3y ago

Do elaborate on what UI paradigm web browsers ought to use from mid-90s GUI development.

usea 3y ago
They said things should be better than they are, not that we should go back to the 90s or even use it as inspiration.
- paulddraper 3y ago
  Oh well, yes, it would be nice for things to be better than they are. (^ feel free to copy-paste that to any HN thread)
  - aegypti 3y ago
    It would be nice for conversations to be kinder, less snarky, and more curious. Could even edit out any swipes and internet-style cross examination as well.

btbuildem 3y ago

I don't really do FE anymore, but I've worked in that realm long enough to see several frameworks come and go - as well as see the JS ecosystem scale far beyond the limits of its organizing principles. In my opinion, the community is lacking foundations, structure, and principles - something that would otherwise be instilled by formal education. JS is fantastic for exploring how programming works, it makes it easy to stitch things together, and the barrier to entry is basically zero; all you need is a text editor and a browser. The flipside is that people regularly reinvent things, same sets of ideas get formed and re-formed, fall into and out of vogue over and over again. It is true that there is great complexity to be dealt with in this domain, but it feels like whenever the current set of tools and practices matures enough to face some of the hard problems, the instinct in the community is to "start from scratch" and before long some new shiny exciting thing appears. It shows a lot of potential, it's nowhere near facing the hard problems, people jump on the bandwagon, time passes, and the new set of tools and practices arrives at precisely the same place. Web components have been in the works for a long, long time. The inherent competition between the major frameworks divides people into camps, which doesn't help. But, seeing the slow but steady progress in the web components realm indicates to me that they're apart from the patterns I was ragging on in the previous paragraph. They increasingly seem to deliver on the promise of creating advanced building blocks - perhaps one day a developer won't have to choose between a React Table, a Vue Table, a Gobagool Table, etc, but use a plain vanilla standard issue web component table to display their CSVs.

deleted 3y ago
[deleted]

brlewis 3y ago

From the article, <Card> <Avatar /> </Card> This is talking declaratively at a high level about the kind of interface to render. Lots of component frameworks look like this example. Thinking "how sad it is that we haven't progressed beyond the state of gluing together low level divs and spans" sounds like a preconceived idea rather than a response to this article. By the way, I come from mid-80's BASIC on 8-bit home computers. You get off my lawn.

switchbak 3y ago
You can make the calling interface look like that (that’s definitely good), but the implementations in the example were still very document centric inline html. It all just seems like it’s a lot more low level work than it ought to be. I feel much the same way when using a (bad) orm: there’s just a vague feeling that the solution isn’t quite an appropriate fit to the problem. Maybe this gets better when you’re composing from a library of core components, I don’t know. Again, I’m very much an outsider here. I’m not saying that old GUI component frameworks are vastly superior either. I just imagined that we’d have progressed well past the kind of approach the article is mentioning. It’s a side rant, but I don’t think it’s entirely without merit.
jacobsimon 3y ago
Not OP but at the end of the day, custom components like this still have to be rendered down to primitive HTML and CSS, and are plagued by all sorts of browser-specific issues and conventions that make higher level abstraction way more difficult than they need to be. As a random example, HTML specifies that clicking a `<button>` inside a `<form>` automatically submits a POST request to the current URL. We can't change that because it will break a lot of webpages that rely on this default behavior, so now every component system built on top of <form> or <button> needs to prevent the default browser behavior, and there are so many more examples of things like this.

mattgreenrocks 3y ago

The problem with many front and backend web frameworks is they love the medium of the web too much. This might sound absurd, but they leak all sorts of web gunk through and then pile their own concepts on top. A simple example of this is most backend frameworks let you signal an error by throwing an exception. Good choice! Except when you go to throw one, you often have to choose from a bunch of HTTP status codes to bundle with your exception. I want to tell the user that validation failed, that's all. I should throw a ValidationError, not a HttpResponseError. They're not really abstracting anything, just adding a layer of structure, usually via libraries that are glued together. Similarly, I've started to be of the opinion that the ideal HTTP request handler has very few HTTP-specific details in it, as the framework can introspect the types and annotations to determine how to pass data in and out. This is very different from typical frameworks which are happy to hand you raw requests and responses and tell you to do it all. Nothing wrong with that for special cases, BTW, except for people's tendency to mix HTTP, infrastructure (DB/messaging/APIs), and business logic in the same handler. There will always be cases where you need direct control, but I've been moving towards stacks that automate most of this to cut down on the gunky makework feeling I get when doing webdev, and it has been integral to me actually enjoying the tooling rather than feeling like I'm filling out TPS reports. Currently that's Spring Boot + Kotlin, despite the enterprise stigma the JVM and Spring have.

deleted 3y ago

[deleted]

EMM_386 3y ago

> Something something get off my lawn... While I agree, this is what we're stuck with. I have 25+ years of experience. Before JavaScript and CSS existed. Now? I'm on an Angular 16 (moving to 17 SPA). Worked with almost everything else in between. I had all the same feelings. "We're doing what with JavaScript now??". It turns out, it's not all that bad. TypeScript is pleasant enough, for me Angular is logical, and sure at the end of the day it's all just HTML/JS/CSS but what can you do? We're stuck with it, unless WASM totally up-ends the entire thing and we have JIT'd languages like .Net and Java running on the client ... which is ... Well, I'm not even sure what that is anymore. It's not HTML, JS, and CSS!