6 ms·

Son what i'm hearing is that you're looking forward to browser-in-a-browser as if that's somehow not the most depressing trend I didn't know about

samwillis 4y ago
Happy to admit it's a crazy idea, and it's not something that I would want to see as a usual way to built sites. But for small areas of web apps where compatibility is difficult it does make sense. Google Docs used to be contenteditable based, but moved to a custom rendering engine. They are a large enough company to be able to invest in that. Small businesses aren't, and have to rely on content editable. Ladybird as a contenteditable polyfill would help smaller teams, or single developers, achieve the same, while also building on the existing tooling and APIs for contenteditable.
- TedDoesntTalk 4y ago
  What is “content editable”?
  - mkl 4y ago
    https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contenteditable https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... It's an HTML attribute that makes content (mainly text) editable by end users.
  - codetrotter 4y ago
    https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contenteditable https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... Basically if you set the content editable attribute on an element then the user can edit the content of the element directly Here is an example using it: https://codepen.io/caraya/pen/ZyQMWd https://codepen.io/caraya/pen/ZyQMWd
- Brian_K_White 4y ago
  "Google Docs used to be contenteditable based, but moved to a custom rendering engine." Is THAT why you can't cut & paste with the mouse in google docs like you can on every other site? Take me back to the old way then please.
  - andrekandre 4y ago
    yep, the use canvas to render everything now https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
    - still_grokking 4y ago
      I didn't know that. Very interesting! Isn't this actually prove that creating desktop grate applications, like a graphical word processor form the late 90's & some colab backend, is still infeasible with web tech? Doesn't it also prove that it's still easier and faster to create a proper app and GUI toolkit yourself and just render pixels to the screen (as all desktop GUI toolkits do these days) instead of fighting the browser tech idiosyncrasies, even a proper app and GUI stack isn't trivial in itself?
      - andrekandre 4y ago
        > Doesn't it also prove that it's still easier and faster to create a proper app and GUI toolkit yourself and just render pixels to the screen (as all desktop GUI toolkits do these days) instead of fighting the browser tech idiosyncrasies, even a proper app and GUI stack isn't trivial in itself? jmo, but i think so as well.... tho i wonder what the performance/battery-life implications of everything doing that might be... perhaps you could have an 'libhtml' for static sites and documents, and different ones for more interactive apps etc
        still_grokking 4y ago
        > perhaps you could have an 'libhtml' for static sites and documents, and different ones for more interactive apps etc You mean, like a web-browser from the late 90's + Java WebStart?
r3trohack3r 4y ago
As an industry we’ve taken a long and windy path to delivering full applications (with a local cache) on every load to a sandboxed environment that is mostly compatible across environments. While it’s easy to take shots at the current state, I find it hard to imagine another path to delivering a cross platform application over the network. What we have now is actually pretty rad. We built it stone by stone, incrementally, and now I don’t have to package my application for N platforms unless I want to meet users in their app stores.
- selfhoster11 4y ago
  Literally, Java. If we spent all the effort we used up on making JavaScript work on Java instead, I’d be typing this from my Moon habitat. But we instead chose a pig, buried it under layers of lipstick, and strapped a jet engine onto it. Sure, it’s airworthy, but was it the best way to allocate resources?
  - r3trohack3r 4y ago
    I wouldn't say we chose a pig and buried it under layers of lipstick. I think it's more accurate to say people realized: 1) You could deliver software via a browser with some clever hacking 2) That delivering software via a browser had some extremely attractive properties compared to other approaches Those clever hacks turned into real applications and those became real products. As people built applications on top of browsers, the browsers evolved to be a better environment for building applications. It was very organic. The actual language we ended up using is just a byproduct IMO. I don't think people chose JavaScript, they chose the browser and the browser had JavaScript. And since the browser had JavaScript, we kept pushing the limits of JavaScript because we needed to deliver applications to the browser. Honestly hard to see this happening efficiently in any other way. All things considered, the web platform is pretty fantastic compared to the software distribution story in every other ecosystem. I'd argue that we allocated resources pretty well on this one!
    - still_grokking 4y ago
      I guess you missed Java Applets and Java WebStart… The web browser is still the most terrible "application platform" as it's at its core still a document viewer, and not an application platform at all. The pic with a lot of lipstick analogy is pretty to the spot, imho. You can abuse any Turing-complete environment any way you like. But this doesn't make it a good idea in the first place.

samwillis 4y ago

Happy to admit it's a crazy idea, and it's not something that I would want to see as a usual way to built sites. But for small areas of web apps where compatibility is difficult it does make sense. Google Docs used to be contenteditable based, but moved to a custom rendering engine. They are a large enough company to be able to invest in that. Small businesses aren't, and have to rely on content editable. Ladybird as a contenteditable polyfill would help smaller teams, or single developers, achieve the same, while also building on the existing tooling and APIs for contenteditable.

TedDoesntTalk 4y ago
What is “content editable”?
- mkl 4y ago
  https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contenteditable https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... It's an HTML attribute that makes content (mainly text) editable by end users.
- codetrotter 4y ago
  https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contenteditable https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... Basically if you set the content editable attribute on an element then the user can edit the content of the element directly Here is an example using it: https://codepen.io/caraya/pen/ZyQMWd https://codepen.io/caraya/pen/ZyQMWd
Brian_K_White 4y ago
"Google Docs used to be contenteditable based, but moved to a custom rendering engine." Is THAT why you can't cut & paste with the mouse in google docs like you can on every other site? Take me back to the old way then please.
- andrekandre 4y ago
  yep, the use canvas to render everything now https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
  - still_grokking 4y ago
    I didn't know that. Very interesting! Isn't this actually prove that creating desktop grate applications, like a graphical word processor form the late 90's & some colab backend, is still infeasible with web tech? Doesn't it also prove that it's still easier and faster to create a proper app and GUI toolkit yourself and just render pixels to the screen (as all desktop GUI toolkits do these days) instead of fighting the browser tech idiosyncrasies, even a proper app and GUI stack isn't trivial in itself?
    - andrekandre 4y ago
      > Doesn't it also prove that it's still easier and faster to create a proper app and GUI toolkit yourself and just render pixels to the screen (as all desktop GUI toolkits do these days) instead of fighting the browser tech idiosyncrasies, even a proper app and GUI stack isn't trivial in itself? jmo, but i think so as well.... tho i wonder what the performance/battery-life implications of everything doing that might be... perhaps you could have an 'libhtml' for static sites and documents, and different ones for more interactive apps etc
      - still_grokking 4y ago
        > perhaps you could have an 'libhtml' for static sites and documents, and different ones for more interactive apps etc You mean, like a web-browser from the late 90's + Java WebStart?

r3trohack3r 4y ago

As an industry we’ve taken a long and windy path to delivering full applications (with a local cache) on every load to a sandboxed environment that is mostly compatible across environments. While it’s easy to take shots at the current state, I find it hard to imagine another path to delivering a cross platform application over the network. What we have now is actually pretty rad. We built it stone by stone, incrementally, and now I don’t have to package my application for N platforms unless I want to meet users in their app stores.

selfhoster11 4y ago
Literally, Java. If we spent all the effort we used up on making JavaScript work on Java instead, I’d be typing this from my Moon habitat. But we instead chose a pig, buried it under layers of lipstick, and strapped a jet engine onto it. Sure, it’s airworthy, but was it the best way to allocate resources?
- r3trohack3r 4y ago
  I wouldn't say we chose a pig and buried it under layers of lipstick. I think it's more accurate to say people realized: 1) You could deliver software via a browser with some clever hacking 2) That delivering software via a browser had some extremely attractive properties compared to other approaches Those clever hacks turned into real applications and those became real products. As people built applications on top of browsers, the browsers evolved to be a better environment for building applications. It was very organic. The actual language we ended up using is just a byproduct IMO. I don't think people chose JavaScript, they chose the browser and the browser had JavaScript. And since the browser had JavaScript, we kept pushing the limits of JavaScript because we needed to deliver applications to the browser. Honestly hard to see this happening efficiently in any other way. All things considered, the web platform is pretty fantastic compared to the software distribution story in every other ecosystem. I'd argue that we allocated resources pretty well on this one!
  - still_grokking 4y ago
    I guess you missed Java Applets and Java WebStart… The web browser is still the most terrible "application platform" as it's at its core still a document viewer, and not an application platform at all. The pic with a lot of lipstick analogy is pretty to the spot, imho. You can abuse any Turing-complete environment any way you like. But this doesn't make it a good idea in the first place.