4 ms·
Seems browsers are obsolete and are now just getting in the way. People are trying to use every loophole and new technology possible to bypass features implemen
by Fuxy 13y ago
Seems browsers are obsolete and are now just getting in the way. People are trying to use every loophole and new technology possible to bypass features implemented in browsers.
I think it's time browsers took a step back and gave more control to developers.
It's time for a major rethink of what a browser should be/do.
- tomelders 13y agoI'm inclined to agree with you here. While I love HTML, CSS and Javascript it's not the right tool for where the web appears to be heading, which is essentially a transport layer for data that services apps. Mobile devices have turned the process of installing an app into something 'close enough' to the experience of browsing the web that I think a lot of consumers wouldn't notice if the twitter web site disappeared (except that would be big news, and they wouldn't be able to avoid all the complaining). Conclusion... I don't know, but I think our current concept of a browser and the web might be reaching the end of it's usefulness. More data needed.
- GrinningFool 13y ago"Seems browsers are obsolete and are now just getting in the way. People are trying to use every loophole and new technology possible to bypass features implemented in browsers." Warning: unpopular view ahead. It's a bit ranty, too. That's because we're hell-bent on doing everything in browsers in the first place. Somewhere along the way, we collectively decided that write-once run-anywhere would become reality, damn the consequences. We just wouldn't call it that anymore - to do so would raise the spectre of desktop java which has essentially shit the bed. Instead, we'll call it "standards". It's a most peculiar definition of "standards" though. These standards are a shifting target, receiving regular modification. Every major vendor can claim compliance regardless of whether they are actually compliant - after all, vendor prefixes. And many front-end developers extoll the virtue of these 'standards', apparently believing that the libraries and tooling that hide the inconsistencies from them are actually a solution instead of a band-aid. We've been trying for "write-once-run-anywhere-but-don't-call-it-that" [WORABDCIT] for years. And we've made such progress - in another decade we may actually have consistent standard support across browsers. Of course, we haven't had this for the last decade so I'm not sure why we're perpetually hopeful that we will in the next. And that's not even getting into performance. Because these 'standards' are built atop so many layers that applications built on them can very, very rarely provide performance like an application actually built for a native platform does. Leading to a whole discipline of computer science with a goal of performance that merely approaches native speed on a consistent basis. Back when I first started in my career, I remember building native application UIs that were poorly coded, inefficient and bloated. Hell, I used MFC for love of K&R. Yet this crap still ran faster on a Pentium III than the majority of "web apps" run on the latest hardware. A native application is nearly always going to be faster than javascript through a browser. For most applications being developed, it will provide excellent performance - even on ARM -- without any tuning, tweaking, shortcuts, or loopholes. It will give an experience consistent with the rest of the platform, so that users aren't having to learn a new UI paradigm with every hot new app. You can even integrate technologies into a native app that still allow you to communicate with back-end components over http/https - go figure. A well-written native library is cross-platform (thanks to meaningful standards), so that only the UI bits would differ. The cost is more time building. A loss of some flexibility. Levelling up some basic skills, perhaps raising the barrier of entry a bit. A step back from RAD practices that have become so rapid that it's become common for a new "app" to be deployed knowing it will break under stress and worry about fixing it later. Not saying that this didn't happen before - but I am saying it wasn't accepted as the norm to the degree it is now. But nah. Native is yesterday. Why on earth would we want to take fullest advantage of modern hardware to provide a good user experience? Let's continue to reinvent the browser. We'll keep on with WORABDCIT because sooner or later, we're bound to come up with standards that are finalized and implemented consistently. Really. We will.
- Fuxy 13y agoMost of you're points I agree with but we tried Native it's not the answer. With native you have to redo your work multiple times that is not efficient java had the right idea but their implementation is a nightmare. We need something that would be as simple as using a browser but would act more like a java interpreter under the hood. But I wouldn't want java or javascript as a language. We need something that trows exceptions every time you attempt to do something the wrong way like Python because a log of beginners will try and if the language allows it there's going to be a lot of messed up code.