Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

711–717 of 717 posts

Re: It’s time to kill the web app

#711

Earlier quoted context omitted.

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 compa…

This only means that Android managed to create something that's wors than html+css, which is quite an achievement. Meanwhile, for every small thing that you need on the web you need to reinvent things from scratch. Animations. Lists/virtual lists. Containers. Toolbars. Menus. Keyboard shortcuts. Constrained layouts. Layouts in general. Interactions. Combinations of anything above. Any basic UI component and interacti…

The css is the part i will leave mostly the same, i will change the syntax a bit, but mantain the functionality.

Re: It’s time to kill the web app

#712

Earlier quoted context omitted.

How do web-apps help lock-in? Because you can force users to update?

Because your data is being held hostage by the service provider. No more grandmas showing photo albums to their grandchildren when Facebook is long gone 30 years from now :'(

Well, you can easily do this with a native app that relies on content from your servers (e.g. dropbox).

Re: It’s time to kill the web app

#713
post #662

Earlier quoted context omitted.

> And blaming this on the market is a cheap attempt to dodge responsibility. If programmers paid more than lip service to responsibility, they'd push for safer languages. If programmers paid more than lip service to responsibility, the whole dumb paradigm of "worse is better" would not exist in the first place. As it is, we let the market decide, and we even indoctrinate young engineers into thinking that business ne…

> If programmers paid more than lip service to responsibility, the whole dumb paradigm of "worse is better" would not exist in the first place. I used to think like this but I've come to realize that there are two underlying tensions at play: - How you think the world should work; - How the world really works. It turns out that good technical people tend to dwell a lot on the first line of thinking. Good sales/market…

The world doesn't always work that way though. There are plenty of areas where we've decided that the cost of worse is better is unacceptable, and legislated it into only being acceptable in specific situations. For example, many engineering disciplines.

Re: It’s time to kill the web app

#714

Earlier quoted context omitted.

Because your data is being held hostage by the service provider. No more grandmas showing photo albums to their grandchildren when Facebook is long gone 30 years from now :'(

Well, you can easily do this with a native app that relies on content from your servers (e.g. dropbox).

But with dropbox and/or alternatives you can always access raw files via the/a file browser. With Fb, OTOH, there was a story some time ago where you only could download photos in downscaled resolutions, or where downloading native resolution files was hidden in obscure option menus.

Re: It’s time to kill the web app

#715

Earlier quoted context omitted.

Can you run web apps in a multithreaded environment? UI remains the largest overhead in a web app in my opinion.. Or, how much speedup would you estimate, if we convert all GoogleDocs functionalities into Word97? I'd estimate 1000 times. :) Or perhaps, the computation power for drawing a cursor alone will far exceed the whole Word97.

> Can you run web apps in a multithreaded environment? UI remains the largest overhead in a web app in my opinion.. Yes, you have webworkers for multi threaded development. They're basically independent applications which run on different threads and you pass messages (which are simply objects) between them. The browsers themselves are also moving their layout and rendering engines to be multithreaded. A well designe…

> Yes, you have webworkers for multi threaded development. They're basically independent applications which run on different threads and you pass messages (which are simply objects) between them. The browsers themselves are also moving their layout and rendering engines to be multithreaded.

Yes I'm actually referring to this. The programming model. Workers are great if you can divide and conquer the problem and offload (exactly what you have mentioned). But the messaging payload would be high under some circumstances when you have to repetitively copy duplicate a lot of data to start a worker. I don't have hands-on experience with web workers but I think it is unlikely to solve the messaging overhead without introducing channels/threads. Workers are more like processes. And currently they don't have Copy-On-Write. Of course we may see improvements over time, but this is to gradually reinvent all the possible wheels from an operating system, in order to be as performant as an OS.

> A well designed app would do very little on the UI thread

I partially agree. It may do little, but in turn, the consequence may be huge. This is because DOM is not a zero-cost abstraction of a UI. It does not understand what the programmer really want to do if, say, he/she constantly ramping the transparency of a 1px div. Too much happens before the cursor blink is reflected onto a framebuffer, compared to a "native" GUI program. I think it will be very helpful if the DOM can be declarative as in XAML, where you can really say without translating them eventually into barebone bits. Developers are paying too much (the consequence) to customize this representation.

> Whatever the speedup would be the speedup the users would likely not notice or will only notice a slight improvement.

There won't be a faster-than-light word processor but I really want it to: 1. Start immediately (say 10ms instead of 1000ms) when I call it up 2. Response immediately when I interact (say 1ms instead of 100ms) 3. Reduce visual distractions until we get full 120fps. Don't do animations if we don't have 120fps. 4. If the above requirements can always be satisfied by upgrading to a better computer.

The speedup will guarantee 4) and make the performance scalable. But currently the web apps lag no matter I use a cellphone or a flagship workstation. This clearly indicates that the performance of a web app does not scale linearly with computation power, and this is not about how much javascript is executed (that part will scale I believe).

Re: It’s time to kill the web app

#716

Earlier quoted context omitted.

Agreed, I learned Elm a year ago and haven’t looked back. Love being able to dismiss all other frontend web talk without a second thought.

But you can't. The moment you need to do a layout, you're back into html + css and it's inabilty to cater to anything beyond single-page documents (not apps) ;)

Actually server side rendering is comming, it's working in a hacky way, but it's promising.
Post reply on HN