321–330 of 717 posts
Main reason for web apps stay : they can evolve without a distribution life cycle.
Around REST and RPC : No what you see on the web is not REST. And please stop bringing back RPC. It was a bad idea before, it is still a bad idea.
Earlier quoted context omitted.
> "But modern UI in Office is only an evolution of what was there in the 90s and hasn't changed fundamentally either yet it doesn't feel any faster." Evolution of a UI isn't as important as evolution of the features the UI exposes. As for whether it feels any faster, depends on what you're doing. To give an example, Excel functions can be calculated using multiple CPU cores, which AFAIK wasn't a feature of Excel in t…
That's precisely the point. The author of the article was complaining that web applications are slow and compared it to Windows 95. And my point is that web apps have a lot of features that didn't exist back then, and because of feature additions Office and other native applications don't exactly feel snappy either.
That was the general point, but I was responding to a side comment that I disagreed with.
> "because of feature additions"
Adding features does not require slowing an application down. The reason modern apps (desktop and web) are slow is to do with inefficient use of computing resources, which has very little to do with available features.
Earlier quoted context omitted.
A lot of the churn is because the web is so young as an application platform. It’s been less than 20years since GMail which was probably the first thing that even approximated an application on the web. Chrome was released in 2008 less than 10years ago, and it was the first time the web had a runtime engine which was perform at enough to even build an app.
There were plenty of webapps before Gmail. There was even plenty of other webmail services before Gmail and Gmail wasn't much different from the status quo. I've been using webmail since 1997 and even my University had a web interface (SquirrelMail) for those who preferred using the web interface (almost everyone). This was pre Gmail.
Earlier quoted context omitted.
> if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately. That's not really the problem. The problem is there is no distinction between data and control leading to everything coming to you in one binary stream. If the control aspect would be out-of-band then the problem would really go away. Length prefixes will just turn into one more thing to overwrite or inte…
I'm having a hard time seeing how having separate control and data streams would have an effect here. Using FTP to retrieve a document isn't more secure than HTTP... the problem is in how the document itself is parsed. If you added a separate side channel for requesting data (a la FTP), you'd still have the issue of parsing the HTML on the other side. Granted, if you made that control channel stateful, you'd make a l…
Or, run your data through stored procedures instead. It took me a while to figure out why stored procedures were so much more secure than regular queries. I finally figured out it was because a stored procedure does exactly what the grandparent post says: It treats all inputs as data with no possibility to run as code.
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…
> >*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 impossible to secure. I…
Since when has an inexperienced mob of people ever done the correct thing on the first try?
And, yet, the mob has continued the very fine legacy of those 90s (and 80s and 70s) software developers in pushing software into more places it's never been before. Somehow, it's working, despite the relative ignorance and stupidity of the average developer (myself included) in their understanding of history.
I think I'm being misinterpreted as saying the web is great because it has no flaws. Which is not my intention. The web has many ugly flaws. The web is great because of what it does despite those flaws. And, also, a lot of those flaws come down to inexperience, which we can't cure with technology. It seems likely it can only be cured by making the same dumb mistakes a few times until it becomes collective wisdom that it was a dumb mistake...the kind that gets beaten out of programmers very early during their learning process.
I guess I'm just more optimistic about the web-as-platform than most. I see all its flaws, I just don't think they should result in a death sentence.
But, if you show me something better, I'll gladly participate.
Any system using a SQL database is susceptible to SQL vulnerabilities, web based or not. Not to mention SQL injection is a largely solved problem. Creating concatenated strings for your database to execute is hardly the web's fault.
Fun fact: The colorful Windows 98 explorer sidebar that is shown in the first screenshot was implemented as HTML (and Javascript), along with the desktop background (called active desktop).
Earlier quoted context omitted.
That's precisely the point. The author of the article was complaining that web applications are slow and compared it to Windows 95. And my point is that web apps have a lot of features that didn't exist back then, and because of feature additions Office and other native applications don't exactly feel snappy either.
> "That's precisely the point" That was the general point, but I was responding to a side comment that I disagreed with. > "because of feature additions" Adding features does not require slowing an application down. The reason modern apps (desktop and web) are slow is to do with inefficient use of computing resources, which has very little to do with available features.
> UI is only a small part of an app, a well designed app will have most of the work performed outside of the UI thread and it shouldn't feel any slower than a native implementation. My thoughts are rendering speed isn't the issue but application design.
at the start. :) So, we're in agreement.