441–450 of 717 posts
> 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 compar…
Earlier quoted context omitted.
> "That's precisely the point" That was the general point, but I was responding to a side comment that I disagreed with. > "because of feature additions" Adding features does not require slowing an application down. The reason modern apps (desktop and web) are slow is to do with inefficient use of computing resources, which has very little to do with available features.
That's why I said: > 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. at the start. :) So, we're in agreement.
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.
Earlier quoted context omitted.
"If you want to rag on JSON, that's fine. It's not a great format" JSON is simple and powerfull. It's success justifies it, to call it a great format, I think. But I am curious, what whould be a great format, in your opinion?
JSON gets the most important thing right: it's simpler than XML. I probably should have rephrased my comment. I literally mean that it's a decent format, but not a great one. One issue is that it's surprisingly poorly specified: http://seriot.ch/parsing_json.php . As a data-interchange format, it lacks first class dates/timestamps, the issues about specification are a pain when dealing with numbers (depending on lang…
Earlier quoted context omitted.
> 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…
Then prove it, list substantial codebases written in C++ that you deem secure. You'll find that it's not easy to do.
Developers who have been ingrained in web technologies tend to think of the times before as dark ages. They really weren't. Today simply isn't the absolute best that all things have ever been.
Sure some things were a bit simpler & less flashy then and hardware was more limited, but there were a lot of great ideas that have been forgotten and shoved aside in the excitement for modernization. Best practices & whatnot.
But, what the author forgets, is that this is the state of things. Really inventive ideas exist, sometimes in niches, die, and then get rediscovered and reimplemented in circuitous ways. Asinine artifacts tend to arise in every paradigm shift.
I'd argue that word processing, for example, has barely caught up to the days prior to the graphical user interface. Now, with the web browser & mobile, it hasn't even come close to feature parity yet. It will, eventually, mostly. And it will be exponentially more bloated and complicated than before. Such are things.
Earlier quoted context omitted.
The thing is, though, the web is reasonable - for its intended purpose, which is displaying and interlinking documents. And despite the complaints, faults and shortcomings, it's even remarkably not as bad as it could be at being an application platform. Throwing that out because it's less than optimal at a use case it was never intended to serve would be monumentally short-sighted. Just build something else and leave…
I still haven't found a reliable way to save webpages. Firefox and wget won't download stylesheets or script tags generated by javascript. The only working approach is to print webpages as PDFs. It's a pretty terrible platform for documents.
almost universally?
mobile dev has enough inefficiencies and complications that, for many use cases, quite a few people today wonder if native is preferable to mobile web, especially PWAs.
i mean, look at the discussion here, 12 days ago: https://news.ycombinator.com/item?id=15219154 and this: https://joreteg.com/blog/betting-on-the-web#what-sucks-about...
Earlier quoted context omitted.
That's why I said: > 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. at the start. :) So, we're in agreement.
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.
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 designed app would do very little on the UI thread and would pass messages between the UI thread and the webworkers, it would also spin up webworkers on demand to offload work. It's not as easy as some environments to develop in, but it's also fairly straight forward once you make the effort to do it.
If I was designing react for instance I'd have all the virtual dom / diffing stuff being handled by a webworker and then would only pass the updates through to the UI when computation is completed.
> 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.
Whatever the speedup would be the speedup the users would likely not notice or will only notice a slight improvement.
And yes, drawing the cursor as a 1px wide div is computationally intensive, I guess you're referring to that article posted on HN awhile back that VS Code used 13% of the CPU just to render the cursor? :) Doing stuff outside of content editable is not ideal for writing applications as you lose a lot of system settings (like keyboard mappings, cursor blink speed, etc) that the browser automatically translates to the built in cursor.
All of these are pretty thoroughly solved by picking tools that don’t let you shoot yourself in the foot, and SQL injection isn’t remotely a web app thing. (The others are far less severe than RCE, anyway, as they only affect the one app. I guess the argument here is that the web platform isn’t yet optimal? Work is always continuing to improve security – take Content-Security-Policy, for example, which mitigates every type of exploit mentioned even if you do everything else wrong – and if you think it can’t work out, point out a real alternative.)