gophering on
HN Gopher Feed (2017-09-23) - page 1 of 10
It's time to kill the web app
330 points by raindev

hexmiles - 2 hours ago
While i understand the article and agree with it, i love
programming webapps. The combination of html/CSS is much easier
(for me at least) to work with than most other rendering framework,
also JavaScript while not perfect is very good for fast moving
target, and with "extension" like typescript you can even manage
very large application in a progressive way (you can mix js and
typescript).I also work with the android layout system and a bit of
the iOs one, and they are a lot more confusing, (Constraint-layout
fixed a couple of problem on android recently). Currently i work
manly with legacy app at work, and shiny all-js webapps at
home, but i done a lot of work also with winform and android
appsAlso the ability to update the app "on the fly" and be able to
download only the part of the application that you need is pretty
cool. Your can make your user always use the last version and
quickly deploy hotfix. I understand that this are not propriety
desirable for every type of application but sometimes are game-
changer.What i really want to have is a lighter implementation, i
think that Facebook did something similar with is Facebook lite
app.Here's a gist with what i really want for a layout/app runtime.
* Using a Url style system for retrieving resource.* A binary
protocol similar to protobuf,capnproto etc.. for talking with the
server.* A clear separation between the template and the data, so
that i can cache the entire page and only request the data for
populating it.* A Module and a Permission system, with versioning
(for backward and forward compatibly),maybe integrated.* One way to
store data (i personaly like key-value system, but i think a
document system would be more suitable).* A Unified syntax for html
and css.* a Component system(this is a big one), ideally the spec
should only define a div-style generic container that can be
specialised in a new component by adding to it, a name, style and
optionally a script witch control is behaviour, (I'm not a fan of
the web-component spec as it is).What would you want from an
alternative layout/runtime system for web-like app? I'm really
curious!PS: I really hope there will be more engineering post about
the Facebook lite app, it seem a concept really cool that could be
used for a lot of other apps!edit: adjusting formatting
  dmitriid - 1 hours ago
  > The combination of html/CSS is much easier (for me at least) to
  work with than most other rendering frameworHtml+css is not a
  rendering framework. Also, come back with your "much easier" when
  you need to do anything even remotely resembling iOS's screen
  transitions, animations, and capabilities for constrained
  layout.Even properly implementing the seemingly simple toolbar in
  Google Docs is an excercise in endless frustration.
    hexmiles - 1 hours ago
    My bad, i didn't express myself, for rendering framework i mean
    both the language and the technology that actually "execute"
    them. I understand that different browser do thing different
    but the concept are the same.Also i don't know ios very well,
    but i have implemented complex layout in both android and the
    html/css/js and i can say that android is MUCH more
    frustrating, even when we consider browser backward
    compatibility, especialy on the animation side (css animations
    were a bit hard at first, but in little time i was able to
    construct complex animation very quickly).I actually have
    builded a toolbar like the one on google docs (which i use
    daily) for editing data in a timeline for appointment, which
    had to be compatible with IE8 and while there was a lot of
    pain, i was able to iterate and experimentate a lot more
    quickly than android, and it wasn't that bad, also in my
    experience when we talk about layout and user interface there
    is A LOT more documentation on html/css than android, and there
    also are more framework/library that can help you deal with
    browser diffrence.
hyperpape - 2 hours ago
I don't get the section on JSON, which seems to assert that XML is
more secure than JSON. It does this by linking to a Wikipedia page
that includes the security consideration that you shouldn't call
eval on JSON. True, but at least that's a tractable problem. Your
linter can check for code that calls eval.In contrast, there are
plenty of XML attacks (DOS with billions of laughs, entity
references), and parsing XML is a lot more complicated, which
matters a great deal if you're using non-memory-safe libraries for
parsing. Also, because XML is so general purpose, you get things
like libraries allowing deserialization of arbitrary objects from
XML, which is a security nightmare.That last point isn't a clean
win because sometimes the same library will handle JSON and XML,
and so you have to audit the use carefully. However, if you're sure
that your serialization libraries only use JSON, its simplicity
means that it shouldn't have that kind of deserialization
vulnerability.P.S. If you want to rag on JSON, that's fine. It's
not a great format. But "it's less secure than XML" is not the tack
I'd take.
k__ - 1 hours ago
The only reason I do React-Native apps instead oft web apps now is,
the RN ones pay better.I'd love to keep doing web apps.
sunseb - 34 minutes ago
Yeah, I have been working on the web for 10 years. When I started,
it was fun, because I knew nothing, and that seemed magical to me,
but the more I work on this platform, the more I realize it's
crap.We are now at peak crap. Did you see all this JavaScript
bullshit code needed nowadays to just render a fucking web page and
fetch some data?I hope OOP would die too, I mean, it's often an
over-engineered bloat that only works for trivial Programming 101
courses (using Bike, Vehicle classes). In real world, I found OOP
to make things messy with pseudo-objects like Service, Manager,
(Abstract?!)Factory and so. Just using params and functions feels
more natural I think.Sorry for the rant. I think we all do an
unbelievable job pushing these tools to their limits, but it's just
made me sad that we may building on ugly foundations.
valuearb - 33 minutes ago
I deleted Facebook from my iphone because i don?t want to give them
that much access, and now only use their web app on my iphone. And
it?s horrible. If Facebook can?t get it right, who can? My latest
example is from 30 minutes ago, where I tried uploading s video;
and almost gave up after 5 mins. The UI was hard to understand,
extremely slow and never let me understand what was
happening.Professionally I?m an iOS lead on a dual platform (iOS @
Android) app that has hundreds of thousands of users. I?ve
occasionally wondered about whether we should switch to React
Bative and using Web Facebook always cures me of that idea.And the
fact that i?ve spent hundreds of hours optimizing our app and every
view to ensure they launch and open as quickly as possible, down to
managing every bit of memory use as ruthlessly as possible. And
letting our users use our app offline. Every second costs us users
and dollars.Then there are new technologies like ARKit. Native is
still the best way to go if you can afford the time and people to
do it the best way possible.
  rocqua - 3 minutes ago
  Facebook has decent incentive to move people from their web app
  to their mobile app.
fictionfuture - 3 hours ago
This article is so naive.It completely negates all the benefits of
the open web while  presenting problems along with non-sensical
  chime - 1 hours ago
  I apologize in advance for a political analogy but this sounds
  like "Obamacare is bad so we must repeal and replace it. I'll
  show you the replacement later."I've been a webdev for two
  decades now and while the author highlights the problems
  correctly, almost all of them have known fixes and there are
  'best practices' to avoid them.Humans are not done with
  engineering and technology. We're still coming up with better
  ways to do things. Building for the browser is one of the best
  things we've done as a civilization. I can build something, send
  a link to my dad, and he can look it up on his phone with
  literally a single touch. How is that not amazing? It blows my
  mind every time I stop to think about it.It sounds ridiculous to
  say that since buildings fall every now and then, it's time to
  kill dwellings or since cars crash frequently, it's time to kill
  transportation. So without seeing the author's replacement, I am
  not yet ready to throw away the browser and JS-ecosystem just
  yet. It's terrible that Authy's 2-factor was bypassed with one
  simple trick but that doesn't mean HTML/CSS/JS need to die. You
  could have the same exact issues with mobile apps, installed
  software, or even hardware devices.
    goatlover - 1 hours ago
    > It sounds ridiculous to say that since buildings fall every
    now and then, it's time to kill dwellings or since cars crash
    frequently, it's time to kill transportation.It's more like,
    since cars crash frequently, time to replace human drivers with
    machines.I take his argument as replacing the web as an
    application platform with something designed from the ground up
    for applications.
  generalpf - 1 hours ago
  I mean, he worked at Google for 8 years, so he probably picked up
  some of their attitude. cough AMP cough
amelius - 1 hours ago
The web is our best bet to converge to a single platform.I find it
extremely intellectually unfulfilling to write my code for three
platforms (web/Android/iOS) instead of just one. So until there is
a better common denominator, the web is my first choice, because at
least it is accessible from all three platforms, and from the
agumonkey - 3 hours ago
Even though it's a bit forced, I agree that the whole mainstream
computer field as a weird non ROI. Machines 10000x faster, personal
value/productivity: flat or below.
  closeparen - 2 hours ago
  Web properties have invested growing processing power to the
  immense benefit of their customers, advertisers. Of course users
  have not reaped productivity gains from something we don't pay
  Alex3917 - 2 hours ago
  > personal value/productivity: flat or belowExcept for that there
  are a thousand times more computer users than there were 30 years
  ago, now that we have the computer power to render talking
  paperclips or whatever to make computers usable by the average
  SwellJoe - 2 hours ago
  How do you measure that, though?It seems like you have to ignore
  all value derived from networks in order to come to the
  conclusion that software is no more powerful than in the 90s.In
  the 90s I couldn't have met with my team, with members in Moscow,
  California, Pennsylvania, and Texas, in any reasonable I can chat, including video and sound, on a
  whim!Managing source code today is massively more productive than
  in the 90s. CVS (or, heavens forbid, RCS) on a central server was
  how it was done back then, if you had revision control, at all.
  It's not merely a better revision control system (git), it's the
  web-based infrastructure around it (github/gitlab/web-based
  CI/whatever). That wouldn't be possible on any platform that's
  less connected and less widely available than the web.The rise of
  package managers is another massive productivity booster that
  maybe goes unheeded (we all love them, but I think their
  productivity value is wildly else can you
  add 100,000 lines of code, that probably works, in a couple of
  minutes, and reliably allow every member of your team to do the
  same?). Web technologies have enabled that. There's a reason npm
  has the largest package selection the world has ever seen, and I
  think it's the massive interconnectivity of the web platform.
  (This feels sort of vaguely defined, I guess...but, there is a
  magic to the web platform.)There's so many areas where we're more
  productive today because of the network effects of the web as a
  platform. Also, because the web is universal, I don't have to use
  Windows, ever. Everything I ever want to do has a Linux version.
  Anything that falls short of complete platform independence is
  probably a step backward, IMHO, even if it has other benefits
  like smaller/faster binary builds.Also...WebAssembly is coming.
  We're going to see a fast/efficient web, long before a new
  platform could possibly be delivered.
    u801e - 1 hours ago
    > In the 90s I couldn't have met with my team, with members in
    Moscow, California, Pennsylvania, and Texas, in any reasonable
    wayI remember in the mid '90s that there were a couple of
    applications that would allow you to do that (netmeeting from
    Microsoft and cooltalk from Netscape). I don't remember how
    easy or difficult it was to find other users though.
    agumonkey - 2 hours ago
    "mainstream computer" < I was talking about the average desktop
    use, not distributed codebases
      SwellJoe - 1 hours ago
      Sure, I was speaking directly to what I know...but, are
      distributed docs in Google Docs not more productive than
      passing around a Word doc with annotations? Is banking,
      accounting, trading stocks, bill payments, buying and selling
      nearly any product, not more productive today due to the same
      forces? We (people in tech) are just at the leading edge of
      it...but, it impacts everyone.But, I would argue that the web
      platform has produced a bigger productivity boost (in terms
      of output per unit of time) than any other single paradigm
      shift in computing history. Who cares if typing is a little
      more sluggish than the native app if you don't have to email
      the resulting document to everyone on the team and then
      converge edits at the end of the editing process?
    ZenoArrow - 1 hours ago
    The Internet != The Web.Many of those benefits you listed are
    linked to the growth of the Internet. Package managers, video
    conferencing, distributed version control, all mostly Internet-
    based. The web is just one part of Internet activity. It's the
    part that requires use of a web browser. If you can do
    something online without using a web browser it's because of
    the Internet.The criticisms that are being levelled at the web
    are related to it being an inefficient and insecure platform
    for applications. Note this is not Internet-enabled
    applications like package managers, but rather applications
    that run within the web. It might seem like a pedantic
    distinction, but it's a key one in understanding what's under
      SwellJoe - 54 minutes ago
      I get that and tried to make it clear that I get that,
      particularly in the paragraph about npm; Perl has the CPAN,
      Python has had a half dozen package managers (I don't even
      know which one finally "stuck"), Ruby has gems, but nothing
      exploded the way npm did. So, what's different? I would argue
      it's not that JavaScript is a better language (though it's a
      pretty strong language today). I would argue that it's a
      better platform, and that platform, ultimately, is the
      web.Every package manager works over the internet. Only one
      represents the web-as-a-platform. And, it turns out that's
      the one that has dwarfed all others in size and scope, in a
      quite short time. Nearly everything I mentioned above
      requires the internet for interconnectivity, sure, but also a
      platform that delivers it to the user. Any platform for
      building apps that fails to deliver at least as much as the
      web will never be as successful as the web.Edit: Also,
      desktop apps have had the Internet for decades. What have
      they done with it?
  mbell - 2 hours ago
  > Machines 10000x faster, personal value/productivity: flat or
  below.I'd love to hear an argument for this, personal
  value/productivity has increased massively in the last 15 years.
aidenn0 - 2 hours ago
My understanding of HEIST is that it is completely defeated by
disabling compression on dynamic content.  That doesn't seem to be
"the end of the web" to me...
jimbobimbo - 2 hours ago
The reason the web platform is "ugly" is because nobody owns it.
Multiple players need to get on the same page in order for things
to happen. The end result is not pretty (different browser versions
behave differently, incomplete specs, etc.), but one thing is
constant - nobody owns the platform.This is important because of
things like this [1]. You may dislike some apps' mission, or
approach to moderating content, but you cannot outright ban it from
your platform, if you don't own the platform.[1]
Entangled - 27 minutes ago
How about using an app:// protocol for compiled apps with security
in mind, meaning sandboxed and no filesystem access? Http is for
hyper TEXT, not hyper BYTES.Wasm is a great opportunity to reinvent
web apps. Please don't fuck it up.
fckurpropaganda - 23 minutes ago
Just make better webapps... There are too many second rate
"developers" making shitty apps...
fiatjaf - 2 hours ago
> "Flux, the latest hot web framework from Facebook."This guy is
clearly not a web developer.
fiatjaf - 2 hours ago
> All this adds up. I feel a lot more productive when I?m writing
desktop apps (even including the various ?taxes? you are expected
to pay, like making icons for your file types).That made me
remember something: compatibility. I like web apps because they
will run on my Linux machine and on all other people's Windows
machines. What is your solution to that, angry guy from the
article?Also, please provide solutions to:* the dangers of
installing other people's software to your computer -- dangers that
practically inexist in web apps;  * the friction of getting people
to try out your apps.
intrasight - 2 hours ago
I wish modern web apps were as good as and as consistent as Win 98
davesque - 1 hours ago
The web became as popular as it did precisely because it sucks.  A
lot of the supporting technologies made design decisions that
favored easy of use over stability and things that experienced
developers like.  Every argument I hear about how the web sucks
basically boils down to an argument that it should be more
consistent and well-designed.  But most well-designed technologies
fail because engineering doesn't win the day -- delivery does.  I
say all this even though I consider myself an engineer with a
penchant for the craft of writing software.  I love beautifully
architected systems, but I have to sadly admit that they're often
not relevant to the bottom line.I don't think it's time now or in
the near future for the web to die.  Just as we often still
mindlessly adhere to the 80 character limit for terminal width,
even though this limit has its origins in the size of punch cards,
we'll still be using traditional web stack technologies decades
from now.
ivancamilov - 18 minutes ago
The author seems to think that most developers think the Web sucks
and needs to be killed. While this may have a sliver of truth
behind it ?in that a lot of us are dissatisfied with certain
aspects of the platform? there's one thing the author fails to
address:If the Web (and Javascript) suck so badly, then what's up
with all those Electron desktop apps? And all those react
native/nativescript/ionic mobile apps?IMHO, the author fails to
address the only reason the web is popular as an application
platform: its still the only reliable way to make sure your code
runs everywhere with as little effort as possible.
scottmf - 1 hours ago
I?m tired of seeing this same article on HN every week.I?ve begun
to feel that a lot of HN is stuck in 2010, a lot of people refusing
to adapt to a changing industry who want me to get off their
lawn.I?m in desperate need of some links to alternatives. Perhaps
something with the same vibe as this site had several years ago.Not
to say there isn?t still a lot of good discussion on here. But at
least when it comes to the web there?s far too much noise. It?s
pjc50 - 2 hours ago
Firstly, rewrites never work and people won't abandon a working
solution for a "better" one unless it has a killer feature.But the
real thing is: the "web platform" is not the result of a design
process, it's the result of a war. It's the stalemate point between
so many competing technologies. It's the no-mans-land between
warring monopolists.Any monopolist could have given us a "tidier"
solution (although probably not secure either!) We could have had
the ActiveX future, or even a global Minitel system. The web is
uniquely in persisting without yet fully falling to any "winner
takes all" effect.
microcolonel - 16 minutes ago
> Hence my conclusion: if you can?t hire web devs that understand
how to write secure web apps then writing secure web apps is
impossible.Furthermore, the web devs that understand how hard it is
to write secure web apps generally don't want to do it for a
andrewstuart2 - 2 hours ago
This reads like an article about web applications written by
somebody who doesn't have any meaningful amount of experience
writing web applications (which I've just seen he admits further
down in the comments). The number of false statements and false
assumptions in just the first section is enough to make it hard for
me to continue reading, since it's supposedly the foundation for
the rest of the suggestions.> Web apps can't use real
sockets.Because security is an important consideration, and
websockets are designed to live within the constraints of the same-
origin policy, which helps immensely in creating apps that are
secure by default.> Things as basic as UI components are a disaster
zone. [Links to article about web components]Web components are a
failed/failing/doomed (IMO) proposed standard and are nothing but
an implementation of the idea of UI components. The design of web
components is about building component object hierarchies, and is
doomed to fail (IMO) in a markup language built around content
composition. Saying UI components are a disaster because (one guy
says, though I agree) web components are a disaster is like saying
"a square won't fit here, so obviously no rectangles will fit.">
HTML5 has peer to peer video streamingNo, it doesn't. Browsers
support the completely-separate WebRTC specification and its
related javascript APIs. No HTML spec says anything about WebRTC.My
suggestion would be that if you want to replace something, you need
to actually grok it first, or at least have a sufficient
understanding of the complexities (and the reasons they exist)
you're trying to argue against. Otherwise it's way too easy to
point out that you don't really know what you're asking to replace,
and your opinions, while potentially valid, are going to be tossed
with the rest of the bath water.
  dmitriid - 1 hours ago
  > Web components are a failed/failing/doomed (IMO) proposed
  standard and have nothing to do with the common UI component
  frameworks that exist today. The design of web components is
  about building component object hierarchies, and is doomed to
  fail (IMO) in a markup language that excels at composition.1.
  Exactly2. Instead of building a set of native (to the platform)
  common UI elements w3c ended up ckreating an incomplete low-level
  API for something, no one knows what exactly.3. Existing UI
  frameworks re-invent a huge amount of things, poorly and
dispo001 - 3 hours ago
So much truth you get sick of hearing the truth.
tomchristie - 15 minutes ago
> a meaningful number of developers are openly questioning the web
platform.And then going back to building their products. On
GitHub.Oh, wait.
StevePerkins - 2 hours ago
> For the first time, a meaningful number of developers are openly
questioning the web platform.Lost me in the opening paragraph.
"For the first time"?  Please, people have been openly questioning
the web platform for a decade now.Ever since mobile (and their
native apps) starting "killing off the desktop".Ever since people
downloaded their first PhoneGap/Cordova app, and saw how badly it
looks and behaves compared to native widgets.Ever since people
pulled up a task manager, and noticed how much RAM and CPU that
Electron-based app was using.On the other hand... we've been openly
questioning native too, ever since basic social media apps starting
weighing a hundred megs each.  Every platform has its problems.
  da02 - 49 minutes ago
  Are there any alternatives to Phonegapp? Ever used Flutter or
grahamburger - 13 minutes ago
I wonder if there's a market for a WebApp store. Like a curated
WebApp library - centralized billing, some form of vetting before
apps can be listed, maybe even some apis for notifications or
whatever. WebApps tested on a few major browsers and platforms
before they're allowed to be listed. I'd probably be more willing
to pay for WebApps if they were delivered that way.
  albertgoeswoof - 9 minutes ago
  Most consumers don't know the difference between a web app and a
  native app, so no one would care
notatoad - 2 hours ago
>In part 2 I?ll propose a new app platform that is buildable by a
small group in a reasonable amount of time, and which (IMHO) should
be much better than what we have today... Next time: how we can do
that.i look forward to that article.  This one, on the other hand,
seems a little pointless.  Does the web have problems?  yes,
absolutely.  But I have a hard time believing the best way to solve
them it to tear down everything we've built so far and start over.
  KGIII - 2 hours ago
  I agree.People seem to think that there was a time when the
  internet was better than it is today. Well, I've been 'online'
  since before the web was world wide. Frankly, it was never
  good.In fact, it is better now than it has ever been. It's just
  people choose to use the worst parts of it.I've seen the various
  tech that was supposed to rebuild and revolutionize the web. It's
  just created more kludge. It's just lipstick on a pig. It's just
  one more set of standards that get half-ass implementations and
  even worse support.If you tear it down and rebuild it, it's just
  going to end up the same except it is using different names for
  the protocols.I'm not angry when stuff breaks. I'm amazed it
  works at all.And, truthfully, I kinda like it the way it is. We
  have, at our fingertips, vast amounts of information and
  entertainment. It works, after a fashion and for some definition
  of 'works.' If the Internet sucks for them, maybe they should
  look elsewhere? The Internet is huge. It's not hard to find parts
  that don't suck.Tearing down and rebuilding isn't going to work
  and nobody is going to invest in that. Hell, we can't even get
  ubiquitous IPv6 adoption. Not one browser is fully compliant with
  HTML5. And it's okay. It works, mostly.
    resu_nimda - 1 hours ago
    Everyone has a different definition of what's good and what's
    bad about the web. A lot of smart programmers seem to think
    almost all software is bad. Probably all software that is
    actually used is not as good "as it could be." Any evolutionary
    process is going to be like that.HTTP and HTML were absolutely
    not designed for many of the things they are used for today. A
    bunch of really smart people probably could come up with a much
    better solution for modern usage, and lots of them have tried.
    But the web has too much inertia (the users are there and don't
    care about these problems) and, as you say, it more or less
    works, or can be made to work.It does seem inevitable that it
    will be superseded eventually, but how far off is that?
      KGIII - 44 minutes ago
      > how far off is that?Whenever an OS depreciates, but not
      kills, something in an API, somebody ignores that it is
      depreciated, doesn't use the new method, and writes new
      software against the now-depreciated function.There are
      people still using legacy software that got was first written
      in the 1970s. Someone took that software and converted it
      from punchcards to hard drives and from memory that was a
      spinning drum to memory that is solid state.Somewhere, there
      are COBOL developers still maintaining stuff older than many
      of the folks that frequent HN.I suspect you're right, in that
      it will be superseded - but I am willing to wager that it is
      going to take a long time and never be completely done. There
      is stuff that hasn't been updated since the 486 days and is
      mission critical. Fortunately, it works - because nobody has
      any idea how to fix it if it stops working.As a society,
      we've accumulated so much technical debt that we may have
      reached a tipping point where it's simply impossible for us
      to catch up and it's unrealistic to think we will burn it to
      the ground and rebuild.I suppose some external force could
      crash the house of cards but I suspect we'd just rebuild it
      with new faults or the same old faults.Like you say, HTTP and
      HTML weren't meant to do this. Now we have webassembly,
      HTML5, and JavaScript libraries that nobody fully
      understands. We've now tacked on DRM to the standards, put
      the real functionality in the hands of ICANN, and crammed our
      data into towering silos of proprietary goodness.We had a
      brief moment where we largely owned our devices and our data.
      Now, we lease supercomputers for our pockets while giving
      control of our data to a mysterious entity known only as The
      Cloud. 100 years from now, nobody is going to know how it
      works and we will attend churches where we pray, sacrifice,
      and tithe to the god known as The Cloud.It will be
      superseded, but it will be just another kludge patched on
      top. It's like cars in Cuba. They are old and functional, but
      contain engines from a Lada, bumpers from a bus, seats from
      three different cars and a horse drawn cart, an exhaust made
      from tin cans, and four different size wheels.And you know
      what? Those cars are a testament to the resiliency and skill
      of the Cuban mechanic. They are awesome. It's not amazing
      that they break down, of course they do. It's amazing that
      they run at all.On a more serious note, I suspect well just
      keep patching and tweaking. Eventually things will get
      better. It has been steadily getting better this whole time.I
      like to complainand point out the flaws, but it really does
      function. It's great and the immediacy of information has
      been a great asset for humanity.The Internet really is better
      than it has ever been. Searches used to be done by a human.
      As in, you'd send them your question and they'd go through
      their directory, make phone calls, contact institutions, and
      get back to you with an answer - usually 3 days latter.
      Yup... Three days to get an answer. Sometimes, you had to
      wait for a system to come online, usually a small localized
      network, and only then would your email be delivered.It
      works. It's like a dysfunctional family. Loving, possibly
      abusive, but our family. I suspect it will continue to
      improve, slowly but surely. Smart people are constantly
      innovating and improving. Standards and specs get refined.The
      Internet, being vast, means there is a place for pretty much
      everybody. It has it's warts and there are legitimate
      complaints, but sometimes it actually does what it is
      supposed to do, when it is supposed to do it. Sometimes,
      possibly by accident, people make good choices that result in
      good things.Also, cats... So long as we have cats, the
      Internet will be just fine. Gotta love it, warts and all.
addicted - 1 hours ago
The 2arguments presented are: 1)Reinventing the 90s - Why is this
necessarily a bad thing? The author links to a blog post discussing
how Flux is similar to Windows 1.0 but that author of that post
does not claim that makes Flux bad. In fact they agree it works
well and scales well as well. The only thing they say is that based
on the experience in the 90s it?s likely we will have further
developments on this model. Why should those developments not be on
the web platform itself (also who thinks that if we are gonna start
a completely new platform we wouldn?t reinvent the 90s on it
again?).2. Impossible to secure - Yes security is a huge issue with
the web. But a large part of that is older designs and many have
been mitigated (as an example, the wiki section the author links to
show why JSON is insecure has 2insecurities. Security issues in
parser implementations which are not written in web technologies
anyways and the fact that before 2009 and the widespread
availability of JSON.parse and JSON.stringify people used eval to
parse JSON).I?ll be honest that I do think the web needs to be
improved/changes/replaced. I don?t think this article makes the
point well and possibly focuses on the wrong things. But my biggest
concern is with the idea that improvements need to be achieved by
replacing the web instead of the kind of incremental improvement we
are already seeing.I would be interested in Part 2 to see if the
replacement the author has in mind is really worth it. It would
need to at least be an order of magnitude better to sacrifice the
compatibility advantages the web has, but it may still be
worthwhile to think of what a platform written today from scratch
would look like to focus the kind of improvements we would like to
see on the web.
randcraw - 2 hours ago
Until I can block ads in web apps, I'll keep my browser thanks.
  diminish - 2 hours ago
  And you can't block ads in youtube, instagram or fb apps.
ashitlerferad - 1 hours ago
click bait
marcrosoft - 9 minutes ago
The web app is the best we have. Please give us an alternative or
else it's not actually time to kill it.
alanh - 1 hours ago
There is a section heading that reads, ?Why the web must die.? I
almost stopped reading there. I value the web for its longevity,
accessibility, and non-proprietary nature.There are some goods
points made in this article, however:> My experience has been that
attempting to hire a web developer that has even heard of all [the
above-mentioned security] landmines always ends in failure, let
alone hiring one who can reliably avoid them. Hence my conclusion:
if you can?t hire web devs that understand how to write secure web
apps then writing secure web apps is impossible.
SwellJoe - 2 hours ago
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.
  nostrademons - 1 hours 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 - 1 hours ago
    > they'll lose out to systems that promise security (and
    usually address a few specific attacks on the previous
    incumbentThis 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.
      nostrademons - 37 minutes ago
      Yep.  Databases, web frameworks, GUI frameworks, editors,
      concurrency models, social networks, photo-sharing sites, and
      consumer reviews as well.  Outside of computers, it applies
      to traffic, airlines, politics, publicly-traded companies,
      education & testing, and any industry related to "coolness"
      (fashion, entertainment, and all the niche fads that hipsters
      love).I refer to these as "unstable industries" - they all
      exhibit the dynamics that the consequences of success
      undermines the reasons for that success in the first place.
      So for example, the key factor that makes an editor or new
      devtool popular is that it lets you accomplish your task and
      then gets out of the way, but when you've developed a
      successful editor or devtool, lots of programmers want to
      help work on it, they all want to make their mark, and
      suddenly it gets in your way instead of out of your way.  For
      a social network, the primary driver of success is that all
      the cool kids who you want to be like are on it, which makes
      everyone want to get on it, and suddenly the majority of
      people on it aren't cool.  For a review site, the primary
      driver of success is that people are honest and sharing their
      experiences out of the goodness of their heart, which brings
      in readers, which makes the products being reviewed really
      want to game the reviews, which destroys the trustworthiness
      of the reviews.All of these industries are cyclical, and you
      can make a lot of money - tens of billions of dollars - if
      you time your entry & exit at the right parts of the cycle.
      The problem is that actually figuring out that timing is non-
      trivial (and left as an exercise for the reader), and then
      you have to contend with a large amount of work and similarly
      hungry competitors.
  pron - 2 hours 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 - 2 hours 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.
  Spooky23 - 2 hours 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
    TeMPOraL - 1 hours 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 - 15 minutes ago
      Windows 95-era Word didn?t have to handle real-time
      collaboration over the Web between an arbitrary number of
  intrasight - 2 hours 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 - 2 hours ago
    there's the opposite of an "institutional memory" - kind of a
    continuous revolution where we must forget, repeat and forget
    and repeat.
  Devid2014 - 1 hours 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.
  microcolonel - 18 minutes 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.
  dvfjsdhgfv - 1 hours 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
  alkonaut - 1 minutes 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.
  disordinary - 2 hours 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.
    valuearb - 31 minutes ago
    Just imagine how slow MS Office could be as a web app.
      tmccrmck - 15 minutes ago
      Imagine? With wasm, I'm afraid you won't have to imagine in a
      few years...
    ZenoArrow - 1 hours 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 - 55 minutes 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.
      bsder - 37 minutes ago
      Power users are the vector to spread Microsoft-only
      spreadsheet viruses.This is what gets lots on most people.The
      power users create some "nifty" spreadsheet that runs some
      "important" piece of a business.  That "nifty" spreadsheet
      now requires Microsoft Excel and forces everybody in the
      company to have a copy if they want access to it.
  ryanlol - 1 hours 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 - 1 hours 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.
    MikeHolman - 1 hours 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 - 41 minutes 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.
    jdietrich - 1 hours 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.
  aidenn0 - 2 hours 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
    bastawhiz - 2 hours ago
    > if html used length-prefixed tags rather than open/close tags
    most injection attacks would go away immediately.If this was
    the case, it would be near-impossible to write HTML by hand.
    And if you're writing HTML with a tool (React, HAML etc.), the
    tool could be doing HTML escaping correctly instead. This isn't
    an issue with HTML, it's an issue with human error.
      quadrangle - 1 hours ago
      If you have an issue with human error and don't design your
      programmed tool to avoid letting the errors out into the
      world, then it is the fault of the tool.
        bastawhiz - 31 minutes ago
        I'm not sure what the argument you're putting forth is. All
        of the HTML-generating tools I'm aware of (barring dumb
        string templating tools) work sufficiently well and prevent
        human error.My point is that there's nothing wrong with
        HTML. HTML isn't a tool, it's a format for storing and
        transmitting hypertext. If you're using React or HAML or
        any of the other HTML-generating tools, you're effectively
        immune from XSS. I'm putting forth that developers aren't
        using effective tools (shame on every templating engine
        that doesn't escape by default), and that calling the web
        as a platform bad is a bit nonsensical. It's like saying
        "folks are writing asm by hand and their code has security
        issues, therefore x86_64 is insecure".
      TeMPOraL - 1 hours ago
      > This isn't an issue with HTML, it's an issue with human
      error.All security issues are due to human error. Those are
      solved by building better tools.> If this was the case, it
      would be near-impossible to write HTML by hand.If, besides
      the text form, there would be a well-defined length-prefixed
      binary representation, we could simply compile HTML to
      binary-HTML, which would immediately made the web not only
      safer, but also much more efficient (it's scary if you think
      just how much parsing and reparsing goes on when displaying a
      web page).
        lou1306 - 1 hours ago
        One could build something similar by using a set of
        "conventional" canonical S-expressions:
          krapp - 4 minutes ago
          Prefixes for character length? Is that a better choice
          than byte size or would it even matter?
    SwellJoe - 2 hours 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."How so? If you allow the
    user to send arbitrary data, and your handling of that data is
    where the problem lies, it isn't going to matter whether the
    client sends a length-prefixed piece of data. You still have to
    sanitize that data.HTML, and whether it uses closing tags or
    not, is pretty much irrelevant to the way injection attacks
    work, as far as I can tell. Maybe I'm missing
    you have an example or a reference to how this could solve
    injection attacks?
      an_account - 1 hours ago
      If you can say, ?the next 450 characters are plain text and
      should be rendered as such?, then even if the text includes
      script tags (or whatever), they won?t be parsed or executed.
        SwellJoe - 1 hours ago
        This seems like an argument for strong types. Which is
        reasonable. But, one could do that with closing tags, too.
        We already know that relying on a programmer to specify the
        length of data is prone to bugs (C/C++). And, you can't
        trust the client to specify the length of data.I feel like
        this is conflating two different problems and potential
        solutions.I'm not saying injection attacks aren't real. I'm
        saying that whether HTML uses closing tags or not is
        orthogonal to the solution. But, again, maybe I'm missing
        something obvious here. I just don't see how what you're
        suggesting can be done without types and I don't see how
        types require prefixing data size in order to work.
      sp332 - 1 hours ago
      If the length is not pre-defined, the input has to be parsed
      to look for the closing tag. That makes your code vulnerable
      if the input tricks it into finding the wrong closing tag.
      But if the length is fixed, you don't have to parse it at
      all. That would avoid a whole class of vulnerabilities.
        dgoldstein - 1 hours ago
        True, assuming that programmers don't compute code
        (HTML,SQL, etc) from user input and miscompute the length
        of a fragment.It would be interesting to see if this idea
        could work in practice.
    sbov - 2 hours 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 immediatelyNo 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.
      katastic - 1 hours ago
      >The problem is not lengthOh thank God. I'm going to forward
      this to my wife.
        krapp - 1 hours ago
        "Buffer? I don't even know her!"Ha ha. I'll get my coat.
          to3m - 5 minutes ago
          Droll. But wasn't context unawareness part of the problem
      andrewstuart2 - 1 hours 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 - 20 minutes 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.
      danpalmer - 1 hours ago
      The point is that if you know the length of some data up-
      front before starting to parse it, you don't have to inspect
      the data in any way to see when it ends. This means that you
      don't need to know what the SQL injection looks like and
      protect against it, or what JS looks like to sanitise your
      inputs ? the problem does go away to a large extent.
        always_good - 1 hours ago
        That doesn't make sense.Obviously nobody is going to be
        typing length prefixes manually, so our tools are going to
        do it for us.Now we're back where we started where you
        accidentally inline user content as HTML, except now HTML
        has the added cruft of someone's HN comment solution.
        roywiggins - 1 hours ago
        This doesn't do anything for Bobby DROP TABLE injections,
        right? The whole thing is a user-supplied slug, there's no
        source of truth on how long a user's name is. Or am I
        missing something?
          dgoldstein - 1 hours ago
          Bobby tables would be considered data.  Or should be.
          And hopefully it would be obvious that it doesn't belong
          in the code section.But like you I'm not totally
          convinced.  I think this idea would make it easier for
          people trying to do the right thing to get it right; but
          for the blissfully ignorant? Might not help at all.
          Either way it needs a more flushed out spec.
    jacquesm - 1 hours ago
    > 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 intercept and change.
    That's much harder to do when you can't get at the control
    channel but just at the data channel. Many old school protocols
    worked like this.
      mbreese - 31 minutes ago
      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 lot of
      problems go away. But you could do that with a combined
      control/data stream too.What am I missing? How would an out-
      of-band control channel make things easier?That said, I think
      many issues with the web could be solved by implementing new
      protocols as opposed to shoehorning everything into HTTP just
      to avoid a firewall...
        jacquesm - 14 minutes ago
        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        1> 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
        interpreted. This blocks any and all attacks based on being
        able to trick the server or eventual recipient browser of
        the two streams to do something active with the datum, it
        can only be passive data by definition.For comparison take
        DTMF, which is inband signalling and so easily spoofed (and
        with the 'bluebox' additional tones may be generated that
        unlock interesting capabilities in systems on the line) and
        compare with GSM which does all its signaling out-of-band,
        and so is much harder to spoof.The web is basically like
        DTMF, if you can enter data into a form and that data is
        spit back out again in some web page to be rendered by the
        browser later on you have a vector to inject something
        malicious and it will take a very well thought out
        sanitation process to get rid of all the possibilities in
        which you might do that.If the web were more like GSM you
        could sit there and inject data in to the data channel
        until the cows came home but it would never ever lead to a
        security issue.No amount of extra encoding and checks will
        ever close these holes completely as long as the data stays
        'in band' with the control information.
      stouset - 56 minutes ago
      Thank you.This is the important takeaway here. Changing the
      encoding simply swaps out one set of vulnerabilities and
      attacks for another. Separating control flow and data is the
      actual silver bullet for this category of
      attacks.Unfortunately, there?s rarely ever a totally clear
      logical separation between the two. Anything you want to
      bucket into ?control?, someone else is going to want the
      client to be able to manipulate as data.
    edoceo - 1 hours ago
    Even when the sender tells you the length of the data to expect
    the receiver still needs to read every thing that is sent?Or
    were senders always going to send true values for length and
    data?Really, you can't trust any sender, so the data should be
    validated anyway.There's been known attacks where a sender says
    here's 400 bytes and the receiver stupidly trusted that length
    specifier, and the sender's sends more (or less) crafted bytes
    and BOOM!Known good data start and end specifiers, which HTML
    has, seems a good answer when dealing with untrusted senders
  acobster - 38 minutes 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 - 35 minutes 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
jkelsey - 1 hours ago
I agree with the premise but the problem is developing apps in any
other ecosystem decreases your overall audience. You're either in
the corporate world with their walled gardens, or in the FLOSS
world where there's all sort of rough edges and things don't work
as smoothly (and I say that with nothing but respect and admiration
for all the well-meaning hard work from folks that's gone into both
ecosystems, but it's the stark reality of matter).The web is as
close as we've gotten to making tech as user friendly and
accessible. I bet Mr. Hearn has a bunch of technical proposals
lined up for part 2, but how we cross all the factionalism,
corporate or idealogical, that's formed in the software community
at large since the birth of the web?
bitwize - 2 hours ago
All the more reason to switch to Urbit. Have you accepted Curtis
Yarvin into your heart as your personal BDFL yet?
  mixedCase - 2 hours ago
  As soon as it does something useful, sure. As a power user I
  could not be any less interested in whatever I've been able to
  understand Urbit does.
tarikjn - 1 hours ago
Apart from some justified points on how confusing origins can be,
the author fundamentally misunderstands Web development.Not only do
users want fast sites and multiple of them open, so the performance
point bears little weight, but the authors points to OOP
techniques, presenting them as necessarily superior to FRP because
they came later to Windows.Next the criticism on productivity and
size of developer teams. Productivity has gone up tremendously in
my experience e.g. by doing universal apps using React/Webpack/CSS
Modules and following FRP principles, all of which you can do while
maintaining Web semantics. If you haven't noticed gains in
productivity, your workflow is wrong and you aren't taking
advantage of the current tools. From my point of view, things used
to be much worse and it is finally maturing.I won't bother
commenting on the rest because the article just go down from there
in confusion mixing up services with applications. The author just
basically wants to write desktop apps, but also be able to take
advantage of the Web's discoverability.
  ZenoArrow - 1 hours ago
  > "Next the criticism on productivity and size of developer
  teams."Were we reading the same article? The main criticisms made
  by the author of the article were about web app security. If
  there was a mention of productivity it was only made in passing.>
  "The author just basically wants to write desktop apps, but also
  be able to take advantage of the Web's discoverability."Is this a
  bad approach?
hoodoof - 1 hours ago
The return of Adobe Flex!
mwcampbell - 2 hours ago
What about the fact that the Web platform isn't owned by any one
company, but is supported (to varying degrees) by every major
native platform? A shiny new app platform won't have that. That's
  zdkl - 2 hours ago
  In theory indeed. In practice there's 3 vendors and the standard
  defining organisation represents commercial interests in the
  platform, not you.
    aidenn0 - 2 hours ago
    3 vendors is still better than one.
    mwcampbell - 2 hours ago
    On balance, and having read the whole article now, I think
    you're right. I shouldn't have reacted before reading the whole
    thing and really considering it.
disordinary - 2 hours ago
When you've got things like new multi threaded renderers, all
browsers now 64bit, web assembly, service workers, faster
processors etc. It seems that in actuality app development with web
technologies is finally practical.But, why are these things framed
as an either or? Surely the best thing is always to use the best
technology for the job and in many cases the speed and security
trade off is worth it in order to utilise existing assets and
expertise from a businesses web application.
LarryMade2 - 3 minutes ago
Why web Apps?  Because you can hit just about every platform with
one codebase, you got instant distribution, you got near universal
compatibility. And, If you are inclined, you have minimal
licensing.Desktop has big compatibility cross/platform hurdles
(does it run on Linux, MacOS, Windows, Android, iOS, and
Playstation?), difficult distribution, and at times licensing (even
moreso on walled-garden platforms).You are also dependent on the
desktop/PC manufacturer (ever have Microsoft, Apple, Google, etc
pull the rug from under your product?  it happens regularly
especially with OS updates and "trusted" platform initiatives)  Not
to mention the development platform whims ("Sorry guys, we are
selling to MS. We're sure they'll keep those MacOS and Linux
versions up to-date, they are really excited about it!")Maybe if
its a open platform with high adoption on the scale of LibreOffice
or GIMP... maybe.
andrewflnr - 1 minutes ago
I agree that the web is kind of a catastrophe. However, the problem
is not really that it confused documents and apps. I would actually
like to see this distinction get blurrier, in the form of better
support for active documents, ranging from interactive
illustrations of ideas to spreadsheets with formulas.
Exuma - 59 minutes ago
No, it's not "time". I hate stupid headlines so much.
avaer - 2 hours ago
I sympathize with the sentiment, but the web app only sucks if
you're using the stuff that sucks.Like any technology with decades
of evolution it has a thick sediment of peat. Half of Javascript,
half of Windows, even half of *nix is garbage you should never use,
but it's all there because old things would stop working without
it.It's just that the web has a very low barrier to entry and very
high reach, so the compost doesn't get thrown out as quickly as it
should. So people still pack jQuery when they need to select
elements, or pull a left pad from npm without realizing it's in the
language core. Or pack Reactiflux when they want to do a form.In an
age where you can literally compile existing, GPU-heavy C++ code to
WebAssembly and run it in the browser with no fuss, you can't
complain the web doesn't let you do things right, or at least the
way you want. It's just admittedly easy to hop on the wrong library
bandwagon and complain when things go wrong. But it's not a problem
with the web.
  dmitriid - 1 hours ago
  > but the web app only sucks if you're using the stuff that
  sucks.Please show me anything that doesn't suck on the web. And
  yes, I've been doing web development for close to 17 years
  now.There's almost nothing that doesn't suck on the web. The
  languages, the tooling, the platform - you name it. It is good
  for one thing, and one thing only: displaying single-page
  interlinked documents with little to no embedded media. Any and
  all other attempts to make it do anything else end up bloated
  incomplete internally inconsistent overlapping monstrosities.
    kuon - 1 hours ago
    I have been using elm for some time now, and it's the first
    time I feel I am using a non broken tool.
  vvanders - 2 hours ago
  Having written things targeting WASM, when you can provide me an
  environment like Visual Studio that has breakpoints(including
  data) and a debugging I can step then we can talk.Until then WASM
  is cool, but not nearly as productive for C++ as the native
  rayiner - 2 hours ago
  The web is way worse and less coherent than something like Cocoa,
  even though Cocoa is older. That?s because the former was
  designed for text documents.
    smitherfield - 29 minutes ago
    Slight bit of pedantry: only the AppKit (1989) component of
    Cocoa predates the web (1990) while Foundation and Core Data
    (both 1994) came later. Of course, many nowadays-integral
    features of the web also came after its initial release, such
    as CGI and the 
 and  tags (all 1993), cookies and
    HTTPS (both 1994), Javascript (1995), HTTP headers, methods
    other than GET, non-ASCII text encodings and CSS (all 1996),
    AJAX (1999), and the