Web Code is a solved Problem – how about fixing Web UI next?(weblog.west-wind.com)
weblog.west-wind.com
Web Code is a solved Problem – how about fixing Web UI next?
https://weblog.west-wind.com/posts/2018/May/31/Web-Code-is-a-solved-Problem-How-about-fixing-Web-UI-next
103 comments
Exactly. Plus op assume js is a solved problem. It's really, really not. The ecosystem is a total mess and a moving target, training new commers is hard, all designers must now know how to code but all artists are note made to be coders, page bloat is getting out of hand, setting up a modern project is quite complex, espacially debugging...
page bloat certainly is a problem, though the progress in device performance and bandwidth of mobile internet connections has been tremendous. I think people like Addy Osmani from Google are spreading awareness of provide in depth guides for drastic improvements, e.g. those two:
https://medium.com/dev-channel/the-cost-of-javascript-84009f...
https://images.guide/
https://medium.com/dev-channel/the-cost-of-javascript-84009f...
https://images.guide/
Has ui improved? Yes. But is ui a good experience? No.
Simple tasks like centering or multiple equal height columns are now possible (yay!) but aren't actually simple.
A large majority of css techniques are trying to get around how css tries to work.
Flexbox is great compared to what came before...but have you tried teaching it to someone new? Zindex and stack context? Style a container based on what it contains?
Compared to the improvements in js, and compared to the ease of use of non web ui building, there is a lot of room for progress.
Simple tasks like centering or multiple equal height columns are now possible (yay!) but aren't actually simple.
A large majority of css techniques are trying to get around how css tries to work.
Flexbox is great compared to what came before...but have you tried teaching it to someone new? Zindex and stack context? Style a container based on what it contains?
Compared to the improvements in js, and compared to the ease of use of non web ui building, there is a lot of room for progress.
What’s not simple?
CSS has spectacularly bad ergonomics and cognitive issues; for app development, it's particularly apparent with styles all over the place and having far-distance effects, and in any case a giant "impedance mismatch" to what you're doing in the main parts of your code. It might not be so obvious if you're working daily on CSS, but for casual use or use within a team with rotating roles it's really bad.
It also doesn't help that CSS's basic premise is flawed, and the fake narrative behind CSS's origin and role is insulting to any thinking person: that instead of typed markup attributes for some reason it's better to use an ever-growing bunch of ad-hoc micro syntax with poor checking and typing, and then postulating an arbitrary "semantic HTML" ideal after-the-fact. HTML is as syntactic as it gets; as it should, it being a standard in information presentation.
CSS is also incredibly bloated.
CSS has a serious issue with Stockholm syndrome (saying this as someone who also fell victim to it): once you "get" CSS and its many, many quirks, you're prone to dick-around with your CSS knowledge as a trophy to those who don't have the time and inclination to dabble around with it. In any case, CSS is seriously out of whack with the simplicity of HTML.
It also doesn't help that CSS's basic premise is flawed, and the fake narrative behind CSS's origin and role is insulting to any thinking person: that instead of typed markup attributes for some reason it's better to use an ever-growing bunch of ad-hoc micro syntax with poor checking and typing, and then postulating an arbitrary "semantic HTML" ideal after-the-fact. HTML is as syntactic as it gets; as it should, it being a standard in information presentation.
CSS is also incredibly bloated.
CSS has a serious issue with Stockholm syndrome (saying this as someone who also fell victim to it): once you "get" CSS and its many, many quirks, you're prone to dick-around with your CSS knowledge as a trophy to those who don't have the time and inclination to dabble around with it. In any case, CSS is seriously out of whack with the simplicity of HTML.
I was going to disagree but...
> It also doesn't help that CSS's basic premise is flawed, and the fake narrative behind CSS's origin and role is insulting to any thinking person: that instead of typed markup attributes for some reason it's better to use an ever-growing bunch of ad-hoc micro syntax with poor checking and typing, and then postulating an arbitrary "semantic HTML" ideal after-the-fact. HTML is as syntactic as it gets; as it should, it being a standard in information presentation.
On reflection I agree. I understand this approach when it's only document styling (here's a ruleset for h1, h2 etc kept separate from the HTML) but as soon as you start adding (multiple) classes... well yeah.
I fell into the yawning crevice that's semantic CSS, where "These class names give the HTML meaning". That and semantic HTML zealotry took up too much of my teenage years when I could've been making stuff, and have left me suspicious of any tech idea proclaimed with religious overtones.
> It also doesn't help that CSS's basic premise is flawed, and the fake narrative behind CSS's origin and role is insulting to any thinking person: that instead of typed markup attributes for some reason it's better to use an ever-growing bunch of ad-hoc micro syntax with poor checking and typing, and then postulating an arbitrary "semantic HTML" ideal after-the-fact. HTML is as syntactic as it gets; as it should, it being a standard in information presentation.
On reflection I agree. I understand this approach when it's only document styling (here's a ruleset for h1, h2 etc kept separate from the HTML) but as soon as you start adding (multiple) classes... well yeah.
I fell into the yawning crevice that's semantic CSS, where "These class names give the HTML meaning". That and semantic HTML zealotry took up too much of my teenage years when I could've been making stuff, and have left me suspicious of any tech idea proclaimed with religious overtones.
Yes, and the ideal of "semantic HTML" might even point at a deep misunderstanding of what's required for a content-delivery standard. Consider how the MP3 standards were created: by specifying a decoder from bits and bytes to sound, so that we can have devices that "play" content many years from now. WHATWG's "Living Standard" thing and the ongoing sugaring of JavaScript syntax and other added complexity is completely antithetical to this.
> have left me suspicious of any tech idea proclaimed with religious overtones
If for nothing else, that's a valuable lesson learned in it's own right :)
> have left me suspicious of any tech idea proclaimed with religious overtones
If for nothing else, that's a valuable lesson learned in it's own right :)
CSS clicked with me right away. As for semantic CSS (not really css, class names are HTML) it made sense, especially when I sawy .green10px being neither green nor 10px.
Centering is just `display:flex;align-items:center;justify-content:center;` on the parent. Equal height columns is just `display:flex;` on the parent. How is that not simple?
"Here's the 'display' property. It controls how the element is treated for flow. Or it decides how to change how the children are centered, when it's 'flex'. BTW, display:flex is totally unrelated to all other forms of flow control. We have multiple ways to center content, and vertical centering vs horizontal centering are not the same."
It's not impossibly complex, or even highly complex, but compared to any non-CSS layout, it's not simple. Only if you compare it to previous CSS layouts is it "simple".
It's not impossibly complex, or even highly complex, but compared to any non-CSS layout, it's not simple. Only if you compare it to previous CSS layouts is it "simple".
It even works if you just say `margin:auto` on the flex child
Only if it's a block or inline-block child though, right?
No, margin auto will center the child regardless of display property so long as the parent is a flexbox.
I want to say, as a guy who is not much of a web developer but is trying to make a web site, css is f'ing frustrating.
For example I found a CSS-only stylized dropdown list, which is great. Why should I have to use Javascript to stylize a dropdown list?
Anyway I take the component and css from codepen and put it in my site and it doesnt work, at all. Works perfectly on codepen, doesn't work on my site. As far as I can tell there really isn't a way of figuring out _why_ it isn't working either. There aren't any errors or anything, no real means of debugging it. I'm basically going through line-by-line the computed CSS for all the different parts and trying to see what's different and why that is impacting the look of the thing. Very frustrating.
For example I found a CSS-only stylized dropdown list, which is great. Why should I have to use Javascript to stylize a dropdown list?
Anyway I take the component and css from codepen and put it in my site and it doesnt work, at all. Works perfectly on codepen, doesn't work on my site. As far as I can tell there really isn't a way of figuring out _why_ it isn't working either. There aren't any errors or anything, no real means of debugging it. I'm basically going through line-by-line the computed CSS for all the different parts and trying to see what's different and why that is impacting the look of the thing. Very frustrating.
Have you had more positive experiences with any native alternative? My experience with em has generally been that they work well until you want to customize things.
I think people tend to seriously underestimate the complexity involved in dealing with layout and styles. CSS has some poor defaults and plenty of quirks, but it's also incredibly powerful and not that difficult if you bother taking the time to learn it properly. You are struggling because you have not learned to use the tool correctly.
Try implementing a few basic layout algorithms as a weekend project. I believe it'll change your view of CSS.
I think people tend to seriously underestimate the complexity involved in dealing with layout and styles. CSS has some poor defaults and plenty of quirks, but it's also incredibly powerful and not that difficult if you bother taking the time to learn it properly. You are struggling because you have not learned to use the tool correctly.
Try implementing a few basic layout algorithms as a weekend project. I believe it'll change your view of CSS.
So true. I looked at implementing some layout algorithms in PDF pages for a project I was working on; eventually realized I should just use the standard elements in the library I was using and forget about anything custom because otherwise I'd be making a separate product...
The worst part is trying to figure out which CSS property takes precedent and why that well is grey instead of white when you clearly said you wanted it to be white. But it’s inheriting it’s color from a parent div... somewhere.
The CSS inspector in most browsers these days has a "computed" section which lists every property and where it comes from, in order of precedence.
I think any language or technology you're not familiar with is frustrating and difficult to use.
Not trying to say that CSS is the best it can be, but I see lots of developers think that CSS isn't 'real programming' or think they can just float (heh) in and out of CSS development, not spend the effort on understanding it.
Not trying to say that CSS is the best it can be, but I see lots of developers think that CSS isn't 'real programming' or think they can just float (heh) in and out of CSS development, not spend the effort on understanding it.
CSS has poor defaults, but you can't break backwards compatibility on the web. Check out this gist [0], which sets far more sensible defaults for flexbox. I took it from css-layout, which was later renamed to yoga [1]. Everyone I've convinced to try it out has told me that they found it much more intuitive. It makes things work the way you'd expect them to!
I'd be genuinely interested in hearing about your experiences with other layout and styling languages or tools, and what you like about them. I used to hate on CSS a lot, but eventually changed my view and grew to like it, and I think given its history it's actually quite good. I haven't had much in-depth experience with native alternatives, but when I've tried em out I usually found they each have their own shortcomings. For example, on macOS I'd say Auto Layout is certainly easier when getting started, but as soon as you want to create your own components from scratch it becomes rather challenging.
As for styling a container based on what it contains, if you know of any examples which showcase good execution of this idea I'd also love to check em out. I know of at least two proposals / libraries which are attempts at tackling that problem in CSS; take a look at CSS-Element-Queries [2] and EQCSS [3].
[0] https://gist.github.com/cesarandreu/3e87cb6993bedeb162b56482...
[1] https://github.com/facebook/yoga
[2] http://marcj.github.io/css-element-queries/
[3] https://elementqueries.com/
I'd be genuinely interested in hearing about your experiences with other layout and styling languages or tools, and what you like about them. I used to hate on CSS a lot, but eventually changed my view and grew to like it, and I think given its history it's actually quite good. I haven't had much in-depth experience with native alternatives, but when I've tried em out I usually found they each have their own shortcomings. For example, on macOS I'd say Auto Layout is certainly easier when getting started, but as soon as you want to create your own components from scratch it becomes rather challenging.
As for styling a container based on what it contains, if you know of any examples which showcase good execution of this idea I'd also love to check em out. I know of at least two proposals / libraries which are attempts at tackling that problem in CSS; take a look at CSS-Element-Queries [2] and EQCSS [3].
[0] https://gist.github.com/cesarandreu/3e87cb6993bedeb162b56482...
[1] https://github.com/facebook/yoga
[2] http://marcj.github.io/css-element-queries/
[3] https://elementqueries.com/
> CSS has poor defaults, but you can't break backwards compatibility on the web.
That is why we should create something new that does not have this legacy baggage: The W3C tried this with XHTML 2.0
> https://en.wikipedia.org/w/index.php?title=XHTML&oldid=83709...
and it seems to have been much more elegant than HTML5:
> http://www.informit.com/articles/article.aspx?p=1994793
> https://web.archive.org/web/20100611220044/http://immike.net...
That is why we should create something new that does not have this legacy baggage: The W3C tried this with XHTML 2.0
> https://en.wikipedia.org/w/index.php?title=XHTML&oldid=83709...
and it seems to have been much more elegant than HTML5:
> http://www.informit.com/articles/article.aspx?p=1994793
> https://web.archive.org/web/20100611220044/http://immike.net...
Gods I miss the dream of the semantic web. I can’t seem to convey why it’s ideals are important to the younger generation. They seemingly just want to build proprietary apps to make money. I wanted to build data sources to help the world.
The death of semantic CSS still stings. I simply cannot stand the current state of just appending classes that don’t describe the data to style. It’s barely an improvement over using style attributes. The HTML should ideally have zero consideration for how it will look on the page and just describe the data within; admittedly that became something of CSSs failing though I believe a lot of that can be resolved with preprocessors to allow easier reuse.
The death of semantic CSS still stings. I simply cannot stand the current state of just appending classes that don’t describe the data to style. It’s barely an improvement over using style attributes. The HTML should ideally have zero consideration for how it will look on the page and just describe the data within; admittedly that became something of CSSs failing though I believe a lot of that can be resolved with preprocessors to allow easier reuse.
>Flexbox is great compared to what came before...but have you tried teaching it to someone new
Yes, and it's way easier than trying to explain floating and clearing to someone who doesn't know the box model. Compared to what came before, it actually makes logical sense.
Yes, and it's way easier than trying to explain floating and clearing to someone who doesn't know the box model. Compared to what came before, it actually makes logical sense.
That's my point though: Being way better and logical than what came before is NOT the same as being a good solution. The Article here is talking about how the UI experience is lagging behind the coding improvements. The poster a few posts above pointed out that CSS has indeed made progress. And my argument is that both statements can be true: CSS is much improved, but still sucks.
> Yes, and it's way easier than trying to explain floating and clearing to someone who doesn't know the box model.
That’s as hard as explaining arithmetic to someone who can’t read the numbers. The solution is the same: teach that first. The box model is not really complicated.
That’s as hard as explaining arithmetic to someone who can’t read the numbers. The solution is the same: teach that first. The box model is not really complicated.
Agree with this.
Plain HTML and CSS are good and simple enough on modern browsers.
Plain HTML and CSS are good and simple enough on modern browsers.
With an app-centric view of the Web like that, you can only come to the conclusion that the Web is broken. When in reality your premise is false: the Web is a document-centric self-publishing mechanism. That you're hell-bent to using it at as application delivery platform doesn't make it any more reasonable to judge the Web for something it simply isn't designed for. It's not a question of immaturity either: the Web has been in the making for almost 25 years; yet the newest mainstream Web frameworks (eg. React) still build on a DOM rather than a more appropriate scene graph model such as the one Flash had 15 years ago.
The problem isn't the Web, but people wanting to sell Web apps, yet still wanting to free-ride on the popularity and one-time-success of the Web. Why not address this at WHATWG (as in "Web Hypertext Application Working Group")? It would be easier for both camps because the document-oriented Web doesn't have to look after the incidental complexity introduced with overreaching Web standards and CSS.
Edit: see also "The Cult of the Complex" at https://news.ycombinator.com/item?id=17214045
The problem isn't the Web, but people wanting to sell Web apps, yet still wanting to free-ride on the popularity and one-time-success of the Web. Why not address this at WHATWG (as in "Web Hypertext Application Working Group")? It would be easier for both camps because the document-oriented Web doesn't have to look after the incidental complexity introduced with overreaching Web standards and CSS.
Edit: see also "The Cult of the Complex" at https://news.ycombinator.com/item?id=17214045
Hot take: it's a mistake to assume that document models don't apply to many apps.
Most of the apps that I use on my computer are fancy ways to process and display document-like information. Even many of the games I play fall into this category.
I would prefer for them not to get off of the web train, but rather to get rid of their app mentalities and embrace the principles they're complaining about on the web. Progressive enhancement, content/styling separation, user control over system access: these are all principles that I want in the majority of my apps.
The web isn't broken, and its philosophies should be used for many (not all, but many) apps. But the way we build apps is broken, so people assume the web either needs to change or that it shouldn't be used as a development platform.
The web is built around this concept where developers have very little control over the software they write. The tools seem weird and annoying and unnecessarily complicated because they're solving problems that most developers don't realize they have.
Most of the apps that I use on my computer are fancy ways to process and display document-like information. Even many of the games I play fall into this category.
I would prefer for them not to get off of the web train, but rather to get rid of their app mentalities and embrace the principles they're complaining about on the web. Progressive enhancement, content/styling separation, user control over system access: these are all principles that I want in the majority of my apps.
The web isn't broken, and its philosophies should be used for many (not all, but many) apps. But the way we build apps is broken, so people assume the web either needs to change or that it shouldn't be used as a development platform.
The web is built around this concept where developers have very little control over the software they write. The tools seem weird and annoying and unnecessarily complicated because they're solving problems that most developers don't realize they have.
> The problem isn't the Web, but people wanting to sell Web apps
That is backwards, I think. People want to use web to get their applications (for mostly good reasons). Of course developers will make them.
> yet still wanting to free-ride on the popularity
"Free riding" concept sounds misused here.
> Why not address this at WHATWG (as in "Web Hypertext Application Working Group")
How would that work? I want to make a SaaS app to solve some problem, but instead I write letters to WHATWG to do... what?
That is backwards, I think. People want to use web to get their applications (for mostly good reasons). Of course developers will make them.
> yet still wanting to free-ride on the popularity
"Free riding" concept sounds misused here.
> Why not address this at WHATWG (as in "Web Hypertext Application Working Group")
How would that work? I want to make a SaaS app to solve some problem, but instead I write letters to WHATWG to do... what?
My comment wasn't addressed at practitioners developing web apps so much as a response to principled criticism of the Web architecture as application development platform. As the author of TFA says he's coming from a Windows desktop app development background, praising early-90s RAD environments such as FoxPro for their superior workflow and adequateness for the job of creating business apps.
Then why not use those tools rather than the Web? But the author insists
> The last thing I want to see is us going back to native development as the first line for development. The Web has always been the future for application development and I believe it will go all the way in the end. I believe in the Web as a platform and I want it to stay as the dominant platform.
Why does the Web have to be everything to everybody, gaining incredible complexity to the point that it's useless as a standard because we're never going to see new independent implementations from scratch?
Re WHATWG: I don't think HTML5 is bad, but it must be said that it was the late 2000s "HTML5 rocks" propaganda making plugins (Flash and Java) unfashionable for better or worse. Turned out the offered overlapping and partially implemented alternatives (Canvas API, declarative CSS animations and shapes, SVG) were lacking, and didn't address the principal use cases. Those being describing highly interactive apps, controlled piercing of Web sandboxes for integration with native file systems and devices, etc.
Then why not use those tools rather than the Web? But the author insists
> The last thing I want to see is us going back to native development as the first line for development. The Web has always been the future for application development and I believe it will go all the way in the end. I believe in the Web as a platform and I want it to stay as the dominant platform.
Why does the Web have to be everything to everybody, gaining incredible complexity to the point that it's useless as a standard because we're never going to see new independent implementations from scratch?
Re WHATWG: I don't think HTML5 is bad, but it must be said that it was the late 2000s "HTML5 rocks" propaganda making plugins (Flash and Java) unfashionable for better or worse. Turned out the offered overlapping and partially implemented alternatives (Canvas API, declarative CSS animations and shapes, SVG) were lacking, and didn't address the principal use cases. Those being describing highly interactive apps, controlled piercing of Web sandboxes for integration with native file systems and devices, etc.
> Then why not use those tools rather than the Web?
I think the author of the article writes from the app developer perspective - his users are on the web and due to it's reach he's stuck there. He does appear to be cheering on the web as the application platform, but that might be the most reasonable way forward just because of it's momentum. And it is somewhat decent app development platform.
All of this comes at the cost of large amount of complexity, there I agree.
I think the author of the article writes from the app developer perspective - his users are on the web and due to it's reach he's stuck there. He does appear to be cheering on the web as the application platform, but that might be the most reasonable way forward just because of it's momentum. And it is somewhat decent app development platform.
All of this comes at the cost of large amount of complexity, there I agree.
> When in reality your premise is false: the Web is a document-centric self-publishing mechanism. That you're hell-bent to using it at as application delivery platform doesn't make it any more reasonable to judge the Web for something it simply isn't designed for.
The distinction between app-oriented and document-oriented is largely artificial anyway. They give you slightly different primitives, but the same set of programs are expressible in either paradigm (like the equivalency of Turing machines and the lambda calculus).
The main problem of HTML+CSS for the web is the inconsistencies in element styling and cross-browser support. You still can't apply some styles to buttons in some browsers, for instance. And this applies to both document publishing and web app development.
Things are much better with flexbox and soon CSS grid, but there's still considerable knowledge required to avoid the many pitfalls that should never have existed to begin with.
The distinction between app-oriented and document-oriented is largely artificial anyway. They give you slightly different primitives, but the same set of programs are expressible in either paradigm (like the equivalency of Turing machines and the lambda calculus).
The main problem of HTML+CSS for the web is the inconsistencies in element styling and cross-browser support. You still can't apply some styles to buttons in some browsers, for instance. And this applies to both document publishing and web app development.
Things are much better with flexbox and soon CSS grid, but there's still considerable knowledge required to avoid the many pitfalls that should never have existed to begin with.
I can't up-vote this comment enough. I've been saying web apps are broken for about 15 years. In the beginning everyone gets bent out of shape over technologies attempting to standardize like Flash and Applets. And since then everyone bitches about the disjointed, non-standard tech landscape.
It's like that whole community is schizophrenic.
It's like that whole community is schizophrenic.
I have to agree with @rado on this one. The article presents this as a "code" vs "UI" debate when really it's a "web" vs "app" debate.
Although we use the web as an application platform, it was designed for information interchange, and evolved to support "an Internet-scale distributed hypermedia system." Those are often two quite different things. An application platform focuses on "component semantics" whereas the concept of an "Internet-scale" application focuses on "connector semantics".
"Not only is the set of input controls really small, but these controls have almost no functionality associated with them." - yes and that's a useful attribute if you are architecting "internet-scale" applications (think hypermedia, rest, hateoas et al.) because the intent is that each component is dumb enough to be seamlessly switched out with another. In this mindset, a page in a web application does one thing and does it well. It doesn't coincidentally provide retina scanning and 3d imagery (yes, i know...)
Neither the code nor the UI of the web are "solved" problems if you are trying to use it as a traditional application programming platform. You need frameworks and tooling to accomplish that.
I'm not arguing here that it should be this way (although I happen to love the web concept), but the real debate here is about "web" vs "app" - not "code" vs "UI". HTML is designed to facilitate web applications and that will continue to evolve very slowly and deliberately. The alternative is to reimagine web technologies as a traditional application platform from the ground up.
Although we use the web as an application platform, it was designed for information interchange, and evolved to support "an Internet-scale distributed hypermedia system." Those are often two quite different things. An application platform focuses on "component semantics" whereas the concept of an "Internet-scale" application focuses on "connector semantics".
"Not only is the set of input controls really small, but these controls have almost no functionality associated with them." - yes and that's a useful attribute if you are architecting "internet-scale" applications (think hypermedia, rest, hateoas et al.) because the intent is that each component is dumb enough to be seamlessly switched out with another. In this mindset, a page in a web application does one thing and does it well. It doesn't coincidentally provide retina scanning and 3d imagery (yes, i know...)
Neither the code nor the UI of the web are "solved" problems if you are trying to use it as a traditional application programming platform. You need frameworks and tooling to accomplish that.
I'm not arguing here that it should be this way (although I happen to love the web concept), but the real debate here is about "web" vs "app" - not "code" vs "UI". HTML is designed to facilitate web applications and that will continue to evolve very slowly and deliberately. The alternative is to reimagine web technologies as a traditional application platform from the ground up.
"Web Code is a solved Problem"
honestly whenever I see this said about anything, I'm pretty sure it's not a solved problem.
honestly whenever I see this said about anything, I'm pretty sure it's not a solved problem.
Unpopular opinion: Please not another builtin high-level UI for the web, none of the native platforms got their 'system UI' right either, and there will never be a single UI solution for all problems.
Radical, overly optimistic suggestion: Reduce the browser to 2D+3D canvas, audio (not WebAudio please, too over-engineered), input, networking (...) and implement everything higher level on top of those thin platform abstraction APIs in JS+wasm modules that are loaded ond demand. Put the current HTML APIs into such modules as well for backward compatibility.
Radical, overly optimistic suggestion: Reduce the browser to 2D+3D canvas, audio (not WebAudio please, too over-engineered), input, networking (...) and implement everything higher level on top of those thin platform abstraction APIs in JS+wasm modules that are loaded ond demand. Put the current HTML APIs into such modules as well for backward compatibility.
That's a terrible suggestion. We need markup. We need standard markup. We need accesibility. We need semantic tags. We need interoperability. We need developer tools.
We don't need N+1 "standards". We don't need N*2 developer tools. We don't need N^2 teams working on subpar competing "platforms".
We need HTML.
We don't need N+1 "standards". We don't need N*2 developer tools. We don't need N^2 teams working on subpar competing "platforms".
We need HTML.
The HTML standard would be implemented in a module, which could even be bundled with browsers so it doesn't need to be downloaded on first use. Nothing would change for HTML usage except that it wouldn't be baked into the browser executable, and alternatives to HTML could be explored without bloating the browser even more.
The devil is in the details of course, that's why I wrote "overly optimistic" :)
The devil is in the details of course, that's why I wrote "overly optimistic" :)
I mean, Canvas is there. You're more than welcome to draw your own UIs in it, as plenty have done/tried before. Flipboard had a render-react-to-canvas project they used for mobile (which was completely inaccessible to any sort of assistive technologies), but I believe they abandoned it.
I kind of did and it works quite well. Fair point about accessibility though. Another problem is that there's no way to access system font data from WebGL. Also the way I'm currently doing rendering (continuous frame rendering even if the UI doesn't change) isn't mobile-friendly. But these are all solvable with a few more resources thrown at it (Dear ImGui is a single-developer-project, and the cross-platform rendering library (sokol-gfx) too.
http://floooh.github.io/oryol-sticky-tests/imgui-highdpi-sap...
This is 460 KByte wasm, 260 KByte of this is embedded TTF font data.
http://floooh.github.io/oryol-sticky-tests/imgui-highdpi-sap...
This is 460 KByte wasm, 260 KByte of this is embedded TTF font data.
Wow. Your library is simply amazing. Especially considering it's a single-developer project.
Ah sorry I was unclear, Dear ImGui isn't my library. Credit goes to @ocornut: https://github.com/ocornut
The sokol_gfx graphics wrapper is my stuff, but that's much smaller :)
The sokol_gfx graphics wrapper is my stuff, but that's much smaller :)
Still amazing :)
Interesting idea, so you're proposing different standards of HTML for different web apps? Seems like added complexity for simplified app development
I'm still super gung-ho about web components. The progressive browsers are committed to making it happen.
The picture is not so bleak for custom elements: https://caniuse.com/#feat=custom-elementsv1
Firefox also just announced that Shadow DOM arrived in a nightly:
https://bugzilla.mozilla.org/show_bug.cgi?id=1460069
https://news.ycombinator.com/item?id=17172613
Contrary to popular belief, you can start using web components WITH just custom elements and WITHOUT shadow DOM! https://twitter.com/rob_dodson/status/961780022628331520
I jumped onto this bandwagon early and struggled with Polymer 2 and HTML imports (ugh!). Now they have made the same realizations and moving forward LitElement will lead the charge toward usable and lightweight web components:
https://www.polymer-project.org/blog/2018-05-02-roadmap-upda...
https://github.com/Polymer/lit-element
Here's how you can get started: https://github.com/Polymer/pwa-starter-kit/wiki
It's not paradise, there are kinks to work out, but ultimately one can make production worthy apps with web components TODAY (polyfills available). You can sleep at night not worrying that your library will become the new jQuery someday: https://twitter.com/SaraSoueidan/status/999645120155746304
The picture is not so bleak for custom elements: https://caniuse.com/#feat=custom-elementsv1
Firefox also just announced that Shadow DOM arrived in a nightly:
https://bugzilla.mozilla.org/show_bug.cgi?id=1460069
https://news.ycombinator.com/item?id=17172613
Contrary to popular belief, you can start using web components WITH just custom elements and WITHOUT shadow DOM! https://twitter.com/rob_dodson/status/961780022628331520
I jumped onto this bandwagon early and struggled with Polymer 2 and HTML imports (ugh!). Now they have made the same realizations and moving forward LitElement will lead the charge toward usable and lightweight web components:
https://www.polymer-project.org/blog/2018-05-02-roadmap-upda...
https://github.com/Polymer/lit-element
Here's how you can get started: https://github.com/Polymer/pwa-starter-kit/wiki
It's not paradise, there are kinks to work out, but ultimately one can make production worthy apps with web components TODAY (polyfills available). You can sleep at night not worrying that your library will become the new jQuery someday: https://twitter.com/SaraSoueidan/status/999645120155746304
> I'm still super gung-ho about web components.
Please tell me how web components solve the issue described in the article, namely that one of UI?
I am not even going to get started on the extremely limited capabilities of these components and the need for yet another batch of dozens of frameworks to make them even remotely useful.
Please tell me how web components solve the issue described in the article, namely that one of UI?
I am not even going to get started on the extremely limited capabilities of these components and the need for yet another batch of dozens of frameworks to make them even remotely useful.
I know a lot of people are excited about them, but I still have problems with how web components are being designed.
Custom elements feel like we're moving in the opposite direction from semantic markup - they just degrade into divs, so they're not particularly meaningful unless the DOM used to construct them is also descriptive and meaningful. So immediately we get Shadow DOM which hides a bunch of stuff from the end user. It's really clearly bad for accessibility and user control.
Beyond that, it's not clear to me what problem we're solving:
- Integrated templates into HTML: Okay, I get it, potentially useful. You don't need custom elements for that.
- Blocking global CSS from styling your components: Valid, but this is a really hacky way to solve that problem. What we'd prefer is CSS boundaries that don't require JS to use.
The main thing seems to be that people think the code looks cleaner than using divs and CSS classes. Which... great, I kind of agree. But why should I be so excited about what basically boils down to syntactic sugar?
The one super useful, really exciting part of web components was HTML import. HTML imports would have been amazing.
But that effort has been messed up as well - it relies on Javascript. We can already use Javascript to make AJAX requests and append content to the DOM. What we can't do is include a single header across multiple pages without building either a webapp or a preprocessor.
I think Mozilla is in the right to have dragged their feet so much on this. Beyond shadow DOM, which I'm nonplussed about, what is now possible with modern web components that wasn't already possible 3-5 years ago?
Custom elements feel like we're moving in the opposite direction from semantic markup - they just degrade into divs, so they're not particularly meaningful unless the DOM used to construct them is also descriptive and meaningful. So immediately we get Shadow DOM which hides a bunch of stuff from the end user. It's really clearly bad for accessibility and user control.
Beyond that, it's not clear to me what problem we're solving:
- Integrated templates into HTML: Okay, I get it, potentially useful. You don't need custom elements for that.
- Blocking global CSS from styling your components: Valid, but this is a really hacky way to solve that problem. What we'd prefer is CSS boundaries that don't require JS to use.
The main thing seems to be that people think the code looks cleaner than using divs and CSS classes. Which... great, I kind of agree. But why should I be so excited about what basically boils down to syntactic sugar?
The one super useful, really exciting part of web components was HTML import. HTML imports would have been amazing.
But that effort has been messed up as well - it relies on Javascript. We can already use Javascript to make AJAX requests and append content to the DOM. What we can't do is include a single header across multiple pages without building either a webapp or a preprocessor.
I think Mozilla is in the right to have dragged their feet so much on this. Beyond shadow DOM, which I'm nonplussed about, what is now possible with modern web components that wasn't already possible 3-5 years ago?
Another +1 for web components. We have been using this paradigm exclusively for new features and it's really fantastic. Template literals eliminate the need for things like JSX and you can just use small simple libraries for state management and data binding. Keep every web component in it's own NPM module with it's own test suite and dependency resolution, and have a single package.json that describes your entire app.
Would you recommend any specific combination of libraries boilerplate/starter kit? (I suppose I should just search npm, GitHub..) I feel like there are almost too many libraries for, i.e., transforming template literals to HTML, data binding, state management, etc. I know "do one thing only", but it can be daunting to figure out an optimal integrated setup.
Is there a popular/well-used set of tools for the kind of web-component based projects that you're describing? Polymer is one, I recall - wasn't too keen on it last time I looked at it, would prefer more minimal/modular..
Is there a popular/well-used set of tools for the kind of web-component based projects that you're describing? Polymer is one, I recall - wasn't too keen on it last time I looked at it, would prefer more minimal/modular..
[deleted]
This is one of the reasons I'm such a fan of Vue.js. Using the vue-loader, you write single-file 'components' which all their included templating, logic, and style. While not EXACTLY what the promise of "Web Components"/"Custom Components" offers, it is definitely a good step forward in thinking on how to modularize all the pieces of the front-end.
https://vuejs.org/
https://github.com/vuejs/vue-loader
https://vuejs.org/
https://github.com/vuejs/vue-loader
[deleted]
yep that and vue-cli and you have all the framework you need including a dev server and a test framework.
> CSS Grid works with all major evergreen browsers, but Internet Explorer - which sadly still has significant browser share - is not supported by CSS Grid.
Well, it does support Grid, just an older, prefixed version of the spec, with plenty of bugs. With autoprefixer (which I use via postcss-cssnext), you have to deliberately enable IE grid support (config option `grid: true`), and then it will block you from doing things in Grid that IE definitely doesn’t cope with, and you will still sometimes have to make adjustments to get it to work (e.g. IE has no qualms about stacking content in the same cell, so you may need to specify locations rather than using auto layout), but it hasn’t been too bad for most stuff I’ve done so far.
IE’s share steadily shrinks, and what remains consolidates around IE11. These days I’d say that the vast majority of developers should care a little about IE11 (my rule of thumb is to ensure everything works, but some ugliness or deviation from design is acceptable), possibly a bit about IE9, and definitely not at all about any other version of IE.
Just wait another two years and then you can forget about IE for good, or something. ;-)
Well, it does support Grid, just an older, prefixed version of the spec, with plenty of bugs. With autoprefixer (which I use via postcss-cssnext), you have to deliberately enable IE grid support (config option `grid: true`), and then it will block you from doing things in Grid that IE definitely doesn’t cope with, and you will still sometimes have to make adjustments to get it to work (e.g. IE has no qualms about stacking content in the same cell, so you may need to specify locations rather than using auto layout), but it hasn’t been too bad for most stuff I’ve done so far.
IE’s share steadily shrinks, and what remains consolidates around IE11. These days I’d say that the vast majority of developers should care a little about IE11 (my rule of thumb is to ensure everything works, but some ugliness or deviation from design is acceptable), possibly a bit about IE9, and definitely not at all about any other version of IE.
Just wait another two years and then you can forget about IE for good, or something. ;-)
> Just wait another two years and then you can forget about IE for good
Because most developers will target chrome with a current market share of about 60%.
I bet google will stop to innovate and compete as soon as they ate most of the cake, hopefully without forcing "standards" on other browser.
But some of their products is already crippled on other browsers, so that ship might have sailed already.
In another two years, or something.
Because most developers will target chrome with a current market share of about 60%.
I bet google will stop to innovate and compete as soon as they ate most of the cake, hopefully without forcing "standards" on other browser.
But some of their products is already crippled on other browsers, so that ship might have sailed already.
In another two years, or something.
So the author claims that the JS ecosystem is excellent and HTML&CSS are broken? Yet it is my never-ending experience with the web that a website’s usability is inversely proportional to the extent it uses fancy JS frameworks.
Think back to the inspiration for modern UI. It's a flight engineer in the back of the cockpit, or an astronaut on his way to the moon. He has some buttons and switches, a lot of gauges and maybe a couple of digital displays. Then think about documents. The written word. Information graphics. What the web has been trying to do is make an astronaut's control panel the same kind of thing as a Guttenberg bible. That is a very tall order, and it's not surprising that it's taking some iteration.
> I got my start in FoxPro, worked some in VB6 and MFC/C++ and then worked in .NET WinForms and WPF which I still use on occasion to this day for things that simply work better on the desktop - mostly tools or applications that need to interface with hardware.
> When I think back on those days one thing that stands out to me is how easy and fast it was to develop functional UIs for these applications due to a plethora of pre-made components, easy to use visual tools that allow easy placement and visualization of content. And maybe more importantly a well defined underlying UI API that supported creation of common controls that addressed the most common use cases.
The sheer ugliness that is produced by .Net developers is astounding. The simplest most ridiculous thing is the sizing of buttons. The great simple thing of using something like bootstrap is that buttons are padded in nice proportions. The only options are text, S/M/L and some colour styles. But if you hand a developer a form designer tool they generate buttons 10x bigger dumped somewhere in the middle of the form.
The other WPF form that's been around wehre I work for 8 years has a peach coloured background... because the company logo is kind of orange.
Sticking to the rules that boostrap / material design give you produces quite nice looking and usable interfaces. But sticking to the rules of Windows UIs gives you at best usable but almost never nice looking.
Then of course there's the unholy curse of Java UIs...
> When I think back on those days one thing that stands out to me is how easy and fast it was to develop functional UIs for these applications due to a plethora of pre-made components, easy to use visual tools that allow easy placement and visualization of content. And maybe more importantly a well defined underlying UI API that supported creation of common controls that addressed the most common use cases.
The sheer ugliness that is produced by .Net developers is astounding. The simplest most ridiculous thing is the sizing of buttons. The great simple thing of using something like bootstrap is that buttons are padded in nice proportions. The only options are text, S/M/L and some colour styles. But if you hand a developer a form designer tool they generate buttons 10x bigger dumped somewhere in the middle of the form.
The other WPF form that's been around wehre I work for 8 years has a peach coloured background... because the company logo is kind of orange.
Sticking to the rules that boostrap / material design give you produces quite nice looking and usable interfaces. But sticking to the rules of Windows UIs gives you at best usable but almost never nice looking.
Then of course there's the unholy curse of Java UIs...
You should compare stock wpf and html that renders the system controls. Otherwise there are many equivalents to bootstrap in the wpf world. The team that made your wpf probably would have made the same abomination.
Niche enterprise UIs never even got the benefit of one designed, let alone a team. The devs could be handed the most amazing and the result would still look “undesigned”.
Bootstrap provides cookie cutter design solutions, but it is well known that you’ll benefit from a designer if you need something more custom (and your UI will look bad if you don’t invest much in its design).
Bootstrap provides cookie cutter design solutions, but it is well known that you’ll benefit from a designer if you need something more custom (and your UI will look bad if you don’t invest much in its design).
I think bootstrap is great for all the sysadmins etc that need to create a tool but don't want to spend days tunning css.
The fact that there is no standardized date picker for the web in 2018 is impressive.
Yes this. That to get cracking functionality you have to include React, in order to include AirBnB's superb one [1].
1. http://airbnb.io/react-dates/
1. http://airbnb.io/react-dates/
Maybe we need the web to be a way to publish basic documents, and then use docker-like thing where people publish apps and you can immediately access them by downloading the upper layers.
What's happening now is the reverse, expanding the Web APIs to become an OS when we already have so many of those. HyperKit, Hyper-V, and Linux containers (or whatever docker) use are already there!
Web Components solve most of the problems he describes here, yet he claims they only work in Chrome so it'll be another two years. That's false. We've built the next version of Ionic controls 100% as web components, specifically targeting mobile, and we've been incredibly happy with how ready they are.
Sure, building web components really benefits from some sugar (much like jQuery back then), but once you have that sugar they work great (we built a helper WC tool called Stencil: http://stenciljs.com/).
Now that web components are ready, we just need to educate people on how they can start using custom components through normal HTML tags. We're on to phase two.
Sure, building web components really benefits from some sugar (much like jQuery back then), but once you have that sugar they work great (we built a helper WC tool called Stencil: http://stenciljs.com/).
Now that web components are ready, we just need to educate people on how they can start using custom components through normal HTML tags. We're on to phase two.
All of current HTML and CSS standards still assume that web pages are just that: static paper-like pages.
Vast majority of JS code and frameworks treat web pages as parts of applications, where static paper-like pages may happen, but only as a view within a larger app.
I usually bring Sencha as an example. It's as impossible to build anything remotely close to Sencha's components today as it was 15 years ago when it was called just ExtJS[1].
[1] http://examples.sencha.com/extjs/6.2.0/examples/kitchensink/...
Vast majority of JS code and frameworks treat web pages as parts of applications, where static paper-like pages may happen, but only as a view within a larger app.
I usually bring Sencha as an example. It's as impossible to build anything remotely close to Sencha's components today as it was 15 years ago when it was called just ExtJS[1].
[1] http://examples.sencha.com/extjs/6.2.0/examples/kitchensink/...
Here's the CSS fix not enough people are paying attention to: http://gss.github.io/
My understanding is that this approach was rejected because of path-dependence of the layout, i.e. deterministic only if you include the full interaction history. Path-dependence in a layout engine would be a debugging nightmare.
The sad thing about GSS is that Cassowary Constraint Solver was proposed to w3c in 1999 (!!!), and it was rejected on the grounds that it might be too costly in terms of power etc.
Edited to clarify meaning
Edited to clarify meaning
A simple step forward would be to standardize SCSS and start moving to native browser support rather than compilers. That doesn't seem hard to do.
Code is solved because you use a JS framework.
UI is unsolved, because you don't use a UI framework.
What a strange article.
>You step away from the Web world for a month and you come back and there are 20 new things you need to look at
Generally a problem is not solved when people keep trying to come up with new solutions for it every month
Generally a problem is not solved when people keep trying to come up with new solutions for it every month
> Ask most Web developers about the biggest pain point in Web applications today, and they will likely tell you that Web UI is their biggest time sink.
I would say this is equally true for most native app developers.
I would say this is equally true for most native app developers.
The problem is with the average UI designers, the average frontend developers, the average backend developers and the average micro-managers as well as the slice 'n' dice let's-pretend-it's-agile way of working. I am guilty of being one of these average team players but after doing some frontend work the average agency way I now know a little bit about how stupid the problem is.
Your average website looks pretty but lurking behind it is 10000 lines of CSS, none of it maintainable and put together by some silly build tools that hide rather than solve the problem.
This CSS is like Jenga, take one line out and it falls apart. The only thing the average frontend developer can do is add more cruft to it. They don't have the bravado to chuck it all out, to start over with CSS Grid and forget every bit of margin and padding they have 'learned' over the past years. Plus they would have to do all that in their spare time, their sliced 'n' diced 'agile' workflow just would not allow for it.
So we still have this charade of average 'web designers' making up drawings in some artworker program of what the thing should look like. They add their own flair - let's put the search box on the left, shall we? None of what they do is needed as the way to lay out content on a page is pretty much worked out. Plus these average designers work with placeholder copy and never real content. Plus they never ask the devs what can and cannot be done, with every client there are special things needed bespoke just for that client and their market niche. Dev's can do that stuff but they don't get to talk to the client and don't understand what the client is trying to do.
The average web 'designer' then gets the designs signed off with the client and the whole thing is then bundled off to the team who do code things. By now it is too late for the dev team to say 'we could have done that whole thing in CSS Grid by tea time', it is all nailed down and has to be delivered the old fashioned way to exactly match the PDFs or whatever the designs came in on.
So the same base templates from the same package get rolled out and those templates pull in antiquated cruft such as 'moderniser' or 'jquery'. The carousel goes on the home page, again needing a library of more JS and CSS that gets churned together with one of these 'build tools'.
To make the site 'faster' a CDN gets used, a bigger AWS box gets used, third party plugins do things to mangle the images so everyone gets to see the same cruddy images whatever platform they are on.
Even worse is what happens to content. It is arranged to work with the 'divs' and 'floats' and 'position absolute' gubbins, often with the layout different on mobile/desktop because the same content is repeated twice and hidden accordingly.
Regarding the javascripts, there is no need for 99% of it. Input boxes don't need it, image viewers don't need it but the average website delays for ten seconds or so on mobile because none of the average experts thought outside the box and bothered to RTFM and KISS in a DRY way.
Thank goodness for Google and Mozilla, there is innovation aplenty and the real challenge is how average web developers work in average agencies. It reminds me of being at university and how people did assignments by essentially copying what everyone else did and not going first principles it, to actually understand what is going on.
I am personally grateful of this situation as I can see possibilities to make lots of money rescuing small businesses from the burden of average clock-watching frontend web developers and average designers.
Of course, none of this applies to the HN reading crowd and those people doing fantastic work, just those people still churning out Jenga CSS.
Your average website looks pretty but lurking behind it is 10000 lines of CSS, none of it maintainable and put together by some silly build tools that hide rather than solve the problem.
This CSS is like Jenga, take one line out and it falls apart. The only thing the average frontend developer can do is add more cruft to it. They don't have the bravado to chuck it all out, to start over with CSS Grid and forget every bit of margin and padding they have 'learned' over the past years. Plus they would have to do all that in their spare time, their sliced 'n' diced 'agile' workflow just would not allow for it.
So we still have this charade of average 'web designers' making up drawings in some artworker program of what the thing should look like. They add their own flair - let's put the search box on the left, shall we? None of what they do is needed as the way to lay out content on a page is pretty much worked out. Plus these average designers work with placeholder copy and never real content. Plus they never ask the devs what can and cannot be done, with every client there are special things needed bespoke just for that client and their market niche. Dev's can do that stuff but they don't get to talk to the client and don't understand what the client is trying to do.
The average web 'designer' then gets the designs signed off with the client and the whole thing is then bundled off to the team who do code things. By now it is too late for the dev team to say 'we could have done that whole thing in CSS Grid by tea time', it is all nailed down and has to be delivered the old fashioned way to exactly match the PDFs or whatever the designs came in on.
So the same base templates from the same package get rolled out and those templates pull in antiquated cruft such as 'moderniser' or 'jquery'. The carousel goes on the home page, again needing a library of more JS and CSS that gets churned together with one of these 'build tools'.
To make the site 'faster' a CDN gets used, a bigger AWS box gets used, third party plugins do things to mangle the images so everyone gets to see the same cruddy images whatever platform they are on.
Even worse is what happens to content. It is arranged to work with the 'divs' and 'floats' and 'position absolute' gubbins, often with the layout different on mobile/desktop because the same content is repeated twice and hidden accordingly.
Regarding the javascripts, there is no need for 99% of it. Input boxes don't need it, image viewers don't need it but the average website delays for ten seconds or so on mobile because none of the average experts thought outside the box and bothered to RTFM and KISS in a DRY way.
Thank goodness for Google and Mozilla, there is innovation aplenty and the real challenge is how average web developers work in average agencies. It reminds me of being at university and how people did assignments by essentially copying what everyone else did and not going first principles it, to actually understand what is going on.
I am personally grateful of this situation as I can see possibilities to make lots of money rescuing small businesses from the burden of average clock-watching frontend web developers and average designers.
Of course, none of this applies to the HN reading crowd and those people doing fantastic work, just those people still churning out Jenga CSS.
It seems unfair to compare a proprietary and closed system api to a standards based one. Where there are many companies with different and conflicting goals setting the standards.
We're trying to solve exactly this problem with Pagedraw! Check out https://pagedraw.io/
Manual X/Y and width and no flexbox or even Bootstrappy column settings in sight? No thanks.
Try https://diasli.de (not able to export to HTML or a component yet, but the editor is a bit better and works across browsers)
Yikes!
"Sorry, our editor is optimized for Chrome"
"Sorry, our editor is optimized for Chrome"
That is an amazing characteristic in a project for building websites. What in the what.
I though we'd not see those messages after IE6 died but Chrome stepped up and filled that role : - |
What's even worse: It isn't "optimized" for Chrome, it only works in Chrome.
Detail question:
Why does he talk about HTML5 being 8 years old? Wasn't the first release in 2013 (or something)? Help me out here...
Why does he talk about HTML5 being 8 years old? Wasn't the first release in 2013 (or something)? Help me out here...
timeline differs if the standards work is taken into account, not the widespread implementation by browser vendors. See here: https://en.wikipedia.org/wiki/HTML5#History
+ a standard to close session (logout)
Web code is clearly unsolved:
1. The elephant in the room, Apple, is highly non compliant with web standards (iOS Safari lacks js web workers, webgl 2, WebRTC data channel, and many many others)
2. The roadmap of webassembly is merely the start of glaring unsolved problems
3. GPU compute will play an increasingly important role in the future, given the advent of AI, complex cryptography, video, image,... The web and browser have outdated and insufficient support for the same
4. Access to sensors and peripherals is abysmal. WebUsb is a step in the right direction, but much needs to happen there
1. The elephant in the room, Apple, is highly non compliant with web standards (iOS Safari lacks js web workers, webgl 2, WebRTC data channel, and many many others)
2. The roadmap of webassembly is merely the start of glaring unsolved problems
3. GPU compute will play an increasingly important role in the future, given the advent of AI, complex cryptography, video, image,... The web and browser have outdated and insufficient support for the same
4. Access to sensors and peripherals is abysmal. WebUsb is a step in the right direction, but much needs to happen there
> iOS Safari lacks js web workers, webgl 2, WebRTC data channel, and many many others
Are you referring to service workers? I've been using web workers on iOS for years.
Are you referring to service workers? I've been using web workers on iOS for years.
Mozilla [1] lists webworker support on iOS to be basic, clearly lagging in compliance.
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
> clearly lagging in compliance
What is missing is shared workers support (and producing output from console.log in web workers). Of the two, shared workers would be a particularly useful feature, as it would in theory enable different browser tabs to utilize a shared, potentially resource hungry script, as per the Mozilla description at https://developer.mozilla.org/en-US/docs/Web/API/SharedWorke...
The devs at Apple claims that this use case is not relevant and/or better served by Service Workers (which is even less supported). Not sure I understand their reasoning. https://bugs.webkit.org/show_bug.cgi?id=116359
What is missing is shared workers support (and producing output from console.log in web workers). Of the two, shared workers would be a particularly useful feature, as it would in theory enable different browser tabs to utilize a shared, potentially resource hungry script, as per the Mozilla description at https://developer.mozilla.org/en-US/docs/Web/API/SharedWorke...
The devs at Apple claims that this use case is not relevant and/or better served by Service Workers (which is even less supported). Not sure I understand their reasoning. https://bugs.webkit.org/show_bug.cgi?id=116359
I started to find the compliance tables on MDN outdated. I am not sure how they are being updated but my guess is that it is manual and needs to be revisited.
And iOS + mac safari have service workers now
>4. Access to sensors and peripherals is abysmal. WebUsb is a step in the right direction, but much needs to happen there
FWIW Chrome 67 has just shipped with initial support for the Generic Sensor API spec
https://developers.google.com/web/updates/2018/05/nic67#gene...
https://www.w3.org/TR/generic-sensor/
FWIW Chrome 67 has just shipped with initial support for the Generic Sensor API spec
https://developers.google.com/web/updates/2018/05/nic67#gene...
https://www.w3.org/TR/generic-sensor/
I work On UI/UX for B2B software businesses and the reason Isee for the problem is that the web is built by engineers. There has been a big focus on code quality, best practices, frameworks etc. But the majority of these engineers didn’t spend time on UI. This is definitely changing. 95% of our customers are great engineers that are seeing the value good UI/UX can add to their product and help deliver a better experience to their user. We’re in the early stages of this shift, but forward thinking engineers are already paving the way.
http://fairpixels.pro
http://fairpixels.pro
winform and win32 were built by engineers. Wpf had much more thought put in place for design aspects. The problem s we try to write applications in a system designed for documents.
UI would be a solved problem from an engineering perspective if someone could define what was necessary for building a good UI, for all time, without working directly with pixels, and without completely obliterating the at least somewhat secure browser sandboxing.
There are essentially no unknowns from an engineering perspective to create any possible ( not impossible ) solution in this space, except for two: What is a good UI, and how do we make almost intrinsically safe execution environment for categorically untrusted code?
There might be, and probably is objectively good UI practices, but what is considered by most to be good UI changes with fashion, with what primitives are available, and what is almost - but not entirely - possible at any point in time.
The kind of freedom the author seem to want is probably not possible to do in any reasonable secure way without all operative systems makers agree on a rather advanced security model that continues far outside the browser, in fact it has to essentially replace the default OS model for all content generated from the browser, and for any application that has ever interacted with any such content.
Looking at saving a file without a save dialog as an example, it might sound trivial, but then the smallest bug in the browser, which is a very complicated runtime for executing distributed content of mostly untrusted nature, could rewrite any file into an executable Trojan horse, completely taking over control the next time you run it.
To avoid this, the OS would have to restrict anything saved or generated from a page to the same set of restrictions that page had, transitively.
Even the possibility to save anything at all opens this window quite a bit, but not at all to the same extent as being able to do it silently. In addition to the obvious reasons, there are other benefits like not having to keep a list of allowed files, and thus can't as easily be tricked as easily to reveal the local names of those files either through direct attacks, or side-channel attacks. Unless you are okay with the 'application' not knowing the name of the files, but then someone is going to complain that it's impossible to make a 'recent files' menu, and thus the circle continues.
There are actually solutions to this that are plausible from a technical and engineering perspective, but they all work by extending the sometimes cumbersome restrictions of the browser right into the native environment to an extent that would probably make OS companies extinct in short order. They are likely to want to either avoid this, or try to become a single supplier. The various strategies of the actors in this space seems to be rather obvious.
There are essentially no unknowns from an engineering perspective to create any possible ( not impossible ) solution in this space, except for two: What is a good UI, and how do we make almost intrinsically safe execution environment for categorically untrusted code?
There might be, and probably is objectively good UI practices, but what is considered by most to be good UI changes with fashion, with what primitives are available, and what is almost - but not entirely - possible at any point in time.
The kind of freedom the author seem to want is probably not possible to do in any reasonable secure way without all operative systems makers agree on a rather advanced security model that continues far outside the browser, in fact it has to essentially replace the default OS model for all content generated from the browser, and for any application that has ever interacted with any such content.
Looking at saving a file without a save dialog as an example, it might sound trivial, but then the smallest bug in the browser, which is a very complicated runtime for executing distributed content of mostly untrusted nature, could rewrite any file into an executable Trojan horse, completely taking over control the next time you run it.
To avoid this, the OS would have to restrict anything saved or generated from a page to the same set of restrictions that page had, transitively.
Even the possibility to save anything at all opens this window quite a bit, but not at all to the same extent as being able to do it silently. In addition to the obvious reasons, there are other benefits like not having to keep a list of allowed files, and thus can't as easily be tricked as easily to reveal the local names of those files either through direct attacks, or side-channel attacks. Unless you are okay with the 'application' not knowing the name of the files, but then someone is going to complain that it's impossible to make a 'recent files' menu, and thus the circle continues.
There are actually solutions to this that are plausible from a technical and engineering perspective, but they all work by extending the sometimes cumbersome restrictions of the browser right into the native environment to an extent that would probably make OS companies extinct in short order. They are likely to want to either avoid this, or try to become a single supplier. The various strategies of the actors in this space seems to be rather obvious.
Web Code is definitely not a solved problem. I am working on a project in Angular right now and it has advantages and major trade offs over writing it in plain JS. I’m at this point not sure it was worth it.
As far as Web UI goes, Angular has the Material Library, Bootstrap was all the rage a few years ago and there would have been this same article in reverse.
But the reality is these things are never solved. You may just feel happy with the current state of something but it won’t stay that way for long. These massive JS frameworks are probably a fad.
As far as Web UI goes, Angular has the Material Library, Bootstrap was all the rage a few years ago and there would have been this same article in reverse.
But the reality is these things are never solved. You may just feel happy with the current state of something but it won’t stay that way for long. These massive JS frameworks are probably a fad.
If you made a website in the 90s or early noughts, everything was tables. Do you remember how to make a button with a bevel in 2005? You made a 3x3 table, and had to splice an image into 9 different sub images, and then stitch them all together. Now you have background:linear-gradient and border-radius. I mean, maybe you take this for granted now, but seriously, that was game changing for me when those things came out.
Now add on UI frameworks like Bootstrap and Zurb. Before everything was a JPG photoshop mockup. Every design was treated in isolation. There were entire businesses revolved around taking a PSD and turning it into HTML/CSS. Now everything is a component. It's reusable...and useable. Sure, we may have watered down design to the point where largely every SaaS landing page is the same, but the speed with which we can get developers to convey trust via design is vastly improved over the old days.
Sure, JS frameworks are all the rage right now. But we have made serious strides in web UIs as well.