Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

Post reply on HN
Print view View original

251–260 of 717 posts

Re: It’s time to kill the web app

#251

Post by spynxic »

giblaz wrote: post #240
marmart wrote: post #225

Earlier quoted context omitted.

Gridbox and Flexbox largely make layouts sane again.

This to both. However, the problem with the web is there are old implementations that must be maintained in browsers for backwards compatibility. The issue with this is that it increases the barrier to entry for web development because it's much harder for a new person to even know what options to gravitate to. Of course, there are books and guides to help people, but how would someone figure out which guides are wor…

For the sake of creativity, suppose browsers were the wrong direction to take for web exploration. What do we do now?

The same idea may be applied to an operating system's ability to allow a user to operate on their machine.

Edit: It would be useful to consider why the need for a universal interface to the internet was originally sought out.

Re: It’s time to kill the web app

#252

Post by tormeh »

nostrademons wrote: post #188
jacquesm wrote: post #156

Earlier quoted context omitted.

> they'll lose out to systems that promise security (and usually address a few specific attacks on the previous incumbent This happens in other areas besides applications as well. Programming languages, operating systems. This leads to an eternal re-invention of the wheel in different forms without ever really moving on.

Yep. Databases, web frameworks, GUI frameworks, editors, concurrency models, social networks, photo-sharing sites, and consumer reviews as well. Outside of computers, it applies to traffic, airlines, politics, publicly-traded companies, education & testing, and any industry related to "coolness" (fashion, entertainment, and all the niche fads that hipsters love). I refer to these as "unstable industries" - they all e…

>concurrency models

We started out with OS threads (I guess processes came first but whatever) and now we're trying to figure out what the next paradigm should be. It looks to me like it's Hoare (channels, etc) for systems programming and actors for distributed systems, both really really old ideas. To be fair there are other ideas (STM, futures, etc) that fill their own niches, but they either specialize on a smaller problem (futures) or they're still not quite ready for popular adoption (STM). If this is cyclical then I think we're pretty early in the first cycle.

Sure, the spotlight moves from one model to the other and back, but that's because the hype train cannot focus on many things at the same time, not because the ideas go out of style.

Re: It’s time to kill the web app

#253

Post by leeoniya »

NMDaniel wrote: post #243
Pxtl wrote: post #180

Earlier quoted context omitted.

Yes, but then the malware can also compromise the server, since it now has js access to all the users and can Masquerade as them when they see the ad - even as admins. Keys to the kingdom. This is a feature, not a bug - it means the user and the server are now in the same boat, and the server will have some friggin diligence about whose code they run. Also, means the server has to pay for the damned bandwidth.

That's not how it works, the server wouldn't execute JS that is meant for a browser client, it would just serve it like any other static file. What you're suggesting will actually hamper security, because scripts served from your domain have less limitations(see https://en.wikipedia.org/wiki/Same-origin_policy , https://en.wikipedia.org/wiki/Content_Security_Policy and other mechanisms)

the implication of same-origin would affect all requests made from the client. you can serve malicious js from the server all day long but it would be restricted to only talking back to that same server.

Re: It’s time to kill the web app

#254

Post by jaltekruse »

hutzlibu wrote: post #230
hyperpape wrote: post #55

I don't get the section on JSON, which seems to assert that XML is more secure than JSON. It does this by linking to a Wikipedia page that includes the security consideration that you shouldn't call eval on JSON. True, but at least that's a tractable problem. Your linter can check for code that calls eval. In contrast, there are plenty of XML attacks (DOS with billions of laughs, entity references), and parsing XML i…

"If you want to rag on JSON, that's fine. It's not a great format" JSON is simple and powerfull. It's success justifies it, to call it a great format, I think. But I am curious, what whould be a great format, in your opinion?

A standard way to at least represent common data types, dates/times, integers/longs and fixed precision decimal would be nice. I know that the JSON format doesn't specify any limit or precision limitations on the size of numeric values, but almost all libraries assume they should be read as doubles. It is a real pain for people doing analysis on semi-structured JSON after apps have been deployed for a while and the data model has evolved over time.

Re: It’s time to kill the web app

#255

Post by nostrademons »

mwcampbell wrote: post #226
nostrademons wrote: post #188

Earlier quoted context omitted.

Yep. Databases, web frameworks, GUI frameworks, editors, concurrency models, social networks, photo-sharing sites, and consumer reviews as well. Outside of computers, it applies to traffic, airlines, politics, publicly-traded companies, education & testing, and any industry related to "coolness" (fashion, entertainment, and all the niche fads that hipsters love). I refer to these as "unstable industries" - they all e…

How do we fix this?

We don't. Learn to embrace it instead.

There's a flip side to everything. In this case, if you "fixed" this problem, it would imply a steady-state world where nothing ever changed, nothing was ever replaced, and nobody could ever take action to fix the things bugging them. To me, this is the ultimate in dystopias. It's like the world in The Giver or Tuck Everlasting, far more oppressive than the knowledge that everything we'll ever build will eventually turn to dust.

Or we could get rid of humans and let machines rule the earth? Actually, that wouldn't work either, these dynamics are inherent in any system with multiple independent actors and a drive toward making things better. If robots did manage to replace humans (ignoring the fact that this is already most peoples' worst nightmare), then the robots would simply find that all their institutions were impermanent and subject to collapse as well.

Re: It’s time to kill the web app

#257

Post by petra »

x0x0 wrote: post #233
alkonaut wrote: post #223

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

The web isn't the place to look for good tooling.

Properiatery low-code tools built over the web are a better starting point.

Re: It’s time to kill the web app

#258

Post by userpass »

jerf wrote: post #31
mikebenfield wrote: post #20

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…

"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 coherent mental model of the architecture of a web application or figure out what the best practices are for web development." If it makes you feel any better, that's because there isn't a coherent mental model. If you've ever heard of the ORM/Relational impedance mismatc…

>If you've ever heard of the ORM/Relational impedance mismatch, it's got nothing on the set of impedance mismatches between the way servers like to work, the HTTP protocol (and its still very page-based orientation in a world of streams), the browser's DOM model, and how Javascript works, especially if you want to get excellent performance out of it.

Mapping objects to tables is a solved problem. The only noteworthy challenge is subtyping but it has easy solutions. I'm surprised how well it works even if you have an old crusty database with an archaic table structure. Compared to serialising objects to JSON or other formats that have no concept of identity it's downright trivial. However mapping objects to tables is the primary thing an ORM really does. Usually it implements lazyness for correctness so that your code while inefficient still works as intended.

What an ORM however does not do is write queries for you. Databases are remote devices, you can't just treat remote objects as if they were local (like CORBA did) if you care about performance.

Remember: You still have to write your queries but usually the ORM still helps you writing queries by providing a query builder or has it's own query language. The point of the ORM is that you don't have to manually marshall rows into objects, it's not a tool to avoid queries. It's right there in the name: Object Relational Mapping. It does not say AutomaticQueryGenerator or something related to queries.

Re: It’s time to kill the web app

#259

Post by missing_cipher »

TeMPOraL wrote: post #144
Spooky23 wrote: post #70

Earlier quoted context omitted.

My alarm siren went off when the commentary started critiquing the “complexity” of Google docs as compared to Windows explorer circa 1998. Complex things are often complex because the work that we do as humans is, well, complicated. A journey map painstakingly built by an epic designer and smart person at large may design the ultimate document template that addresses every need that you are aware of. Then I come alon…

Your alarm shouldn't go off, because the example is very much apt. The article compared the UI offered by both, and they are indeed directly comparable. As for the work Google Docs do, come on, they're a glorified Markdown editor, they lose in any kind of comparison with Windows 95-era Word.

Text editors are much more complex than you think.

Re: It’s time to kill the web app

#260

Post by markhahn »

silly author - sandboxed binary apps won't solve the problem. your whinges about client-server communication are inherent to, you know, clients and servers. whether the thing on the client side is real app or a web app is irrelevant. what matters is the communication. imagine if that channel could only carry keyboard/pointer input events to the server and static images in return. yep, that would be pretty robust.
Post reply on HN