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…
It’s time to kill the web app
401–410 of 717 posts
Re: It’s time to kill the web app
#402It'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…
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
#403I 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
#404Earlier 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…
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
#405Earlier 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.
Re: It’s time to kill the web app
#406Earlier 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…
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
#407I 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…
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?
Re: It’s time to kill the web app
#408Earlier 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.
Re: It’s time to kill the web app
#409Earlier 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.
Re: It’s time to kill the web app
#410- 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".