[HN Gopher] Ask HN: Is there still a place for native desktop apps?
___________________________________________________________________
Ask HN: Is there still a place for native desktop apps?
Modern browsers these days are powerful things - almost an
operating system in their own right. So I'm asking the community,
should everything now be developed as 'web first', or is there
still a place for native desktop applications?
Author : Jaruzel
Score : 189 points
Date : 2020-05-17 13:31 UTC (9 hours ago)
| nakodari wrote:
| I am running a native desktop app Jumpshare
| (https://jumpshare.com), a remote working communication tool that
| helps you share your work and ideas through instantly shareable
| links. Basically, it combines video recording, screenshot
| capture, and file sharing - all in one app. This is not something
| you can build using a modern browser or Electron because it does
| not have tight integration with the operating systems.
| paulmooreparks wrote:
| I'm mixing a song in Pro Tools right now, and earlier I edited a
| video in VideoPad. I can't fathom doing either on a web app.
| mellosouls wrote:
| Whatever contemporary technical arguments for and against are,
| it's worth bearing in mind that people were asking the exact same
| question, with similar arguments at least 10 years ago (and
| probably more), so I would say:
|
| Yes.
| Ingon wrote:
| In some (most) cases, desktop apps could be better - performance,
| latency, offgrid capabilities, and even privacy. In most cases, I
| prefer offline desktop apps, then their online counterparts.
|
| One area which is really tough to nail is cross-platform support
| though. Getting a good app on one system is hard enough, getting
| it in all three - rarely done. This is one of the things where
| web shines.
|
| From business standpoint, I think web-first with an eye on native
| works for majority of cases. That is, as long as the majority of
| users don't care about the above. In some future, if we start
| valuing efficiency and especially privacy more, this could turn
| around. But it feels like, even then, web will probably find a
| way to make more sense for most people.
| funcDropShadow wrote:
| But building a good app on all three major operating systems is
| not solved by an abstraction layer, neither by a cross platform
| gui toolkit nor by a web layer. Different operating systems
| have different conventions, metaphors and standards. A portable
| application will usually feel foreign on all, but the
| developer's primary platform. Unless, the developers invest in
| adapting to the differences of the platforms.
| roel_v wrote:
| Lots of software would be better (from the user's POV) as a
| desktop app. However as a developer and as a software business
| owner/investor, it's (much) better to write web apps. So it
| depends on what you're asking here. Should you invest in desktop
| dev skills to further your career? No. Should you write your
| software idea as a desktop app if you want to make a business of
| it? Not if you can avoid it. If you're asking something else,
| well I guess the answer is 'maybe'.
| cpach wrote:
| OTOH, creating desktop apps is a skill in itself that one might
| want to master. At least in the Mac ecosystem this is a
| regarded skill and amongst the users there is a willingness to
| pay for apps. SaaS might still be more lucrative though.
| chadcmulligan wrote:
| > However as a developer and as a software business
| owner/investor, it's (much) better to write web apps.
|
| Why do you say that?
| dtly wrote:
| Scaling out cross-platform, lower cost of investment to
| support multiple OS/Devices.
|
| User does not need to worry about dependencies and libraries
| - they just need to make sure they're running a somewhat up-
| to-date version of a modern browser.
|
| Users are not tied to a single device either.
| Dotnaught wrote:
| As a business, it's not to your advantage to have to ask
| permission from app store owners. The web does not require
| permission from a third-party that may decide to compete with
| you.
| benibela wrote:
| But with the app stores you get more users
|
| I basically had no users for one of my desktop apps for
| seven years, till I ported it to mobile and put it in the
| normal app store
| amelius wrote:
| Because of the main advantages of SaaS: recurring payments
| and data lock-in.
| tonyedgecombe wrote:
| Adobe achieves that with desktop apps, if you can call it
| an achievement.
| TomMarius wrote:
| Sadly I am not Adobe
| WilliamEdward wrote:
| Achievement is a big word here. They had to shove it down
| people's throats with a bloated, buggy, and expensive app
| suite.
| tonyedgecombe wrote:
| Yes although people still put their hand in their pocket
| every month so they must be getting some value from it.
| rohan1024 wrote:
| I think he is saying that because with webapps you have
|
| - control over your software and updates
|
| - no one can pirate your software/service
| ken wrote:
| How do you have more "control over your software" with a
| web app? With a native app, I can do virtually anything.
| With a web app, I can really only do what (Google [?] Apple
| [?] Microsoft)'s web browser teams decided to prioritize,
| and allow, and optimize.
|
| As for 'pirating', is that a serious concern these days?
| I've only ever heard about it being an issue at big
| companies selling software to other big companies, where
| it's solved with "license servers".
| ZoomZoomZoom wrote:
| >> How do you have more "control over your software" with
| a web app?
|
| It means they can break a program I'm using at any moment
| they wish, even after I paid for it.
| hellisothers wrote:
| I think they mean rapid, continuous deployment. If it's a
| web app you can push out changes every day to near
| universal adoption. With a native app you have to cajole
| users to update
| ken wrote:
| There are auto-updaters for desktop software, too.
| rohan1024 wrote:
| This is exactly what I meant.
| alexgmcm wrote:
| Also on mobile you are constrained by the app store
| requirements as well.
| Memosyne wrote:
| > no one can pirate your software/service
|
| Huh? Given how most web applications these days are using
| client-side rendering there's nothing stopping someone from
| just downloading all of the frontend assets. You can also
| connect to a server from your desktop application so I
| don't understand how desktop makes it easier to pirate
| anything.
| ssimono wrote:
| Web applications have lots of essential parts on the
| server-side even if they do client-side rendering. And
| each paying user is logged in when using it, so the
| company can accept/deny requests depending on the user.
|
| Proprietary desktop applications are usually downloaded
| after a payment, and then the full software is available
| locally. By hacking the security parts of it one can then
| have a totally free version and distribute it. That's why
| it is easier to pirate.
| jfkebwjsbx wrote:
| Not anymore!
|
| Games and even productivity apps are known to be moving
| small pieces to their servers so that you cannot run the
| entire application on your own...
| tfehring wrote:
| Here's PG's response from 2001:
| http://www.paulgraham.com/road.html
| thrower123 wrote:
| Fuck no, everything should not be a webapp. Most things that are
| webapps should not be, it's just that nobody knows how to do
| anything else.
|
| It's really about time for the pendulum to start swinging back,
| as processors aren't getting much faster anymore.
| emddudley wrote:
| Yes, there is still a place for native apps.
|
| Anything that communicates with devices using serial, UDP, or
| custom layer 2 protocols.
|
| Also anything which needs to be used in a lab environments with
| networks that can't access the web or corporate network.
|
| Also anything that needs to run in a manufacturing environment,
| where precise configuration management, predictability, and
| reliability are crucial.
| kgin wrote:
| What a crazy world where for desktop/laptops, we're not sure we
| even need native apps even for complex use cases.
|
| But for mobile, there is an almost religious insistence that even
| text-based CRUD apps need to be compiled binaries.
| hermitcrab wrote:
| Yes, I hope so. I have just released a new data
| transformation/ETL tool for the desktop (Qt/C++ app for Mac and
| Windows). The advantages of desktop are: -performance/low latency
| -richer UI (e.g. shortcuts) -privacy
|
| But there are trade-offs: -the user has to install/upgrade it
| -less insight into what the user is doing -harder to sell as a
| subscription
|
| I wrote this in 2013 and I think it is still mostly true: 'Is
| desktop software dead?'
| https://successfulsoftware.net/2013/10/28/is-desktop-softwar...
| oblib wrote:
| I've been working on a sort of hybrid of the two by configuring a
| web app to use CouchDB installed on the user's desktop pc to
| store the user's data.
|
| The app code is delivered by a web server and runs entirely in
| the user's browser and with service workers configured it runs
| offline too.
|
| Personally, I think it would be cool to have a sort of secure
| "runtime engine" on the client side that could manage permissions
| to system functions for client side web apps.
| freepor wrote:
| You need a desktop app when 1) you're spending a ton of time in
| the app or 2) you need every ounce of performance and feature set
| that you can obtain and 3) you're willing to pay for it.
|
| If you're not building something like this, don't build for
| desktop.
| pier25 wrote:
| It's true that many apps could be replaced today with a website,
| specially those that are basically capturing and showing data.
|
| But there are still many areas where native is king.
|
| - Games
|
| - Audio / Video work
|
| - Adobe type of work (photo editing, motion graphics, vectors,
| etc)
|
| - 3d
|
| - Office. For me Google docs is enough, but not for heavy users.
|
| - Desktop utilities (eg: Alfred, iStatMenus, etc). You could
| certainly use a web UI for those, and it would probably be fine ,
| but you'd still need some native integration.
| egypturnash wrote:
| I like to take my laptop out to a park and work with all the
| radios off to get the best use out of my battery. I also like to
| do complicated things with a lot of files that need to be
| organized in a real filesystem, the directory structure of a
| graphic novel can easily match the complexity of a program's
| source tree.
|
| Your web app, which requires several extra levels of indirection
| between the code and the bare metal, an online connection, quite
| possibly is built on a framework that tends to suck down a
| significant percentage of my CPU even when it's idle in the
| background with all windows closed, and its own weird file
| management that's probably a giant hassle when I need to get my
| work into another program, has no place in my world.
| teddyc wrote:
| I like a desktop app for uploading / syncing large files or
| directories to the cloud.
|
| I'm sure there's a good web implementation out there for the
| Dropbox-style sync thing, I just haven't seen it yet.
| [deleted]
| Optimal_Persona wrote:
| O God, please no! I can't see anything requiring true low-latency
| real time performance (like audio production DSP) ever being fast
| enough on the web compared to native. Also, when everything went
| 64 bit in recent years, developers got really lazy about memory
| management.
| kokizzu wrote:
| this just like asking: do you prefer to use native/high
| performance applications? yes do you like developing native
| application? no if the performance and memory usage of web app
| already equal to native desktop app, which do you prefer to use?
| web
|
| XD
| theredbox wrote:
| If computers get significantly faster then no...but at this point
| I always reach for a native application if I have the choice.
|
| The only non-native app I dont detest that much is VS Code but it
| still feels painfully slow compared to something like Sublime
| Text.
|
| Lets look at the chat apps that provide a similar functionality.
|
| * Teams
|
| Takes between 600-800MB on my PC. It's sluggish as hell and will
| often choke to re-render if I click on something.
|
| * A native chat app Takes 15MB...Is just as eye candy as Teams
| and yet i dont care if it's running or not.
| perilunar wrote:
| What a crazy mixed-up world: on desktop we ask if there's a
| future for native apps, while on mobile we ask if there's a
| future for web apps.
| Youden wrote:
| Yes, there's definitely still a place for them.
|
| I'd say that that when you're writing an application which is
| fundamentally just a pretty wrapper (e.g. it exists to take user
| input and pipe it over HTTP to some web service or use it to
| generate a command for some other binary) and your users don't
| care about performance, resource usage or reliability, it makes
| sense to use a browser. Your application is very UI-focused and
| if you're already familiar with HTML, CSS and JS, use what you
| know.
|
| However if you're working on an application that has strict
| resource usage, reliability and/or performance requirements like
| say a control system for industrial equipment, a 3D game, a video
| encoder, photo editing software, or software that's going to be
| run on an embedded system, you're going to find it difficult to
| do what needs to be done with a browser/wrapper. It can be done
| for sure but it'll be something you work around rather than with.
| hellisothers wrote:
| 100% this, it depends on the context, and as one other person
| mention it depends on your goal.
| AnonC wrote:
| It depends on what you're developing, who the target users are
| and how much you need to charge to sustain yourself. It also
| depends on your skills and how much time you're willing to invest
| in creating a desktop application (doing one that's cross
| platform, that performs well and works like a native app on each
| platform would take a significant amount of effort).
|
| Native desktop apps targeted at the average user are better done
| on macOS, since that platform has a higher percentage of users
| who will pay (compared to the percentage of users who'd just
| pirate it).
|
| Applications targeted at professional users, corporate users and
| developers can get an audience that's willing to pay on any
| platform.
|
| If your application is better done as a service, and you'd like
| better control on managing versions, a web based SaaS might make
| sense.
| hermitcrab wrote:
| >Native desktop apps targeted at the average user are better
| done on macOS, since that platform has a higher percentage of
| users who will pay (compared to the percentage of users who'd
| just pirate it).
|
| That was always the standard wisdom. However I have released
| the same software on Windows and Mac and seen significantly
| worse piracy for the Mac version.
| webscalist wrote:
| Sure, if you want to drain battery
| gdulli wrote:
| Not having a real native desktop player is why I won't subscribe
| to Spotify. When I'm going to use something more than lightly, I
| hate using applications that feel like web tech. But I realize
| I'm in the minority.
| zacharycohn wrote:
| _Reads comment. Cocks head, curiously. Closes eyes, listens to
| the music coming from his computer. Opens eyes, alt-tabs to the
| Spotify app. Closes all web browsers. Music continues,
| uninterrupted except by ads. Shrugs, goes on with his day._
| CORBLIMEY-19 wrote:
| Spotify on the desktop is just a big Chromium Embedded
| Framework frame, thats what makes it not-native for the
| purposes of this discussion
| begriffs wrote:
| Anybody here ever create graphical apps with Motif? Care to share
| your experience?
|
| Motif appears to have an old and stable API. Its visual style
| looks grey and blocky, but has a rich widget toolkit.
|
| https://www.oreilly.com/openbook/motif/
| sys_64738 wrote:
| I want native apps not webpages that run in their own 'app'. If I
| want a web app then I'll run it in a web browser. Things like
| Electron apps are something I simply refuse to run.
| goatherders wrote:
| I use a number of native desktop apps. For email. For music. For
| projects. For saving files. For instant messaging.
| thewebcount wrote:
| I go out of my way to avoid web apps. They're uniformly awful.
| They also have a tendency to require an internet connection, even
| when they don't need to. Some can use local storage, but the
| other problems with web apps don't make up for it. I don't want
| an OS running on my OS. I want to just use my apps.
| derision wrote:
| The web versions of Office software still feels way less polished
| than the desktop version. It just doesn't feel quite right
| lern_too_spel wrote:
| Barely ever. If I have to install an app, even (especially) an
| Electron app, you've already lost me unless you provide something
| I can't get anywhere else.
| gherkinnn wrote:
| OS extensions like command line tools, Alfred or Little Snitch
| will remain native by necessity.
|
| As will applications like Final Cut Pro and Logic Pro. As I see
| it, the web platform is neither adequately performant, nor are
| its timing mechanisms accurate enough.
|
| So no, native is sliding. I argue that >95% of users are happy
| with browsers and/or electron apps.
|
| Either that, or those peeps move over to iPads. Which by design
| forces native or psuedo-native apps.
| WaltPurvis wrote:
| If you develop an application that runs in the web browser, I
| won't use it. That's not some dogmatic principle of mine, it's
| just an empirical fact.
|
| I use only one browser-based application: Gmail.
|
| I've never used another browser-based application and I can't
| imagine that I ever will unless there's truly no alternative and
| it's forced on me by an employer.
|
| I've happily paid for dozens of desktop applications, and I'm
| even semi-happily paying for around ten of them that have
| switched to a subscription model, but I never have and likely
| never will use browser-based applications even if they're free.
| twicetwice wrote:
| I'd be surprised if that is the case--or perhaps we have
| different definitions of what constitutes a "browser-based
| application." For example, I do all my online banking in my
| browser; it's the most fully-featured way to do so. It might
| not obviously be a PWA or an SPA, but I certainly think it
| deserves to be called a "browser-based application." What else
| could it be? It's certainly not a "web page." In fact I'd argue
| that any site that has content that's scoped to a user and can
| be manipulated by the user is a "web application."
| kleiba wrote:
| I don't get the downvotes: the original question asked about
| opinions on web-based vs. native apps, and this guys is giving
| exactly that. And what else could you do, you can either cite
| some usage statistics or give personal assessments.
| kleiba wrote:
| What, and now even my own comment gets downvoted?! If there
| was at least a reason given... coward.
| shams93 wrote:
| Well the browser is still not good at things that say Blender or
| Protocols can do. Media pros still need desktop software for
| example audio latency in chrome is far too high to use it for any
| serious pro audio applications.
| dzonga wrote:
| as a Linux desktop user. I believe, having web applications is
| preferable to desktop ones. however, the problem is talent is
| lacking around the industry to make performant web apps. Not
| every company can produce a high quality products such as Figma.
| things on web are not tied to walled gardens or any other stupid
| shit. easily accessible.
| feifan wrote:
| IMO desktop apps aren't quite equivalent to native apps. Native
| apps look and behave in a consistent way. They have
|
| * Familiar UI primitives: - Controls and chrome are in the same
| place - Font sizes are the same across apps - Consistent icons
| and button shapes
|
| * Support standard keyboard shortcuts (including obscure ones
| that developers re-implementing these UIs might not know about) -
| All the Emacs-style keybindings that work in native macOS text
| fields but are hit-or-miss in custom web text fields - Full
| keyboard access (letting me tab and use the space bar and arrow
| keys to interact with controls)
|
| * And consistent, predictable responsiveness cadences - Somewhat
| contrived example: In Slack (browser or Electron app), switching
| between channels/DMs (via [?]K) has a lag of about 0.5-1 second.
| If I start typing my message for that recipient during this lag,
| it actually gets saved as a draft in the channel that I just left
| and my content in the new channel gets truncated. I don't think
| that kind of behavior would happen in a native macOS app, which
| renders UIs completely synchronously by default/in-order (so it
| might block the UI, but at least interactions will be in a
| consistent state)
| pbhjpbhj wrote:
| Consistency is maybe overrated?
|
| I purposefully make my FF unlike the other apps on my system. I
| use a couple of workarounds to prevent OS level keybinds from
| working in some apps. Sometimes a completely purpose made UI is
| better, sometimes.
|
| In general, consistency [in desktop UI] is good, but there are
| good reasons to break it.
| pmlnr wrote:
| It is certainly not overrated. See Windows 10.
|
| https://www.techrepublic.com/article/control-panel-and-
| setti...
|
| https://www.windowscentral.com/sites/wpcentral.com/files/sty.
| ..
| dredmorbius wrote:
| Depends heavily on the user community, use case, time-in-
| environment (short- and long-term), inter-user communication
| _about_ application, and rate of change. There 's almost
| certainly a set of interrelationships between these.
|
| For a highly technical userbase, a highly bespoke UI may be
| defensible,even preferable, especially:
|
| - User community is expert, highly skilled, and highly
| computer-literate.
|
| - If daily-weekly time-in-environment is high. User "lives
| in" application.
|
| - If lifetime time-in-environment is high. Users base career
| in application.
|
| - If there's relatively little communication _between_ users
| about application state, interactions, or activities. Put
| another way: users interact _with_ the app, but not _about_
| the app with others (users, clients, management, techs).
|
| - The UI avoids drastic change over time.
|
| By contrast, reverse virtually any of these conditions and
| you'll want a UI that conforms closely to _current_
| standards:
|
| - Users are inexpert, poorly computer-literate (the vast
| majority, see OECD computer skills study), or simply
| nontechnical with app.
|
| - Time-in-environment is low. At the extreme, all users are
| one-time novices.
|
| - If users must communicate with others regarding app state
| or tasks -- close management, team interaction, client /
| management interactions. All parties need a ready and clear
| mental model of the UI and state.
|
| - If the UI changes drastically over time, it should do so
| consistently with all other major elements. (Both should
| change as little as possible.)
|
| Somewhat more concretely, the _absolute worst_ feature a UI
| can have is change. Users get confused, lose trust, and are
| burdened by obsolete knowledge. This afflicts both expert and
| nonexpert users, profoundly, though in somewhat different
| ways.
|
| For very technical tools used principally creatively ---
| virtually all editors, development environments, and many
| reader/browser/search/analysis tools fit this description ---
| a highly distinctive (and customisable) interface may be
| appropriate _for advanced users_. This is a small, but
| generatively critical, user community. There 's a requisite
| complexity to such tools, simplified UI comes at the cost of
| vastly less efficient performance.
|
| Virtually all "weird" tools in heavy use today evolved from
| what were _at the time of their creation_ , common motifs, at
| least within the environment of origin. Think of Unix, vi,
| emacs, Photoshop, Excel, and Eclipse, say.
|
| For standard workflow, control, and transactional tools,
| highly standard UIs are preferred. Here, users are
| interacting closely with others _regarding state or
| interactions with the interface_ , and clarity, consistency,
| and common knowledge of the UI and state changes matter.
| Point-of-sale systems, equipment controls, general monitors,
| enterprise applications, end-user/customer support tools, and
| the like.
|
| Occasional-use, public use, and similar tools must be
| generally usable without training. Adherence to standard
| motifs is critically important. UIs and capabilities are
| generally simple.
|
| The trade-offs:
|
| - More expert users and more heavily-used tools can support
| more novel UIs.
|
| - Less literate users, more unfamiliar tools, and greater
| communications about UI state and interactions, demand more
| standard UIs.
|
| - Change is generally bad, but evolutionary change (within
| the tool) or conformant change (with the overall environment)
| are generally less disruptive than either sudden drastic or
| idiosyncratic changes.
| falafel wrote:
| I don't agree with the first two points. Native applications
| aren't consistent in this way. There are dozens of cross-
| platform GUI kits and they all behave slightly different, just
| like Electron apps. If you want consistency, you need to build
| multiple apps, one for each OS with their respective toolkits.
| Ain't nobody got time for that when you can easily build on
| Electron and target browsers, macOS, Windows, and Linux in _one
| single app_. No wonder Electron is winning the battle so far,
| regardless of your last point.
| madhadron wrote:
| Native implies that you are building for each OS and their
| native toolkit. On macOS, you write Cocoa. On Linux you write
| GNOME or KDE or CDE. On Windows you write...I dunno. Win32
| probably.
| cpach wrote:
| IMO: To some extent, yes.
|
| Here are some desktop applications I enjoy and have gladly paid
| for:
|
| Acorn (image editor) / 1Password / Evernote+Skitch / Pingplotter
| / djay
| [deleted]
| blackrock wrote:
| Adobe seems to have achieved the combination of SaaS and Native.
|
| They got data lock in with Photoshop and Lightroom. Admittedly,
| the free alternative just doesn't work as well as Photoshop or
| Lightroom.
|
| The SaaS is on a monthly or annual subscription. So spending
| $20/month, if you only use it for 1 month, is far cheaper than
| spending $800 outright for a Photoshop license. And now, Adobe
| has the potential to reach a global audience of 7 billion people.
|
| Of course, there is some risk that your code will be pirated,
| decompiled, and reassembled, to remove the ET-phone-home feature,
| but this is only a minor annoyance. It's better to get your
| product pirated, than another competitors product. That way, the
| people using the pirated copies, who are likely poorer, or kids,
| will learn your program, and eventually pay for a full commercial
| license eventually, when they get a job professionally using the
| product.
| rptr-web wrote:
| Webassembly is slowly taking over and i believe native apps days
| are numbered.
|
| If legacy apps like AutoCAD ported to WASM can give similar
| performances and experience as web app this is just inevitable
| now.
| cecja wrote:
| Make a New Text file save your comment in it. Wait 5 years and
| laugh at your past self. Look at what problems wasm has right
| now the overhead will stay. If you look at vscode the limit is
| reached you just can optimize so much with aweb based apps,
| discord, vscode game launchers like the lol client every
| engineer working on it is aching. They are good for your jkob
| security but that's it.
| mike50 wrote:
| Speed of light is still fixed.
| thr0waw4y5555 wrote:
| I always go for a native app over a web app/electronjs app.
| Native will most likely have the familiar idioms of the OS, lower
| overhead, and take advantage of platform specific features. I
| happily pay money for native apps. I generally don't pay for
| blobs of JS in app form.
| alkonaut wrote:
| Take any app that uses all cores nearly 100%, maybe maxes out the
| GPU eats 3-5GB of ram, and is a 2-100GB install.
|
| Those will always be native.
|
| These are your Cad programs, your video editors, your AAA games.
|
| You can make a cad program in a browser too. But you trade a
| chunk of perf for convenience, and thats only rarely acceptable.
|
| Anything that could ever be done in a mobile app (chat, media
| consumption, ..) those might be possible to do in a browser. But
| you didn't even really need a computer for them to begin with.
| ComputerGuru wrote:
| Tell that to Autodesk. Fusion is like 70% web, slow, and
| bloated. They don't even have a good excuse since the whole UI
| is just a shell around a canvas and could easily be made
| native, it's not as if they're actually benefiting from the DOM
| or CSS.
| alkonaut wrote:
| That's the one I was referring to. That is, Fusion is a
| tradeoff that isn't always a acceptable (and still it's not
| completely web based).
| ZoomZoomZoom wrote:
| I'm going to be slammed for using these two words, but for any
| _real work_ you need to have as few layers of indirection between
| the user and the machine as possible, and this includes the UX,
| in the sense that it is tailored to the fastest and most
| comfortable data entry and process monitoring.
|
| I don't see any `web first` or Electron solution replacing Reaper
| or Blender in a foreseeable future. One exception I'm intrigued
| with is VS Code, which seems to be widely popular. May be I need
| to try it to form my own opinion.
| ur-whale wrote:
| Blender in the browser. Ugh. <shudders>
| brachi wrote:
| I don't find it that crazy, if properly compiled with web
| assembly. The thing is that Blender's UI is all synchronous
| python, so, yeah, that and the addons system would be to need
| rewritten. Python in the browser is a no-go performance-wise,
| of course.
| CharlesW wrote:
| > _Python in the browser is a no-go performance-wise, of
| course._
|
| "Running the Python interpreter inside a JavaScript virtual
| machine adds a performance penalty, but that penalty turns
| out to be surprisingly small -- in our benchmarks, around
| 1x-12x slower than native on Firefox and 1x-16x slower on
| Chrome. Experience shows that this is very usable for
| interactive exploration."[1][2]
|
| [1] https://hacks.mozilla.org/2019/04/pyodide-bringing-the-
| scien... [2] https://alpha.iodide.io/notebooks/300/
| p_l wrote:
| So, an already slow language made slower?
|
| No thanks.
| digi59404 wrote:
| Both VS Code and Atom use significant amounts of WebAssembly
| and low level libraries to achieve that performance. In
| addition to that they've written their own view layer for an
| IDE in modern JS which makes it more performant and stable.
|
| I despise electron and html-wrapper apps. But I gotta give
| credit where it's due. VS Code is pretty good.
|
| With the advent of the new WinUI, React+Native on Windows, and
| Blazer. I'm betting the future of windows is more web based
| technologies mingled with low-level native libraries.
| psds2 wrote:
| VSCode, because of electron, doesn't allow you to have multiple
| windows that share state while working on a project. This makes
| it terrible with multiple screens.
| camccar wrote:
| It's not because of electron. They could have multiple
| windows but it would be a massive over haul of the
| architecture . So they say just use another instance
| sime2009 wrote:
| OnShape (https://www.onshape.com/) offers professional level
| CAD which runs in a browser. Works great.
| namdnay wrote:
| "Professional level" covers a lot of different uses...
| Juicero and Airbus both use CAD, I seriously doubt the latter
| are going to replace CATIA with OnShape
| pupdogg wrote:
| I'm in agreement with @namdnay...I don't think it will
| replace enterprise packages like Siemens NX or CATIA anytime
| soon. I do all of my CAD design in Solidworks and I do like
| the out-of-the-box thinking/features of OnShape...but...their
| pricing model ends up being more expensive in the long run
| ($2100/year for Pro Version). I paid $4k for Solidworks in
| 2016 and it's paid itself off more than 10x times since
| then...all without the need for a forced upgrade! When a
| newer version substantiates its value for my workflow, I will
| upgrade. Not to mention, most of my work can easily be done
| in Solidworks 2008-2010 because that is the innate nature of
| CAD packages, regardless of the version, they will get the
| job done.
| alkonaut wrote:
| So is Autodesk Fusion. But you won't see Autocad stop selling
| their desktop software. People don't buy extreme rigs to use
| for production, and then trade even 5% of the perf for
| convenience.
| KaoruAoiShiho wrote:
| VS Code is slow at basic things like having characters show up
| on screen after hitting the key. It's good at everything else
| though so that lag doesn't matter as much.
| boardwaalk wrote:
| It probably depends on your hardware. I have an "older"
| (several years at least) Windows work laptop with iGPU that
| is quite sluggish with VS Code when hooked up to an external
| 4K display. However, it's snappy compared to Microsoft Teams
| in the same situation.
|
| Meanwhile, my similar era MacBook with dGPU hooked up to the
| same screen is very snappy and I honestly would probably not
| be able to tell the difference in a blind test between VS
| Code and typing in a native text box (like the one here in
| Safari).
|
| I'd consider myself pretty anal about latency -- I was never
| able to deal with Atom's, for example (disclaimer: I haven't
| tried it in years). I even dumped Wayland for X11 when I had
| a Linux desktop because of latency (triple buffering or
| something?) I couldn't get rid of.
|
| But VS Code is not bad.
| robin_reala wrote:
| Figma is pretty much replacing all web design applications
| precisely because it's leveraging web tech for collaboration on
| a single document at the same time.
| ashtonkem wrote:
| I think Figma's success is less about being web first and
| more to do with filling in gaps in what Sketch offered,
| especially in collaboration. Today you need to buy at least 2
| apps, Sketch and Abstract, to match the feature set of Figma.
|
| Design is one of the areas where one could arguably create a
| native app, largely because the user base is much more
| homogenous in OS than most other user bases.
| pupdogg wrote:
| Figma is a great tool and all but it will still take it
| years, if not decades, to replace immersive content creation
| technologies like Ventuz, one of the best in the game!
| https://www.youtube.com/watch?v=nu2FnEVk9_U
| polishdude20 wrote:
| Is this an ad or are you serious?
| ZoomZoomZoom wrote:
| I think we can safely exclude 'collaborative web design'
| applications from the set of hardcore tools not gaining much
| from being implemented as web apps for understandable
| reasons.
| blehn wrote:
| Huh? Why? Designers had previously been using native apps
| for ages -- Photoshop, Illustrator, Sketch... Figma has
| been successful not just because it's collaborative but
| also because it's performant, powerful, and reliable. Not
| sure why you think that can't be achieved with other kinds
| of software
| CharlesW wrote:
| And yet it is a hardcore tool, and does gain a lot from
| being implemented as a web app. Another example might serve
| your point better.
| ZoomZoomZoom wrote:
| Ok, I see my point being not so understandable, after
| all. I didn't mean Figma isn't a hardcore tool, I meant
| that we exclude it because it specifically concerns with
| web technology (being a tool for web design) _and_
| leverages web to implement collaborative usage. So it 's
| probably logical for it to be a web app.
| blehn wrote:
| You're still way off. It's not a "web" design tool; it's
| a visual design and prototyping tool. Folks are designing
| a lot more than websites and web apps with Figma.
| CharlesW wrote:
| > _So it 's probably logical for it to be a web app._
|
| Ah, gotcha. Although I'd have assumed that Figma is used
| more to design native apps that web apps, this helps me
| understand where you're coming from.
| burke wrote:
| As an Electron hater, I'm constantly surprised at just how much
| VS Code doesn't suck.
| api wrote:
| It doesn't suck, but try Jetbrains IDEs. C++ and other "not
| JS" language support is vastly superior including refactoring
| that actually works.
| nwatson wrote:
| Jetbrains IDEs (and others for that matter) provide so much
| more than the glorified text-editors, including extensive
| debugging support (both in my own code, library code,
| platform code), code-autocompletion, code navigation, code-
| formatting, refactoring, linting, static-analysis (works
| well for Python as well), great syntax highlighting, spell-
| check, a good plugin ecosystem. I'd never go back to
| editing code without that support.
|
| The Jetbrains ecosystem is real cheap too, I pay
| US$160/year for the personal-license all-product suite I
| can install and use anywhere ... and I use PyCharm
| (Python), IntelliJ IDEA (Java et al), and Datagrip (DB)
| extensively, dipping into CLion (C++/Rust) as well ... but
| they have IDEs for many other languages and ecosystems as
| well. It's definitely a good deal.
|
| Jetbrains suite, along with Docker, Atlassian SourceTree,
| and Homebrew (and connection to AWS/Kubernetes) are my main
| tools these days.
| Groxx wrote:
| I keep periodically re-trying VSCode, but holy cow. It's a
| _massive_ step down from a Jetbrains IDE, in every single
| language I 've dev'd in.
|
| Jetbrains stuff _works_ , VSCode _mostly handles the basics
| if it 's possible to configure it correctly_. Which is
| quite the achievement, and it's a very reasonable option
| and far better than much that came before it. But it's not
| where I want to spend my time if I can avoid it.
| ninjakeyboard wrote:
| You're working with statically typed compiled languages
| tho. Once you try using a dynamic language you realize
| another editor is enough IMO. I use emacs for anything
| dynamically typed (including compiled languages like
| elixir) and intellij for scala/java.
| thrower123 wrote:
| Webstorm or PyCharm isn't as good as IntelliJ or
| ReSharper, but holy hell is it better than just a text
| editor, even emacs.
|
| I really don't understand why so many programmers proudly
| proclaim that they do things the hard way and wear that
| as a badge of honor.
| Groxx wrote:
| It's miles better on Python and _most_ javascript that I
| 've touched (VSCode's ecosystem does tend to have more
| breadth, and if you're working on something that VSCode
| has plugins for but Intellij does not, yea - VSCode can
| be noticeably better for most purposes). Most commonly
| around stuff that requires better understanding of the
| structure of the language / project, like refactoring and
| accurately finding usages.
|
| But yes, for many dynamic languages a fat IDE is less
| beneficial, especially for small-ish projects (anything
| where you can really "know" the whole system).
| FpUser wrote:
| Same here. I am all native guy, including back end C++
| servers but VS code is very decent. But then again I think
| the level of developers who did the main task is way above
| the average. And MS itself wrote that they worked super hard
| to optimize it for memory and performance. Something that
| regular developer usually ignores / does not really know how
| to do due to their lack of understanding how lower level tech
| works.
| 2muchcoffeeman wrote:
| VSCode is Electron? I had no idea. That's the only electron
| app I use willingly then! Good job MS!
| ZoomZoomZoom wrote:
| The reason for this, I think, is developers of VS Code really
| understand the problem field in this case, as they are making
| the tool for themselves.
|
| Also, there's probably a ton of resources involved.
| mmmeff wrote:
| Interesting past thread on Atom's performance struggles and
| how they got outplayed by the VSCode team:
| https://news.ycombinator.com/item?id=14140421
| heywire wrote:
| I love vs code, and its plugin system, but if I'm on my
| laptop without a charger, I use something else. When I'm
| running vs code, my battery life is cut nearly in half.
| noahtallen wrote:
| What do you use instead? In my experience, normal IDEs
| (Android Studio, Xcode, Visual Studio) all perform worse
| than VS Code in terms of memory use and battery. :/
| PopeDotNinja wrote:
| My personal evolution has gone from Sublime Text 3 to Atom to
| VS Code to Sublime Text 3. I've never been a heavy plugin
| user, mainly sticking to code highlighting. The thing I
| really like is speed. Sublime Text rarely chokes on me. I
| love being able to type `cat some_one_gigabyte_file | subl`
| and getting it to open up with little difficulty. VS Code
| chokes on files of non-trivial size, and that was the thing I
| liked about it the least.
|
| For anyone wondering why I'd open up a 1 GB file in a text
| editor, I guess the answer is largely because it's
| convenient. Big log file? No problem. Huge CSV? No problem.
| Complete list of AWS pricing for every product in every
| region stored as JSON? No problem.
| fartcannon wrote:
| Vim handles large csv files pretty good, as well.
|
| Not saying you should use it, just something that I found
| out years ago.
| PopeDotNinja wrote:
| I've tried pure text editors, but they haven't really
| grabbed me, and my fingers are quite clumsy.
| whowhatwhy wrote:
| i just use less for big files, convenience is a matter of
| taste
| xwdv wrote:
| I don't open big files at all. There's no point. Files
| exist as data made to be transformed from one form to
| another. It is only worth looking at a file in its final
| form unless you are making some kind of edit.
|
| And even then, I make edits on large files through a
| series of commands, never opening the file.
|
| By thinking of files in this way, it becomes easy to
| create programmable tool chains for manipulation.
| whowhatwhy wrote:
| not everybody uses a computer for the same exact thing
| you use a computer for
| xwdv wrote:
| Of course, if they did there would be no point in making
| my comment, it would be redundant.
| abbadadda wrote:
| I think the issue with your original comment is with
| "there's no point," which is in effect invalidating the
| opinion of others.
| tomxor wrote:
| I'm an atom user, and it chokes for the very same reason.
|
| However I also use vim for tweaking server side stuff, and
| use less by default whenever I want to read something (logs
| is an obvious one)...
|
| This is both for speed but also UX, i believe vim style
| navigation (which less basically gives you), is great for
| reading and searching - what I cannot stand though is doing
| more than small edits in vim, for development (and i mean
| code is flying around like crazy stage of development, not
| read for 1 hour and make tweaks), then I am fastest with
| the kind of flexibility atom provides.
|
| I know it can be tempting to have one tool for everything
| when it seems like the tools are supposed to be doing the
| same thing, but in my mind lean text editors tend not to
| compete with the big fat slow electron style editors - so
| just use them both, for their respective strengths.
| PopeDotNinja wrote:
| I hear you on the value a text editor on the server side.
| I have picked up the basics of vi for this use case, but
| I ain't fast with it :)
| madhadron wrote:
| VSCode uses a C++ backend to get that performance.
| zingplex wrote:
| I think you're confusing Atom and VS Code.
| robinduckett wrote:
| VSCode uses the same c++ based regex parser for syntax
| highlighting as TextMate, Sublime, Atom, etc
| karlding wrote:
| For anyone interested, this is the Oniguruma [0] regex
| library written by K. Kosako. It's also used in Ruby and
| PHP.
|
| [0] https://github.com/kkos/oniguruma
| fermentation wrote:
| Yes, Chromium.
| user_50123890 wrote:
| Don't care, i'll take a good web app over a shitty native app any
| day.
|
| Since native apps take much longer to develop and the UI toolkits
| are stuck in the 90s, it's pretty much given nowadays that new
| ones are shitty compared to the equivalent web one.
| smabie wrote:
| But like, do they. Personally, I've found using a high level
| native UI API (like Racket's) to be _much_ easier than a
| webapp. More flexible and performant too.
|
| Personally, I hope that web browsers die off and we go back to
| gopher for displaying information. I hate the web.
| kleiba wrote:
| Please take a look at actual screenshots from the 90's to
| quickly disprove your assessment.
|
| The only other argument you mention is that native apps take
| much longer to develop, and that from that somehow follow that
| they are "shitty". I'm not even convinced the premise is
| correct, but I certainly don't see why longer development times
| would imply worse outcomes...
|
| Intuitively, I would assume the opposite: something that is put
| together all too quickly should have a higher potential for
| being half-baked.
|
| I'm not criticizing your preference, I just don't buy the
| arguments.
| iphone_elegance wrote:
| Personally I feel like webapps are really holding us back but
| to each their own
| implicit wrote:
| If you are going to expect me to run your software in an always-
| on manner, I would greatly appreciate a native application.
|
| I frequently do light computing on a Surface Go. It's a
| delightful little device and I love it, but it is not powerful
| enough that I can leave gmail, Slack, and Discord open all the
| time.
|
| I don't have enough RAM to run another web application but I
| could very easily afford a native app or two.
| pmlnr wrote:
| There's a pidgin plugin for discord. While pidgin is dated and
| has issues, the existence of it shows that even modern chat
| systems could be made fast.
|
| https://github.com/EionRobb/purple-discord
| znpy wrote:
| I have an old ThinkPad X200s that I turn on from time to time.
| I keep a fedora installed and updated just in case, and since
| I'm there, i also sync my nextcloud stuff.
|
| E-mails using claws-mail are not a problem. It generally runs
| fast enough until I open firefox and web stuff in general.
| squarefoot wrote:
| Claws Mail on an old Atom is a lot faster than webmail on
| pretty much anything else. This probably illustrates best the
| difference between the two approaches.
| pmlnr wrote:
| I remember times when webmail basically meant squirrel
| mail. It was fast over an 56k modem, but desktop was always
| better.
|
| http://www.squirrelmail.org/
| analog31 wrote:
| Indeed, I asked on another HN thread, why do you developers
| need so much RAM, and I got lots of good answers. But it occurs
| to me that a few lightweight, quick-starting apps will help me
| stave off the day when I have to get a new PC because my old
| one ran out of juice.
|
| I'm not sure that's enough of a reason to develop a commercial
| app, because tightwads like me also like our stuff to be free.
| johnchristopher wrote:
| There's still a place. But not for reinventing wheels and half
| bake a new take on a "solved" problem (mail reader, music player,
| personal task manager, etc.).
| mrkramer wrote:
| Wasn't Steve Jobs' idea to have Web Apps for Iphone but Iphone
| team talked him into native apps for various reasons such as
| performance and security and he finally gave in.
|
| I would assume the same for desktop versus web apps but as time
| goes on I think web apps will prevail.
| prepend wrote:
| Apple always had native apps. Jobs said web only for third
| party apps in the first release.
|
| Jailbreak App Store came out and lots of third party apps, then
| Apple opened up.
| zadjii wrote:
| I mean, we built the Windows Terminal as a native application
| because we didn't want users to have to be saddled with 40MB of a
| webview/Electron just to boot up a terminal. It might take us
| longer to make the terminal as feature rich than it would have
| with JS, but no amount of engineering resources could have
| optimized out that web footprint. When we think about what the
| terminal looks like in 5 years, that's what we were thinking
| about.
| jfkebwjsbx wrote:
| I don't use Windows, but thank you for having gone for it.
| bhauer wrote:
| Thank you. As you say, in the long haul, Windows Terminal is
| considerably better than it would have been thanks to that
| decision. It _feels_ responsive and lightweight; unlike any
| Electron app, and that is greatly appreciated by many users,
| myself included. I look forward to each new version.
| sebazzz wrote:
| Didn't they eventually did some crazy optimizations to keep
| the terminal in VS Code performant?
| Cthulhu_ wrote:
| They still do; for years now I read the patch notes and
| every time there's a segment dedicated to the terminal with
| things like font support or sane selection, things that IMO
| are both basic features and which should be in native
| terminal emulators already.
|
| also I've never used the VS Code terminal, iterm works
| better for me. Also because it's its own dedicated app, so
| I can actually alt-tab to it instead of having to learn
| whatever shortcut it would be in the editor.
| dmitrybrant wrote:
| I specialize in data recovery / digital forensics tools, which
| require very low-level disk access to be able to read physical
| media at the block level. I doubt there will ever be an HTML5
| standard for low-level disk access.
|
| But aside from my particular specialty, I also prefer any other
| software I use to be fully native. I'm surprised that's such a
| controversial thing to ask for these days. All I ask is so
| precious little:
|
| * I want the software I use to be designed to run on the CPU that
| I own!
|
| * I want software that doesn't require me to upgrade my laptop
| every two years because of how inefficient it gets with every
| iteration.
|
| * I want software that isn't laughably bloated. I think we have a
| real problem when we don't bat an eye upon seeing the most
| rudimentary apps requiring 200+ MB of space.
| marclave wrote:
| Have you looked into webassembly and how browsers give access
| to filesystems[1], there could be hope for a future of high
| performant filesystem access.
|
| [1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystem
| floo wrote:
| From the linked article:
|
| _This interface will not grant you access to the users
| filesystem. Instead you will have a "virtual drive" within
| the browser sandbox. If you want to gain access to the users
| filesystem you need to invoke the user by eg. installing a
| Chrome extension. The relevant Chrome API can be found here._
| kokizzu wrote:
| that's not low level disk access
| whb07 wrote:
| Can you explain how it isn't?
| jfkebwjsbx wrote:
| If you are accessing the file system, you are accessing
| an abstraction, not the actual disk data (which is
| another abstraction on top of the actual hardware).
| kccqzy wrote:
| Does it give you access to /dev/disk0 (or /dev/nvme0, or
| /dev/sda0, or /dev/rdisk0 etc)? If not, no.
| umvi wrote:
| I remember hanging out in /r/Unity3d and some newbie posted a
| download for their completed game. It was super basic - just a
| game where you move a cube around a grid, but the size of the
| game was insane, like half a gig.
|
| The dev who posted it seemed perplexed when people told him the
| game was 100x bigger than it should be.
| peteforde wrote:
| I hope that you did the kind thing and showed them how to
| adjust what gets compiled into their package, depending on
| whether they are targeting a development or production build.
|
| Nothing worse than people who mock beginners showing their
| first work. We were all there, once.
| DangitBobby wrote:
| He was probably expecting useful feedback or even praise.
| room505 wrote:
| CAD and BIM
| samstave wrote:
| Exactly what I came to say.
|
| As someone who has used Autocad since Ver 9 (1993) this is
| important.
|
| Also - heavy 3D design. Blender/Alias/whatever these days.
|
| Solidworks as well.
| preommr wrote:
| webgl and wasm?
|
| Edit: I presumed that the context of the discussion was apps in
| a general sense. Obviously not every application is going to be
| on the web and there are a lot of niche software that will
| never make the switch. I was thinking more qucad or sketch 3d
| for woodworkers to plan their desks, not solidworks and all its
| plugins to handle complex fluid simulation in mission critical
| areas.
| kroltan wrote:
| Still wishful thinking at this point.
| TomMarius wrote:
| Do you know OnShape?
| etimberg wrote:
| I worked in the EDA space for a while and even built an
| online circuit simulation tool [0] while there. I'm aware of
| couple of startups such as [1] that tried to move these tools
| to the browser. There are a number of challenges that make
| web apps difficult in this space such as"
|
| 1. Pricing model: For the simulation side of EDA, you need a
| lot of computing power. With desktop apps, the user already
| has a powerful machine available that you don't have to pay
| to use. With the cloud, you need to pay for all the machines
| so finding a pricing model that works is a challenge.
|
| 2. User expectations: The users who are willing to pay >
| $100k/seat/year expect very advanced features that would
| probably take 10s or 100s of engineering years to get
| working. These users also don't care as much about the UI/UX
| problems that a modern app would solve.
|
| References
|
| 0. https://www.multisim.com/
|
| 1. https://upverter.com/
| throwaway9087 wrote:
| We've had some success with 2D AutoCAD on WASM, but it's not
| as easy as just recompiling when you are dealing with a
| nearly 40 year old codebase and care about pixel level
| accuracy. Also, it will never be as responsive as native,
| mouse events lag on the browser even if you are doing nothing
| else. AutoCAD users care a lot about such lag.
|
| The BIM stuff (i.e. Revit) is very Windows-specific so a
| straight port with WASM is a no-starter.
|
| The actual 3D rendering with WebGL is the least problem, we
| have that nearly solved (in terms of performance relative to
| desktop -- we never really needed 60fps anyway). The problem
| there comes in when you have a huge design that does not fit
| in the allocated/allowed heap space.
|
| (throwaway for obvious reasons)
| moeamaya wrote:
| The new Autocad web app is pretty impressive. Feels native even
| with large CAD files:
| https://www.autodesk.com/products/autocad-web-app/overview
| flarg wrote:
| IMHO native applications represent a valuable class of niche
| software tools that deliver very highly specialised functionality
| in concert with desktop software. Add ons for MSProject and Excel
| abound and there really isn't an equivalent for online tools or
| indeed a viable or stable market.
| gwbas1c wrote:
| The big advantage of web applications is that they don't have an
| installer, and they don't need to deal with pushing updates.
|
| Many comments here explain the advantages of full desktop
| applications. (And there are many.)
|
| The thing to always keep in mind is, does your application
| justify an installer? There's so many tiny utilities that run in
| a browser that I can find with Google. These are utilities that I
| probably use once a year and don't care to install.
|
| But if I use the application heavily, I want a desktop
| application even if it's just an application specific browser.
| jacobcritch wrote:
| Native apps are totally necessary. Why abstract everything to the
| browser?
| htk wrote:
| I would say it depends on complexity. Either algorithmic or UI
| complexity. Web apps just aren't as efficient as Desktop apps,
| and at this moment this is still relevant in various cases,
| probably in many less in the future.
| hootbootscoot wrote:
| Of course!
|
| I would rather reverse the question: In which situations is it
| acceptable to use Electron, for example? Something like Balena
| Etcher makes sense, but Logic Audio not so much.
|
| Don't let hype and popularity on HN (not to mention market share
| of JS as pertains to the amount of web front-end work vs desktop
| work) serve as a surrogate for noting actual performance given a
| specific application.
|
| Wrap-a-browser approaches and bloaty non-native frameworks are
| good for configuration ware, and things that don't need to engage
| in high amounts of real time processing saturating the CPU and
| RAM.
|
| Many applications continue to squeeze required performance out of
| each platform. Cross platform approaches can serve just fine if
| there are zero-cost abstractions.
|
| Audio/Video/3D/Image production software, for example. CAD, not
| to mention developers tools and compilers, just for the tip of
| the iceberg.
| gfxgirl wrote:
| It really depends on the app.
|
| A 3d modeling package? Although Clara.io exists most of the time
| I'm dealing with 100s of megs of data so native wins. Creating a
| game? Mostly same though I can imagine some limited online game
| creation tool even the small sample 3D platformer for unity is
| 3gigs of assets so a game editor native seems to win. Photo
| editing, when I get home from vacation there's 100gig of photos
| so native wins for me. Video editing same thing.
|
| On the other hand there are apps I have zero interesting in being
| native. WhatsApp, Line, Slack, Facebook, Office, Email, Discord,
| etc. I'm 100% happy with them in a browser tab. Native apps can
| spy on way more than browser apps (maybe less on Mac). They can
| install keyloggers, root kits, scan my network, read all or most
| of my files, use my camera, mic, etc.
|
| I also use 7 machines regularly. Being able to go to any one and
| access my stuff is way more convenient than whatever minor
| features a native app would provide.
| znpy wrote:
| Native desktop apps already are one of those fields that very few
| people can master. Such niche will probably become super
| lucrative in the upcoming years.
| madhadron wrote:
| They're not that hard. They're just unfamiliar to Unix command
| line users. A lot of people managed to write desktop apps in
| Delphi, Cocoa, and Win32 for many years.
| lucis wrote:
| You might wanna check Oni2 [1]
|
| [1] https://github.com/onivim/oni2
| blargmaster33 wrote:
| Every time I work on our WPF app at work I get reminded what a
| fucking joke HTML/CSS/JS is. It's worse in every conceivable way.
| intrepidhero wrote:
| The lines between the two have been slowly blurring for some time
| now. My crystal ball says that will continue as the need for
| cross platform support, especially desktop versus mobile, gets
| bigger. I think we'll see more and more emphasis on 3rd party VM
| type frameworks, like JVM, unity, and electron. However with
| Moore's law reaching an asymptote I believe that writing for
| performance will also become more and more important. I think
| these forces will result in a high demand for the skills needed
| to improve performance on all types of apps.
|
| What I'm hoping for is a pendulum reaction to the recent trends
| of UX design, where we see a renaissance in really solid
| interfaces that focus on discovery and speed. But I'm not seeing
| signs of that yet.
| peignoir wrote:
| Anything relying on DLTs has to be on desktop
| fbelzile wrote:
| I make a living developing software only available on Windows and
| macOS. That said, if I didn't need to interact so much with the
| operating system, I'd be making a web app. It all depends on what
| you want to make though. Video editing software? Native app. CRUD
| app? Web app.
|
| You may also want to consider pricing implications of both.
| Desktop software can usually be sold for a higher up front cost,
| but it's tough sell to make it subscription based. SaaS would
| make your life a lot easier if you have a webapp. People are
| starting to get used to paying monthly for a service anyway.
|
| Pro tip: If you decide to make a native app, don't use Electron.
| Instead, use the built-in WebBrowser/WKWebView components
| included in .NET and macOS. Create the UI once using whatever web
| framework you want, and code the main app logic in C#/Swift.
| Although the WebBrowser control kind of sucks right now,
| Microsoft is planning on releasing WebBrowser2 which will use
| Blink. I think they might also have it where the libraries are
| shared between all apps using it, to further reduce bloat. The
| old WebBrowser component can be configured to use the latest Edge
| rendering though by adding in some registry keys or adding this
| meta tag:
|
| <meta http-equiv="x-ua-compatible" content="ie=edge">
| OkGoDoIt wrote:
| I understand the concept of making a native app to include
| using the native UI platforms. What you described is hardly
| more native than electron, which is basically a web app at
| heart.
|
| Or maybe there needs to be a consensus on terms. Do people
| consider electron apps to be native? I would put them in some
| weird middle ground, but definitely closer to web technologies
| than native development.
| neurostimulant wrote:
| The main complain about electron app is due to their bundling
| of complete web browser runtime, which is over a hundred of
| MB, not to mention the big memory requirements. By using
| platform's built-in webview component, your app size will
| hardly any bigger than the total size of the zipped
| html+js+css of your app. If you're going to use web stack to
| develop your desktop app anyway, might as well try using
| native ui webview first if you don't need any electron-
| specific feature.
| arithma wrote:
| From a capabilities point of view, they're native. You can
| access the OS api just like any other native app.
|
| From a developer side, it looks like developing a webapp
| without the usual limitations of API access, albeit at an
| extra cost of marshaling or build-complexity.
|
| There really is no reason to think of HTML/CSS/JS as Web only
| though.
| enos_feedler wrote:
| With Electron, it feels more like starting from web and
| making it behave like a native app, from the standpoint of
| operating system app handling (task bar, notification). It
| can also fill a gap left by web for exposing a filesystem and
| other things that are native to some abstract computer.
|
| Using WKWebView for UI is different in that you are starting
| from a native app and using web technologies to leverage code
| sharing and programming model of the user interface (js, css,
| html).
|
| I think for this view to make sense you have to see web apps
| and native apps as fundamentally different things, which I
| believe they are.
| antaviana wrote:
| We sell our B2B desktop software as a subscription since 2012
| (previously it was freeware).
|
| The key is to make it only available as a subscription (no
| permanent licenses) and it does not have any cloud component.
|
| We managed not to fall in the trap of making two types of
| licenses (suscription or permanent) to maximize early revenue
| (we could affort to wait).
|
| We seek a marriage relationship with our users not a hook up.
|
| This increases the value our users extract knowing it will not
| go away in the long term and the lifetime value of customers is
| a lot higher.
|
| We know that some customers will not accept a subscription-only
| desktop application but in B2B world they are fewer than it
| might seem.
| doteka wrote:
| For a personal project I am currently using this approach and
| can confirm it works great.
|
| I wrote just enough PyObjC to get myself a trayicon in the Mac
| menu bar, which shows a popover containing a wkwebview to
| localhost. Then I have all the app logic in Python, exposed to
| the webview through a bottle server, and Svelte for the UI.
| Highly recommended.
| CameronNemo wrote:
| Do you distribute Python with your application too then? How
| well does that work?
| dvdhnt wrote:
| > Pro tip: If you decide to make a native app, don't use
| Electron. Instead, use the built-in WebBrowser/WKWebView
| components included in .NET and macOS. Create the UI once using
| whatever web framework you want, and code the main app logic in
| C#/Swift. Although the WebBrowser control kind of sucks right
| now, Microsoft is planning on releasing WebBrowser2 which will
| use Blink. I think they might also have it where the libraries
| are shared between all apps using it, to further reduce bloat.
| The old WebBrowser component can be configured to use the
| latest Edge rendering though by adding in some registry keys or
| adding this meta tag: > > > <meta http-equiv="x-ua-compatible"
| content="ie=edge">
|
| Great to know, thank you.
| spenvo wrote:
| Native apps can take advantage of OS APIs that are much richer
| than those via the browser (or Electron) pass-through APIs.
|
| For example, I've made a Mac app that lets you customize your
| Spaces (virtual desktops), assign names to them, jump to specific
| ones, track your time spent across them, and trigger custom
| events when you move to specific ones. None of this would be
| possible via a web app or electron app. Project homepage
| https://www.currentkey.com, app link:
| https://apps.apple.com/app/apple-store/id1456226992?pt=11998...
|
| And as long as there is differentiated hardware between
| platforms, there will be opportunities for innovative native
| apps. For example, though I personally don't love the Touch Bar,
| there are interesting native app projects around that like Pock:
| https://github.com/pigigaldi/Pock
| ahmedbaracat wrote:
| Checking your app, sounds very useful :) Thanks for building it
| spenvo wrote:
| Enjoy! And thanks for the kind words
| ahmedbaracat wrote:
| I am constantly annoyed by the web apps, not only because they
| consume so much resources, but because of the noticeable UI lag
| that drives me crazy. For example, I have been entertaining the
| idea recently of building a native Todo app for macOS because of
| how slow Todoist has become in the past few years.
| nikivi wrote:
| I'd check https://www.2doapp.com
|
| It's super fast and featureful
| dirtylowprofile wrote:
| I mean look at Telegram. I wonder why big companies can't follow
| with all them dollars.
| [deleted]
| JKCalhoun wrote:
| No internet? No web-app.
|
| I suppose I am increasingly frustrated with the inability to use
| my computer if it has no internet....
| alasdair_ wrote:
| >No internet? No web-app.
|
| I've seen lots of tools that spin up a local webserver and then
| use that to serve the webapp even offline. But then the
| question becomes is this really a webapp if I have to install a
| native server?
| ZoomZoomZoom wrote:
| Truly, that old quote about "computer engineering concerning
| with solving problems that didn't exist before computers"
| gets less funny every year.
| chrismorgan wrote:
| This needn't be true. You can use a service worker to make the
| code load when offline, and IndexedDB to store data.
|
| As a trivial example, https://jakearchibald.github.io/svgomg/
| (which has no data storage requirements) works just fine
| offline.
|
| Offline support is a banner feature of the PWA (progressive web
| apps) movement.
| inetknght wrote:
| Service workers are an antipattern. I don't want to visit a
| website and have it install something that runs in the
| background.
|
| If you, as a website owner, want me to run an application
| then you should ask for permissions. No ifs, no buts, no ors.
| ken wrote:
| I was excited to see how this worked, so I visited the page,
| clicked around to see what it did, disconnected from my
| network, and tried opening the page again in a new window. I
| got the usual browser error page: "You Are Not Connected to
| the Internet". So I connected to the network, loaded the
| page, _then_ disconnected from my network, clicked the Demo
| button, and got: "Couldn't fetch demo SVG".
|
| So by trial and error, I found that I need to load the page
| before disconnecting, and only use the 1st of the 5 buttons
| on the side (even "About" requires network connectivity).
| Then it works offline. Which is pretty cool!
|
| But _every_ native application I have works perfectly
| offline, and I don 't need to do anything special ahead of
| time, or worry about which parts might not be available.
| There's a big difference between "some parts may work offline
| sometimes" and "entire app will definitely work offline
| always".
|
| From decades of experience, when a "trivial" app struggles
| with demoing a feature, there's little chance it'll be widely
| supported among real apps. PWAs have been "any day now!" for
| 10 years now.
| chrismorgan wrote:
| Sounds like the service worker didn't register for you.
|
| The logic that decides whether the browser accepts service
| workers is a little bit iffy. My vague recollection is that
| browsers default to something like "when you access the
| site for the second time, keep the service worker". (Don't
| quote me on that, and if anyone knows better, please
| correct me.) "Add this to your home screen" functionality
| will definitely make the service worker go. (That's mostly
| for mobile browsers only at this time, though desktop
| browsers will _eventually_ get it consistently available,
| as we've been promised for... hmm, about 8+-2 years, I
| think.)
|
| Privacy and blocking extensions may block service workers
| from being registered, too.
|
| If the service worker is loaded, then it loads just fine
| with no internet connection, and the demo works too. The
| contribute and about links, being to GitHub, still don't
| work.
|
| I first actually discovered this completely by accident: I
| was offline, and thought "I need to shrink this SVG file,
| so I'll open a tab to the SVGOMG URL and that error page
| will remind me to do it when I reconnect; huh, it _loaded_
| , must have a service worker. This is _really great_." On
| later reflection, I realised that it being by Jake
| Archibald (a big mover in the service worker space) pretty
| much guaranteed it was going to work offline.
| feifan wrote:
| Finda's architecture[0] is great for this discussion.
|
| On the one hand, you can say "look, an Electron app that's
| actually fast!"
|
| On the other hand, you can say "wow web apps are slow; it takes
| ~50x longer to render a basic list than to regex search across
| tens of thousands of strings".
|
| From a performance perspective, the JS part of the stack
| certainly isn't helping.
|
| 0: https://keminglabs.com/blog/building-a-fast-electron-app-
| wit...
| prepend wrote:
| I run a native desktop app called Moneydance. Syncs files,
| encrypted, to dropbox, and everything runs locally on whatever
| machine runs Moneydance.
|
| I use this because I don't like the idea of financial account
| info being stored by a third party has has no liability for
| breach. And also because I have over 10 years of transactions in
| the ledger and running this remote can take a long time. I'm not
| even sure if there are any services that store for 10 years and
| let you do text searches.
| [deleted]
| jrockway wrote:
| Native desktop apps are great.
|
| The reason that people don't write them is because users aren't
| on "the desktop". "The desktop" is split between OS X and
| Windows, and your Windows-app-compiled-for-Mac is going to annoy
| Mac users and your Mac-app-compiled-for-Windows is going to annoy
| Windows users. Then you realize that most users of computing
| devices actually just use their phone for everything, and your
| desktop app can't run on those. Then you realize that phones are
| split between Android and iOS, and there is the same problem
| there -- Android users won't like your iOS UI, and iOS users
| won't like your Android UI. Then there are tablets.
|
| Meanwhile, your web app may not be as good as native apps, but at
| least you don't have to write it 6 times.
| fartcannon wrote:
| And therefore, beware any OS attempts to break cross platform
| browser compatibility.
|
| Also I think you can deploy to all those things with Qt.
| camccar wrote:
| And pay QT like 5,000 $ a year to keep it closed source. No
| thank you. Would rather write it 6 times. Or just use
| electron.
| Narishma wrote:
| AFAIK you only have to pay if you modify Qt itself and
| don't want to release those changes.
| roblabla wrote:
| Qt is LGPL licensed is it not? LGPL license means you can
| distribute your app closed source, so long as the user can
| swap out the Qt implementation. This usually just means
| dynamic linking against Qt so the user can swap the DLL.
| The rest of your app can be kept closed source.
|
| On iOS and Android the situation might be a bit more
| complicated, but this discussion[0] seems to say that
| dynamically linking would also work there.
|
| [0]: https://wiki.qt.io/Licensing-talk-about-mobile-
| platforms
| detaro wrote:
| Qt is mostly LGPL. It's really not that hard to comply with
| that on desktop, and doesn't require you opening your
| source code.
| api wrote:
| Qt doesn't require that but even if it did writing it 6
| times is vastly more expensive. People would just rather
| spend 500k on writing it 6 times than 5k on a license
| because they are somehow offended at the notion of paying
| for dev software or tooling.
|
| It's a major reason UI coding sucks. There is no incentive
| for anyone to make it not suck, and the work required to
| build a modern UI library and tooling is far beyond what
| hobbyist or spare time coders could ever attempt.
| modzu wrote:
| u forgot linux. :(
| jrockway wrote:
| I started using Linux in the late 90s and have since lost all
| expectation of someone writing an app for it.
| CamperBob2 wrote:
| _Windows-app-compiled-for-Mac is going to annoy Mac users_
|
| And they'll let you know it, too. Unfortunately this has been
| an issue since the first Macs left the assembly line in 1984.
| If you point out that based on their share of the software
| market they're lucky they get anything at all, the conversation
| usually goes south from there.
| jcelerier wrote:
| > Meanwhile, your web app may not be as good as native apps,
| but at least you don't have to write it 6 times.
|
| I must be living in a parallel world because I use a ton of
| desktop apps that aren't "written 6 times" - and write a few,
| including a music & other things sequencer (https://ossia.io).
|
| Just amongst the ones running on my desktop right now,
| Strawberry (Qt), Firefox (their own toolkit), QtCreator (Qt),
| Telegram Desktop (Qt), Bitwig Studio (Java), Kate (Qt), Ripcord
| (Qt), all work on all desktop platforms with a single codebase.
| I also often use Zim (GTK), which is also available on all
| platforms, occasionnally Krita (Qt) and GIMP (GTK), and
| somewhat rarely Blender. Not an HTML DOM in sight (except FF
| :-)).
| guggle wrote:
| Bitwig has been ported to Android ? Or IOS ?
| jcelerier wrote:
| I don't think it makes sense to use it on even small
| laptops screen to be honest so I don't really see the
| point. You'd have to redo the UI and whole paradigm
| entirely anyways for it to be meaningful on small devices.
| But there is certainly not any obstacle to porting - from
| my own experience with ossia & Qt, it is fairly easy to
| make iOS and Android builds, the difficulty is in finding a
| proper iOS and Android UX.
|
| In particular C++ code works on every machine that can
| drive a screen without too much trouble - if the app is
| built in C++ you can at least make the code run on the
| device... just have to make something pretty out of it
| afterwards.
| guggle wrote:
| The point is that the parent poster mentioned tablets and
| phones which you don't address in your point. Of course
| your examples aren't written 6 times, but they support
| fewer platforms too (only desktop).
|
| Off-topic, but regarding Bitwig: of course it makes
| perfect sense to use it on smaller devices. Not phones,
| but tablets. It's even officially supported with a
| specific display profile in your user interface settings
| (obvious target amongst others: windows surface). This is
| particularly useful for musicians on stage.
| nitrogen wrote:
| Ossia looks pretty sweet! I'll be checking that out for sure.
| avmich wrote:
| Do you count Qt apps as native, but not count web apps as
| native? Why?
| AsyncAwait wrote:
| Qt may not 'look' native, but it has native performance,
| whereas Electron really doesn't.
| thawaway1837 wrote:
| Isn't that more of an Electron issue?
|
| I mean, is anyone clamouring for VS Code, for example, to
| be rewritten in native toolkits?
| jcelerier wrote:
| a few reasons :
|
| - Qt is actually the native toolkit of multiple operating
| systems (Jolla for instance and KDE Plasma) - you just need
| to have a Linux kernel running and it handles the rest. It
| also does the effort of going to look for the user theme
| for widgets to mix in with the rest of the platform, while
| web apps completely disregard that.
|
| - Windows has at least 4 different UI toolkits now which
| all render kinda differently (win32, winforms, wpf, the
| upcoming winui, whatever is using Office) - only Win32 is
| the native one in the original sense of the term (that is,
| rendering of some stuff was originally done in-kernel for
| more performance). So it does not really matter on that
| platform I believe. Mac sure is more consistent, but even
| then ... most of the apps I use on a mac aren't cocoa apps.
|
| - The useful distinction for me (more than native and non-
| native) is, if you handle a mouse event, how many layers of
| deciphering and translation has it to go through, and are
| these layers in native code (eg. compiled to asm). As it
| reliably means that user interaction will have much less
| latency than if you have to go through interpreted code,
| GC, ...
|
| Of course you can make Qt look deliberately non-native if
| you want, but by default it tries its best - see https://co
| de.woboq.org/qt5/qtbase/src/plugins/platforms/coco... and
| code such as https://code.woboq.org/qt5/qtbase/src/plugins/
| platforms/wind...
| ninjakeyboard wrote:
| I still can't believe bitwig is java. I'm a bitwig user. It
| even runs on linux.
| hawaiianbrah wrote:
| Wasn't that Java's original selling point, it runs anywhere
| (there's a JVM)?
| ubercow13 wrote:
| Only part of it will be Java, probably the UI logic layer
| IvanK_net wrote:
| I think he did not mean "written 6 times", but more like
| Compiled 6 times, with 6 different sets of parameters, and
| having to be tested on 6 different devices.
| PaulDavisThe1st wrote:
| Because you _NEVER_ have to do that with browsers, right?
| theshetty wrote:
| Many desktop apps these days seems to be built on Electron, a
| JS framework for building desktop-class apps.
|
| https://www.electronjs.org/
| ebj73 wrote:
| I think this has changed. People used to be very particular
| about how their apps looked on different native platforms, like
| you say. But I don't think it's like that anymore. People are
| more agnostic now, when it comes to how user interfaces look,
| because they've seen it all. Especially on the web, where
| there's really no rules, and where each new site and web app
| looks different. I believe this also carries over to native
| apps, and I think there's much more leeway now, for a user
| interface to look different from the native style, as long as
| it adheres to any of the general well established abstract
| principles for how user interface elements ought to behave.
| thrower123 wrote:
| Targeting Windows alone gets you 90% of the desktop market. 95%
| if you make it run reasonably in Wine. This argument is often
| used, but it's an excuse.
|
| Anything that you need to run on a desktop can't be used
| effectively on a touch screen anyway, so phones and tablets
| don't really count for serious software. (Writing this comment
| is stretching the bounds of what I can reasonably do on an
| IPhone).
| tpush wrote:
| Concerning the desktop, I honestly don't see Windows users
| caring much about non-native UIs. Windows apps to this day are
| a hodgepodge of custom UIs. From driver utilities to everyday
| programs, there's little an average Windows user would identify
| as a "Windows UI". And even if, deviations are commonplace and
| accepted.
|
| Linux of course doesn't have any standard toolkit, just two
| dominant ones. There's no real expectation of "looking native"
| here, either.
|
| Which leaves macOS. And even there, the amount of users really
| caring about native UIs are a (loud and very present online)
| minority.
|
| So really, on the Desktop, the only ones holding up true cross-
| platform UIs are a subset of Mac users.
| ahmedfromtunis wrote:
| During my days of Windows-exclusive computing, I wondered
| what people meant by native UIs, and why do they care about
| them. My wondering stopped when I discovered Mac OS and, to a
| lesser extent, Ubuntu (especially in the Unity days).
| Windows, with its lack of visual consistency, looked like a
| hot mess compared to the aforementioned platforms.
|
| And now that I think about it, would this made it easier,
| even by an infinitesimal amount, for malware to fool users,
| as small deviations in UI would fail to stand out?
| pessimizer wrote:
| > And now that I think about it, would this made it easier,
| even by an infinitesimal amount, for malware to fool users,
| as small deviations in UI would fail to stand out?
|
| I don't think that's how fraud works in actuality;
| malicious actors will pay _more_ attention to UI
| consistency than non-malicious actors (who are just trying
| to write a useful program and not trying to sucker anyone),
| inverting that signal.
| nitrogen wrote:
| I don't know, I've read that e.g. spam will not focus on
| grammatical accuracy because they want to exclude anyone
| who pays attention to details. Also most fake Windows UIs
| from malicious websites I used to see weren't exact
| matches of the native UI.
| atombender wrote:
| I don't know exactly what time period you're referring to,
| but back when Java was attempting to take over the desktop
| UI world with Swing, it was painfully obvious when an app
| wasn't native on Windows. Eclipse was the first Java app I
| used that actually felt native, thanks to its use of native
| widgets (through a library called SWT) instead of Swing.
| crazygringo wrote:
| After using Photopea (web) as a virtually full replacement for
| Photoshop (desktop), I'm starting to think that these days, all
| _interfaces and business logic_ should be web-first. JavaScript
| is fast, other languages can compile to it or WebAssembly, and
| HTML+CSS is a lingua franca. Obviously PWA 's are required,
| designed to run offline.
|
| Where brute-force performance is a #1 concern I think it
| diverges. For things like Photoshop filters or rendering,
| WebAssembly _may_ still be fine (it depends). But for real-time
| processing that needs timing guarantees or more direct access to
| hardware (games, DSP, etc.) the code has to be native running in
| dedicated threads. Still, it would be nice if those operated
| essentially as native browser plug-ins that still interfaced with
| a browser environment, rather than a totally separate executable.
|
| I'm seriously ready to let my web browser just be the GUI to my
| operating system. I want my file manager and terminal and system
| preferences just to be tabs next to my Gmail and Docs.
| heyoni wrote:
| Speed in relative terms means that JavaScript in the browser is
| not fast. The language runs on top of just about as many
| abstraction layers as possible and I do not envy this world you
| describe. I wish we'd move away from it.
| crazygringo wrote:
| But it's fast _enough_. JIT compilation means algorithms run
| decently fast, and when it deals with the DOM it 's fast
| _enough_ for everyday interface tasks.
|
| Nobody's saying it's elegant. But it's cross-platform and
| it's a standard that lots of people know. Wishing we move
| away from it seems like a lost battle at this point -- at
| least unless we somehow invent a brand-new computing paradigm
| that replaces browsers, the way browsers have replaced apps
| in many cases. But I can't even imagine what that might ever
| be.
| heyoni wrote:
| It's not though. Not even close. And I know this partially
| a matter of taste but I have one of the fastest computers
| you can buy and I can't even participate in text chats
| without input lag and delays in interaction. It's not a
| good user experience for me at least but that's ok, we'll
| keep stacking more cpu power until it's all in the cloud
| anyways.
| crazygringo wrote:
| That just sounds like server latency to me or some kind
| of bad programming like relying on polling.
|
| Obviously if you build a chat client in the browser and
| communicate between windows then it's instantaneous.
| Faster than human perception.
|
| Certainly doesn't seem to be a CPU issue to me. I mean,
| we run _videochat_ in the browser which works fine.
| Obviously text chat can be instant.
| heyoni wrote:
| I'm talking about the native slack app. I used to use the
| irc gateway and now go back and forth between desktop and
| unofficial gateways. I use keyboard shortcuts to navigate
| between chat windows and nothing about it is
| instantaneous...even when there's nothing but text. Same
| thing applies to discord, and less so with WhatsApp and
| signal. Messages on the other hand is silky smooth, and
| terminal irc couldn't get any faster.
| jfkebwjsbx wrote:
| You run _hardware accelerated_ video, or in some cases
| SIMD hand-tuned native codecs.
|
| That is in the opposite side of where the abstraction
| that the web provides is.
| 40four wrote:
| I've always been on the fence about this. I can see both sides,
| and don't have a strong opinion either way. But answering is
| there still a _place_ for native? I think yes for sure! I guess
| it comes down to if it is really important to your philosophy as
| a developer, or your type of app could really benefit from native
| capabilities.
|
| A good example of a recent app that chose to leverage native
| platforms is Table Plus. They are developing native apps on Mac,
| Windows, and Linux. I respect the effort/skill and dedication
| required to pull this off! https://tableplus.com/
| signaru wrote:
| Modern browsers these days are powerful things... just a
| curiousity, are there non native browsers?
| alasdair_ wrote:
| >Modern browsers these days are powerful things... just a
| curiousity, are there non native browsers?
|
| Sort of. There are browsers written in things like Java
| (HotJava was an old one that was basically a demo app) and so I
| guess anything written in a VM-language could technically be
| considered non-native.
| nodelessness wrote:
| What's a non-native browser?
| mrkramer wrote:
| Any browser that is not running on a host machine then for
| example on Virtual Machine.
| [deleted]
| mongol wrote:
| Perhaps Lynx?
| ilrwbwrkhv wrote:
| Every single app that I use, I try and make sure it is native. I
| shun electron apps at all cost. It's because people who put in
| effort to use the native APIs put in a lot more effort in the app
| in general based on my anecdotal evidence. It is also more
| performant and smaller in size, things that I cherish. It also
| pays homage to limits and striving to come up with new ways of
| overcoming them, which hackers would have to do in the past. I
| don't think not worrying about memory, CPU, etc are not healthy
| in the long run. Slack desktop app is almost 1 gig in size. That
| is crazy to me, no matter the "memory is cheap" mantra.
| airstrike wrote:
| Bonus points if it includes offline documentation. As nice as
| it is to have "updated" online docs, the reality to me seems to
| be defined more by broken links than by actual up-to-date
| documentation.
| egypturnash wrote:
| _Slack desktop app is almost 1 gig in size._
|
| On a whim I just checked how big the copy of Adium still
| lingering in my Mac is: 60 megs.
|
| And Ripcord (a native discord/slack client) is a mere 40.
| DaiPlusPlus wrote:
| And Winamp is 4MB (after removing the stock plugins that I
| don't need, like modern skins and the long-broken media
| library internet lookup stuff).
|
| How big is Spotify now?
| jleahy wrote:
| Spotify is 273MB (on Linux at least), 70MB for the binary
| and 137MB for Chrome, plus some other bits and bobs.
| $ pacman -Qi spotify Name : spotify
| Version : 1:1.1.10.546-4 Description : A
| proprietary music streaming service Architecture :
| x86_64 ... Installed Size : 272.79 MiB
|
| So at least it's smaller than Slack.
| Harrrr wrote:
| I have a noob question, but how do proprietary apps (IE:
| Slack) make it onto the AUR without having an official
| binary?
| detaro wrote:
| Both Slack and Spotify do provide Linux versions, even if
| not/less supported officially.
| Harrrr wrote:
| Thanks! I hadn't tried Arch yet, but I just saw the
| pkgbuild script on the site (didn't know it was there)
| and it makes since now :)
| kmarc wrote:
| There are many PKGBUILDs on AUR that cactually download
| rpm / deb packages and unpack the binaries and deps from
| it.
| dialamac wrote:
| There's nothing to really block much on the aur. There
| are some guidelines in naming and no duplicates, no
| maliciousness etc that are enforced, but that's it. But
| anyone can upload a build script (PKGBUILD) for anything.
|
| If you want to see how it's done search the package name
| and AUR and you can see the build script right on the
| website.
| Harrrr wrote:
| TIL! Thank you :)
| [deleted]
| hootbootscoot wrote:
| OTOH, if you are using Slack, you probably deserve it :P
|
| "The emperor wears no clothes" and all... paying for threaded
| messaging, hmmm that's up there with To-Do MVC and Hello
| World in complexity... well, ok it's a bit higher. Not to
| mention their billing system lol...
| lytedev wrote:
| ooh I'll have to check out ripcord!
| thewebcount wrote:
| I use it daily. It's OK. It's better than having a full
| electron app/browser running, but it's fairly incomplete.
| (For example, in Slack I can't find a way to set my
| status.) I also have to reauthenticate every Monday morning
| which means launching Slack in a web browser to grab my
| credentials. It's a pain.
| ryukafalz wrote:
| I agree, in part because of performance, but also in part
| because I value being able to bootstrap from source as much as
| possible. There are only a few projects seriously working on
| this, one being GNU Guix: https://guix.gnu.org/
|
| The trouble with Electron apps though (and most Node apps) is
| the sheer number of dependencies. It's just infeasible to
| package them for a distro if you care about their dependencies
| being packaged as well - at least, not without the entire
| process being automated.
| ttoinou wrote:
| 1 gig for Slack ? I count < 300 MB on my Windows C:\Users\\[MY
| USERNAME]\AppData\Local\slack counting app-4.5.0 and packages
| folder
|
| And currently taking < 300 MB RAM
| developerdylan wrote:
| 185MB on mac.
| BubRoss wrote:
| It is true that there is a a correlation between lower level
| programming and better programming in general. You probably
| won't see someone writing asm but creating crazy O^2 algorithms
| that run on every frame with memory allocations that run in the
| inner loop.
|
| At the same time a native win32 program can pack significant
| functionality into a 20KB exe. Put these together and you have
| a program where everything is instant, all the time on any
| computer. The original uTorrent was just over 100KB and
| installed then ran in an instant.
|
| These two refinements together are such a massive difference
| from any electron program that it melts my brain when people
| say that it isn't a problem to have a chat program feel like
| using windows 95 on a 386.
|
| People say talk about needing cross platform programs, but
| something like fltk has everything most people will need and
| also runs instantly, while adding only a few hundred kilobytes
| to an executable.
| ghettoimp wrote:
| I strongly disagree with the idea that lower level is better.
|
| Yes, lower-level languages allow for programs with good
| performance, small executables, and so forth. There are many
| domains where they are clearly the way to go.
|
| But higher-level languages allow for better safety,
| tremendous productivity, portability, exploration, and
| flexibility.
|
| If you keep your data in an SQL database and you can easily
| query and update it in any number of ways that you didn't
| initially realize you wanted. If you instead keep it in hand-
| crafted C structs, you can probably provide awesome
| performance. for whatever you originally thought you needed.
| Once your needs go outside of that box, you'll have to spend
| significant development effort.
|
| The correct choice depends almost entirely on the domain.
| hootbootscoot wrote:
| How about "being aware of what your abstraction layers
| cost, and being palpably aware of every needless contortion
| you create"
|
| know what everything does. call if from up on high? fine,
| but only if you literally can trace that high level call
| down to the machine code it emits :D C compiler suites can
| do that no problem "gcc -S mycode.c"
|
| For an appropriate dose of humility, so that you know that
| I'm not elevating myself here, but pointing out reality,
| check out GCC or LLVM source code.
|
| Something like Lua or Berkeley DB can be defined inside
| your program in a matter of a few hundred lines of included
| library code, but what does it DO?
|
| Bringing SQL and a database on board is rather odd for a
| desktop app, wouldn't you say? Configuration should be flat
| files, ideally, or managed via the apps gui, in which case
| an embedded database like Berkeley DB is usually more
| relevant. Your mention of SQL smacks of "all things are
| nails, always use hammers", to me at least.
|
| Have you worked with the actual computer itself in any
| capacity? I mean ASM, C, C++, etc, but essentially being
| aware of what an ABI is, what types actually are (memory
| shape patterns so we can define physical memory in terms of
| our data structures) Javascript is not computer
| programming, but rather programming the browser, or it's
| disembodied transplanted javascript engine. the animal is
| completely different from physical memory and actual
| instructions.
|
| Computers essentially manipulate memory structures. The
| further away from this you get, the more likely that your
| abstractions will be leaky, not fit what computers are
| actually DOING with your data, and this results in
| beautiful script driving janky machine code.
|
| Seriously, while we all like to pretend that everyone is
| equally special, let's recall that someone is a VBscript
| for Word expert, and that this is basically a virtual
| machine that itself is just defined inside someone elses
| program. Technological stacks are defined in terms of semi-
| arbitrary made-up things other people made-up and that you
| just need to know how to use.
| com2kid wrote:
| Sqlite is inanely well tested, incredibly lightweight,
| and will be more reliable than the vast vast majority of
| flat file configuration systems.
| BubRoss wrote:
| You are arguing against a point I didn't make. I'm not
| trying to rehash nonsense language arguments. I'm saying
| that many times the easy electron route is also correlated
| with programming that gives poor performance even outside
| of electron functions.
| usrusr wrote:
| Not sure that I entirely agree there: I could easily imagine
| someone writing too close to the metal to stick to list
| iteration where a hash would be better and so on, unless it's
| prohibitively slower, whereas someone slightly higher would
| freely choose whatever they feel appropriate for the
| situation. They might often guess wrong and take a structure
| that is overkill for the typical dataset but the penalty for
| that will be negligible compared to the one paid for using a
| badly scaling structure on way too much data.
| dkarl wrote:
| > You probably won't see someone writing asm but creating
| crazy O^2 algorithms
|
| I watched a lecture by Bjarne Stroustrup that he gave to
| undergraduate CS majors at Texas A&M where he coded a
| solution to a problem using linear scans and then a "better"
| solution using better algorithms with better big O
| performance.
|
| Then he did something interesting. He did a test on a tiny
| data set to demonstrate that the solution with linear scans
| was faster, and he asked the audience to guess at what data
| size the more efficient algorithms would start to beat the
| linear scan. After the audience members threw out a wide
| range of guesses he confessed that he didn't know. He had
| tried to test it that afternoon, but the linear scans
| outperformed the "better" algorithms on any data set that he
| could allocate memory for on his laptop.
|
| IIRC he finished by telling them that professionals often do
| performance optimization the opposite of how the books
| present it. Using an algorithm with optimal big-O scaling
| isn't the optimized solution. It's the safe answer that you
| start with if you aren't bothering to optimize. When you need
| better performance, you evaluate your algorithms using real
| data and real machines and qualify your evaluations based on
| the characteristics (size, etc.) of the data.
| SllX wrote:
| Agreed. If you have a CPU from 2012 onwards, 16GB of RAM and an
| SSD, that's a respectable hardware setup. It might not be the
| fastest piece of kit on the planet, but I don't see any reason
| why it couldn't last another 3 to 5 years without feeling slow.
|
| Electron apps invariably make such kit feel slower than it
| actually is. You can get good performance out of even older
| hardware if you treat it well and load it with good software
| that respects the hardware.
| dx87 wrote:
| Yep, the new Steam library being a bloated web app is what
| forced me to install more RAM. I normally don't close out of
| applications when I'm not using them, so I was always
| hovering around ~6-7 of my 8 gigs of RAM in use. Then they
| update the library to the new bloated version, and my
| computer starts freezing because the library memory footprint
| is so much larger that my computer was having to use over a
| gig of swap space.
| karatestomp wrote:
| I have a rig powerful enough to run a lot of last-gen games
| at 4K with high quality settings, and a lot of current-gen
| ones at mid to high settings and 1080p. The fucking
| redesigned Steam library lags, _none_ of the animations
| (why does it need animations?!) are even close to smooth,
| and there 's massive delay on every input. I've never once
| encountered a move toward webtech, or toward heavier and
| "appier" JS use in something that's already webtech, and
| gone "oh good, this works much better now, I'm so glad they
| did that."
| Groxx wrote:
| And somehow it's still _dramatically_ better than the
| Epic Games launcher.
|
| I don't know what these companies are doing. Clearly
| they're not paying attention though. This is not merely
| _low-hanging_ fruit that 's going ignored, it's
| _watermelons_.
| toomuchtodo wrote:
| I type this from a 2014 MacBook Air with 8GB of ram, still
| going strong, no upgrades except a battery replacement.
| Everything is still as snappy as the first day I got it.
|
| No electron apps!
| seventh-chord wrote:
| The "<resource> is cheap" mantra also really only makes sense
| if you are writing server code, where you yourself pay for all
| the memory your code will ever use. If you deploy code to a
| large number of users it makes little sense. If a million users
| start your app daily, and your app has a 5 second load time and
| uses 300mb of ram, you are wasting over 50 days of user time,
| and hogging close to 300 terabytes of ram.
| hobofan wrote:
| So you are telling me that I can easily exchange development
| time which I would have to pay for end-user resources, which
| I would not have to pay? Sounds like a great deal.
| dialamac wrote:
| In a fair society it should be taxed as an externality.
| There is a real environmental cost associated with software
| bloat.
| pkalinowski wrote:
| People pay with electricity, uncomfortable temperature
| and fan noise, wasting time working on slow apps.
|
| Apparently, they trade off still worth it, as many
| electron apps are popular despite these issues. Many
| times there is electron app or nothing.
| p_l wrote:
| Your last sentence hits the nail - many users don't have
| a choice in selecting the application, and due to
| industry fads can't expect to have a better option.
|
| I can make a great chat system that uses fast native
| client, but it won't change the fact that Corporation A
| paid for a slack license and won't switch to mine.
| hobofan wrote:
| Then I hope we would also tax the bad UX of the competing
| 20-year old Frankenstein applications, which lead to
| slower business processes (= more resources used as
| well).
| CJefferson wrote:
| But, I am traiding my time for my user's CPU and RAM, and
| evidence suggests many users are willing to pay the CPU and
| RAM to get more apps with more features.
| bobblywobbles wrote:
| I admire your words here.
|
| I am on the other side, building electron apps, I appreciate
| the flexibility and ease because I would rather iterate on
| ideas then learn three different OS-hooks.
|
| I do agree that memory usage is too high on these types of apps
| and we as developers can be lax about performance.
| smabie wrote:
| When why not just use gtk or qt and call it a day? Electron
| is unnecessary.
| joshbaptiste wrote:
| Mainly due to them being both more tightly integrated to
| C++/Python than JS/TS for building desktop apps.
| smabie wrote:
| Yeah, but, honest question, why would you want to use JS
| if you didn't have to? It's like, the worst language
| possible.
| mingabunga wrote:
| I agree too, and your average user is not going to care about
| the fact you've used Electron, or even know. It's a big win
| for development.
| thewebcount wrote:
| I disagree. I mean they may literally not know that your
| app uses Electron, but they'll certainly have the feeling
| of, "Oh, that janky app that doesn't quite work correctly
| and makes my system slow."
| throw7 wrote:
| Well, I don't have a epic games account. Does that count?
| davinci26 wrote:
| Controversial opinion: Yes, native desktop apps are the future.
|
| Msft is pushing on react-native-windows and macOS has project
| catalyst. React-native is making cross-platforms native apps
| viable.
|
| Apps are way more immersive than the browser and it allows the
| developer to give a gamification experience.
| Hackbraten wrote:
| What do you mean by "gamification experience?"
| bhauer wrote:
| I prefer well-designed desktop applications to web applications
| for most things that don't naturally involve the web:
|
| * Email clients (I use Thunderbird)
|
| * Office suites
|
| * Music and media players
|
| * Maps
|
| * Information managers (e.g., password managers)
|
| * Development tools
|
| * Personal productivity tools (e.g., to-do lists)
|
| * Games
|
| As Windows starts on-boarding their unified Electron model (I
| can't recall what they have named this), I suspect we'll see more
| lightweight Electron desktop apps. But for the record, I like
| purpose built, old-fashioned desktop applications. I prefer
| traditional desktop applications because:
|
| * Traditional applications economize on display real-estate in
| ways that modern web apps rarely do. The traditional desktop
| application uses compact controls, very modest spacing, and high
| information density. While I have multiple monitors, I don't like
| the idea of wasting an entire monitor for one application at a
| time.
|
| * Standard user interface elements. Although sadly falling out of
| favor, many desktop applications retain traditional proven high-
| productivity user interface elements such as drop-down menus,
| context menus, hotkeys, and other shortcuts.
|
| * Depth of configuration. Traditional desktop apps tended to
| avoid the whittling of functionality and customization found in
| mobile and web apps. Many can be customized extensively to adapt
| to the tastes and needs of the user.
|
| Bottom-line: Yes, for some users and use-cases, it still makes
| sense to make desktop apps. It may be a "long-tail" target at
| this point, but there's still a market.
| kick wrote:
| Thunderbird isn't a native app, for the record. It's a web
| application similar to an Electron application, but with extra
| steps.
| monocasa wrote:
| Eh. XUL isn't really a web technology the same way as
| Electron.
| kick wrote:
| It's not XUL anymore, actually, as far as I know. That's
| why it ripped out support for XUL addons.
| monocasa wrote:
| Firefox has been ripping out xul, but Thunderbird still
| appears to support it.
| kick wrote:
| Only if you're using a ridiculously outdated copy:
|
| changed
|
| Add-on support: Add-ons are only supported if add-on
| authors have adapted them
|
| changed
|
| Dictionary support: Only WebExtension dictionaries are
| supported now. Both addons.mozilla.org and
| addons.thunderbird.net now provide WebExtension
| dictionaries.
|
| changed
|
| Theme support: Only WebExtension themes are supported
| now. Both addons.mozilla.org and addons.thunderbird.net
| now provide WebExtension themes.
|
| https://www.thunderbird.net/en-
| US/thunderbird/68.0/releaseno...
| monocasa wrote:
| Literally here's a doc explaining how XUL has changed as
| of Thunderbird 68, the most recent version, released
| about a month and a half ago. Yes, some elements have
| been removed, but others have been modified and still
| exist.
|
| https://developer.thunderbird.net/add-
| ons/updating/tb68/chan...
|
| And that's in the add-on documentation, not even just
| internal development docs.
|
| Also, describing information changed in the most recent
| stable release, a month and a half ago, hardly qualifies
| any older as "ridiculously outdated ".
| WilliamEdward wrote:
| Email doesn't naturally involve the web? What?
| rpeden wrote:
| Email over ARPANET and the internet predates the web by a
| couple of decades.
|
| The way we use email hasn't really changed that much since
| the 70s.
| yliu wrote:
| Ray Tomlinson's design for email came in the 70s. RFC 788
| (SMTP) was published in 1981.
|
| Email predates the Web, and, imo, has been made much worse by
| all the Web-adjacent features shoved into it.
| PNWChris wrote:
| I believe they're referring to the web as port 80/443 http(s)
| traffic. It's the old World Wide Web vs internet distinction,
| if you will.
|
| Email really is just a protocol for message sending, and it
| lives on it's own port with its own server. If you have an
| email client and access to an email server
| (POP/SMTP/however), you can use email over the internet but
| without the "web".
|
| Basically, the web email client ought not be the only email
| client.
| WilliamEdward wrote:
| It was the ambiguity of the word 'web' that tripped me up.
| You still need a network of computers for email to be
| useful.
| PNWChris wrote:
| Totally fair! Frankly, I only know the distinction from a
| high school computers teacher who was adamant about the
| distinction.
|
| I guess the easiest way to get the name is to see the
| "Web" as a "web" of hyper text documents, where
| hyperlinks act as the strands in the web (graph edges, if
| you will).
|
| Honestly, like you say, it's all built on top of a
| computer network (yet another web/graph). As a
| consequence, the distinction never really made a ton of
| sense to me, either.
|
| Alas, this is the common parlance, so it is what it is.
| macintux wrote:
| I don't think you'll find many people here who agree that
| "web" is ambiguous.
| Jtsummers wrote:
| `Web`[0] is shorthand for `World Wide Web` which is
| specifically about HTTP/HTTPS and/or the applications
| built on that protocol. It is an entirely unambiguous
| word in this context.
|
| `Internet`[1] is distinct, and that's the general purpose
| network of networks that you refer to which the Web is
| built on top of.
|
| [0] https://en.wikipedia.org/wiki/World_Wide_Web
|
| [1] https://en.wikipedia.org/wiki/Internet
| goatlover wrote:
| Nope, different protocols. You don't need web browsers for
| email, and the email clients that run in web browsers are
| using mail servers to send and receive.
|
| If the web didn't exist, which it didn't prior to 1991, email
| would still work fine. There just wouldn't be any web-based
| email clients.
| pretendscholar wrote:
| What is your maps desktop application?
| [deleted]
| bhauer wrote:
| I just use Maps that ships with Windows.
| Droobfest wrote:
| This is a big part of why I still use MacOS. The mail, notes
| and reminder apps are simple, easy, fast and can be used with
| third party providers like Fastmail. The Windows apps are
| fairly sluggish by comparison. I prefer most native MacOS apps
| in general, Finder/Explorer is a big exception though.
| Slartie wrote:
| We're building POS applications for major retailers, and for this
| kind of software, native is king and will stay for the
| foreseeable future (with a few exceptions confirming the rule, of
| course). These applications need tight integration with exotic
| hardware, must satisfy weird fiscal requirements often written
| with native applications in mind, must run rock-solid 24/7 with
| daily usage and predictable response times for weeks without a
| restart, must be able to provide core functionality without
| interruption in offline situations while syncing up transparently
| with everyone else when back online and usually run in an
| appliance-like way on dedicated hardware (start with the system,
| always in foreground, only major application on the system, user
| should not be able to close or restart it, updates and restarts
| triggered by remote support/management).
|
| All of this is much easier to do with native applications,
| running them in a browser just adds the need for crazy kludges
| and workarounds to simulate or enforce something you get for free
| if running native. Also you end up with managing hardware boxes
| with periphery attached and software running on them anyway, so
| whether managing a native application that is a browser which
| then runs the POS application or whether directly managing the
| POS application does not save you any work; if anything it even
| gives you an additional thing to manage, which increases
| maintenance effort and potential for failure (which quickly is
| catastrophic in this business, POS down today effectively means
| the store can close its doors).
|
| Back-office applications in the same space are actually pretty
| well-suited for a web application, and frequently implemented as
| such today.
| jitendrac wrote:
| just being curious, What is the stack and does server works on
| xml/json apis? Any other setup info of system will be
| appreciated.
| joshbaptiste wrote:
| Yea but as a Point of Sale application for retailers.. you have
| the luxury of running on a consistent hardware platform.
| neya wrote:
| I have a slightly different take - I wrote my own CMS based on
| Elixir. It's a static site solution, which means it generates,
| static HTML files that are then uploaded to a CDN (Eg. Netlify).
| My UI is done in VueJS and my database is actually inside of my
| application. I wrote a simple electron wrapper combined with
| docker in the background to deliver my CMS solution to my clients
| and it has worked really well for me. The reason being, I don't
| first of all need to collect my clients' data and store them on a
| central server, at the same time, my clients don't need to bother
| finding a hosting provider to maintain the site. They can just
| run this thing off their desktop and publish and be done with it.
| What's nice is, if they need updates and new features, they got
| to pay, which supports me and my work as well.
|
| In fact, the whole project started out as writing a replacement
| for Wordpress from scratch. At least 6 of my clients' websites
| got hacked and one of them had a million visits a month. Simply
| because of stale plugins (it's easier to accumulate them than you
| think). So, long story short, I absolutely believe there is a
| place for desktop apps even in 2020.
|
| BTW, I plan to open source my CMS soon :)
|
| (and I do write about my journey here - https://medium.com/build-
| ideas)
| ComputerGuru wrote:
| See, everyone likes to complain about electron but when I did a
| market study asking "would you pay for a full-featured native
| Slack app that was lightweight and designed with functionality in
| mind" the answer I got was mainly "yeah but no." As best as I can
| figure, it was mainly feeling they were entitled to it for free
| as it's what Slack _should_ have developed, so they were not
| about to pay to correct a mistake they're "not responsible for"
| never mind that they're the ones paying the price for it.
|
| (I wrote a fully native iMessage client for Windows 10 [0] and
| enjoyed it enough to consider building a product around the code,
| minus the iMessage component.)
|
| [0]: https://neosmart.net/blog/2018/imessage-for-windows/
| mintplant wrote:
| I paid for Ripcord.
|
| https://cancel.fm/ripcord/
| osrec wrote:
| There is a need for native apps, however that need is shrinking
| and, in my opinion, will continue to do so. I also happen to
| think that's a good thing.
|
| The issue is that developing for a particular OS is, generally,
| more difficult than developing for the web. The app delivery
| mechanism is also more convoluted (for native apps) than simply
| entering a web address in the browser. The web also seems to have
| more ubiquitous standards that abstract away the differences
| between OSs - you can, with a high degree of certainty, ensure
| that your app is usable by 99% of computer users, given the
| _current_ software they have on their device - with native apps,
| there is no such guarantee, especially if you 're relying on
| shared libraries.
|
| Browsers are also becoming more feature rich. This has had a
| negative impact on their memory consumption, but given it's 2020,
| some may retort "memory is cheap". And while some browsers
| (Chrome, looking especially at you) do a very poor job of memory
| management, I believe the competitive nature of the browser
| market will force a reawakening soon, where a lot of the
| inefficiencies in memory management will have to be eradicated
| (or vendors risk losing market share). Think back to 2014/15 when
| Node.js was really becoming established - the PHP team suddenly
| felt a need to re-optimise their engine for PHP7 (and with
| dramatic results)... Point is, only after ~20 years at the top
| did something spur PHP's team on enough to do something about
| their inefficiencies.
|
| Finally, I can see a future where the line between web and native
| apps is even more blurred. WebAssembly is the first step, however
| things could get even more elaborate. Perhaps we could end up
| with the ability to start docker-like containers from within web
| apps (given the right permissions, of course) to spin up servers
| for audio/video/image processing on the client itself, and
| interact with them via a web page. If we get to this point,
| native apps would feel even more obsolete.
|
| I know your question was only about the current state, but I felt
| the need to talk about the future to highlight the marked
| difference in the rate of innovation in the web ecosystem (fast)
| vs the native ecosystem (slower). It would not surprise me if the
| web ecosystem ends up winning in the end. If I was building an
| app today, and it only requires features I can deliver via the
| browser, I would almost certainly go the web app route.
|
| Now, if I was building a _video processing_ app today, I 'd
| almost certainly go native, but in a couple of years, my answer
| may be very different.
| Schnitz wrote:
| I will use a native desktop app over the other alternatives every
| time given the chance.
| oscar_franco13 wrote:
| Yes! at some point I got tired of web stuff, I try to use small
| native apps for the day to day stuff, cramming everything into
| the browser completely kills the benefits of the desktop
| environment.
|
| I created a small macOS native app, it is a menu bar app for
| monitoring CI pipelines https://tempomat.dev, something like this
| is not possible on the web because everything is running on the
| same browser but native features are so much better
| me551ah wrote:
| The whole idea of web first has actually made things worse. Let's
| compare web apps to native desktop apps, shall we?
|
| Memory Usage
|
| A few years ago while trying to figure out why I was running out
| of RAM, I stumbled upon chrome's task manager. Gmail was using up
| 700MB of RAM and all I had open was the Inbox. No fancy search
| box or Compose, the Inbox was taking up 700MB of RAM to display
| lines of text in a Tabular format. I've been a heavy user of
| Email clients and if you pick any of the native clients
| (Thunderbird, Outlook, Apple Mail) and open a bunch of searches
| and compose windows the memory usage will still stay below 100MB.
|
| I used mIRC a few decades ago to connect to multiple chat
| servers, run my own bots, serve files over DCC and run scripts
| all while staying under 20MB of Ram. These days to send a text
| message over Slack I need over 1GB of RAM. Even basic apps with
| all of their trackers, external javascript scripts and doms take
| up 100s of MBs in memory. And the most common solution to running
| out of memory is to close chrome windows.
|
| Battery/CPU Usage
|
| DOM is slow. Updating layout and repainting is even slow.
| Javascript being a dynamic language is slow. Web apps are
| anything but simple these days and since they have to work under
| the limitations of all the slow components, the CPU ends up
| making up for it. Chrome is almost always present in my Macbook's
| 'Using significant energy' tab. On the other hand, I rarely if
| ever see native apps in the battery bar unless I'm doing
| something which should actually consume a lot of CPU cycles like
| running multiple synths in Ableton or Compiling. When apps are
| built for mobile, battery usage is a major area to optimize on.
| But nobody even gives it a thought for web apps
|
| 60 FPS
|
| Mobile apps run on 60fps, Native desktop apps run at 60fps, Games
| run ( or at least are designed to) run at 60fps. Instagram on
| chrome starts at 2-3 fps and usually hovers around 30fps. My
| laptop which is supposed to be more powerful than my mobile phone
| is only able to churn out half the frame rate even though they
| are both running at the same resolution! Web apps are not buttery
| smooth and can be jerky at times. Sure somebody can work really
| hard and optimize a website to run at 60fps at all times, but it
| needs a lot of effort. Mobile apps run at 60fps out of the box
| without much effort. Mobile and native apps use the GPU a lot
| more efficiently. Since they have a lot more information about
| which controls are being used, they can recycle items a lot
| better and do a much better job at hardware acceleration via the
| GPU. Not to mention that you have access to raw graphics APIs in
| case you want to push UI performance even further.
|
| Development Environment You can build desktop apps in a plethora
| of languages and even for mobile apps you have many cross-
| platform frameworks. But building for the web(and electron)
| forces you to HTML/Javascript(and derivates). Javascript is a
| dynamic prototypical language that was not designed for the scale
| of apps that are being built in it today. It has no type safety,
| memory leaks are common and it's slow due to its dynamic nature.
| While there have been many efforts to improve performance like
| V8s JIT, it still lags behind a lot of major languages. WASM
| seems promising, but it's still has a long way to go. And it's
| laughable how weak the browser platform itself is. SQLite is
| available on raspberry pi, embeddable systems, mobile platforms
| and just about every other platform on the planet. You can store
| data, run complex relational queries and do more with so less.
| But it is not available on the most widely used platform on the
| planet, the browser.
|
| With the rise of electron apps, big and bulky web apps have
| started making their way onto the Desktop. There are some who are
| even trying to get the same apps on mobile via PWAs. While the
| web has the advantage of easy accessibility, IMO we have
| sacrificed too much in terms of user experience for that one
| convenience. If you built an app with the same UI and
| functionality in a native language and as a web app, the native
| app will run circles around it.
| squarefoot wrote:
| Web last, badly, and only when needed. Having tons of resources
| at disposal shouldn't be an excuse to add layers of unnecessary
| stuff where native code always perform better.
| alasdair_ wrote:
| There are still a lot of fields where performance matters. This
| is especially true with apps that need low latency, like most
| games. Something like Stadia may be fine for a casual gamer but
| it still feels laggy to many, especially those used to gaming at
| 144Hz+ with almost zero input lag and gsync.
|
| VR is another area where native desktop is still superior.
|
| Then there is anything that is dealing with a lot of local data
| and device drivers. Video editing for example.
|
| Development tools that work in a browser are getting better but
| native (or even just Java-based like IntelliJ stuff) still seems
| superior for now.
|
| Stuff that doesn't use TCP, like network analysis tools, either
| need to be done as a desktop app or need to run a local server to
| point the webapp used to control them to.
|
| I guess what I'm getting at is that if you need low-level access
| to the local device or if you care a lot about things like
| rendering performance then native is still the way to go.
| SubiculumCode wrote:
| Also from a security standpoint, it seems to me that having all
| apps work in the browser is creating single points of failure.
| gundmc wrote:
| Can you elaborate on the security considerations of this? It
| seems like you could just as easily say it's more secure
| because it reduces the attack surface to a well-tested
| program with mature sandboxing.
| paulgb wrote:
| It goes both ways, the sandboxing means that the app has
| less access to the OS, but the flip side is that the open
| web has more access to the app (CSRF, XSS, evil extensions,
| etc.)
|
| Coincidentally, I just published a blog post that touches
| on this from both sides: https://paulbutler.org/2020/the-
| webassembly-app-gap/
| desc wrote:
| You mean like the OS is supposed to be?
| jfkebwjsbx wrote:
| Stadia's games do not run in a browser.
|
| The client you use to interact with the stream is a web page,
| yes, but the actual game running in their servers is a native
| Linux application.
| mantas wrote:
| Place? Absolutely. Developers will to provide quality apps and
| customers will to pay for them? Not so much...
| nikivi wrote:
| Browsers have one huge problem and that is they override
| important hotkey space (like cmd+w, cmd+f for searching etc). So
| native apps will always provide a better experience.
| rbinv wrote:
| Google Docs actually hijacks CMD+F.
| kroltan wrote:
| And nowadays even websites that don't hijack the shortcut
| itself are non-"find in page"-able, due to the trick of
| disposing unused/out-of-view components (which is actually I
| suspect what Docs is doing, too, but they made their own find
| so people wouldn't get stuck)
| zabil wrote:
| Not yet for music production. DAW's, software synthesisers, drum
| machines, latency matters here.
| slyzmud wrote:
| Funny that the other day I discovered bandlab. It's not
| professional but for my hobby usage it's the best I've found
| dantheta wrote:
| Same here - I was a Cakewalk user back in the 90s, and
| decided on a whim to find out if it was still around.
| alkonaut wrote:
| I imagine DAWs like many others could be a very small native
| audio processing binary with a gui on top that can be whatever
| it wants. Some are already Java UIs over C++ backend (e.g
| Bitwig). Should be possible to do an electron or web frontend
| over the C++ backend too. Replacing the processing bits will be
| hard though. Driver interfaces aren't exactly the strong point
| of web dev.
| m4r35n357 wrote:
| Web last, please!
| mdrachuk wrote:
| It does feel better to use a native app. Marketing as a "premium"
| product could work.
| elorant wrote:
| For me the simplest example is e-mail. I need an e-mail client on
| my PC where I can browse all my e-mails even when offline.
| Nothing that runs inside the browser could match the speed and
| efficiency of a native app.
| nikofeyn wrote:
| it's crazy that we've reached the time where this is a question.
| it just feels like web browsers are just worse operating systems
| but that's somehow where everyone thinks things should be.
|
| i generally hate using web-apps. the usability and performance
| just isn't there, and the web was not built for this use case.
| even now, it's a terrible experience.
|
| for industrial engineering, scientific, creative jobs and more,
| almost everything you use aside from confluence is a desktop
| application. visual studio, visual studio code (line is blurred,
| but it's still a desktop app), solidworks, opera, other modeling
| software, xilinx vivado, matlab, visio, simulink, houdini,
| touchdesigner, unreal engine, logic, pro tools, studio one, VSTs,
| office suite, control applications, perforce visual tools, git
| gui clients, custom internal tools, etc.
|
| all the real work gets done in desktop apps and yet people keep
| saying desktop apps are a thing of the past.
|
| i truly don't understand what people's end game with web browsers
| and applications are.
| red_admiral wrote:
| On Office 365 (desktop version), sometimes when you click a
| dropdown like the "different kinds of bullet lists" the whole
| application freezes for a couple of seconds while it builds the
| menu content or something. This didn't happen with earlier
| versions, if memory serves me right. I'm not sure if this is web
| tech or some other kind of new framework under the hood, but it
| makes me sad that with the speeds and cores we have on modern
| processors old-fashioned things like word processing have got
| slower than they used to be.
|
| Native Applications in the platform's toolkit (not some cross-
| platform abstraction on top) will always squeeze a little bit
| more performance and usability out of the corners.
___________________________________________________________________
(page generated 2020-05-17 23:00 UTC)