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

by rivy • 8 years ago

111 96 8 years ago

icc97• 8 years ago

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...

seanmcdirmid• 8 years ago

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).

calgoo• 8 years ago

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.

PretzelFisch3• 8 years ago

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.

jpochtar• 8 years ago

We're trying to solve exactly this problem with Pagedraw! Check out https://pagedraw.io/

crooked-v• 8 years ago

Manual X/Y and width and no flexbox or even Bootstrappy column settings in sight? No thanks.

misterdata• 8 years ago

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)

towndrunk• 8 years ago

Yikes!

"Sorry, our editor is optimized for Chrome"

jholman• 8 years ago

That is an amazing characteristic in a project for building websites. What in the what.

eitland• 8 years ago

I though we'd not see those messages after IE6 died but Chrome stepped up and filled that role : - |

rndgermandude• 8 years ago

What's even worse: It isn't "optimized" for Chrome, it only works in Chrome.

joeblow9999• 8 years ago

"Web Code is a solved Problem"

honestly whenever I see this said about anything, I'm pretty sure it's not a solved problem.

ernsheong• 8 years ago

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

danShumway2• 8 years ago

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?

aphextron2• 8 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.

lioeters• 8 years ago

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..

DivisionSol• 8 years ago

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

keyle• 8 years ago

yep that and vue-cli and you have all the framework you need including a dev server and a test framework.

dmitriid5• 8 years ago

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.

mankash6662• 8 years ago

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

matharmin• 8 years ago

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.

mankash6662• 8 years ago

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...

connorelsea• 8 years ago

And iOS + mac safari have service workers now

aphextron2• 8 years ago

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/

rado• 8 years ago

Code is solved because you use a JS framework. UI is unsolved, because you don't use a UI framework. What a strange article.

goofballlogic• 8 years ago

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.

acconrad• 8 years ago

So his central thesis is that JS has been getting all of the love while HTML and CSS have been marginalized. I want to empathize with him because he's a seasoned vet in programming and has been at it longer than I have. But, I've been doing web development since i was 12 on pet projects, and we totally have been making great strides in web UI.

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.

ergothus3• 8 years ago

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.

rimliu2• 8 years ago

What’s not simple?

SahAssar2• 8 years ago

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?

jgh• 8 years ago

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.

TheAceOfHearts2• 8 years ago

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/

hoorayimhelping• 8 years ago

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.

sametmax• 8 years ago

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...

mxschumacher2• 8 years ago

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/

gymshoes• 8 years ago

Agree with this.

Plain HTML and CSS are good and simple enough on modern browsers.

dagenix• 8 years ago

He's upset he can't send text messages or interact with Bluetooth from html? Wtf. How is this even an article. I'm angry my toaster isn't batting 0.500 for the Nats. Seriously, nothing to see here.

based2• 8 years ago

+ a standard to close session (logout)

speedplane• 8 years ago

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.

cameldrv• 8 years ago

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.

Theodores• 8 years ago

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.

flohofwoe4• 8 years ago

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.

kaoD• 8 years ago

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.

flohofwoe4• 8 years ago

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" :)

chrismorgan• 8 years ago

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. ;-)

oneweekwonder• 8 years ago

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.

transfire• 8 years ago

Here's the CSS fix not enough people are paying attention to: http://gss.github.io/

dmitriid5• 8 years ago

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

smaddox• 8 years ago

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.

ebbv• 8 years ago

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.

fairpx• 8 years ago

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

PretzelFisch3• 8 years ago

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.

mickronome• 8 years ago

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.

dmitriid5• 8 years ago

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/...

blackbrokkoli• 8 years ago

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...

mxschumacher2• 8 years ago

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

yakubin• 8 years ago

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.

tannhaeuser4• 8 years ago

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

naasking• 8 years ago

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.

0x445442• 8 years ago

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.

balfirevic2• 8 years ago

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?

tannhaeuser4• 8 years ago

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.

danShumway2• 8 years ago

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.

PretzelFisch3• 8 years ago

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.

pixelrevision• 8 years ago

The fact that there is no standardized date picker for the web in 2018 is impressive.

pbowyer2• 8 years ago

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/

jacobr• 8 years ago

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.

yesimahuman• 8 years ago

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.

tomatotomato37• 8 years ago

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

arithma• 8 years ago

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 Code is a solved Problem – how about fixing Web UI next?

Related Stories