I have an impression the author confuses the Web and web apps written in JavaScript… The Web is a distributed publishing, collaboration and interaction medium, it’s not going anywhere. The application technology is constantly changing, and, one might argue, is in a certain blind alley right now.
Did author of article try WinAPI, MFC and COM/OLE? Flux has nothing in common with WindowProc. Even higher-level toolkits like Qt, GTK and Cocoa are far behind React where you directly bind data to UI and web where you bind appearance, including sizing, to “class”.
All these npm-problems are nothing compared to that COM/OLE/ActiveX thingy. “Undefined is not a function” is nothing compared to dangling pointers. Lack of Web IDE is actually advantage. You build with npm run build instead of “open project settings, change someone’s absolute path to path of where you put DLLs on your computer, then press build button, then copy binary somewhere or run .bat”. You don’t have to reinstall Atom every month, unlike Visual Studio.
It’s strange romanticizing of 90s desktop era which was dirtier than all these facebooks now.
Bloatware is very common in desktop apps written in C++. Photoshop is getting more and more bloated and not more powerful, despite it does not use web. Popular iOS apps has size of 100-200 Mb and often run slowly, despite ban on non-native code.
Since he links to my post to justify that claim, I think it’s worth pointing out two things.
First, my original comparison of Flux to WndProc and the like was about recognizing the pattern at a high level, and having concerns about its ability to scale to very large apps. (Specifically, the larger the app, the more you have many messages flying around where it’s hard to know with any confidence that you fully understand all the ways that the message can mutate the app state.) I’d agree with you that raw Win32 emphatically had nothing at all like data binding the way React does; no argument. But I also think both Flux and WndProc do in fact have quite a bit in common at a high level.
(As an aside, I am a bit befuddled about your comments about modern GUI toolkits being far behind. I cannot speak to Qt or Gtk, but you absolutely can bind variables to appearance in both Cocoa and WPF—and I’d swear I was doing that in VisualAge C++ back in the 90s, too.)
That said, I think your memory of the 90s might be genuinely worse than it was in reality. I didn’t then, nor do I now, reinstall Visual Studio (or Visual C++/Visual Basic) every month (and I’m not even entirely clear what you’re referencing, to be entirely honest). npm run build works great, except when it doesn’t and spews out a pile of confusing backtraces, and while yarn and/or package.lock are helping with some of that, I can’t say that the average run-of-the-mill web developer reliably knows how to fix that—and I’d definitely take fixing absolute paths in a VC++ project config over trying to parse through equivalent distro- or system-specific errors in the typical oddly bespoke Webpack configuration any day of the week.
Every environment has issues. The web is dramatically superior in some ways, dramatically inferior in a few places, and a wash in yet other areas. I’m pretty disappointed by the quality of this article, but I think believing everything on the web is superior to where we were in the 90s is a dangerous road to go, too.
Even with all damage done to Web, it still has a lot of value based on the document-oriented structure. Some discoverability is still there. In most cases the user still has a chance to adjust font size to make it fit the screen. It is even still hard to represent tabular data in a way that is not copy-pastable into a spreadsheet.
Then of course there are many network effect, up to typical firewall configuration, that make people want to make applications that pretend to be a part of Web while not caring about any of the useful conventions of the Web.
Lines and lines of rant without a clear goal. I can tell from the context the guy doesn’t like HTTP (or is it Javascript? both?). What part of the “web” did he exactly want to kill and how?
I thought the author addresses this near the beginning:
This is the first of two articles. In part one I’m going to review the deep, unfixable problems the web platform has[…] In part 2 I’ll propose a new app platform that is buildable by a small group in a reasonable amount of time
I don’t see JS ecosystem imploding under its own churn. 10 years ago we had a similar battle of frameworks where jquery ended up taking the lion’s share and prototype/mootools/dojo/yui made up the rest. Now we have angular/react dueling with a bunch of others making up the rest. Web dev is so much easier now than it was then, too. The tooling has gotten way better. Browsers have gotten faster.
But I guess it’s easier just to shit on everything you’re not great at and say it’s dying despite the very obvious fact that it is not. And how did it lose on mobile, exactly? Almost everyone designs sites with mobile-friendly UI, and many do it mobile-first/responsive.
Not to mention the fact that more and more electron apps keep popping up which are js/web apps in desktop wrappers.
But yeah, it sucks so bad, it’s unusable, and we definitely need to replace it.
Building large complex apps is easier and more robust then it was, but in general web development has become far more difficult.
10 years ago your average hack could slap together HTML4, CSS2, a bunch of jQuery plugins and JS copy pasta… FTP it to a server, call themselves a Web Developer and find plenty of work.
Now you need to be on the ball with a plethora of rapidly evolving and complex frameworks, tooling (tooling and more tooling) and “best practice”.
And that’s just the front end, the complexity of back end code and systems administration/dev ops has exploded from LAMPs heyday and the VB/IIS monstrosities that plagued corporate networks.
There are beautiful simple stacks available now (eg choo on the front and flask on the back)… but you wont find much work building in that.
Are you arguing that JS getting away from non-devs selling themselves as devs is a bad thing? You can still throw stuff together with HTML4/CSS2 and a bunch of jquery plugins. Tons of smallers companies don’t care. But that’s not really “dev” so much as throwing a bunch of premade things together. If you’re trying to get hired as a web developer, you ought to know something about developing for the web.
I’m no type really aware of the point you’re implying…is JS only succeeding because computers are fast? I didn’t think that was even remotely the case.
I’m not sure what you’re saying here. JS is getting more complex because browsers are getting faster. They’re getting faster so we can have improved functionality. They’ve always done that. If you want a browser that felt like it was the end stage of the browsing world, you’re free to bust out IE6 again.
… web apps fix those but then re-introduce their own very similar mistakes: SQL injection, XSS, XSRF, header injection, MIME confusion, and so on.
This leads to a simple thesis:
I put it to you that it’s impossible to write secure web apps.
Not sure about that conclusion - SQL injection is preventable by prepared statements, XSS and XSRF are preventable by CORS. These aren’t considerations made in the design phase relating to the architecture that I’d agree are hard/impossible to prevent, these are exploits that should be handled by abstraction layers in the frameworks you use.
SQL injection is preventable by prepared statements
Or more precisely: parameterized queries, where parameters are never interpreted as part of the query. The distinction between the two is important at least in Postgres, because prepared statements require more work on the client side than parameterized queries do.
I do like to complain about the web, but I couldn’t get into this. And I sure as hell do not feel like installing your app just to read complaints about the web.
I have an impression the author confuses the Web and web apps written in JavaScript… The Web is a distributed publishing, collaboration and interaction medium, it’s not going anywhere. The application technology is constantly changing, and, one might argue, is in a certain blind alley right now.
The author specifically calls out the Web as being a passable platform for document interchange, which seems to address what you’re thinking of?
The “open in app” button obscuring the content would suggest otherwise.
Did author of article try WinAPI, MFC and COM/OLE? Flux has nothing in common with WindowProc. Even higher-level toolkits like Qt, GTK and Cocoa are far behind React where you directly bind data to UI and web where you bind appearance, including sizing, to “class”.
All these npm-problems are nothing compared to that COM/OLE/ActiveX thingy. “Undefined is not a function” is nothing compared to dangling pointers. Lack of Web IDE is actually advantage. You build with
npm run buildinstead of “open project settings, change someone’s absolute path to path of where you put DLLs on your computer, then press build button, then copy binary somewhere or run .bat”. You don’t have to reinstall Atom every month, unlike Visual Studio.It’s strange romanticizing of 90s desktop era which was dirtier than all these facebooks now.
Bloatware is very common in desktop apps written in C++. Photoshop is getting more and more bloated and not more powerful, despite it does not use web. Popular iOS apps has size of 100-200 Mb and often run slowly, despite ban on non-native code.
Since he links to my post to justify that claim, I think it’s worth pointing out two things.
First, my original comparison of Flux to
WndProcand the like was about recognizing the pattern at a high level, and having concerns about its ability to scale to very large apps. (Specifically, the larger the app, the more you have many messages flying around where it’s hard to know with any confidence that you fully understand all the ways that the message can mutate the app state.) I’d agree with you that raw Win32 emphatically had nothing at all like data binding the way React does; no argument. But I also think both Flux and WndProc do in fact have quite a bit in common at a high level.(As an aside, I am a bit befuddled about your comments about modern GUI toolkits being far behind. I cannot speak to Qt or Gtk, but you absolutely can bind variables to appearance in both Cocoa and WPF—and I’d swear I was doing that in VisualAge C++ back in the 90s, too.)
That said, I think your memory of the 90s might be genuinely worse than it was in reality. I didn’t then, nor do I now, reinstall Visual Studio (or Visual C++/Visual Basic) every month (and I’m not even entirely clear what you’re referencing, to be entirely honest).
npm run buildworks great, except when it doesn’t and spews out a pile of confusing backtraces, and whileyarnand/orpackage.lockare helping with some of that, I can’t say that the average run-of-the-mill web developer reliably knows how to fix that—and I’d definitely take fixing absolute paths in a VC++ project config over trying to parse through equivalent distro- or system-specific errors in the typical oddly bespoke Webpack configuration any day of the week.Every environment has issues. The web is dramatically superior in some ways, dramatically inferior in a few places, and a wash in yet other areas. I’m pretty disappointed by the quality of this article, but I think believing everything on the web is superior to where we were in the 90s is a dangerous road to go, too.
Even with all damage done to Web, it still has a lot of value based on the document-oriented structure. Some discoverability is still there. In most cases the user still has a chance to adjust font size to make it fit the screen. It is even still hard to represent tabular data in a way that is not copy-pastable into a spreadsheet.
Then of course there are many network effect, up to typical firewall configuration, that make people want to make applications that pretend to be a part of Web while not caring about any of the useful conventions of the Web.
Lines and lines of rant without a clear goal. I can tell from the context the guy doesn’t like HTTP (or is it Javascript? both?). What part of the “web” did he exactly want to kill and how?
I thought the author addresses this near the beginning:
I don’t see JS ecosystem imploding under its own churn. 10 years ago we had a similar battle of frameworks where jquery ended up taking the lion’s share and prototype/mootools/dojo/yui made up the rest. Now we have angular/react dueling with a bunch of others making up the rest. Web dev is so much easier now than it was then, too. The tooling has gotten way better. Browsers have gotten faster.
But I guess it’s easier just to shit on everything you’re not great at and say it’s dying despite the very obvious fact that it is not. And how did it lose on mobile, exactly? Almost everyone designs sites with mobile-friendly UI, and many do it mobile-first/responsive.
Not to mention the fact that more and more electron apps keep popping up which are js/web apps in desktop wrappers.
But yeah, it sucks so bad, it’s unusable, and we definitely need to replace it.
Building large complex apps is easier and more robust then it was, but in general web development has become far more difficult.
10 years ago your average hack could slap together HTML4, CSS2, a bunch of jQuery plugins and JS copy pasta… FTP it to a server, call themselves a Web Developer and find plenty of work.
Now you need to be on the ball with a plethora of rapidly evolving and complex frameworks, tooling (tooling and more tooling) and “best practice”.
And that’s just the front end, the complexity of back end code and systems administration/dev ops has exploded from LAMPs heyday and the VB/IIS monstrosities that plagued corporate networks.
There are beautiful simple stacks available now (eg choo on the front and flask on the back)… but you wont find much work building in that.
Are you arguing that JS getting away from non-devs selling themselves as devs is a bad thing? You can still throw stuff together with HTML4/CSS2 and a bunch of jquery plugins. Tons of smallers companies don’t care. But that’s not really “dev” so much as throwing a bunch of premade things together. If you’re trying to get hired as a web developer, you ought to know something about developing for the web.
I mean, it works because we keep adding CPU cores and RAM to our systems… but it’s a pretty unfortunate mess
I’m no type really aware of the point you’re implying…is JS only succeeding because computers are fast? I didn’t think that was even remotely the case.
I’m not sure what you’re saying here. JS is getting more complex because browsers are getting faster. They’re getting faster so we can have improved functionality. They’ve always done that. If you want a browser that felt like it was the end stage of the browsing world, you’re free to bust out IE6 again.
Those who do not understand WebApps are condemned to reinvent them, poorly.
Not sure about that conclusion - SQL injection is preventable by prepared statements, XSS and XSRF are preventable by CORS. These aren’t considerations made in the design phase relating to the architecture that I’d agree are hard/impossible to prevent, these are exploits that should be handled by abstraction layers in the frameworks you use.
Or more precisely: parameterized queries, where parameters are never interpreted as part of the query. The distinction between the two is important at least in Postgres, because prepared statements require more work on the client side than parameterized queries do.
Just like memory overflows and double-frees should be solved by abstractions in the language you use :)
XSS ans XSRF are not preventable by CORS to my knowledge. at the opposite, they are intinsic to web technology and bypass CORS.
I do like to complain about the web, but I couldn’t get into this. And I sure as hell do not feel like installing your app just to read complaints about the web.
the JVM idea is a terrible idea. There is no sandboxing in JVM and the idea to have bytecode by default is a terrible one.