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.
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.
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  and EQCSS .
That is why we should create something new that does not have this legacy baggage: The W3C tried this with XHTML 2.0
and it seems to have been much more elegant than HTML5:
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.
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.
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.
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.
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".
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 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.
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.
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.
> 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 :)
Plain HTML and CSS are good and simple enough on modern browsers.
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
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.
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?
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.
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.
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.
It's like that whole community is schizophrenic.
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.
honestly whenever I see this said about anything, I'm pretty sure it's not a solved problem.
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.
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 devil is in the details of course, that's why I wrote "overly optimistic" :)
This is 460 KByte wasm, 260 KByte of this is embedded TTF font data.
The sokol_gfx graphics wrapper is my stuff, but that's much smaller :)
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:
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:
Here's how you can get started:
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
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.
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?
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..
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.
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. ;-)
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.
> 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...
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).
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.
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.
Edited to clarify meaning
Generally a problem is not solved when people keep trying to come up with new solutions for it every month
I would say this is equally true for most native app developers.
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.
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.
"Sorry, our editor is optimized for Chrome"
Why does he talk about HTML5 being 8 years old? Wasn't the first release in 2013 (or something)? Help me out here...
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
Are you referring to service workers? I've been using web workers on iOS for years.
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
FWIW Chrome 67 has just shipped with initial support for the Generic Sensor API spec
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.
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.