21 ms·

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

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 impossible to secure. "Buffers that don’t specify their length" Is this really a common problem in web apps? Most web apps are built in languages that don't have buffer overrun problems. There are many classes of security bug to be found in web apps, some unique to web apps...I just don't think this is one of them. This was a common problem in those C/C++ programs from the 90s the author is seemingly pretty fond of. Not so much web apps built in PHP/JavaScript/Python/Ruby/Perl/whatever.

pron 9y ago
> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. Many programs in the 90s, especially of the simple CRUD type, were written in VisualBasic and other RAD tools, as they were known at the time, and later Java. > Is this really a common problem in web apps? Most web apps are built in languages that don't have buffer overrun problems. It's not buffer overrun in the "undefined behavior" sense, but rather problems relating to the need to parse text data, which can be tricky and susceptible to injection attacks.
- SwellJoe 9y ago
  "Many programs in the 90s, especially of the simple CRUD type, were written in VisualBasic and other RAD tools, as they were known at the time, and later Java." And, we complained endlessly about how slow and bloated those programs were. So it goes.
  - blub 9y ago
    I don't rememeber complaints about Delphi or VB being particularly slow. Java apps were on the other hand slow. Ironically, today we have so many languages producing slow code, that Java is considered fast.
Spooky23 9y ago
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 along and want something else. When the answer is that everything is wrong, the question is usually wrong.
- TeMPOraL 9y ago
  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.
  - crooked-v 9y ago
    Windows 95-era Word didn’t have to handle real-time collaboration over the Web between an arbitrary number of users.
    - TeMPOraL 9y ago
      No, it didn't. But is it so complex it requires 10x+ the resource use? I don't think so.
      - Brakenshire 9y ago
        You can say the same about Windows 2016. Recommended RAM has gone up more than 100-fold, from 16MB to 2000MB. Developers use the resources made available to them, that has nothing to do with the web.
        lunchables 9y ago
        No one is writing web apps using javascript because they're "using the resources available" to them, in the form of powerful hardware. They're using the only TOOLS available (javascript). The problem is we just don't have a better choice, at least on the front-end.
disordinary 9y ago
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 the discipline and rigor that was required before. In some ways we've traded speed for productivity.
- ZenoArrow 9y ago
  > "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.
  - disordinary 9y ago
    That's not the point though. The example given in the article was Google Docs which has the same UI paradigm to Word. Under the hood it's massively different obviously with real time collaboration and constantly up to date syncing. So, the reasoning is that UI is fundamentally the same (or worse if not done right) to native UI from the 90's, yet it hasn't had a massive speed increase which seems wasteful. 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. 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.
    - ZenoArrow 9y ago
      > "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 the 1990s. You'll only see that speed up if you've working with a large enough volume of formulas. Measuring speed by UI speed alone doesn't get you very far. All that being said, you won't find me disagreeing with the fact that desktop apps are bloated (web apps even more so). I've experienced responsive desktop apps running on a 7.14MHz CPU. The fact that we've thrown away most of the hardware improvements since the 1980s should be clear to anyone paying attention.
intrasight 9y ago
I agree - nothing new. Reason: next generation of developers has to make the same mistakes as the previous generation. I mean why wouldn't they? It's not like there is any institutional memory in this profession.
- diminish 9y ago
  there's the opposite of an "institutional memory" - kind of a continuous revolution where we must forget, repeat and forget and repeat.
  - intrasight 9y ago
    Yeah. Like "anti-memory".
aidenn0 9y ago
> "Web development is slowly reinventing the 1990's." > The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. Yes, this reminds me of: "Wasn't all this done years ago at Xerox PARC? (No one remembers what was really done at PARC, but everyone else will assume you remember something they don't.)" [1] > "Buffers that don’t specify their length" > Is this really a common problem in web apps? Most web apps are built in languages that don't have buffer overrun problems. There are many classes of security bug to be found in web apps, some unique to web apps...I just don't think this is one of them. This was a common problem in those C/C++ programs from the 90s the author is seemingly pretty fond of. Not so much web apps built in PHP/JavaScript/Python/Ruby/Perl/whatever. Most injection attacks are due to this; if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately. 1: https://www.cs.purdue.edu/homes/dec/essay.criticize.html https://www.cs.purdue.edu/homes/dec/essay.criticize.html
- sbov 9y ago
  > Most injection attacks are due to this; if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately No it wouldn't. It wouldn't fix sql injection and it also wouldn't fix the path bug the op linked. The problem is not length, it is context unaware strings. The problem is our obsession with primitive types that pervade our codebases.
  - andrewstuart2 9y ago
    SQL injection is not a web problem. If you create SQL queries based on any untrusted (e.g. user) input on any platform, you have to escape/explicitly type your input. Injection in general is simply a trust problem. If you can trust all inputs fully (hint: you can't, because nobody can), then you will never have an injection attack.
    - vbezhenar 9y ago
      SQL injection is a problem with SQL, which is similar to problems with HTML. SQL was created as human-friendly query languages, it wasn't created to be built from strings in a programming language. Proper database API should be just a bunch of query builder calls and with this API SQL-injection is not possible.
ryanlol 9y ago
>Most web apps are built in languages that don't have buffer overrun problems. This is a very dangerous assumption. The interpreters you use have not been built with security in mind. Go take a look at PHP changelogs for example.
gens 9y ago
> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. Back then the compilers sucked. They would take complete crap of code and still it would work. They were like browsers are today. (from my experience from going through one old MUD code) Today the song is different. Not only will the compilers warn you of many things, there's even tools for static analysis (and dynamic). So the argument that C (and even the more complex C++) is inherently insecure holds much less weight (just go run old code through a static analyzer, or a normal compiler for that matter). That said there's only one way to write a "secure program", and that is formal verification. People that talk with a serious tone should back up their claims, at least that's my opinion.
- jdietrich 9y ago
  C and C++ simply weren't designed with safety in mind. Even with a good compiler and static analysis, security-critical bugs will slip through the net that simply wouldn't happen in other languages. It's not so much a question of whether it's possible to write safe C, but whether it's natural or easy. C is unsafe by default.
- MikeHolman 9y ago
  C and C++ are definitely not as secure as a language with automatic memory management. OOB reads/writes, type confusion, and UAF are all very real problems in C and C++. Static analysis helps, but it can't catch everything. I work on a modern C++ codebase, and we still face all of these issues. Formal verification is infeasible for most software projects, but they can get guaranteed type/memory safety by using a language proven to be safe. C/C++ can't give you that, but JavaScript might be able to.
  - gens 9y ago
    Not as secure, but nowhere near the death traps as some(many?) describe them. Things that are written in C these days are usually written in C for performance reasons. FFMPEG would not have even close to the performance it has if it was written in a memory safe language instead of C and assembly. I doubt that a magical compiler (and/or language) will appear in my lifetime that can compile high level code into performant machine code, especially when it comes to memory management. (note that C also has advantages other then performance) JS doesn't even have a proper specification, let alone a bug-free interpreter/compiler. EDIT: AFAIK verifying memory access is part of a formal verification, where memory is also modeled mathematically.
nostrademons 9y ago
The security aspect was an interesting part of this piece, because one of the main reasons webapps took over from Windows apps is because they were perceived as more secure. I could disable ActiveX and Java and be reasonably confident that visiting a webpage would not pwn my computer, which I certainly couldn't do when downloading software from the Internet. And then a major reason mobile apps took over from webapps is because they were perceived as more secure, because they were immune to the type of XSRF and XSS vulnerabilities that webapps were vulnerable to. Consumers don't think about security the way an IT professional does. A programmer thinks of all the ways that a program could fuck up your computer; it's a large part of our job description. The average person is terrible at envisioning things that don't exist or contemplating the consequences of hypotheticals that haven't happened. Their litmus test for whether a platform is secure is "Have I been burned by software on this platform in the past?" If they have been burned enough times by the current incumbent, they start looking around for alternatives that haven't screwed them over yet. If they find anything that does what they need it to do and whose authors promise that it's more secure, they'll switch. Extra bonus points if it has added functionality like fitting in your pocket or letting you instantly talk with anyone on earth. The depressing corollary of this is that security is not selected for by the market. The key attribute that customers select for is "has it screwed me yet?", which all new systems without obvious vulnerabilities can claim because the bad guys don't have time or incentive to write exploits for them yet. Somebody who actually builds a secure system will be spending resources securing it that they won't be spending evangelizing it; they'll lose out to systems that promise security (and usually address a few specific attacks on the previous incumbent) . And so the tech industry will naturally oscillate on a ~20-year cycle with new platforms replacing old ones, gaining adoption on better convenience & security, attracting bad actors who take advantage of their vulnerabilities, becoming unusable because of the bad actors, and then eventually being replaced by fresh new platforms. On the plus side, this is a full-employment theorem for tech entrepreneurs.
- jacquesm 9y ago
  > 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.
Devid2014 9y ago
> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. You know that most today OS are written in C or C++ ? Also many higher level languages are it self written in C or C++? Write secure applications is hard and need a lot of discipline and knowledge that most developers simple do not have. Better tools can and need to help here as well as better languages. But it is still possible to write pretty secure and efficient software in modern C++. Yes it is not easy but possible.
- armitron 9y ago
  Then prove it, list substantial codebases written in C++ that you deem secure. You'll find that it's not easy to do.
  - fdchn2016 9y ago
    In another comment on this page, there is a developer who claims a web server was made more secure by writing it in Perl (which is written in C/C++). The original webserver was written in C.
dvfjsdhgfv 9y ago
> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. > "Buffers that don’t specify their length" And yet, we found good ways to eliminate the most common sources of these problems by using new languages. The web, on the other hand, is an amalgamate of several different technologies and creating a new language won't make it more secure.
acobster 9y ago
Totally agree, and would add that it's no coincidence that articles like these tend to conflate "web programming" with the current state of the JS ecosystem. Yes JS is kinda crazy if you don't know how to select the right tooling for the job (just like every other popular language), but the leap to the web in general - getting people to go along with the conflation - is not possible without a good deal of FUD.
weddpros 9y ago
"Buffers that don’t specify their length" Most if not all webapp security problems come from an attack of servers, not clients... It's just one of these assertions that throw a dark shadow on the whole article. But "Flux is Windows 1.0" is my favorite.
microcolonel 9y ago
C is not impossible to secure, actually. There are popular C programs which are more robust than your average high-level dynamic language program. It takes a deep commitment (hence a lack of good examples), but there is generally a clear path to a well-behaved program in C, and there's nothing about C itself which prevents you from writing secure code. On the web, you must actively mitigate pitfalls of the platform itself, in C you just have to make sure your program is itself well behaved. You might argue either way, but a straightforward C program can be correct if it is well formulated, but a straightforward web app can not be correct unless it is fully mitigated.
- bloaf 9y ago
  How many really truly secure C programs have ever been released into the wild? Maybe qmail? But qmail did it by completely rewriting the C standard library.
  - microcolonel 9y ago
    Admittedly few, but generally in native land you have the ability to plaster over platform deficiencies with equally-well-performing code. On the web, you can never really compete with the execution speed or integration of the native code in the browser, so you have to accept whatever is there. I'd say OpenSSH (since SSH2) has a better track record than most webapps, as unfair a comparison as that is. In terms of local robustness, there's SeL4, which is also a bit unfair (since it took about a decade for a team of geniuses to prove enough properties to make it probably not very buggy).
    - moosingin3space 9y ago
      I wouldn't consider seL4 to be a "C project". Yes, their github repository is mostly C, but the process of writing seL4 was extremely involved: write the kernel in Haskell, then write it again in C, then prove that the C is equivalent to the Haskell. seL4 is ~9000 lines of C, ~600 lines of asm, and ~200,000 lines of Isabelle (theorem prover). I don't disagree with your use of OpenSSH as an example.
  - 9y ago
alkonaut 9y ago
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 go the same way as the HTML layout model.
- marmart 9y ago
  Gridbox and Flexbox largely make layouts sane again.
  - giblaz 9y ago
    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 worth it? There are a lot of highly rated books on the topic of web development and if you don't already know what you need, it can be daunting. But yes, flexbox is great.
    - spynxic 9y ago
      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.
      - webjprgm 9y ago
        Telnet? That's the alternative I can remember.
jeffdavis 9y ago
"Most web apps are built in languages that don't have buffer overrun problems." You misunderstood the author's point. Things like SQL injection are really equivalent to buffer overflow attacks -- data creeping into the code because of poor bounds checking.
- halfteatree 9y ago
  But SQL injection isn't a thing unique to the web right? Like, SQL injection is totally a thing with c/c++ as well. Maybe focus on one problem at a time.
  - mike_hearn 9y ago
    SQL injection is to do with SQL, a text based protocol for expressing commands to a server. Like all text based protocols trying to combine it with user-provided data immediately takes you into a world of peculiar escaping rules, magic quotes and constant security failures. The fix for SQL injection is to work with binary APIs and protocols more. Parameterised queries are the smallest step to that world, where the user-supplied data rides alongside the query itself in separated length-checked buffers (well, assuming you're not writing buggy C - let's presume modern bounds checking languages here). They aren't combined back into text, instead the database engine itself knows how to combine them when it converts the SQL to its own internal binary in-memory representation, as IR objects. Another fix is to move entirely to the world of type safe, bounds checked APIs via an ORM. But then you pay the cost of the impedance mismatch between the object and relational realms, which isn't great. I will provide a solution for this in part II.
Myrmornis 9y ago
> Most web apps are built in languages that don't have buffer overrun problems. The author is using "buffer" in a different sense than you are. You're thinking of a malloc'd buffer. The author is using "buffer" more abstractly, to refer to a data segment, such as a JSON or HTML string, or a string of encoded form data. His point is that that latter type of "buffer" has no declared length, and needs to be parsed in order to determine where it ends, and that as a result it is subject to problems that one can term "buffer overrun" by analogy with the traditional C scenario in which one obtains a pointer to some memory that you should not have access to.
deleted 9y ago
[deleted]
snipethunder 9y ago
As an iOS developer, I would say state of web development is not true for iOS. Sure it is slowly evolved to the current state but the framework much more thought out than their web counter part.
- hannofcart 9y ago
  "As an iOS developer" is another way of saying "I can't see past the walls of Apple's walled garden". Seriously, the reactive frameworks (any really: React/VueJS/Preact/...) used in tandem with a separate state container (Redux, Vuex...) is a much better "thought out" approach to application programming than anything in the Cocoa/Swift world.
coldtea 9y ago
> >*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 don't see how this is an argument in favor of the web. If anything, it re-enforces the accusation TFA made against it even more. If "The 90s were slowly reinventing UNIX" then why would be recreating the 90s today a good thing? If the 90s "slowly reinvented UNIX", then the correct thing to do would be for the web today to either be a fully modern 2017-worthy technology, or at least take its starting point from where the 90s ENDED, not re-invent the 90s.
- SwellJoe 9y ago
  "If the 90s "slowly reinvented UNIX", then the correct thing to do would be for the web today to either be a fully modern 2017-worthy technology, or at least take its starting point from where the 90s ENDED, not re-invent the 90s." 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.
  - blub 9y ago
    Better for what? The web is getting worse and worse for the users. Before this JavaScript craze it was predictable, bookmarkable, usable and reasonably performant. Now it's slow, burns your battery, it's full of ads/tracking and anti-patterns like infinite scroll or SPAs and view source is useless. For me, a site like HN or amazon (with some reservations) is the pinnacle of what the web is able to offer.
artagnon 9y ago
Every generation of programmers _does_ learn from previous work, and every new platform starts from scratch learning the lessons, and incrementally evolves. A Hello World GUI on Windows 95 will require calling into a complex and undecipherable Win32 API; a Hello World on the web needs one simple line. Platforms do get frozen over time (like the Linux kernel), and people use it to build useful things with low effort. The Linux kernel is a result of incremental evolution: Linus proudly says that it's not designed. There are severe shortcomings in all platforms that have aged. Why does power management in Linux suck so hard? Why can't we have networked filesystems by default (NFS is quite bad btw)? Until somewhat recently (~7 years), audio on Linux was a disaster: "Linux was never designed to do low-latency audio, or even handle multiple audio streams (anyone remember upmixing in PulseAudio?)". What the hell are UNIX sockets? Is there no modern way for desktop applications to talk to each other? (DBus was recently merged into the kernel). Why doesn't it have a native display engine? (X11?) Today, it's more fashionable to criticize the web, since majority of the industry programmers endure it. Sure, there are some "simple" things that are just "not possible" with the web (everyone's pet peeve: centering). Yes, you lose functionality of a desktop application, but that's the whole point of a new platform: make what people really need easy, at the cost of other functionality. For an example, see how Emacs has been turned into a web app, in the form of Atom? You don't have to write hundreds of lines of arcane elisp, but you also don't get many features. Atom is a distillation of editor features that people really want. I don't understand the criticism of transpiling everything to Js; you do, after all, compile all desktop applications to x86 assembly anyway. x86 assembly is another awful standard: it has evolved into ugliness (ARM offers some hope). Every platform was designed to start out with, and evolved into ugliness as it aged. We already have a rethink of part of the system: wasm looks quite promising, and you'll soon be able to write your Idris to run in a web browser.
- pjmlp 9y ago
  Instead of doing console.alert("Hello World") We would do (VB) MsgBox("Hello World") Or maybe (Delphi) MessageBox("Hello World"); Only hard core C devs bothered to use Win32 directly.
  - 9y ago
ksk 9y ago
>Every negative thing said about the web is true of every other platform, so far. What are you basing this on? You can't put Ada, Erlang, Haskell, FORTRAN, etc in the same bucket as C or C++.
johnvega 9y ago
This is a WEB APP https://3d.delavega.us https://3d.delavega.us using 3js. It can run on most iOS and Android smartphones, most Windows and macOS machines and Linux computers. It is likely to run on over a billion devices, and no installation required. Can a non webapp or native app be better than this?
- bottled_poe 9y ago
  Check this out: http://www.georgeandjonathan.com/ http://www.georgeandjonathan.com/
EGreg 9y ago
"Buffers that don't specify their length" Instead of thinking of it as buffers, you just have to encode/decode for the proper environment. Such repetitive stuff is easily implemented in stack layers.
TheMiddleMan 9y ago
Yeah, to me it sounds like a case of "grass is greener" syndrome.
Fej 9y ago
This might be the biggest dichotomy I've yet seen on HN. An opinion piece voted all the way to the top of the front page (with a clickbaity title, might I add), yet the top comment soundly debunks the article's arguments. Yeah, this is why everybody clicks on the comments link first.
- andreineculau 9y ago
  The article itself is click bait since the real meat is to be expected in the follow-up article.
- SwellJoe 9y ago
  Mike Hearn (the author of the original article) is a bright dude, who is well-known in several tech circles, which may explain the high ranking for the post here on HN. I'm not intending to dismiss him outright; he may have an interesting follow-up. I guess I'm just much more optimistic about the web than he seems to be, and more critical of everything that's come before than he seems to be. I think Mike is about the same age as me, and probably has a similarly long history in tech, so I can't really pull the "hard-earned wisdom and experience" card in this conversation. I think I just disagree with him on this, and that's not a big deal. One of us might be right. (But, I think betting against the web is crazy.)
- TeMPOraL 9y ago
  To somewhat counter all the negative comments here - I read this article and agree pretty much 100% with every sentence in it. There are probably more people who agree with the post - hence the upvotes.
  - dgreensp 9y ago
    Yes, I agreed with the entire article as well. I didn't see anything controversial or exaggerated about it. Edit: Ok, maybe I could have predicted that lines like "HTML 5 is a plague on our industry" would ruffle some feathers. I guess I like a little snark in my criticism.
  - jonnytran 9y ago
fetbaffe 9y ago
You are missing one of the main points of the author. It is possible, in theory, to write a secure C/C++ application, however it is not even possible in theory(!) to write a secure web application.

pron 9y ago

> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. Many programs in the 90s, especially of the simple CRUD type, were written in VisualBasic and other RAD tools, as they were known at the time, and later Java. > Is this really a common problem in web apps? Most web apps are built in languages that don't have buffer overrun problems. It's not buffer overrun in the "undefined behavior" sense, but rather problems relating to the need to parse text data, which can be tricky and susceptible to injection attacks.

SwellJoe 9y ago
"Many programs in the 90s, especially of the simple CRUD type, were written in VisualBasic and other RAD tools, as they were known at the time, and later Java." And, we complained endlessly about how slow and bloated those programs were. So it goes.
- blub 9y ago
  I don't rememeber complaints about Delphi or VB being particularly slow. Java apps were on the other hand slow. Ironically, today we have so many languages producing slow code, that Java is considered fast.

Spooky23 9y ago

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 along and want something else. When the answer is that everything is wrong, the question is usually wrong.

TeMPOraL 9y ago
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.
- crooked-v 9y ago
  Windows 95-era Word didn’t have to handle real-time collaboration over the Web between an arbitrary number of users.
  - TeMPOraL 9y ago
    No, it didn't. But is it so complex it requires 10x+ the resource use? I don't think so.
    - Brakenshire 9y ago
      You can say the same about Windows 2016. Recommended RAM has gone up more than 100-fold, from 16MB to 2000MB. Developers use the resources made available to them, that has nothing to do with the web.
      - lunchables 9y ago
        No one is writing web apps using javascript because they're "using the resources available" to them, in the form of powerful hardware. They're using the only TOOLS available (javascript). The problem is we just don't have a better choice, at least on the front-end.

disordinary 9y ago

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 the discipline and rigor that was required before. In some ways we've traded speed for productivity.

ZenoArrow 9y ago
> "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.
- disordinary 9y ago
  That's not the point though. The example given in the article was Google Docs which has the same UI paradigm to Word. Under the hood it's massively different obviously with real time collaboration and constantly up to date syncing. So, the reasoning is that UI is fundamentally the same (or worse if not done right) to native UI from the 90's, yet it hasn't had a massive speed increase which seems wasteful. 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. 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.
  - ZenoArrow 9y ago
    > "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 the 1990s. You'll only see that speed up if you've working with a large enough volume of formulas. Measuring speed by UI speed alone doesn't get you very far. All that being said, you won't find me disagreeing with the fact that desktop apps are bloated (web apps even more so). I've experienced responsive desktop apps running on a 7.14MHz CPU. The fact that we've thrown away most of the hardware improvements since the 1980s should be clear to anyone paying attention.

intrasight 9y ago

I agree - nothing new. Reason: next generation of developers has to make the same mistakes as the previous generation. I mean why wouldn't they? It's not like there is any institutional memory in this profession.

diminish 9y ago
there's the opposite of an "institutional memory" - kind of a continuous revolution where we must forget, repeat and forget and repeat.
- intrasight 9y ago
  Yeah. Like "anti-memory".

aidenn0 9y ago

> "Web development is slowly reinventing the 1990's." > The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. Yes, this reminds me of: "Wasn't all this done years ago at Xerox PARC? (No one remembers what was really done at PARC, but everyone else will assume you remember something they don't.)" [1] > "Buffers that don’t specify their length" > Is this really a common problem in web apps? Most web apps are built in languages that don't have buffer overrun problems. There are many classes of security bug to be found in web apps, some unique to web apps...I just don't think this is one of them. This was a common problem in those C/C++ programs from the 90s the author is seemingly pretty fond of. Not so much web apps built in PHP/JavaScript/Python/Ruby/Perl/whatever. Most injection attacks are due to this; if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately. 1: https://www.cs.purdue.edu/homes/dec/essay.criticize.html https://www.cs.purdue.edu/homes/dec/essay.criticize.html

sbov 9y ago
> Most injection attacks are due to this; if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately No it wouldn't. It wouldn't fix sql injection and it also wouldn't fix the path bug the op linked. The problem is not length, it is context unaware strings. The problem is our obsession with primitive types that pervade our codebases.
- andrewstuart2 9y ago
  SQL injection is not a web problem. If you create SQL queries based on any untrusted (e.g. user) input on any platform, you have to escape/explicitly type your input. Injection in general is simply a trust problem. If you can trust all inputs fully (hint: you can't, because nobody can), then you will never have an injection attack.
  - vbezhenar 9y ago
    SQL injection is a problem with SQL, which is similar to problems with HTML. SQL was created as human-friendly query languages, it wasn't created to be built from strings in a programming language. Proper database API should be just a bunch of query builder calls and with this API SQL-injection is not possible.

ryanlol 9y ago

>Most web apps are built in languages that don't have buffer overrun problems. This is a very dangerous assumption. The interpreters you use have not been built with security in mind. Go take a look at PHP changelogs for example.

gens 9y ago

> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. Back then the compilers sucked. They would take complete crap of code and still it would work. They were like browsers are today. (from my experience from going through one old MUD code) Today the song is different. Not only will the compilers warn you of many things, there's even tools for static analysis (and dynamic). So the argument that C (and even the more complex C++) is inherently insecure holds much less weight (just go run old code through a static analyzer, or a normal compiler for that matter). That said there's only one way to write a "secure program", and that is formal verification. People that talk with a serious tone should back up their claims, at least that's my opinion.

jdietrich 9y ago
C and C++ simply weren't designed with safety in mind. Even with a good compiler and static analysis, security-critical bugs will slip through the net that simply wouldn't happen in other languages. It's not so much a question of whether it's possible to write safe C, but whether it's natural or easy. C is unsafe by default.
MikeHolman 9y ago
C and C++ are definitely not as secure as a language with automatic memory management. OOB reads/writes, type confusion, and UAF are all very real problems in C and C++. Static analysis helps, but it can't catch everything. I work on a modern C++ codebase, and we still face all of these issues. Formal verification is infeasible for most software projects, but they can get guaranteed type/memory safety by using a language proven to be safe. C/C++ can't give you that, but JavaScript might be able to.
- gens 9y ago
  Not as secure, but nowhere near the death traps as some(many?) describe them. Things that are written in C these days are usually written in C for performance reasons. FFMPEG would not have even close to the performance it has if it was written in a memory safe language instead of C and assembly. I doubt that a magical compiler (and/or language) will appear in my lifetime that can compile high level code into performant machine code, especially when it comes to memory management. (note that C also has advantages other then performance) JS doesn't even have a proper specification, let alone a bug-free interpreter/compiler. EDIT: AFAIK verifying memory access is part of a formal verification, where memory is also modeled mathematically.

nostrademons 9y ago

The security aspect was an interesting part of this piece, because one of the main reasons webapps took over from Windows apps is because they were perceived as more secure. I could disable ActiveX and Java and be reasonably confident that visiting a webpage would not pwn my computer, which I certainly couldn't do when downloading software from the Internet. And then a major reason mobile apps took over from webapps is because they were perceived as more secure, because they were immune to the type of XSRF and XSS vulnerabilities that webapps were vulnerable to. Consumers don't think about security the way an IT professional does. A programmer thinks of all the ways that a program could fuck up your computer; it's a large part of our job description. The average person is terrible at envisioning things that don't exist or contemplating the consequences of hypotheticals that haven't happened. Their litmus test for whether a platform is secure is "Have I been burned by software on this platform in the past?" If they have been burned enough times by the current incumbent, they start looking around for alternatives that haven't screwed them over yet. If they find anything that does what they need it to do and whose authors promise that it's more secure, they'll switch. Extra bonus points if it has added functionality like fitting in your pocket or letting you instantly talk with anyone on earth. The depressing corollary of this is that security is not selected for by the market. The key attribute that customers select for is "has it screwed me yet?", which all new systems without obvious vulnerabilities can claim because the bad guys don't have time or incentive to write exploits for them yet. Somebody who actually builds a secure system will be spending resources securing it that they won't be spending evangelizing it; they'll lose out to systems that promise security (and usually address a few specific attacks on the previous incumbent) . And so the tech industry will naturally oscillate on a ~20-year cycle with new platforms replacing old ones, gaining adoption on better convenience & security, attracting bad actors who take advantage of their vulnerabilities, becoming unusable because of the bad actors, and then eventually being replaced by fresh new platforms. On the plus side, this is a full-employment theorem for tech entrepreneurs.

jacquesm 9y ago
> 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.

Devid2014 9y ago

> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. You know that most today OS are written in C or C++ ? Also many higher level languages are it self written in C or C++? Write secure applications is hard and need a lot of discipline and knowledge that most developers simple do not have. Better tools can and need to help here as well as better languages. But it is still possible to write pretty secure and efficient software in modern C++. Yes it is not easy but possible.

armitron 9y ago
Then prove it, list substantial codebases written in C++ that you deem secure. You'll find that it's not easy to do.
- fdchn2016 9y ago
  In another comment on this page, there is a developer who claims a web server was made more secure by writing it in Perl (which is written in C/C++). The original webserver was written in C.

dvfjsdhgfv 9y ago

> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. > "Buffers that don’t specify their length" And yet, we found good ways to eliminate the most common sources of these problems by using new languages. The web, on the other hand, is an amalgamate of several different technologies and creating a new language won't make it more secure.

acobster 9y ago

Totally agree, and would add that it's no coincidence that articles like these tend to conflate "web programming" with the current state of the JS ecosystem. Yes JS is kinda crazy if you don't know how to select the right tooling for the job (just like every other popular language), but the leap to the web in general - getting people to go along with the conflation - is not possible without a good deal of FUD.

weddpros 9y ago

"Buffers that don’t specify their length" Most if not all webapp security problems come from an attack of servers, not clients... It's just one of these assertions that throw a dark shadow on the whole article. But "Flux is Windows 1.0" is my favorite.

microcolonel 9y ago

C is not impossible to secure, actually. There are popular C programs which are more robust than your average high-level dynamic language program. It takes a deep commitment (hence a lack of good examples), but there is generally a clear path to a well-behaved program in C, and there's nothing about C itself which prevents you from writing secure code. On the web, you must actively mitigate pitfalls of the platform itself, in C you just have to make sure your program is itself well behaved. You might argue either way, but a straightforward C program can be correct if it is well formulated, but a straightforward web app can not be correct unless it is fully mitigated.

bloaf 9y ago
How many really truly secure C programs have ever been released into the wild? Maybe qmail? But qmail did it by completely rewriting the C standard library.
- microcolonel 9y ago
  Admittedly few, but generally in native land you have the ability to plaster over platform deficiencies with equally-well-performing code. On the web, you can never really compete with the execution speed or integration of the native code in the browser, so you have to accept whatever is there. I'd say OpenSSH (since SSH2) has a better track record than most webapps, as unfair a comparison as that is. In terms of local robustness, there's SeL4, which is also a bit unfair (since it took about a decade for a team of geniuses to prove enough properties to make it probably not very buggy).
  - moosingin3space 9y ago
    I wouldn't consider seL4 to be a "C project". Yes, their github repository is mostly C, but the process of writing seL4 was extremely involved: write the kernel in Haskell, then write it again in C, then prove that the C is equivalent to the Haskell. seL4 is ~9000 lines of C, ~600 lines of asm, and ~200,000 lines of Isabelle (theorem prover). I don't disagree with your use of OpenSSH as an example.
- 9y ago

alkonaut 9y ago

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 go the same way as the HTML layout model.

marmart 9y ago
Gridbox and Flexbox largely make layouts sane again.
- giblaz 9y ago
  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 worth it? There are a lot of highly rated books on the topic of web development and if you don't already know what you need, it can be daunting. But yes, flexbox is great.
  - spynxic 9y ago
    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.
    - webjprgm 9y ago
      Telnet? That's the alternative I can remember.

jeffdavis 9y ago

"Most web apps are built in languages that don't have buffer overrun problems." You misunderstood the author's point. Things like SQL injection are really equivalent to buffer overflow attacks -- data creeping into the code because of poor bounds checking.

halfteatree 9y ago
But SQL injection isn't a thing unique to the web right? Like, SQL injection is totally a thing with c/c++ as well. Maybe focus on one problem at a time.
- mike_hearn 9y ago
  SQL injection is to do with SQL, a text based protocol for expressing commands to a server. Like all text based protocols trying to combine it with user-provided data immediately takes you into a world of peculiar escaping rules, magic quotes and constant security failures. The fix for SQL injection is to work with binary APIs and protocols more. Parameterised queries are the smallest step to that world, where the user-supplied data rides alongside the query itself in separated length-checked buffers (well, assuming you're not writing buggy C - let's presume modern bounds checking languages here). They aren't combined back into text, instead the database engine itself knows how to combine them when it converts the SQL to its own internal binary in-memory representation, as IR objects. Another fix is to move entirely to the world of type safe, bounds checked APIs via an ORM. But then you pay the cost of the impedance mismatch between the object and relational realms, which isn't great. I will provide a solution for this in part II.

Myrmornis 9y ago

> Most web apps are built in languages that don't have buffer overrun problems. The author is using "buffer" in a different sense than you are. You're thinking of a malloc'd buffer. The author is using "buffer" more abstractly, to refer to a data segment, such as a JSON or HTML string, or a string of encoded form data. His point is that that latter type of "buffer" has no declared length, and needs to be parsed in order to determine where it ends, and that as a result it is subject to problems that one can term "buffer overrun" by analogy with the traditional C scenario in which one obtains a pointer to some memory that you should not have access to.

deleted 9y ago

[deleted]

snipethunder 9y ago

As an iOS developer, I would say state of web development is not true for iOS. Sure it is slowly evolved to the current state but the framework much more thought out than their web counter part.

hannofcart 9y ago
"As an iOS developer" is another way of saying "I can't see past the walls of Apple's walled garden". Seriously, the reactive frameworks (any really: React/VueJS/Preact/...) used in tandem with a separate state container (Redux, Vuex...) is a much better "thought out" approach to application programming than anything in the Cocoa/Swift world.

coldtea 9y ago

> >*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 don't see how this is an argument in favor of the web. If anything, it re-enforces the accusation TFA made against it even more. If "The 90s were slowly reinventing UNIX" then why would be recreating the 90s today a good thing? If the 90s "slowly reinvented UNIX", then the correct thing to do would be for the web today to either be a fully modern 2017-worthy technology, or at least take its starting point from where the 90s ENDED, not re-invent the 90s.

SwellJoe 9y ago
"If the 90s "slowly reinvented UNIX", then the correct thing to do would be for the web today to either be a fully modern 2017-worthy technology, or at least take its starting point from where the 90s ENDED, not re-invent the 90s." 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.
- blub 9y ago
  Better for what? The web is getting worse and worse for the users. Before this JavaScript craze it was predictable, bookmarkable, usable and reasonably performant. Now it's slow, burns your battery, it's full of ads/tracking and anti-patterns like infinite scroll or SPAs and view source is useless. For me, a site like HN or amazon (with some reservations) is the pinnacle of what the web is able to offer.

artagnon 9y ago

Every generation of programmers _does_ learn from previous work, and every new platform starts from scratch learning the lessons, and incrementally evolves. A Hello World GUI on Windows 95 will require calling into a complex and undecipherable Win32 API; a Hello World on the web needs one simple line. Platforms do get frozen over time (like the Linux kernel), and people use it to build useful things with low effort. The Linux kernel is a result of incremental evolution: Linus proudly says that it's not designed. There are severe shortcomings in all platforms that have aged. Why does power management in Linux suck so hard? Why can't we have networked filesystems by default (NFS is quite bad btw)? Until somewhat recently (~7 years), audio on Linux was a disaster: "Linux was never designed to do low-latency audio, or even handle multiple audio streams (anyone remember upmixing in PulseAudio?)". What the hell are UNIX sockets? Is there no modern way for desktop applications to talk to each other? (DBus was recently merged into the kernel). Why doesn't it have a native display engine? (X11?) Today, it's more fashionable to criticize the web, since majority of the industry programmers endure it. Sure, there are some "simple" things that are just "not possible" with the web (everyone's pet peeve: centering). Yes, you lose functionality of a desktop application, but that's the whole point of a new platform: make what people really need easy, at the cost of other functionality. For an example, see how Emacs has been turned into a web app, in the form of Atom? You don't have to write hundreds of lines of arcane elisp, but you also don't get many features. Atom is a distillation of editor features that people really want. I don't understand the criticism of transpiling everything to Js; you do, after all, compile all desktop applications to x86 assembly anyway. x86 assembly is another awful standard: it has evolved into ugliness (ARM offers some hope). Every platform was designed to start out with, and evolved into ugliness as it aged. We already have a rethink of part of the system: wasm looks quite promising, and you'll soon be able to write your Idris to run in a web browser.

pjmlp 9y ago
Instead of doing console.alert("Hello World") We would do (VB) MsgBox("Hello World") Or maybe (Delphi) MessageBox("Hello World"); Only hard core C devs bothered to use Win32 directly.
- 9y ago

ksk 9y ago

>Every negative thing said about the web is true of every other platform, so far. What are you basing this on? You can't put Ada, Erlang, Haskell, FORTRAN, etc in the same bucket as C or C++.

johnvega 9y ago

This is a WEB APP https://3d.delavega.us https://3d.delavega.us using 3js. It can run on most iOS and Android smartphones, most Windows and macOS machines and Linux computers. It is likely to run on over a billion devices, and no installation required. Can a non webapp or native app be better than this?

bottled_poe 9y ago
Check this out: http://www.georgeandjonathan.com/ http://www.georgeandjonathan.com/

EGreg 9y ago

"Buffers that don't specify their length" Instead of thinking of it as buffers, you just have to encode/decode for the proper environment. Such repetitive stuff is easily implemented in stack layers.

TheMiddleMan 9y ago

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

Fej 9y ago

This might be the biggest dichotomy I've yet seen on HN. An opinion piece voted all the way to the top of the front page (with a clickbaity title, might I add), yet the top comment soundly debunks the article's arguments. Yeah, this is why everybody clicks on the comments link first.

andreineculau 9y ago
The article itself is click bait since the real meat is to be expected in the follow-up article.
SwellJoe 9y ago
Mike Hearn (the author of the original article) is a bright dude, who is well-known in several tech circles, which may explain the high ranking for the post here on HN. I'm not intending to dismiss him outright; he may have an interesting follow-up. I guess I'm just much more optimistic about the web than he seems to be, and more critical of everything that's come before than he seems to be. I think Mike is about the same age as me, and probably has a similarly long history in tech, so I can't really pull the "hard-earned wisdom and experience" card in this conversation. I think I just disagree with him on this, and that's not a big deal. One of us might be right. (But, I think betting against the web is crazy.)
TeMPOraL 9y ago
To somewhat counter all the negative comments here - I read this article and agree pretty much 100% with every sentence in it. There are probably more people who agree with the post - hence the upvotes.
- dgreensp 9y ago
  Yes, I agreed with the entire article as well. I didn't see anything controversial or exaggerated about it. Edit: Ok, maybe I could have predicted that lines like "HTML 5 is a plague on our industry" would ruffle some feathers. I guess I like a little snark in my criticism.
- jonnytran 9y ago

fetbaffe 9y ago

You are missing one of the main points of the author. It is possible, in theory, to write a secure C/C++ application, however it is not even possible in theory(!) to write a secure web application.