5 ms·

Are we stuck with HTML/CSS/JS forever? For today's interactive applications, those 3 are clearly insufficient. Can't the standards commitees come up with a new

Are we stuck with HTML/CSS/JS forever? For today's interactive applications, those 3 are clearly insufficient. Can't the standards commitees come up with a new "web language" that actually satisfies the needs of 2020? Or is the goal to just have everything run on WebAssembly? Kudos to the author.. but I was hoping it would be a "for real new" browser.

rcarmo 6y ago
They already did. You probably don't want to go through the SMIL spec on an empty stomach, though.
Spivak 6y ago
Will the current web stack be the preferred language of applications that run in a browser forever? Maybe not. Having the browser just be a WASM target with (potentially) more than one rendering and layout engine doesn’t seem that far fetched. However, I think the need to support the current web stack will continue for the foreseeable future since it would be a terrible waste to simply abandon a platform that so many applications are written for.
- emerongi 6y ago
  I agree. The current stack is here to stay and we will need to support it. However, as a web developer, I spend insane amounts of time dealing with simple issues that stem from the fact that we are building complex applications on top of it. Modal window has a JS select element in it? Now the whole select list has to have an absolute position to make sure it flows out of the modal. Oh wait... now the thing won't reposition itself when the user starts scrolling. So much tech today is being built just to put a band-aid over this stuff, instead of addressing the core issue (the browser is no longer used to just deliver static documents). I can't be the only one that wishes for a new language/browser. WebAssembly might be a saviour, although I'm unsure how issues like accessibility will be addressed.
  - hombre_fatal 6y ago
    Just sounds like grass-is-greener hopefulness to me. If it was just a matter of a fresh start with a new language/stack, then Android/iOS/macOS dev would be compelling experiences. But they're not. And they're changing just as much, bandaging over themselves so much that you end up credentializing in a whole lineage of idiosyncrasies worse than just putting a <select> in a modal, except unlike the web you're just building something that works on an iPhone. Clientdev is hard.
    - corty 6y ago
      Try Delphi/Lazarus, Qt or maybe even VisualBasic. Client Dev has regressed since those days, now it's in a state where devs can't even imagine anything better, but we clearly had that...
  - c-smile 6y ago
    > However, as a web developer, ... modal window has a JS select element in it? Try Sciter then, it was designed precisely for running desktop UI using HTML/CSS as UI declaration languages. I was native UI developer initially, then Web Frontend Architect who returned back to desktop development taking HTML/CSS with me to Sciter.
  - pmoriarty 6y ago
    "So much tech today is being built just to put a band-aid over this stuff, instead of addressing the core issue (the browser is no longer used to just deliver static documents)" Am I the only one who thinks the sooner the web goes back to just delivering static documents, the better?
    - Scarblac 6y ago
      For the Web that would probably be good, yes. But many of us are application programmers using the browser as a UI platform, and that doesn't have that much to do with the Web proper.
      - 6y ago
vbezhenar 6y ago
Can you elaborate, why is it clearly insufficient? There are myriads of web applications made with HTML/CSS/JS. So it's clearly sufficient for any kind of web applications IMO. There are some weak points for web. One of them is performance, hopefully it'll be resolved by Webassembly, so you could write performance-sensitive portions using C++ or Rust. Another one is using hardware and that's resolved by evolving web standards like WebUSB, WebGPU and so on. I don't think that replacing HTML, CSS or JS with something different would solve any actual problem in the web. They are not ideal, but they are good enough and that's all that matters. Well, technically you could replace JS with any other language compiling into JS or Webassembly. Then you could just use one full-screen canvas and draw anything you want there, so you could use Qt or something like that. That does not require any new APIs, but I don't think that's the good idea in the long run.
- filleduchaos 6y ago
  People always jump to criticizing JS, but frankly HTML and CSS are my biggest pain points whenever I work with them. Any reasonably complicated UI inevitably turns into a soup of divs. Why would you stick with markup and styling heavily tailored towards documents for an application platform if you could start fresh with something else? To be fair, CSS is making big strides in this regard with Houdini[0]. It's not yet complete but it's a much better alternative to composing divs and spans in weird ways to get the look you want. 0. https://developer.mozilla.org/en-US/docs/Web/Houdini https://developer.mozilla.org/en-US/docs/Web/Houdini
fulafel 6y ago
JS is already largely a compile target. Aside from ClojureScript, TypeScript, ReasonML etc even human authored JS is usually compiled to more legacy browser friendly JS.
- err4nt 6y ago
  That's gotten trendy in the recent past, but I think you have a generation or wave of developers who literally don't realize it's an interpreted language and you can write short, very sweet vanilla JS and have it run almost everywhere without needing any ahead of time optimizations. _Modern_ JS in _modern_ engines is a dream!
  - ex3ndr 6y ago
    If you will try to profile your app on V8 you will find that almost everything is in binary code, not interpreted.
    - kizer 6y ago
      In this sense it means not requiring a precompilation step. JITing is an implementation detail; also modern engines compile to a bytecode first during interpretation.
  - fulafel 6y ago
    Thhis got me to look up some of the ages, for anyone else curious: ClojureScript is 9-ish year old, CoffeeScript 10+, TypeScript 7.
err4nt 6y ago
Each of these languages you mentioned is extensible, so to a large degree you can shape them to fit your needs! I don't do native software development but just looking at things, it seems like software is eating the world, but also at the same time that web technology is eating software development. I don't think the web is the best development tech on any OS, but it's proving to be the best cross-platform tech that runs on any device. It will continue to evolve to be more suitable, but the idea that it's too weak or wrong is exaggerated.
pjc50 6y ago
Realistically, the standards comittees follow where the implementations lead. And the problem with implementations is that all the large companies making them would much prefer to be either monopolists or drastically advantaged by the choice of technology. Whose native toolkit should it most resemble: Microsoft's, Apple's, or Google's? The web is a mine-strewn no-mans-land between competing factions, which accounts for a lot of the strangeness. (Ironically, the tech is leaking in the other direction as web apps become more popular on both mobile and desktop)
zamalek 6y ago
HTML isn't so bad these days because of grid and flexbox, but it is certainly no XAML. Scoped CSS works really well in conjunction with web components. Languages like SCSS make everything more sane, especially in combination. I'm currently messing about with Yew[1], which is an entire SPA framework in Rust/WebAssembly. There's about 5 lines of bootstrap JS involved (and fiddling about with bundlers, which is much more sane since Rollup[2]). [1]: https://yew.rs/docs/ https://yew.rs/docs/ [2]: https://rollupjs.org/guide/en/ https://rollupjs.org/guide/en/
pravus 6y ago
No, but I think it will take a little re-imagining of what a "browser" should be. In my own opinion I find it very odd that we are using what is effectively a static publishing model to do so many dynamic activities. Modulo all the hacks that have been added since, the original intent and architecture of the web seems to be to share scientific papers for researchers at CERN. It's essentially a single file-server namespace with the ability to embed references to other parts of the namespace inside objects already attached to the namespace in some way. Sprinkle in JavaScript and CSS animations and now we have "applications". Looking at what web browsers are both capable of and expected to do today I think what we really want is an "internet terminal" which would be able to contact resources over the internet, negotiate both local and remote resources for an intended purpose, and then share state bi-directionally (stateless is just zero state). To just conjure a couple of quick examples you can imagine the differences required in providing a service that produces a simple JSON feed versus a full interactive experience that mutates a shared database. The JSON feed wouldn't require a display and could easily be consumed by autonomous agents while the other might require a minimum display size and want to use a widget set to produce controls and toolbars, etc. If my client agent is allowed access to my video display, mouse, and keyboard it could offer these to either service and allow it to respond in whatever way it feels appropriate. The JSON feed could provide a simple UI for viewing recent events, for example. Now we do all of this today with HTML, CSS, JavaScript, etc. but none of it feels organized and all you see is re-invention after re-invention of essentially these same concepts. The fact that we even call them "applications" when they are "documents" is really what seals it to me. I personally would like to see something that is more true to the reality of computing and internet connectivity today and looks at it from a device-to-service POV. Locally I might have a graphical display, audio, and inputs but I might also have access to an SQL database or some other network-attached service. Assuming some level of trust and if negotiated properly there's no reason a remote application couldn't make use of these local resources using credentials and security profiles under my control. The can of worms here is that this is basically RPC which is the other never-ending disaster... Internet is hard. Let's go shopping.
kizer 6y ago
I’m basically going to treat the whole web platform as a compilation target. As long as the result is accessible, I’d like to forget about the “big three” for some time.

rcarmo 6y ago

They already did. You probably don't want to go through the SMIL spec on an empty stomach, though.

Spivak 6y ago

Will the current web stack be the preferred language of applications that run in a browser forever? Maybe not. Having the browser just be a WASM target with (potentially) more than one rendering and layout engine doesn’t seem that far fetched. However, I think the need to support the current web stack will continue for the foreseeable future since it would be a terrible waste to simply abandon a platform that so many applications are written for.

emerongi 6y ago
I agree. The current stack is here to stay and we will need to support it. However, as a web developer, I spend insane amounts of time dealing with simple issues that stem from the fact that we are building complex applications on top of it. Modal window has a JS select element in it? Now the whole select list has to have an absolute position to make sure it flows out of the modal. Oh wait... now the thing won't reposition itself when the user starts scrolling. So much tech today is being built just to put a band-aid over this stuff, instead of addressing the core issue (the browser is no longer used to just deliver static documents). I can't be the only one that wishes for a new language/browser. WebAssembly might be a saviour, although I'm unsure how issues like accessibility will be addressed.
- hombre_fatal 6y ago
  Just sounds like grass-is-greener hopefulness to me. If it was just a matter of a fresh start with a new language/stack, then Android/iOS/macOS dev would be compelling experiences. But they're not. And they're changing just as much, bandaging over themselves so much that you end up credentializing in a whole lineage of idiosyncrasies worse than just putting a <select> in a modal, except unlike the web you're just building something that works on an iPhone. Clientdev is hard.
  - corty 6y ago
    Try Delphi/Lazarus, Qt or maybe even VisualBasic. Client Dev has regressed since those days, now it's in a state where devs can't even imagine anything better, but we clearly had that...
- c-smile 6y ago
  > However, as a web developer, ... modal window has a JS select element in it? Try Sciter then, it was designed precisely for running desktop UI using HTML/CSS as UI declaration languages. I was native UI developer initially, then Web Frontend Architect who returned back to desktop development taking HTML/CSS with me to Sciter.
- pmoriarty 6y ago
  "So much tech today is being built just to put a band-aid over this stuff, instead of addressing the core issue (the browser is no longer used to just deliver static documents)" Am I the only one who thinks the sooner the web goes back to just delivering static documents, the better?
  - Scarblac 6y ago
    For the Web that would probably be good, yes. But many of us are application programmers using the browser as a UI platform, and that doesn't have that much to do with the Web proper.
    - 6y ago

vbezhenar 6y ago

Can you elaborate, why is it clearly insufficient? There are myriads of web applications made with HTML/CSS/JS. So it's clearly sufficient for any kind of web applications IMO. There are some weak points for web. One of them is performance, hopefully it'll be resolved by Webassembly, so you could write performance-sensitive portions using C++ or Rust. Another one is using hardware and that's resolved by evolving web standards like WebUSB, WebGPU and so on. I don't think that replacing HTML, CSS or JS with something different would solve any actual problem in the web. They are not ideal, but they are good enough and that's all that matters. Well, technically you could replace JS with any other language compiling into JS or Webassembly. Then you could just use one full-screen canvas and draw anything you want there, so you could use Qt or something like that. That does not require any new APIs, but I don't think that's the good idea in the long run.

filleduchaos 6y ago
People always jump to criticizing JS, but frankly HTML and CSS are my biggest pain points whenever I work with them. Any reasonably complicated UI inevitably turns into a soup of divs. Why would you stick with markup and styling heavily tailored towards documents for an application platform if you could start fresh with something else? To be fair, CSS is making big strides in this regard with Houdini[0]. It's not yet complete but it's a much better alternative to composing divs and spans in weird ways to get the look you want. 0. https://developer.mozilla.org/en-US/docs/Web/Houdini https://developer.mozilla.org/en-US/docs/Web/Houdini

fulafel 6y ago

JS is already largely a compile target. Aside from ClojureScript, TypeScript, ReasonML etc even human authored JS is usually compiled to more legacy browser friendly JS.

err4nt 6y ago
That's gotten trendy in the recent past, but I think you have a generation or wave of developers who literally don't realize it's an interpreted language and you can write short, very sweet vanilla JS and have it run almost everywhere without needing any ahead of time optimizations. _Modern_ JS in _modern_ engines is a dream!
- ex3ndr 6y ago
  If you will try to profile your app on V8 you will find that almost everything is in binary code, not interpreted.
  - kizer 6y ago
    In this sense it means not requiring a precompilation step. JITing is an implementation detail; also modern engines compile to a bytecode first during interpretation.
- fulafel 6y ago
  Thhis got me to look up some of the ages, for anyone else curious: ClojureScript is 9-ish year old, CoffeeScript 10+, TypeScript 7.

err4nt 6y ago

Each of these languages you mentioned is extensible, so to a large degree you can shape them to fit your needs! I don't do native software development but just looking at things, it seems like software is eating the world, but also at the same time that web technology is eating software development. I don't think the web is the best development tech on any OS, but it's proving to be the best cross-platform tech that runs on any device. It will continue to evolve to be more suitable, but the idea that it's too weak or wrong is exaggerated.

pjc50 6y ago

Realistically, the standards comittees follow where the implementations lead. And the problem with implementations is that all the large companies making them would much prefer to be either monopolists or drastically advantaged by the choice of technology. Whose native toolkit should it most resemble: Microsoft's, Apple's, or Google's? The web is a mine-strewn no-mans-land between competing factions, which accounts for a lot of the strangeness. (Ironically, the tech is leaking in the other direction as web apps become more popular on both mobile and desktop)

zamalek 6y ago

HTML isn't so bad these days because of grid and flexbox, but it is certainly no XAML. Scoped CSS works really well in conjunction with web components. Languages like SCSS make everything more sane, especially in combination. I'm currently messing about with Yew[1], which is an entire SPA framework in Rust/WebAssembly. There's about 5 lines of bootstrap JS involved (and fiddling about with bundlers, which is much more sane since Rollup[2]). [1]: https://yew.rs/docs/ https://yew.rs/docs/ [2]: https://rollupjs.org/guide/en/ https://rollupjs.org/guide/en/

pravus 6y ago

No, but I think it will take a little re-imagining of what a "browser" should be. In my own opinion I find it very odd that we are using what is effectively a static publishing model to do so many dynamic activities. Modulo all the hacks that have been added since, the original intent and architecture of the web seems to be to share scientific papers for researchers at CERN. It's essentially a single file-server namespace with the ability to embed references to other parts of the namespace inside objects already attached to the namespace in some way. Sprinkle in JavaScript and CSS animations and now we have "applications". Looking at what web browsers are both capable of and expected to do today I think what we really want is an "internet terminal" which would be able to contact resources over the internet, negotiate both local and remote resources for an intended purpose, and then share state bi-directionally (stateless is just zero state). To just conjure a couple of quick examples you can imagine the differences required in providing a service that produces a simple JSON feed versus a full interactive experience that mutates a shared database. The JSON feed wouldn't require a display and could easily be consumed by autonomous agents while the other might require a minimum display size and want to use a widget set to produce controls and toolbars, etc. If my client agent is allowed access to my video display, mouse, and keyboard it could offer these to either service and allow it to respond in whatever way it feels appropriate. The JSON feed could provide a simple UI for viewing recent events, for example. Now we do all of this today with HTML, CSS, JavaScript, etc. but none of it feels organized and all you see is re-invention after re-invention of essentially these same concepts. The fact that we even call them "applications" when they are "documents" is really what seals it to me. I personally would like to see something that is more true to the reality of computing and internet connectivity today and looks at it from a device-to-service POV. Locally I might have a graphical display, audio, and inputs but I might also have access to an SQL database or some other network-attached service. Assuming some level of trust and if negotiated properly there's no reason a remote application couldn't make use of these local resources using credentials and security profiles under my control. The can of worms here is that this is basically RPC which is the other never-ending disaster... Internet is hard. Let's go shopping.

kizer 6y ago

I’m basically going to treat the whole web platform as a compilation target. As long as the result is accessible, I’d like to forget about the “big three” for some time.