41–50 of 58 posts
Earlier quoted context omitted.
What do you consider contenteditable=true if not a rich text editing widget?
I think typically "Rich Text Editing" includes controls for presentational aspects: fonts, colors, weights, etc. Contenteditable only lets you change the text itself.
It is a little disappointing that this doesn't directly address the issues with the original article's claims. Instead it continues focusing on CPU execution timings. Like many responses to the original article, the elephant in the room is javascript performance on DOM manipulation/UI. To take an example on the desktop, if I gave you two options a) language a which is about 2 times slower than C in doing some math op…
Dan is too humble when giving his credentials in this article. Reading the comments already, it seems some may be unaware that his first claim to fame was VisiCalc: the software from which all modern day spreadsheets are direct descendants. He's got years of accumulated wisdom that make his comments about programming natively vs. in the browser worth some careful thought. As you read his post, remember he developed a…
Do you have Sprint?
Earlier quoted context omitted.
I'm not sure the cynicism is warranted. Dan does a bunch of native iOS development. He's got more experience than the vast majority of people who read this site. This isn't some random brogrammer writing a post about JavaScript. Dan Bricklin's resume rightfully could include the line "1979: Invented the spreadsheet".
> 1979: Invented the spreadsheet Not to diminish his accomplishments, because I consider him one of my heroes, but he didn't invent spreadsheets. That honor would go to Richard Mattessich 18 years earlier.
Dan is too humble when giving his credentials in this article. Reading the comments already, it seems some may be unaware that his first claim to fame was VisiCalc: the software from which all modern day spreadsheets are direct descendants. He's got years of accumulated wisdom that make his comments about programming natively vs. in the browser worth some careful thought. As you read his post, remember he developed a…
Maybe he could provide a quick sample/prototype of VisiCalc ported to iOS as a web-app? After all 2013-1979 = 34 of innovation, so HTML5 and JS _must_ be a pinnacle of programmer's productivity, right? An if-it-compiles-it-is-correct kind of thing?
Hmm...
I'm in a bit of a hurry, but this sounds familiar:
> For most of what we are talking about, JavaScript does not execute in a vacuum. It runs in a browser. That browser environment brings a lot to the table. The applications you are coding are often ones that lend themselves to what a browser is good for: Presenting information. We already covered this too. Apps that are just about "presenting information" (your typical CRUD stuff, or glorified CRUD, from Gmail to twi…
At heart, arbitrary distinctions like that end up just being "apps that run well" vs "apps that run badly". And no matter how good the system, there will always be some apps in both camps.
What's "arbitrary" about the distinction? Any app that depends on CPU intensive work, with high memory overhead, that doesn't want to be interrupted by GC pauses, will be slow as web based mobile app.
It's a technical distinction. The only reason it's somewhat generic, is that nobody can tell in advance which app belongs in which camp, until we know what the app needs to do.
For a specific app, with known requirements, whether it'll be slow as a web app or not, is anything but arbitrary. E.g "Can I write an image editor as a mobile web app, editing 5MP images with filters etc?", "No, you can't, it will be dog slow".
Sure, you can write a slow native mobile app too. But that's beside the point. We're talking about apps written properly in both cases here. That is, what are the limits of an app in each case.
> Browsers are constantly being upgraded more and more of this important functionality built-in, including rich-text editing I don't see any "rich-text editing" widgets built-in in browsers. And even if that was the case (that they are available in some) it has been 18+ years we've have had to put with BS solutions like the common "rich-text editors" found in most Content Management Systems: slow, buggy, crappy outpu…
What do you consider contenteditable=true if not a rich text editing widget?
Nothing like a "rich text editing widget".
Earlier quoted context omitted.
I think typically "Rich Text Editing" includes controls for presentational aspects: fonts, colors, weights, etc. Contenteditable only lets you change the text itself.
No. It is possible to bold and such. With some code to hook things up you have pretty much everything you need for a "real" rich text box.
Earlier quoted context omitted.
Do you have any proof that DOM manipulation is slow? This is a common refrain that I've never seen proof of (other then anecdotally). There are folks saying that the DOM is fast, and how the JS we use to manipulate it is slow. http://blog.korynunn.com/javascript/the-dom-isnt-slow-you-ar...
To be fair, I'm not sure I would endeavor to make a mobile-only web app load 10000 elements to the DOM all at once. When I set to 2000, for instance, I can get below 200ms on Android 4.1.1 in chrome.