4 ms·

Does anyone think it'd be a good idea for browsers to support more than one toolset? Right now it's just HTML+CSS+JS, no matter what languages people build on t

Does anyone think it'd be a good idea for browsers to support more than one toolset? Right now it's just HTML+CSS+JS, no matter what languages people build on top of that assembly. Elm seems like a neat idea, but based on Paul's post, I dislike the fact that it compiles down to CSS. It seems a disingenuous way to present the language. I'd much rather a browser was simply told this was an application/elm or something and ran with that properly.

general_failure 12y ago
Browsers are struggling to support 1 toolset as-is. Imagine the message of multiple tool sets.
- brandonbloom 12y ago
  Browsers are only struggling because of how complex the toolset is and how poorly defined the expected results are. There are plenty of counter-examples with simple standards and multiple implementations of a high degree of quality and interoperability.
  - recursive 12y ago
    plenty? Let's hear one.
georgemcbay 12y ago
"Does anyone think it'd be a good idea for browsers to support more than one toolset?" Some people do. I do. But it seems to be a minority opinion; most web developers seem to live in this weird cognitively dissonant state where the HTML DOM+CSS is always the right tool for the job because it theoretically allows for platform-independent layout to "any" browser while then spending most of their time dealing with getting their layouts to actually work on about a handful of real-world browsers which all treat the same layout code differently (in ways from subtle to large); resulting in piles of frameworks, pre-processing systems and general hackery to get everything working, mostly, most of the time. If there were a second toolset that were more rationally designed to solve the real-world problems of modern web apps, giving you layout via binding similar to what you see in Adobe Flex, WPF, Qt/QML, etc (not advocating any of those as the specific answer, just stating that I think they are all individually more sane than HTML/CSS/JS for app/UI layout) and just accepted the fact that the vast majority of websites are designed to be laid-out in a fairly constrained way (while still allowing for responsive layout for different sizes/dpis) I think web technology would be a lot less terrible. And just to get it out of the way, there are some good hacky solutions that help the problem I described, like React.js, Angular, Dart, etc, but they are all built on a shaky foundation which always manages to show through because we're stuck with HTML/CSS/JS.
- taf2 12y ago
  I used to believe using something like the tools you outlined would be easier until back in 2004 I spent 6 months porting my naitive windows application to apple. I scrapped the whole thing and started rebuilding on the predecessor to xulrunner, rebuilding mozilla and using XUL was great until I started to need graphing and different fluid layouts that I realized HTML is so much better for cross platform as more people are spending more hours every day making it better on more platforms and devices and it really is write once run everywhere once you move your native app to the server - at the end of the day you are going to spend countless hours tweaking for the different target OSs anyway - the web with HTML / CSS / JS are better at this than any other native solution... [update] we ported our native c++ components to xpcom interfaces and rebuilt the frontend in 4 months allowing us to launch our product simo health - later purchased by RevolutionHealth 4 months later... I still as recently as 3 months ago receive emails from past customers asking for updates.
Aldo_MX 12y ago
Did someone say Shockwave, Flash, Java, Silverlight, etc.? Or maybe VBScript, JScript, Dart, etc.?
e12e 12y ago
Arguably the removal of XLST/XML from the stack of tools browsers support(ed) in favour of JSON/JavaScript (or Anything-including-XML/JavaScript) is a good thing. I still think there are some good ideas in XML/XLST/SAX/XSD/RELAX NG -- but I think it's clear by now that web developers will not, or cannot, leverage the (rather minor) benefits XML can offer over json/javascript (richer datatypes, mostly -- javascript has gotten so fast that I don't think there's any real benefit to xml+sax over JSON in terms of memory/performance -- so once you throw away all your xml tools as well, there are little benefit remaining). Generally you can implement pretty much anything else on top of javascript. I do think we could use a better/different rendering model -- having documents/HTML as the base isn't a very good idea. Not sure what the answer would/should be -- seeing how Apple abandoned display postscript, I don't think PDF is the way to go -- perhaps something closer to GL? I'm a bit of a 90s luddite when it comes to "shiny web apps leveraging javascript for max bling" -- I much prefer gracefully-degrading html+css apps slightly augmented with javascript. But for better or worse, the immediate future clearly belongs to "download code over the internet;run it". Currently we're stuck with js+http+dom as the only real write-once-tweak-for-ever-run-most-places alternative. I think short time success will go to frameorsk like Elm and clojurescript that compile-to-the-browser. And at the rate of progress we seem to have, I don't think we'll see great platform for delivering apps/objects/runable data in the near future. We appear likely to move the visual basic worms of the 90s to javascript worms of the 10s -- never gaining any decent security or privacy -- because there is no demand for it. Luckily, well-designed "apps" based on html+css+conserative js can still be great, and have great performance, so I'll try and stick with that, and I'll let everyone else continue to design blogs that can't be read without running "actual" code on the client. For no real benefit (to the user -- to those selling ads/behavioural data the benefits are more tangible, but I'm not a user of that -- I'm just a victim of that). /rant.
johnpmayer 12y ago
Function calls and loops seem like a neat idea, but I dislike the fact they they compile down to JMP. It seems disingenuous. I'd much rather the CPU just be told this was a loop and ran with that properly.
tete 12y ago
More toolsets seems like the wrong way to me. The reason is that browsers barely even keep up with the current ones or even old ones. Also browsers work because of standards. It's not about the "best", but about agreeing. Recently I see many people trying to make one suboptimal thing by starting from scratch, removing all standards compatibility, throwing away all the knowledge that went in to a thing to make this one single thing work better, resulting only in incompatibilities, non-standards-conformance and making everything else than that one thing harder or even impossible. You can see this with web frameworks, with system tools, etc. Usually this stems from people knowing how to use stuff, but not understanding concepts or why things are the way they are. This is actually also true for CSS. CSS was meant to support all kinds of output devices, regardless of being graphical or not, support screens in all sizes and nowadays people use it to only really support a low number of "pixelperfect" screen sizes with default settings. Everything else is completely broken. Nobody even bothers to look at new CSS3 features, new HTML 5 elements (unless it is for SEO), etc. In the end nobody is interested in implementing it correctly which usually results in standards to only slowly advance and having individual vendors only implementing their favorites or even their proposals and experiments, rendering the standard itself unusable, because of it being implemented by one single vendor. In the end we live in a world where the only thing that's really common inside the infrastructure are hacks to work around those problems. Most developers hoped this would change after Firefox ate a big part of IEs market share, but currently it seems to be repeating. Btw. I am not excluding myself from these things. I don't actively work into other directions and basically do the same things. Before you disagree: If you have something about CSS in your resume. Did you ever even completely read through CSS standards?

general_failure 12y ago

Browsers are struggling to support 1 toolset as-is. Imagine the message of multiple tool sets.

brandonbloom 12y ago
Browsers are only struggling because of how complex the toolset is and how poorly defined the expected results are. There are plenty of counter-examples with simple standards and multiple implementations of a high degree of quality and interoperability.
- recursive 12y ago
  plenty? Let's hear one.

georgemcbay 12y ago

"Does anyone think it'd be a good idea for browsers to support more than one toolset?" Some people do. I do. But it seems to be a minority opinion; most web developers seem to live in this weird cognitively dissonant state where the HTML DOM+CSS is always the right tool for the job because it theoretically allows for platform-independent layout to "any" browser while then spending most of their time dealing with getting their layouts to actually work on about a handful of real-world browsers which all treat the same layout code differently (in ways from subtle to large); resulting in piles of frameworks, pre-processing systems and general hackery to get everything working, mostly, most of the time. If there were a second toolset that were more rationally designed to solve the real-world problems of modern web apps, giving you layout via binding similar to what you see in Adobe Flex, WPF, Qt/QML, etc (not advocating any of those as the specific answer, just stating that I think they are all individually more sane than HTML/CSS/JS for app/UI layout) and just accepted the fact that the vast majority of websites are designed to be laid-out in a fairly constrained way (while still allowing for responsive layout for different sizes/dpis) I think web technology would be a lot less terrible. And just to get it out of the way, there are some good hacky solutions that help the problem I described, like React.js, Angular, Dart, etc, but they are all built on a shaky foundation which always manages to show through because we're stuck with HTML/CSS/JS.

taf2 12y ago
I used to believe using something like the tools you outlined would be easier until back in 2004 I spent 6 months porting my naitive windows application to apple. I scrapped the whole thing and started rebuilding on the predecessor to xulrunner, rebuilding mozilla and using XUL was great until I started to need graphing and different fluid layouts that I realized HTML is so much better for cross platform as more people are spending more hours every day making it better on more platforms and devices and it really is write once run everywhere once you move your native app to the server - at the end of the day you are going to spend countless hours tweaking for the different target OSs anyway - the web with HTML / CSS / JS are better at this than any other native solution... [update] we ported our native c++ components to xpcom interfaces and rebuilt the frontend in 4 months allowing us to launch our product simo health - later purchased by RevolutionHealth 4 months later... I still as recently as 3 months ago receive emails from past customers asking for updates.

Aldo_MX 12y ago

Did someone say Shockwave, Flash, Java, Silverlight, etc.? Or maybe VBScript, JScript, Dart, etc.?

e12e 12y ago

Arguably the removal of XLST/XML from the stack of tools browsers support(ed) in favour of JSON/JavaScript (or Anything-including-XML/JavaScript) is a good thing. I still think there are some good ideas in XML/XLST/SAX/XSD/RELAX NG -- but I think it's clear by now that web developers will not, or cannot, leverage the (rather minor) benefits XML can offer over json/javascript (richer datatypes, mostly -- javascript has gotten so fast that I don't think there's any real benefit to xml+sax over JSON in terms of memory/performance -- so once you throw away all your xml tools as well, there are little benefit remaining). Generally you can implement pretty much anything else on top of javascript. I do think we could use a better/different rendering model -- having documents/HTML as the base isn't a very good idea. Not sure what the answer would/should be -- seeing how Apple abandoned display postscript, I don't think PDF is the way to go -- perhaps something closer to GL? I'm a bit of a 90s luddite when it comes to "shiny web apps leveraging javascript for max bling" -- I much prefer gracefully-degrading html+css apps slightly augmented with javascript. But for better or worse, the immediate future clearly belongs to "download code over the internet;run it". Currently we're stuck with js+http+dom as the only real write-once-tweak-for-ever-run-most-places alternative. I think short time success will go to frameorsk like Elm and clojurescript that compile-to-the-browser. And at the rate of progress we seem to have, I don't think we'll see great platform for delivering apps/objects/runable data in the near future. We appear likely to move the visual basic worms of the 90s to javascript worms of the 10s -- never gaining any decent security or privacy -- because there is no demand for it. Luckily, well-designed "apps" based on html+css+conserative js can still be great, and have great performance, so I'll try and stick with that, and I'll let everyone else continue to design blogs that can't be read without running "actual" code on the client. For no real benefit (to the user -- to those selling ads/behavioural data the benefits are more tangible, but I'm not a user of that -- I'm just a victim of that). /rant.

johnpmayer 12y ago

Function calls and loops seem like a neat idea, but I dislike the fact they they compile down to JMP. It seems disingenuous. I'd much rather the CPU just be told this was a loop and ran with that properly.

tete 12y ago

More toolsets seems like the wrong way to me. The reason is that browsers barely even keep up with the current ones or even old ones. Also browsers work because of standards. It's not about the "best", but about agreeing. Recently I see many people trying to make one suboptimal thing by starting from scratch, removing all standards compatibility, throwing away all the knowledge that went in to a thing to make this one single thing work better, resulting only in incompatibilities, non-standards-conformance and making everything else than that one thing harder or even impossible. You can see this with web frameworks, with system tools, etc. Usually this stems from people knowing how to use stuff, but not understanding concepts or why things are the way they are. This is actually also true for CSS. CSS was meant to support all kinds of output devices, regardless of being graphical or not, support screens in all sizes and nowadays people use it to only really support a low number of "pixelperfect" screen sizes with default settings. Everything else is completely broken. Nobody even bothers to look at new CSS3 features, new HTML 5 elements (unless it is for SEO), etc. In the end nobody is interested in implementing it correctly which usually results in standards to only slowly advance and having individual vendors only implementing their favorites or even their proposals and experiments, rendering the standard itself unusable, because of it being implemented by one single vendor. In the end we live in a world where the only thing that's really common inside the infrastructure are hacks to work around those problems. Most developers hoped this would change after Firefox ate a big part of IEs market share, but currently it seems to be repeating. Btw. I am not excluding myself from these things. I don't actively work into other directions and basically do the same things. Before you disagree: If you have something about CSS in your resume. Did you ever even completely read through CSS standards?