|
"developers should make real native apps instead of dumb web views" is a relatively recent party line. it's also true, but it's the sort of truth that developers are usually not well-equipped to deal with, because the sorts of software architectures that make it easy — exposing a well-designed API for your service, via RPC or whatever, that can be used by either a web or native client — are not decisions that you can make unilaterally as the mobile app development team of a much larger organization
|
#
?
Jan 1, 2018 06:27
|
|
|
|
| # ? Jun 6, 2024 15:31 |
|
|
rjmccall posted:"developers should make real native apps instead of dumb web views" is a relatively recent party line. it's also true, but it's the sort of truth that developers are usually not well-equipped to deal with, because the sorts of software architectures that make it easy — exposing a well-designed API for your service, via RPC or whatever, that can be used by either a web or native client — are not decisions that you can make unilaterally as the mobile app development team of a much larger organization if there is even the slimmest silver lining in this nightmare cloud that is web dev, it is the practice of maintaining usable REST APIs to serve your awful web frontend is standard operating procedure now
|
|
#
?
Jan 1, 2018 06:36
|
|
|
Back in my day it was autogenerated SOAP APIs for your WinForms or VB6 app. Those days were better imo I wish Apple had decent, stable APIs but instead they do things like change drawRoundRect between iOS versions, breaking all drawing apps. Because branding or something
|
|
#
?
Jan 1, 2018 06:38
|
|
|
soap was unironically good and cool and i miss it
|
|
#
?
Jan 1, 2018 06:41
|
|
|
Notorious b.s.d. posted:you joke but i actually saw vbscript used on web pages in intraweb apps vbscript is unironically better than javascript.
|
|
#
?
Jan 1, 2018 06:57
|
|
|
Plorkyeran posted:he's worked at apple a very long time and sometimes that gives him unique insights and sometimes it makes him forget some of the ways in which his experience is unusual very long time only in today’s terms many of my coworkers have been here way longer
|
|
#
?
Jan 1, 2018 07:49
|
|
|
Notorious b.s.d. posted:if there is even the slimmest silver lining in this nightmare cloud that is web dev, it is the practice of maintaining usable REST APIs to serve your awful web frontend is standard operating procedure now even if i knew nothing about web developers, i would feel confident in calling this out as bullshit just because good api design is difficult. i suspect that the actual standard operating procedure is that you make a rest api that changes every 2-3 "sprints" when johnny q. tenecks from the team across the hall adds a new mandatory argument and maybe remembers to update most of the clients and half of the tests
|
|
#
?
Jan 1, 2018 07:57
|
|
|
Blinkz0rz posted:maybe? idk i'd rather write js than c or c++ but maybe that's just me Just you, sorry
|
|
#
?
Jan 1, 2018 09:07
|
|
|
rjmccall posted:"developers should make real native apps instead of dumb web views" is a relatively recent party line. it's also true, but it's the sort of truth that developers are usually not well-equipped to deal with, because the sorts of software architectures that make it easy — exposing a well-designed API for your service, via RPC or whatever, that can be used by either a web or native client — are not decisions that you can make unilaterally as the mobile app development team of a much larger organization why would anyone use a native client over a web based one assuming feature parity? That's an honest question, I'm not trying to be a smartass I literally do not know the answer.
|
|
#
?
Jan 1, 2018 13:05
|
|
|
abigserve posted:why would anyone use a native client over a web based one assuming feature parity? Performance, battery life, etc. Also I have yet to see a web based client that has feature parity with native one without both being horribly crippled in regards to obeying copy paste, resizing, etc etc etc.
|
|
#
?
Jan 1, 2018 13:18
|
|
|
Xarn posted:Performance, battery life, responsiveness, does not randomly fail to download half of its UI,
|
|
#
?
Jan 1, 2018 14:12
|
|
|
redleader posted:i can't wait to ship a webass implementation of the entire .net runtime on every page load so that i don't have to write something that is js or compiles to js hell yeah me too https://github.com/bridgedotnet/Bridge https://github.com/sq/JSIL https://github.com/SteveSanderson/Blazor
|
|
#
?
Jan 1, 2018 14:59
|
|
|
rjmccall posted:even if i knew nothing about web developers, i would feel confident in calling this out as bullshit just because good api design is difficult. i suspect that the actual standard operating procedure is that you make a rest api that changes every 2-3 "sprints" when johnny q. tenecks from the team across the hall adds a new mandatory argument and maybe remembers to update most of the clients and half of the tests oh yeah, you totally nailed it. that's exactly what it's like. but bear in mind that the status quo ante was no api at all. if you wanted to interoperate with whatever another app team was making GBS threads out, your best bet was often to grovel through their databases. if you were really lucky someone would create a relevant view for you
|
|
#
?
Jan 1, 2018 18:48
|
|
|
the rise of elaborate js apps in browsers creates an internal demand for an api that has to be up to date or else the web app stops working this doesn't mean that the api will be well-designed or pleasant to use or tested or documented. only that it will exist, and it will be up to date.
|
|
#
?
Jan 1, 2018 18:50
|
|
|
well gently caress i read rjmccall's post started to write a response then got to the bottom and notorious wrote what i was going to write. a lot of what used to be done with web scraping can now be done by hooking in to the "rest" api driving the site so that's a win right there
|
|
#
?
Jan 1, 2018 19:00
|
|
|
yeah, that makes sense and is definitely progress
|
|
#
?
Jan 1, 2018 19:30
|
|
|
Max Facetime posted:responsiveness, does not randomly fail to download half of its UI, Doesn't eat hundreds of megs of ram, doesnt take 10a of seconds just to start up...
|
|
#
?
Jan 1, 2018 21:00
|
|
|
Notorious b.s.d. posted:the rise of elaborate js apps in browsers creates an internal demand for an api that has to be up to date or else the web app stops working This is something I think about often and the difference between even an unstable, badly defined API and WebForms methods doing low level work in an OnClick handler is massive. Having that distance between the UI and the LOB makes even the laziest devs have to think about things like separation of concerns and layering. (It's even worse in our business using Intersystems Cache (MUMPS++) where database access is only a variable assignment away. Other teams will write the UI in server-side Cache and do all kinds of direct database access, which is a total loving nightmare and something our team thankfully doesn't do.)
|
|
#
?
Jan 1, 2018 21:57
|
|
|
theodop posted:This is something I think about often and the difference between even an unstable, badly defined API and WebForms methods doing low level work in an OnClick handler is massive. Having that distance between the UI and the LOB makes even the laziest devs have to think about things like separation of concerns and layering. Please tell you don't work at epic, lol.
|
|
#
?
Jan 1, 2018 22:47
|
|
|
cis autodrag posted:Please tell you don't work at epic, lol. wrong country  but bad Cache programming is universal, I would think, considering the whole ecosystem is set up to foster horrible practices
|
|
#
?
Jan 1, 2018 22:53
|
|
|
theodop posted:wrong country Well I'll be damned.
|
|
#
?
Jan 1, 2018 22:55
|
|
|
edit: didn't realize there was a page of new replies
TimWinter fucked around with this message at 03:06 on Jan 2, 2018 |
|
#
?
Jan 2, 2018 02:58
|
|
|
do we need a web rear end to mouth thread jesus christ
|
|
#
?
Jan 2, 2018 04:37
|
|
|
 it's not like this thread is an unending stream of other content that's being lost in the ocean of webasm. also it's a legit language-design-and-implementation topic
|
|
#
?
Jan 2, 2018 04:46
|
|
|
yeah this thread goes a few posts a week when there's not an argument
|
|
#
?
Jan 2, 2018 04:47
|
|
|
yeah fair enough
|
|
#
?
Jan 2, 2018 04:47
|
|
|
do the javascript haters here think application developers (i'm talking here about webapps, ionic, phonegap, react native, electrum and whatever else you want to put in this bucket) are choosing to go that route over native apps because they're idiots who don't know any better? or because native development is stuck in 1993? it's clearly the latter, no?
|
|
#
?
Jan 2, 2018 05:01
|
|
|
I think there's a lot of benefit to targeting wide-reaching platforms and it's unfortunate that one of the current widest-reaching platforms is the JavaScript web app. It's also unfortunate that on this platform you still have to account for such a wide range of interface sizes and capabilities. My laptop's old enough that the heavy JavaScript content bogs it down and the screen has a low enough resolution that a lot of websites "responsively" fall into their lovely, neglected tablet layouts. I don't think native development is necessarily stuck in 1993, it's just that few places have the resources to put out versions of their product that work on Windows, Mac, Linux, iOS, Android, Vizio TV's, PS4, XBoxOne, Switch, etc.
|
|
#
?
Jan 2, 2018 06:04
|
|
|
a web app is generally fine for systems like desktops and laptops that can deal perfectly well with an ordinary web site: they're usually connected to reliable high-speed networks, they have enough screen space that you can waste a lot of it on navigational stuff like headers and sidebars, power usage is a second-tier concern, they're not particularly memory-constrained, etc. if the product is for serious content creation then a web app is just going to lead to a long series of bad compromises, but most software is not for serious content creation. it's really just things like phones where web apps are godawful
|
|
#
?
Jan 2, 2018 06:38
|
|
|
the talent deficit posted:do the javascript haters here think application developers (i'm talking here about webapps, ionic, phonegap, react native, electrum and whatever else you want to put in this bucket) are choosing to go that route over native apps because they're idiots who don't know any better? or because native development is stuck in 1993? it's clearly the latter, no? there is a greater than zero percent of them that absolutely are, but I don't think it's anywhere close to the majority (unless you're talking about phonegap since that's basically only used for shoveware) webapps were the first development platform to make "write once, run anywhere" actually work (even if you do still need to test it in a bunch of browsers), and they still have the best installation/update process. for most apps, those two features end up trumping basically everything else.
|
|
#
?
Jan 2, 2018 06:48
|
|
|
Sinestro posted:that's what I'm saying. I can use qt which means using their lovely stl knockoff and either means super weird looking widgets and javascript or a gui library that feels like a trip back to windows forms in a bad way, or I could use gtk which looks like poo poo on macOS... or I could use electron and it'll probably be a battery and memory hog but at least it won't suck as much to write you forgot wxwidgets which, in some ways, is better than all three (but still sucks)
|
|
#
?
Jan 2, 2018 06:55
|
|
|
wx has never had enough development resources to make their cross-platform wrappers for native widgets actually work the same on every platform. it's a shame. if they had twice as many developers working on it for the last decade as they actually did it could have been good.
|
|
#
?
Jan 2, 2018 07:31
|
|
|
wxWidgets is full of "this flag only works on pocketpc" which should tell you exactly how relevant it is
|
|
#
?
Jan 2, 2018 07:43
|
|
|
there were all kinds of alternatives after flash died. until 5+ years ago microsoft were still trying to push silverlight, and during that time they wanted to ensure javascript never got advanced features to compete with .Net by playing games at Ecma, like they did at the ISO with their office formats (also via Ecma). javascript is ok, but obviously its best feature is that companies who hate each other will support it. add flow or typescript and it's sufficient. also SharedArrayBuffer w/ webworkers will be pretty good too i think. i'm making a word processor with them (that's an old version from years ago so it doesn't use those newer features yet, but it does use asm.js). and i thought you'd be arguing about Service Workers wiping out native apps (which they will do)
|
|
#
?
Jan 2, 2018 08:03
|
|
|
CPColin posted:the screen has a low enough resolution that a lot of websites "responsively" fall into their lovely, neglected tablet layouts. I use tiling a lot and the amount of websites that completely fail when being given half of my ultra book screen is sad. Pictures overlap text, menu items disappear but the hamburger menu doesn't appear, etc etc
|
|
#
?
Jan 2, 2018 09:41
|
|
|
rjmccall posted:a web app is generally fine for systems like desktops and laptops that can deal perfectly well with an ordinary web site: they're usually connected to reliable high-speed networks, they have enough screen space that you can waste a lot of it on navigational stuff like headers and sidebars, power usage is a second-tier concern, they're not particularly memory-constrained, etc. if the product is for serious content creation then a web app is just going to lead to a long series of bad compromises, but most software is not for serious content creation. it's really just things like phones where web apps are godawful so ... a web app is ok on computers running x86-64 windows or, occasionally, x86-64 macos which kind of invalidates the whole “web apps mean write once run anywhere!” argument some people have been using, because now there are more different browsers to test your web app on than there are desktop platforms to test your qt or javafx app on (or you could just ignore the tiny mac market and use whichever microsoft gui thing shaggar recommends) the fact that electron even exists says a lot about how bad web apps are in practice. if desktop apps are obsolete, why go to all this effort to turn a web app into one?
|
|
#
?
Jan 2, 2018 09:55
|
|
|
update from trying to use qt quick: this is great if you hate separating your presentation from the rest of your code also if you hate yourself
|
|
#
?
Jan 2, 2018 09:58
|
|
|
theodop posted:Having that distance between the UI and the LOB makes even the laziest devs have to think about things like separation of concerns and layering. i see we've had different experiences
|
|
#
?
Jan 2, 2018 09:59
|
|
|
Soricidus posted:so ... a web app is ok on computers running x86-64 windows or, occasionally, x86-64 macos discord is a web app that runs fine on web, desktop windows, desktop linux, android, and ios. so, i dunno, works for me i guess.
|
|
#
?
Jan 2, 2018 10:02
|
|
|
|
| # ? Jun 6, 2024 15:31 |
|
|
i don’t get the hate for phone gap frameworks i would gain nothing if my banking app was native. i don’t care if you call it shovelware it does the job.
|
|
#
?
Jan 2, 2018 10:04
|
|