701–710 of 717 posts
Earlier quoted context omitted.
Parameter-ized query builders are possible in every SQL library. String escaping SQL? How is anyone thinking that is still a thing in 2017? The problem has been solved for two decades
Not just that, but they are great for sharding too.
Earlier quoted context omitted.
Isn't it kind of offensive to suppose that billions of users should pay more money so that hundreds of developers can use less efficient tools to build apps? Isn't this backwards?
If those are the only factors and the numbers fall in particular ranges, sure. Otherwise, no. Try doing the math here. How much cheaper would a netbook get if every single developer coordinated to reduce RAM and CPU usage? $5? Maybe $10? Looking at market prices, old RAM and CPUs are cheap. They consume basically the same physical resources as new RAM and CPUs, so price competition for not-the-best hardware is fierce…
This is especially true as people are promoting everyone moving to a platform that is substantially worse.
How about getting more performance and battery life out of the same machine which effects more than netbook users.
Earlier quoted context omitted.
Erm, "Mozilla usually pulls such NIH moves to sabotage the introduction or use of languages (even DSLs) other than JS on the web." maybe it is also because their ressources are limited and implementing a new language like dart is somewhat expensive. And NaCL even more I think. But I actually have some anger as well on them for enforcing indexedDB and killing everything else. So now we have to use f indexedDB for stor…
IndexedDB is seriously one of the web's biggest mistakes. WebSQL was awesome, and most people already know how to work with a relational database and SQL. A virtual file system API would be great. It's definitely one of the core features still missing from the ecosystem.
yes. combined with an easy ability to make real files out of them.
Earlier quoted context omitted.
"All the major players these days (like Facebook) get the overwhelming majority of their traffic through their native mobile app" Source? And I do not think, there is a sharp line between WebApp and Website. You could say, we are using one right now (even though very primitive) discussing right now - more than "static(-ish) content" Also most of the other parts of the Web are not really static anymore - highly dynami…
> Source? https://expandedramblings.com/index.php/facebook-mobile-app-... Over 50% of facebook users only access it from their mobile devices. > And I do not think, there is a sharp line between WebApp and Website. You could say, we are using one right now (even though very primitive) discussing right now - more than "static(-ish) content" You could make that claim but it'd be a tough sell. Sites like this are clearl…
maybe it is hidden somewhere, but I only read "mobile users only", not "native app" only. So users who access by browser would be in that category as well
Earlier quoted context omitted.
Agreed. And yes, that needs some attention, but most people doing responsive web do not account for most of that either. What does changing fonts mean? You design something for a font and then change it afterwards or? When I click on some languages (I am not native English and my native language, Dutch, is not very high on the list of priorities for most companies) in some of the biggest companies in the world, you n…
I used to write Petzold-style Win32 apps. I've also written native Cocoa apps as recently as last month, and I've used Qt and GTK+. Having experience with all of these, my preference is still for Web apps, because of the ease of portability and the fact that TypeScript beats C++ for ergonomics, safety, and ecosystem (just having a package manager is huge, even if NPM leaves something to be desired). I find it fun to…
Earlier quoted context omitted.
Software has become more increasingly complicated over time. Aside from adding new features, many companies have improved their efforts of providing accessible applications to a international audiences. Let's not forget we've drastically increased security by writing applications in safer languages. Oh, and newer applications tend to support a far wider variety of devices types, displays, inputs, etc. Developers defi…
> it's unfair to claim stuff is slower without improvements. I claimed no such thing. You're arguing against a statement I never made. Isn't that what's called a straw man argument?
Earlier quoted context omitted.
If those are the only factors and the numbers fall in particular ranges, sure. Otherwise, no. Try doing the math here. How much cheaper would a netbook get if every single developer coordinated to reduce RAM and CPU usage? $5? Maybe $10? Looking at market prices, old RAM and CPUs are cheap. They consume basically the same physical resources as new RAM and CPUs, so price competition for not-the-best hardware is fierce…
Trivializing making bad software that is slower on devices orders of magnitude faster by trying to equate it to netbook prices is a particularly bad methodology of comparison. This is especially true as people are promoting everyone moving to a platform that is substantially worse. How about getting more performance and battery life out of the same machine which effects more than netbook users.
You may have noticed that we are in the technology industry. That means the final measure of our work is economic. The final judges of our work are our customers.
If you believe that X is better in our industry, you must be able to demonstrate that betterness in terms of user economics, in terms of user experience. You haven't yet, and you seem unwilling to even grapple with my argument in those terms. Are you planning on trying?
Earlier quoted context omitted.
nope.
> this was not how the decentralized web was designed... but that doesn't mean that it's "time to kill the web." Its not "time to kill the web", because that was never under consideration.
Earlier quoted context omitted.
> this was not how the decentralized web was designed... but that doesn't mean that it's "time to kill the web." Its not "time to kill the web", because that was never under consideration.
click the link and read the giant 18 point text heading. thx.