Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

401–410 of 717 posts

Re: It’s time to kill the web app

#401

Earlier quoted context omitted.

True but it's crazy that it took 20 years to get sane layout control.

Well _it is_ crazy. We can't trace an alternate history and work with that. We work with what we have. I think, here, we might looking at it with the wrong lens. I'm unable to find the right words to say this. Let me say this statement feels ungrateful. Web is the largest and fastest growing ecosystem of software we've right now (refer: community size, number of projects on github, say, in Javascipt, CSS, and other w…

Your perspective is very interesting to me. It makes me think that as software gets better/easier to write, as web development has become lately, people want to question why it is becoming better/easier. I think this self-reflection we have all been doing on the web is what is causing people to post so many threads and articles with this being the topic.

Re: It’s time to kill the web app

#402

It's probably not realistic, but I would love to see the web be completely thrown out and replaced with something reasonable. I write a decent amount of native code. I write Rust, C, and x64 assembly. I think I'm pretty good at this stuff. But the web is too much for me. Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. I've never been able to put together a c…

I don't think that the web is complex, at least not in a sense I'm understanding "complexity" word. Web is a huge pile of semi-specified standards. There are bunch of written standards, like XML, HTML, DOM, JavaScript, CSS (each with multiple versions). There is a lot of tribal knowledge, that you'll get only with experience, like things that doesn't work with IE 6 (luckily IE 6 is not very relevant today). There is…

That is complexity. It's layers upon layers upon layers of dynamic runtime interactions. Try working on maintaining/extending a web application that's been developed over the course of many years, during that course of time using all of those technologies in many different versions, with the many different styles of architecture and best practices that were 'the right way' to do it at the various points in time when those parts of the system were added. You'll find all kinds of complexity in there, even without looking at the server-side.

Then you mention the modern ecosystem of javascript tools with all of its glued-together hacks, dependency nightmares, grey boxes of 3rd party code that you can look at but don't have the time to understand fully (all of which use different styles/techniques). That is complexity.

The alternative as described by the article is traditional development where you have a language+IDE+GUI design tool that compiles applications into a single file that, if it compiles, just works (except for any bugs). People who haven't developed in Delphi or similar environment have no idea how much less complexity there could be.

Re: It’s time to kill the web app

#403
There is only ONE major thing that's bad with web apps: you have to trust the server. Which makes them unusable for truly secure applications like bitcoin clients. Because you can always say you didn't authorize an action!

I think the future is IPFS and other content-addressable protocols. Why aren't browsers adding them to the web alongside https?

Re: It’s time to kill the web app

#404

Earlier quoted context omitted.

Having written things targeting WASM, when you can provide me an environment like Visual Studio that has breakpoints(including data) and a debugging I can step then we can talk. Until then WASM is cool, but not nearly as productive for C++ as the native platforms.

We could've had that years ago if Mozilla had not (as all the browser vendors do depressingly often[1]) decided to torpedo NaCl for nonsensical reasons that boil down to "NIH," in favor of creating a far-inferior, crippled spec practically designed to be aimlessly bikeshedded for years. [1] Mozilla usually pulls such NIH moves to sabotage the introduction or use of languages (even DSLs) other than JS on the web. See…

XHTML2 was dead on arrival. Mozilla didn't do anything to sabotage it; it sabotaged itself by completely dropping backwards compat in such a horrible way that you could only implement XHTML2 or something that would render existing websites, but not both, unless you jumped through some pretty ridiculous hoops. It turned out, no one wanted to jump.

Plugins were killed by most browser vendors more or less at once, and Mozilla wasn't even the first one.

Dart was opposed by every browser vendor who wasn't Google, though the reasons may have differed. Same thing for NaCl.

WebSQL is the one thing that I am aware of that Mozilla in fact opposed when others were broadly in favor, but the reason was not NIH. It would have been pretty simple to implement WebSQL in Gecko. The opposition came down to two things, I believe. The first was a simple observation: the W3C process at the time required two interoperable independent implementations, and there weren't any for WebSQL; the only implementation that the spec allowed, if you were going to achieve interoperability, was a particular version of sqlite. There were various ways to solve this problem, including abstracting away the database more (i.e. developing an actual Web SQL with well-defined semantics that were not tied to a particular implementation), but none of the WebSQL proponents were willing to go ahead and put in the time to do that, as far as I can tell. The second issue was the fact that WebSQL had synchronous database queries going on. The storage API really should be async, if it's going to be accessed from the "main thread" (the one the Window object lives in). I do think we could have done better than IndexedDB, though. It, like many other recent web specs, feels way over-engineered to me.

[Disclaimer: I work for Mozilla, and did back when most of the things you mention were being discussed, but was not actively involved in the WebSQL/IndexedDB discussions.]

Re: It’s time to kill the web app

#405
post #350
post #305

Earlier quoted context omitted.

This is pure illusion. Otherwise reddit, 4chan, hn, google (until 2010), craigslist, and even amazon would suffocate and go away. The fact is that what makes a web app / web site / whatever be liked by the users is the content and the value; and often times a 2005 porn pop-under is better at that than a today's chic, pedantically over-designed website with grey huge lettering, multi-MB graphics, and tonnes of wasted…

Those communities are all very niche, and in fact part of their brand and image is in their design. Even though they are less flashy, that is the point. Try to convince the owner of a clothing ecommerce site that their store should look like a 4chan bulletin board while trying to sell high priced garments to the public, or that the Coke website can't have a vibrant design in line with the rest of their branding.

I'd like to pose a WhatsApp commerce group as a counterexample.

Re: It’s time to kill the web app

#406

Earlier quoted context omitted.

It's a pity that (classic) VB's excellent Form Designer is tied to such an ugly language.

VB6's form designer (and UI framework that underlies it) has one crucial problem: it has basically zero understanding of flexible layouts. As a result, things break as soon as you try to make an easily resizable window, or font size or family changes (even if it's something as simple as accommodating high DPI), or you localize the dialog and some strings become longer. This lack of support for anything other than har…

> it has basically zero understanding of flexible layouts.

That's largely a non-issue to me. If I need anything fancy, I'll draw it myself. The simple stuff ought to be simple.

> As a result, things break as soon as you try to make an easily resizable window

Au contraire! It is much easier to make a resizable window when you are in full control of how nested widgets are resized along with it. That being said, some automation is fine (e.g., how MFC resizes views in response to their parent frame being resized) as long as simplicity isn't lost in the process (I'm looking at you, CSS).

Re: It’s time to kill the web app

#407

I find this unconvincing. Every negative thing said about the web is true of every other platform, so far. It just seems to ignore how bad software has always been (on average). "Web development is slowly reinventing the 1990's." The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. "Web apps are impossible to secure." Programs in the 90s were written in C and C++. C is impossible to secure. C++ is im…

I just find the way DOM/CSS does layout and styling to be completely convoluted and crazy compared to any desktop toolkit since 1990. Center anything either vertically or horizontally - that cannot require me to google and most importantly cannot have multiple different solutions . Simple things should not just have simple solutions, they should have one simple solution. Memory-unsafe programs on the desktop should g…

As the other commenter said, flexbox and gridbox help alleviate many issues that used to be commonly raised a few years back.

Check out Yoga [0]. It's a small layout engine based on flexbox and the CSS box moel. It doesn't cover all use-cases, but it's pretty powerful for its size. I

It's important to remember that CSS and the DOM was initially created and developed with certain kinds of documents in mind. Both are certainly quirky and missing a lot of features, but I wouldn't say they're as bad as many people make it out to be. Based on my experience with native desktop toolkits, they're all quirky in one way or another. One of the biggest issues with modern CSS is that it doesn't have sensible defaults for web apps.

Could you provide an example of your preferred approach to handling layout and styles, and talk a bit about what why you consider it superior?

What key features do you consider missing from CSS and the web?

[0] https://facebook.github.io/yoga/

Re: It’s time to kill the web app

#408
post #233

Earlier quoted context omitted.

I used vb6 20 years ago and have recently (quite unfortunately) had to learn html/js/css basics. The web is hot garbage for displaying form data compared to microsoft tools circa 1996.

It's a pity that (classic) VB's excellent Form Designer is tied to such an ugly language.

There are alternatives - https://www.lazarus-ide.org/ or Delphi.

Re: It’s time to kill the web app

#409
post #263
post #233

Earlier quoted context omitted.

I used vb6 20 years ago and have recently (quite unfortunately) had to learn html/js/css basics. The web is hot garbage for displaying form data compared to microsoft tools circa 1996.

MS really had rapid GUI development absolutely nailed in the late 90s. For some reason we forgot all that.

I was really surprised when I went and wanted to build a GUI app to find that everyone had abandoned the WYSIWG model completely. You can't just drag your controls over, set their properties, then build the code to drive everything. You have to manually wrestle with containers and whatnot even for desktop things. I could potentially see it as an acceptable tradeoff for wide device compatibility (things with substantially different screen dimensions, etc)... but I still have yet to figure out why the layout systems of the past couldn't simply be made a little bit smart to deduce the constraints necessary to result in the same development experience as before.

Re: It’s time to kill the web app

#410
I'm not impressed with this article:

- The author failed to draw a clear distinction between "The Web" as an application platform and "The Web" as a network of semantic information.

- Digging deeper, "The Web" the application framework is pretty flexible. There are plenty of ways to use hypermedia and HTTP, while using your own non-HTML/CSS UI tooling.

- The article strikes me as ill-researched -- the author writes "Here’s a good blog post on Flux, the latest hot web framework from Facebook". Flux is definitely not the latest from Facebook, and some of the linked articles were from 2015. For better or worse (I think better), front-end is moving really fast, and the web platform roast listicles don't age well.

- The point about "UI Complexity" is just odd. UIs should not be complex. Comparing the windows explorer to Google docs is comparing fruits to vegetables. The point "look! we still have toolbars and shades of grey" has nothing to do with the web and everything to do with UX metaphors and familiar affordances.

- "Things as basic as UI components are a disaster zone". UI "components" are not basic! What is a component? No seriously, ask a programmer content with OO languages, and then ask someone who prefers functional languages. Then ask those developers to agree on an interface.

Though I do agree with:

- Web apps are slow. Painting is really complicated.

- So many apps are written with the assumption that they're always online. The author is right that users have low expectations when it comes to good offline experiences.

- The web wasn't designed with our contemporary single-page application use case in mind.

- JS could obviously be way better.

- The need for backwards compatibility is pretty crippling.

- Security is difficult to get "right".

Post reply on HN