HN Gopher Feed (2017-09-23) - page 1 of 10 ___________________________________________________________________
It's time to kill the web app
330 points by raindev
https://blog.plan99.net/its-time-to-kill-the-web-974a9fe80c89___________________________________________________________________
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 asp.net 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
"fixes"...
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
desktop.
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
for.
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
person.
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
way...today 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 underestimated...how 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
fire.
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]
https://arstechnica.com/tech-policy/2017/08/gab-the-right-wi...
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.
[deleted]
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
apps.
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
toxic.
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
living.
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
inconsistently.
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
Kotlin?
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.
[deleted]
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
wrong.
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
users.
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
secure.
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
immediately.1:
https://www.cs.purdue.edu/homes/dec/essay.criticize.html
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:
https://en.wikipedia.org/wiki/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 something...do
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
too?
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
(read:everyone)
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
favorite.
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
important.
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.
[deleted]
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
platforms.
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