The creator of this post is the same guy who said bitcoin was dead in 2016 [1].
[1] https://blog.plan99.net/the-resolution-of-the-bitcoin-experi...
It’s time to kill the web app
511–520 of 717 posts
Re: It’s time to kill the web app
#512Earlier quoted context omitted.
> "the microsoft office suite for instance slows down every generation despite only having minor improvements and not actually being that different now than from 95" I can't comment on most of the Office suite, but Excel evolved quite a bit since 95. Tables, PowerBI, Apps for Office, etc... If your needs are basic enough then even VisiCalc will do the job, but new features do make an impact for more demanding users.
Excel hasn't evolved at all since 2003. They added a couple new chart types and changed some colors. But functionally they haven't made any significant change. In fact some grey controls have litterally not been updated in 20 years (try clicking the fx button near the formula bar with the same broken search feature since the 90s). There are lots of things they could do. Linking data between spreadsheets or between ex…
> "They could learn from Apple's approach with numbers where a worksheet is a canvas on which you can place multiple tables or charts or diagrams"
You can do this with Excel also. When was the last time you used Excel?
> "There might be 1000 people in the world who use power BI, and only because their IT dept set it up for them."
The Power BI features in Excel come ready to use out of the box. Clearly you've never used them, but they're by far the best new features in modern Excel. Any power user of Excel that isn't exploring them is missing out.
Re: It’s time to kill the web app
#513Earlier quoted context omitted.
Yep, also on speed: it seems to me that the microsoft office suite for instance slows down every generation despite only having minor improvements and not actually being that different now than from 95. The nature of developers is that they will use whatever resources that they have. Faster computers don't necessarily mean faster applications but faster software development cycles from bigger teams with less need for…
Some would argue we've traded speed of execution for snake oil (so called speed of "productivity"). This tweet is an interesting visual that makes the same point: https://twitter.com/TheoVanGrind/status/888850519564984322
Software has become more increasingly complicated over time. Aside from adding new features, many companies have improved their efforts of providing accessible applications to a international audiences.
Let's not forget we've drastically increased security by writing applications in safer languages.
Oh, and newer applications tend to support a far wider variety of devices types, displays, inputs, etc.
Developers definitely be investing a lot more effort into improving the status-quo, but it's unfair to claim stuff is slower without improvements.
Re: It’s time to kill the web app
#514Earlier quoted context omitted.
It makes sure that all your code is yours and that no matter what stuff makes it into the data stream it will never be able to do anything because it is just meant to be rendered. So abc would go as where datum 1 would refer to the first datum in the data stream, being 'abc' and no matter what trickery you'd pull to try to put another tag or executable bit or other such nonsense in the datum it would never be interpr…
I guess what I'm getting at is that it isn't HTTP that's the issue -- it's HTML. I'm all for a control channel in HTTP. But you're still stuck parsing , and it is difficult to think about reorganizing each tag as a separate datum. At what level do you stop converting the data into separately requestable bits? How would you even code it? And making the tags themselves length-prefixed (like csexp's) wouldn't entirely s…
> I could easily see making and resources required to be separately requested (like images are now -- ignoring data/base64 resources), but we're back to redefining HTML.
This has been implemented in HTTP (not HTML); you can enable the requirement right now by serving your pages with an appropriate Content-Security-Policy header.
Re: It’s time to kill the web app
#515It'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…
You need to learn CSS just the way you would approach a learning another programming language. From scratch - without assumptions and short cut solutions you get from Googling. Understanding stuff like block, inline block and positioning and go from there. Take a month's equivalent out and spending time learning it.
Javascript too can be an extremely confusing language for those who come from typed systems.
Then comes the DOM.
Then there is the communication system - AJAX, websockets etc.
Finally there is understanding the browser dev tools. As the tooling has accumulated understanding how to use it and internalize everything will take atleast 2 - 3 days.
If you don't take time to learn these 4 systems independently, when they're all mashed up as in a web application, you will struggle .
Re: It’s time to kill the web app
#516Earlier quoted context omitted.
Excel hasn't evolved at all since 2003. They added a couple new chart types and changed some colors. But functionally they haven't made any significant change. In fact some grey controls have litterally not been updated in 20 years (try clicking the fx button near the formula bar with the same broken search feature since the 90s). There are lots of things they could do. Linking data between spreadsheets or between ex…
> "They could learn from Apple's approach with numbers where a worksheet is a canvas on which you can place multiple tables or charts or diagrams" You can do this with Excel also. When was the last time you used Excel? > "There might be 1000 people in the world who use power BI, and only because their IT dept set it up for them." The Power BI features in Excel come ready to use out of the box. Clearly you've never us…
> You can do this with Excel also. When was the last time you used Excel?
How do you do that then?
Re: It’s time to kill the web app
#517> All buffers should be length prefixed
Fortran called that a Hollerith constant, but that was 60 years ago.
Re: It’s time to kill the web app
#518Earlier quoted context omitted.
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…
SQL injection attacks are an excellent example where code and data are mixed. One solution is to do a lot of clever escaping of 'attackable' characters that instruct the DBMS to stop treating a character string as data and start executing things [1]. Escaping attackable characters attempts to partition data from code. This usually works but not perfectly. Or, run your data through stored procedures instead. It took m…
Yeah, I thought the same thing until I found a colleague who was very fond of calling exec_sql in stored procedures, with the argument being a concatenation of the sp arguments.
Re: It’s time to kill the web app
#519Earlier quoted context omitted.
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.
Which is a point in favour of Word, not Google Docs.
Re: It’s time to kill the web app
#520Earlier quoted context omitted.
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.
Windows 95-era Word didn’t have to handle real-time collaboration over the Web between an arbitrary number of users.
No, it didn't. But is it so complex it requires 10x+ the resource use? I don't think so.