Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

421–430 of 717 posts

Re: It’s time to kill the web app

#421

Earlier quoted context omitted.

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 c…

What bothers me is that I can't make rules with the same expressive power as a regex.

Also css lacks properties for controlling wrapping limits and non-linear image scaling. And for some reason I always have to optimize on either width or height, I can't control both perfectly.

Re: It’s time to kill the web app

#422

Earlier quoted context omitted.

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 M…

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

Heck, Dart was opposed by the Chrome team: there's a reason why it never made it into Blink. NaCl is slightly different insofar as the Chrome team didn't actively fight it.

Re: It’s time to kill the web app

#423

Earlier quoted context omitted.

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 c…

That sounds awesome except for that fact that my customers refuse to use modern browsers that support modern CSS features. GRRR.

Re: It’s time to kill the web app

#424
> Way back then, the web was locked in a competition with other proprietary platforms like Flash, Shockwave and Java

Maybe this is just semantics, but it sounds like "web" is being used as synonymous with "JavaScript."

Re: It’s time to kill the web app

#425
post #302

Earlier quoted context omitted.

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…

I've found that , once you build up the right set of components for yourself, you can easily get nice layouts that work on a variety of screens without much work. There sometimes ends up with edge cases, but overall it works well so long as you design things with the tooling on mind. Meanwhile I've struggled to get things looking well with GTK+ or Tcl/tk. Especially when the UI I'm trying to make is dynamic. The tool…

> Especially when the UI I'm trying to make is dynamic.

That's where I still run into problems with CSS too. However, at some point, and not because I started using flexbox / grid, CSS did click for me and now it's mostly second nature to get the layout that I'm going for.

My feeling on this whole topic is that while as a web developer I have often thought "there must be a simpler way", every time I actually start to imagine what that would look like I end up re-imagining something similar to the web stack as it is now. There is a lot of inherent complexity to GUI-based networked client-server applications that need to be responsive, continuously integrated, database-backed, real-time, etc.

Re: It’s time to kill the web app

#426

Earlier quoted context omitted.

If you have an issue with human error and don't design your programmed tool to avoid letting the errors out into the world, then it is the fault of the tool.

I'm not sure what the argument you're putting forth is. All of the HTML-generating tools I'm aware of (barring dumb string templating tools) work sufficiently well and prevent human error. My point is that there's nothing wrong with HTML. HTML isn't a tool, it's a format for storing and transmitting hypertext. If you're using React or HAML or any of the other HTML-generating tools, you're effectively immune from XSS.…

Well put. I agree with all of that essentially.

Re: It’s time to kill the web app

#427
The internet existed long before the web and there are other protocols than HTTP - TCP/IP, UDP, SSH, telnet, etc. Desktop applications are still built that use the internet for communication but don't try to ram everything through an HTML document. And they're usually far-superior to webapp versions.

But now many people think that things should all be web-only, over HTTPS only. We built a palace of many ports and protocols, but we've locked ourselves away in one bedroom as our own prisoner. Despite a perfectly nice dining room with silverware and dishes, we instead scoop our food off the mattress with our hands because a firewall or NAT might prevent us from getting to the dining room.

Where the web does claim superiority, and why everyone now wants to use it to build applications that are totally unsuited for it, is primarily four things:

1. Run-anywhere cross-platform compatibility. This could be addressed by better cross-platform compilation and cross-platform UI/UX for native applications. Most mature languages have that ability now, but it's not perfect - still in the 'needs work' phase. Likewise browser compatibility and responsive design are still not perfect, but they've come far enough now that they're workable enough. But, run anywhere fails if there's no internet connection or the servers aren't responding. Native still wins there.

2. Simplified distribution and updates. People like that no installation is required and the latest version of the software is distributed from the server every single time a page loads. But in reality almost all modern native software can be built with a simple 'click run to install' installer, and can handle routine updates fairly seamlessly. Native is still more efficient, it just has those two extra 'click to download' and 'click to install' steps. If that could be streamlined, native would win.

3. Ubiquitous acceptance of network requirement. It's unthinkable to block 80/443 and HTTP/HTTPS, so anything can communicate that way. Programs that use other ports or protocols may have trouble with firewalls, NAT, and other middleware. It's kind of insane to limit everything to one or two ports and protocols. That needs solving. That's where the web really wins - only because we've imprisoned ourselves.

4. Server dependence. This is not a feature for the customer, although 'cloud storage and synching' is sold as such. It means that the company making the software gets all of the data. If their servers are ever shut down, or even if you're just temporarily offline, you don't have access to your data. And if someone breaches their system, then your data is effectively public. Local native apps leave you in control of your data and can work with it offline, even after the company that made them goes out of business. True, your system can be break (so keep backups) or be breached, but it's more under your control and less of a target than a system containing everyone's data.

Overall, the web is great for document distribution, but it's only real winning point when it comes to applications is that we've locked ourselves into one single port and protocol out of all that are available and that one happens to be the one that the web uses. If we could solve that, internet applications could be worlds better. But no new javascript framework or CSS compiler will solve that.

Re: It’s time to kill the web app

#428
post #423

Earlier quoted context omitted.

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 c…

That sounds awesome except for that fact that my customers refuse to use modern browsers that support modern CSS features. GRRR.

For those customers, I gave them an ‘application’ version that was just nw.js (basically chrome). Worked reasonably well for the customers that had somewhat recent OS on their desktops or terminal server.

Re: It’s time to kill the web app

#429

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…

Yeah, to me it sounds like a case of "grass is greener" syndrome.
Post reply on HN