"What would you do if you had 16GB of RAM?"
"I'll tell you what I'd do with that. 2 Chrome tabs at the same time."
(Superimposed over the scene from Office Space.)
(On a more charitable note, I worked with the Chrome performance team on a few occasions. The reason for Chrome's massive memory requirements is that they make memory vs. CPU/performance/security tradeoffs on a regular basis, and usually make them against memory. For example, the reason you can have smooth animations in Chrome is because there are multiple in-memory representations of the layout and changing a CSS property relies on cached parsing/cascading/layout decisions and only needs a repaint on the GPU, using blocks of the page that have been pre-rendered into a texture. For another example, the multi-process architecture that gives each webpage isolation from another is a lot more RAM intensive than a shared-state architecture that could share common components, like say the object code from compiling shared JS libraries.)
Do they actually test both approaches, or is it more a matter of "we can code it way A or way B, and way A uses more memory, but we think it'll be faster"?
Many years ago I worked at Watcom, back when they made "the" C++ compiler for DOS games. (Doom, Descent, Duke Nukem 3D, and Tomb Raider all used it.)
The compiler had various optimization settings, and some optimized for size, while other optimized for speed. The compiler was used to compile itself. They normally compiled with the "optimize for size" settings enabled, but one time they decided to try optimizing it for speed to see how fast it could be.
It turned out that optimizing it "for speed" made it considerably slower because of the cache.
-Os meant faster launch times, which for desktop Linux made sense, but in classic Gentoo fashion a big group used -O3 and then did a bunch of hacks to make sure binaries would be loaded at startup and never be evicted from memory (even if the application itself wasn't running).
Gentoo was delightfully silly about this stuff, and mostly self aware that it was excessive.
A lot of memory consumption is various caches (at various layers); those caches weren't added for no reason, they were added because they provided a demonstrable a perf gain.
This is generally a good trade. Memory is not very useful (modulo filesystem caches) when you're not using it, and has a very low cost when you are (extremely tiny power consumption). CPU cycles cost power (leading to heat dissipation and battery life loss) when you use any amount, and latency when you use too much. Latency directly affects user experience and efficiency, which is a much higher cost than "my RAM is at 75% usage".
Additionally, Chrome's tradeoff is such that it works out better on cheaper devices. Memory is far cheaper than more powerful processors - which also reduce battery life, which is even more expensive. On more expensive devices, you have all the memory you need for Chrome anyway, so you're just getting better latency.
Finally, there are very few cases where you should have a large number of Chrome tabs open anyway. Multi-tasking is impossible (the human brain simply doesn't support it) and rapid context-switches are inefficient. As much fun as it might be to have 5 tabs open on each of 10 different topics, you're simply decreasing your productivity and capacity for focus. Even when doing multi-disciplinary research, there are a ton of ways to get around the problem of running out of memory due to Chrome tabs: printing pages to PDF, turning off JavaScript, downloading research papers and reading them in a native PDF viewer, extracting content from webpages and inserting into local documents, and the classic using darn bookmarks instead of tabs like they were intended to be used.
(of course, in an ideal world, all web browsers would use absolutely no memory or processing power whatsoever - I'm just defending this particular engineering tradeoff)
I agree that the human brain doesn't task switch effectively, but that is exactly why I want to have many tabs open. In the case of reading Hacker News, I will go through the main page once, opening each article and comment page in a new tab, then will use that as a to-read list. If I am researching how to do a task, I will open have several pages open for documentation, stack overflow posts, bug reports, etc. These are open not for the sake of multitasking, but in order to reduce the amount of working memory I need. For example, if a post mentions that a particular workaround may be required, then I want to keep that tab open until I have verified that that workaround is not needed in my case.
> In the case of reading Hacker News...
This isn't a "task" - you're reading a bunch of completely separate articles, one at a time. You're consuming, not producing/processing/working on a task/problem - and each element of consumption is separate than all of the others.
> If I am researching how to do a task...
I understand and agree with this definition and workflow! This is how tabs were designed to be used. However, I haven't ever seen a common task (for programmers - who have even more demanding requirements than the general populace) that requires a "large" number of tabs. I guess that's kind of vague and I can always change the number, but really, think about it - how often does a task require more than a dozen tabs? More than two dozen tabs?
Just for fun, I opened every frontpage article (as of the time I accessed it - whoops, should have used Wayback HN or something) in Chrome. All 30 articles took 3.9 GB RAM, and adding all 30 pages of comments consumed another 300 MB, so 4.2 GB. total.
> (1) you should only open tabs for the task you're currently working on
In good part because there are no other simple "read later" alternatives in a browser.
Something that would be an option would be a special single use kind of bookmark that gets deleted once you reopen it.
I am on the extreme side of keeping too many tabs open, part of the reason is that they offer a very simple and unique functionality in the browser (it was my reason between other to switch to Firefox, it could easily handles a few hundred tabs (with some restarts from about:profiles))
from what i observe in others, it seems that tabs get created when a new task needs to be done in the same site (that is already open) but dont want to loose context of the previous ones...
from my own personal experience, i like to reuse them as much as i can, but it gets harder as more and more get added, its easier to start from scratch and get a new tab open and go where i want to go...
i think browsers could be doing much more than just tabs and bookmarks to help people organize, because right now it seems like the equivalent of a desk with lots of papers strewn around where someone grabs yet another blank peice to start writing on...
Absolutely. Zettelkasten is the hotness right now. I'd love to see something like a cross between Zettelkasten and Zotero.
Personally I want something in between bookmarks (which I actually infrequently revisit) and history, which is everything and too much noise, and also not permanent in case of history wipe. Strangely I bookmark a lot but don't revisit often, but when I _don't_ bookmark something and need to find some memory thread, it's awful.
I've been scheming about something which I could hit a hotkey, grab the text and metadata, index it, and save the index, set of words/ngrams, or maybe just zipped html content, it's light enough. Then some personal search interface.
Could you give a few examples of this? I still can't think of anything particularly common that would reasonably justify more than a dozen tabs at once...
> i think browsers could be doing much more than just tabs and bookmarks to help people organize, because right now it seems like the equivalent of a desk with lots of papers strewn around where someone grabs yet another blank peice to start writing on...
Yes, I completely agree. I'm working on a piece of software that goes several levels beyond what browsers currently offer for information organization, and (per the topic) it optimizes for CPU consumption at the expense of memory, for the reasons I gave in my comment. However, for the browsers that we have now, bookmarks are much better for organization than tabs. You can tag them, name them, and put them into folders - none of which you can do with tabs.
For example, currently I'm researching bicycles for my mother. I'm on an online shop, and I just open potential candidates on new tabs, which means they start loading in the background while I keep browsing. And using Tree-Style Tabs, this makes them all "children" of the listing tab, which would be lost information if I bookmarked them instead. When I switch to another task, I can just collapse this tree, and when I get back, the listing will be exactly where I left it, which is particularly useful if the site uses JS search without updating the URL. Bookmarks lose all the memory except for the URL and page title.
Bookmarks could be useful for a long-term reference storage (months/years instead of days/weeks), but then chances are a bunch of those links will have rotted, so I need to use something that mirrors the content instead (I used Pinboard previously, now I just use the SingleFile addon to store it as a file).
Bookmarks can be categorized with folders and tags - which, together, are much more flexible than tab groups. A tab can only exist in one group/tree at a time, but a bookmark can have infinitely many tags and exist in a tree-like structure (which is what you described) using bookmarks and be relabeled so it's easier for you to find using full-text search.
> Bookmarks lose all the memory except for the URL and page title.
Yes, because bookmarks are meant to be long-term storage, tabs are meant to be working memory, and transient web page state like whether a radio button is checked or not is not intended to be long-term. Web page state is supposed to either be stored server-side or client-side using cookies or HTML5 local storage - which persist after the tab is closed.
> if the site uses JS search without updating the URL
Then you can just keep that search tab open if you absolutely have to interrupt yourself and go to another task. Bookmarks will do just fine for all the stuff you found. It's extremely unlikely that you're going to have more than a few of these tasks that all absolutely require page state that isn't present in the URL or through local storage and you're accumulating them faster than you can complete them.
> Web page state is supposed to either be stored server-side or client-side using cookies or HTML5 local storage - which persist after the tab is closed.
Supposed doesn't matter to me, frankly. A solution for me must work for most sites, regardless of whether the web developers of those sites do the "supposed" or not.
But even if they did, those cookies and local storage aren't tied to the bookmarks, so I can't rely on them. Chances are they'll expire much sooner, plus they generally only work on the same machine where they were created, which in the long-term may not be the same I'll be using later.
And the ultimate state loser still applies: URLs rot, and bookmarks rot with them. For long-term storage, they're absolutely not enough. Hence my use of page archiving as files, instead.
> It's extremely unlikely that you're going to have more than a few of these tasks that all absolutely require page state that isn't present in the URL or through local storage and you're accumulating them faster than you can complete them.
Maybe, but I don't care to waste time finding out which pages do or do not have their state in the URL or local storage if I need it. Tabs simply work.
I clicked an internal link in this thread (in firefox) and after it loaded (1s) I clicked the back button. 0.7 seconds later I was back but not at the same position. So I had to scroll to find the position to continue to read. I can save 0.7s load time + 5s or 10s of search by opening a new tab instead.
Disadvantages of single tab usage (off the top of my head):
- additional load time
- formular inputs should be preserved, but I wouldn't count on it.
- highlighted text is not highlighted any more
- server can send me another version (or nonthing 404). So I lose the content alltogether.
-
as an example, someone asks "hey can you update the appstore screenshots" and while i may still have appstore open on anothet tab, ill open a mew one just for that task, then later somone asks, hey whats up with jira ticket 1234, now i already have 3 tickets open in jira, and i dont wanna disturb those, somill open another tab, same with online docs like confluence, or web searches on google... at some poont the overwhelming number of tabs themselves get to be too much, so clearing context to yet-another-tab, is a way of coping i think...
i see this all the time in group meetings btw
> I'm working on a piece of software that goes several levels beyond what browsers currently offer for information organization, and (per the topic)
that sounds cool. one idea ive had for a while is that sites (like confluence ot jira, or gdocs) are basically apps, so they should be treated as such and automatically grouped together (im windows or tabs) just like native apps...
By "browsers we have now" you clearly mean "Chrome, the only browser I care about". Firefox can handle literally thousands of tabs with lower memory than Chrome using one or two dozen due to different trade-offs. Very few people ever use that many, but the presumption that no better should be done on the memory front because your favorite doesn't manage it isn't supported by the facts.
Bookmarks aren't used in the same way as tabs by most people and it's telling that your workflow so easily conflates them that you're making criticisms based the rest of us using them differently. I get the impression that what you want bookmarks for would be better done with tab groups for most people? There are certainly a decent number of happy OneTab users out there who're probably closer to your preferred interface than the rest of us, but even on Firefox its userbase is minuscule.
False. I use Firefox for all of my browsing, hate Chrome, and only use Chrome as a whole-browser sandbox for Google products.
> Firefox can handle literally thousands of tabs with lower memory than Chrome using one or two dozen due to different trade-offs.
Yes, and I'm arguing that that's a tradeoff and that's a good thing based on the intent of tabs.
> the presumption that no better should be done on the memory front because your favorite doesn't manage it
Neither did I say that no better should be done, nor do I actually believe that. Presumptuous today, aren't we.
> isn't supported by the facts.
The facts are that tabs are intended to be a working set and are optimized for that. If you don't use them as such, you're going against the design of the tool and expecting it to do well, which is insane. It's equivalent to using files on a filesystem like RAM (expecting extremely quick access and no wear over time) and then complaining when they're slow and your SSD wears out in a few weeks.
> Bookmarks aren't used in the same way as tabs by most people and it's telling that your workflow so easily conflates them that you're making criticisms based the rest of us using them differently.
Correct, because they aren't different. Bookmarks are intended to be used for saving and organizing things for the long term. Tabs are intended to be used for actively working on a task. They're two different things. Thinking that the case where you reasonably want to work on a task that requires dozens of tabs to be open, all at once, all on the same topic, and you switch between all of them very frequently is a common case is completely unsupported by evidence, and logically incoherent.
This has nothing to do with my workflow, and everything to do with the design intent of the tool, and proper use of the tool. Again, see the example about using disk as working memory.
> I get the impression that what you want bookmarks for would be better done with tab groups for most people?
Again, this is something that bookmarks are much, much better optimized for than tabs. Bookmarks can exist in folders - which are probably like tab groups, but first-class, and much better supported - and tabs cannot. Bookmarks can be tagged, and tabs cannot. Bookmarks can be exported to a file, and tabs cannot. Bookmarks can be renamed, and tabs cannot. Bookmarks are straight-up better at their job then tabs are. This is not "better done with tab groups for most people" - this is "worse than tab groups for everyone".
To summarize: working memory is not the same as long-term storage (in the human brain, in operating systems, in physical desks, in the browser, and everywhere). Tabs are for working memory, and optimized for that. Bookmarks are for long-term storage, and optimized for that. Bookmarks are objectively better than tabs for long-term storage in non-performance metrics (can be organized using folders and tags, can be exported/imported, can be renamed) and performance metrics, and you and everyone else who insist on using tabs like bookmarks are (1) doing yourselves a disservice by using the tool wrong and suboptimally and (2) doing everyone else a disservice by demanding that the tool literally be made less optimal to fit your incorrect use of it.
How users use the program determines how the program should be implemented, not the other way around.
My anecdotal observations are that this often causes extreme number of tabs. I've seen multiple examples from social media in the last month of people scrolling through their mom's (/little brother's/etc) phone, showing hundreds of tabs, but usually all duplicates of the same dozen or so. I remember seeing similar things firsthand (but not to as great an extent) when the first generation iPad came out. And I've also witnessed the same in offices, where doing something in an app or an existing page will arbitrarily open a new window or tab, leading to an explosion of windows and tabs all hidden beneath the IE11 icon in the Windows taskbar.
By all signs, it seems true that (a) average people don't know what tabs are, and (b) they have a lot of them. So it makes me wonder about your methodology. I used to be a Mozillian, and I remember the less-than-rigorous excuses that Firefox UX folks reached for when backfilling justifications for their design whims.
Honestly this is the only reasonable way to use tabs on a mobile browser. There is almost no drawback of keeping them and closing them is a chore. I get it sounds like the typical "boomers using the internet" but given that you should expect old inactive tabs to unload anyway having even hundreds of tabs open is a detail.
That said, what you're saying is, "In practice, users don't have a lot of tabs open", which is very different from what I was responding to, which was "users shouldn't have a lot of tabs open".
Of course important to remember that increased memory utilization results in increased CPU utilization. The range of degradation is quite wide: Increased cache misses (which cost a significant number of cycles), access patterns not in line with the prefetcher, and increased TLB misses.
It's for good reason that one of the most potent optimization techniques for hot code is to reduce the memory footprint and memory access.
Rather the trade off you're thinking of is "caching vs. realtime computation" rather than just "memory vs. cpu". Outside caching, it's pretty universal that more memory utilization just means poorer performance, both in wallclock time and in CPU utilization.
It's also not very useful when someone else is hogging all of it! There is an opportunity cost to the user and other programs. It is supremely selfish to only think of oneself, and reserve all the common resources because "well it was just laying around".
I PAY for the capacity in case I NEED it, not for some bloated browser to snorf it all up because they can't be assed to write reasonable software.
A common use-case: I visit a site I open a new link in a separate tab. Those tabs are visited later.
Having gmail open, slack web client, jira, git and the dev and prod versions of a site I'm building is a common scenerio.
Use the great suspender extension; my friend in academia thanks me every single time we meet. And now I see them have 4 chrome windows open with each having ~20+ tabs in it!!!
For them everything happens in browser, its synced and the great suspender lets them run that monstrosity without choking their MacBook Airs
One problem is that CPUs have various ways to use less power or even switch off parts when not in use, but you always pay the same for RAM.
For battery-operated devices that sleep most of the time such as smartphones, that means being careful with memory usage is the way to go. I think that’s part of the reason iPhones ship with less RAM then Android devices (reference counting needs less RAM than garbage collection for the same performance level)
Additionally, the extra power cost of adding more RAM to a device is very low relative to even using 25% of total CPU TDP. [1] gives 3W per DIMM for DDR3 (which is an upper bound, given that LPDDR3 will consume far less power while fully on, let alone in deep sleep mode) and [2] gives 2.5W for DDR2.
Edit: aha, found a paper[3] on RAM power consumption in a phone. Far less than 5% in either "suspended" or "idle" states, under 10% in almost every other benchmark, and universally lower than CPU power consumption.
[1] http://www.buildcomputers.net/power-consumption-of-pc-compon...
[2] https://superuser.com/questions/40113/does-installing-larger...
[3] https://www.usenix.org/legacy/event/atc10/tech/full_papers/C...
I can't even scroll Twitter without stutter on my hefty gaming laptop, my browser (the whole thing! not just the tab!) often freezes for 10+ seconds when first rendering a page, and toggling Reddit's sidebar takes half a second.
To the extent Chrome's anything can be deemed ‘smooth’, it's because computers are fast, not because they made some clever space-time trade-off.
EDIT: someone in this thread posted this:
I can't even scroll Twitter without stutter on my hefty gaming laptop, my browser (the whole thing! not just the tab!) often freezes for 10+ seconds when first rendering a page, and toggling Reddit's sidebar takes half a second.
I.e. “Disable animations in all web pages (gracefully)”.
Now whether any sites actually make use of it is another matter. Also I don't know how the user would enable it. Perhaps an OS-specific, system-wide setting like dark mode.
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
It would be so much better if browsers were User Agents and respected user settings before the will of the site creator.
In Apple products, it's exposed as an accessibility option:
macOS: https://support.apple.com/guide/mac-help/reduce-screen-motio...
iOS: https://support.apple.com/en-us/HT202655
tvOS: https://support.apple.com/guide/tv/reduce-screen-motion-atvb... (which also disables autoplaying previews!)
I would opt to stop letting web page authors just mangle my CPU cycles because they've opted to poorly animate an SVG or some HTML element. If anything I'd prefer each got a CPU budget and that was all they could use, unless they request more CPU time from the user, then voila! People who want to be annoyed can be, and the rest of us can go back to "browsing the web."
I think I have yet to see a webpage that uses animations in a way I enjoy, even when they’re smooth. (The same goes for most PowerPoint transitions and window manager animations...)
Personally I'd rather wait longer for things to complete than have my whole system grind to a halt because it starts swapping like crazy.
I can run Intellij Idea: Java IDE, load project with thousands of files into it and it won't eat 8 GB.
I understand that Chromium is maintained by extremely talented developers and all obvious improvements were made, so that memory usage is probably necessary. But I still wonder how is it possible. Gigabyte of RAM is a lot.
But yeah, 8GB is unbelievable. I have no clue why Chrome needs this.
I don't have the same experience, PyCharm is absolutely killing my machine and I always have it in Power Save mode. Sure, it isn't eating 8GB but that is because the JVM by default doesn't have that much available. I had to raise the memory limit considerably to be able to open my projects without it hanging.
What plugins do you have installed? Maybe one is slowing it down?
And perhaps run “clear caches / restart” just in case there’s cache corruption
I run it fine on a Linux machine that has 4GB ram total — I’m curious how much memory you’re talking about.
It's kind of obvious and does not at all explain chromium's lower bound of memory usage. But: if Chromium runs better with more memory and no other process is using it: please take it!
That is what it's there for, after all.
Well, not as significantly now, with SSD everywhere, but still faster.
But I have a chromebook with 4GB of ram, and it often struggles to keep a particular set of 3 expensive tabs open because it runs out. It's definitely not reacting to memory pressure by being less greedy.
Gnome and KDE folks. Although I stopped using either of those so I don't care.
I keep obsolete computers and phones around to test with.
This is called Wirth's Law: Software gets slower faster than hardware gets faster.
Pretty much the only thing we've seen it stutter on is browsing very high res images taken with a high end camera off of a USB stick.
So that's about architecture of the Chromium - multiple processes (not even threads) and IPC between them to render stuff.
Thats why on iOS safari if you scroll fast enough you see a checkerboard pattern... that means that tile isn't yet rendered...
The JS is SpiderMonkey, the rest indeed is written from scratch: https://twitter.com/flowbrowser/status/1200098712816631809
Might be nice as an Electron replacement
I have spent hours searching the web for any clues as to Microsoft's intentions here. I would be grateful for any words on how you came to believe this.
One is that TLS is married to DNS, and no third-party CA would issue a certificate for localhost. TlS with self-signed certs generated on the spot becomes easy to forge.
Another is that no web browser suppoorts Unix domain sockets or a Windows equivalent as a an access protocol. You are stuck with IP-based access, wee above.
Third is that access to the OS is limited or forbidden inside the browser, for a good reason. Want to run a locally installed compiler from within your web IDE? Tough luck.
Electron solves all of these problems. It doesn't do it in the best way imaginable, but in some cases just a web site cannot be a replacement.
Developers don't use electron because it'll get its own browser engine instance.
If you can't, it's not the browser's fault. I can definitely screen share in Jitsi from the browser, so there's no technical reason Slack shouldn't be able to do the same thing.
I also see this project but you have to write Go to talk to the OS, not Node: https://github.com/zserge/lorca
But if you want broad cross-platform support "just get the locally installed browser engine" suddenly becomes a hard problem, unless this becomes a popular OS feature.
At the same time, companies were locking down WScript due to scripting viruses and HTAs that were impersonating other applications with their configrable icons.
Kudos to the author.. but I was hoping it would be a "for real new" browser.
There are some weak points for web. One of them is performance, hopefully it'll be resolved by Webassembly, so you could write performance-sensitive portions using C++ or Rust. Another one is using hardware and that's resolved by evolving web standards like WebUSB, WebGPU and so on. I don't think that replacing HTML, CSS or JS with something different would solve any actual problem in the web. They are not ideal, but they are good enough and that's all that matters.
Well, technically you could replace JS with any other language compiling into JS or Webassembly. Then you could just use one full-screen canvas and draw anything you want there, so you could use Qt or something like that. That does not require any new APIs, but I don't think that's the good idea in the long run.
To be fair, CSS is making big strides in this regard with Houdini[0]. It's not yet complete but it's a much better alternative to composing divs and spans in weird ways to get the look you want.
However, I think the need to support the current web stack will continue for the foreseeable future since it would be a terrible waste to simply abandon a platform that so many applications are written for.
So much tech today is being built just to put a band-aid over this stuff, instead of addressing the core issue (the browser is no longer used to just deliver static documents). I can't be the only one that wishes for a new language/browser. WebAssembly might be a saviour, although I'm unsure how issues like accessibility will be addressed.
If it was just a matter of a fresh start with a new language/stack, then Android/iOS/macOS dev would be compelling experiences. But they're not. And they're changing just as much, bandaging over themselves so much that you end up credentializing in a whole lineage of idiosyncrasies worse than just putting a <select> in a modal, except unlike the web you're just building something that works on an iPhone.
Clientdev is hard.
Client Dev has regressed since those days, now it's in a state where devs can't even imagine anything better, but we clearly had that...
Try Sciter then, it was designed precisely for running desktop UI using HTML/CSS as UI declaration languages.
I was native UI developer initially, then Web Frontend Architect who returned back to desktop development taking HTML/CSS with me to Sciter.
Am I the only one who thinks the sooner the web goes back to just delivering static documents, the better?
As a dev if have to choose between a flawed but still very capable open platform and proprietary walled gardens where corporations wield absolute and arbitrary control I’ll take the open option and so should you.
I don't do native software development but just looking at things, it seems like software is eating the world, but also at the same time that web technology is eating software development.
I don't think the web is the best development tech on any OS, but it's proving to be the best cross-platform tech that runs on any device. It will continue to evolve to be more suitable, but the idea that it's too weak or wrong is exaggerated.
Looking at what web browsers are both capable of and expected to do today I think what we really want is an "internet terminal" which would be able to contact resources over the internet, negotiate both local and remote resources for an intended purpose, and then share state bi-directionally (stateless is just zero state).
To just conjure a couple of quick examples you can imagine the differences required in providing a service that produces a simple JSON feed versus a full interactive experience that mutates a shared database. The JSON feed wouldn't require a display and could easily be consumed by autonomous agents while the other might require a minimum display size and want to use a widget set to produce controls and toolbars, etc. If my client agent is allowed access to my video display, mouse, and keyboard it could offer these to either service and allow it to respond in whatever way it feels appropriate. The JSON feed could provide a simple UI for viewing recent events, for example.
Now we do all of this today with HTML, CSS, JavaScript, etc. but none of it feels organized and all you see is re-invention after re-invention of essentially these same concepts. The fact that we even call them "applications" when they are "documents" is really what seals it to me. I personally would like to see something that is more true to the reality of computing and internet connectivity today and looks at it from a device-to-service POV. Locally I might have a graphical display, audio, and inputs but I might also have access to an SQL database or some other network-attached service. Assuming some level of trust and if negotiated properly there's no reason a remote application couldn't make use of these local resources using credentials and security profiles under my control. The can of worms here is that this is basically RPC which is the other never-ending disaster...
Internet is hard. Let's go shopping.
Scoped CSS works really well in conjunction with web components. Languages like SCSS make everything more sane, especially in combination.
I'm currently messing about with Yew[1], which is an entire SPA framework in Rust/WebAssembly. There's about 5 lines of bootstrap JS involved (and fiddling about with bundlers, which is much more sane since Rollup[2]).
[1]: https://yew.rs/docs/ [2]: https://rollupjs.org/guide/en/
The web is a mine-strewn no-mans-land between competing factions, which accounts for a lot of the strangeness.
(Ironically, the tech is leaking in the other direction as web apps become more popular on both mobile and desktop)
This works if browser is the only application that runs on machine. So this is limiting possible use cases (like Electron) quite a lot.
> low memory consumption
Sciter's Quark (https://quark.sciter.com) - 5 MB binary and 28 MB RAM by default is probably the lowest what you can get for HTML/CSS/script engine.
I don't understand what you mean - individual applications within a multi-application system can absolutely utilise multiple cores. It isn't true that it won't work. The kernel schedules all the tasks of all applications across the available cores.
And even if you have many applications running, most of them don't need multiple cores all the time, so it makes sense for each application to be able to use as many cores as possible, when the user is looking at it and doing something.
For example if I'm using my text editor and browsing docs. My text editor only needs tiny a fraction of a core every now and again, but each time I navigate it'd be great if the browser temporarily used all sixteen cores to do that as quickly as possible.
User applications with GUIs are almost never CPU-bound, so the comparison is not really appropriate.
I watch live streams of music producers working with DAWs and they actually end up needing to offload synthesis and filtering to multiple separate machines as they can't do it on one.
Also if you think things aren't CPU-bound then why do you think people spend hundreds or thousands of dollars on CPUs?
The vast majority of what the vast majority of users do on computers remains non-CPU-bound. I chose not enumerate all the exceptions, because as usual, they are exceptions.
Most people aren't doing CPU-bound work and there's no point parallelising your application... but people are buying 32-core processors? Why do you think they're doing that?
I'm just a normal developer and I am very frequently CPU-bound in my work, and I see many other people in other fields also CPU-bound. I'd absolutely love to have a massive Xeon in my laptop. I think it'd have a genuine impact on my productivity.
And sure, as someone who regularly spends 4 minutes waiting for my 16 core threadripper to build my application, I appreciate the sentiment.
But ... this is very very far from the majority of computer users do and quite far from what "supercomputers" are used for (frequent, repeated, long lived CPU-bound workloads).
Video conferencing, JS heavy web browsing, video editing, and gaming are all examples of CPU-intense applications that are becoming increasingly common
And, having done plenty of video dev work recently, beyond the codecs and GPUs, it's also memory bandwidth/lock contention/data path that's really key for getting good video performance. We're almost never decoding or encoding video by CPU anymore. If we can avoid it.
Arguably with JS heavy web browsing you're also looking at memory bandwidth or lock contention as a key limitation -- garbage collection in the JS interpreter, fetching and dispatching opcodes, etc. CPU is only part of the story.
Life just became so so very complicated in the 90s when CPU performance started to compltely outstrip main memory and bus performance.
2) video conferencing is not CPU-bound unless you're doing 1-to-many/many-to-1 feeds locally.
3) JS heavy web browsing ... 'nuff said.
4) Very few people do video editing that is CPU bound. Certainly for video editors, it is an issue.
Clearly, I should have said:
"The majority of applications used by the majority of users are rarely CPU-bound"
Have you ever played around with BeOS or its community-driven successor Haiku? They are what's called "pervasively multithreaded" such that every single widget in the standard UI toolkit has its own thread. It's literally possible in BeOS/Haiku to lower the priority of a single radio button.
This is an OS designed around early '90s era dual CPU hardware. Considering that they made this choice at that time and still ended up with an OS that's remembered primarily for its performance and responsiveness when multitasking it seems hard to believe that threading overhead itself is too big of a deal even at extreme levels.
> IIRC super computers often need special interconnects and software to minimize the distribution costs of so many cores.
This is for entirely different reasons. The specialized supercomputer interconnects exist to minimize the cost of sharing data across nodes. Basically they provide DMA over a network fabric. It only really matters once your workload is large enough that you can't just throw a larger single machine at it but also impossible to split up in to smaller chunks that would fit within individual nodes.
If you're familiar with NUMA in multi-socket systems (or first-gen Epyc/Threadripper) you can think of the supercomputer interconnects as basically extending that principle up another tier to encompass multiple independent servers.
This is not true, individual widgets most definitely do not have their own threads. Windows each have their own threads, which is indeed different from virtually every other OS which does not have this (or even allow off-the-main-thread UI operations.)
The only reasonable option for UI rendering these days (high-DPI monitors) is to delegate rasterization to GPU. CPU is for running application logic. If you would do UI on CPU then this will be the only task your CPU will do. E.g. animations require stable frame rate (60 FPS or more) so UI must run on highest possible priority on your OS.
My comment is rather about "multi-core UI". Many UI tasks have almost real-time requirements (animations, synchronized rendering, video) so they behave as "make -j 4" meaning that the device is just busy rasterizing pixels but not doing anything meaningful.
And all that while we have dedicated powerful (YMMV) GPU that supposed to do those for us.
Obviously actual pixel rendering is is done on a GPU - why would you do it it anywhere else, but that's not what we're talking about here.
It could be that you need to “renice -5” X11 or something (I think some distributions used to tweak the UI runtime priorities. Not sure if they still do.)
Have you tried using nice(1) to set the make's priority lower?
That doesn't even run standard HTML/CSS/JavaScript. That fact alone would make me completely ignore it for any possible application.
This may very well be true depending on the use case, but I'd be very surprised if V8 doesn't just blow Sciter out of the water with regards to performance, like you can be a genius and come up with a comparable engine that's 50x smaller (e.g. QuickJS), but V8 is not big for bigness sake, it's also ~35x faster according to this: https://bellard.org/quickjs/bench.html
I'm mentioning QuickJS here because I couldn't find benchmarks comparing Sciter Script and V8, if anybody has some I'd be interested in seeing them.
And it really does not - in most of typical UI tasks Sciter is faster.
Reason is in different goals. Sciter is an embeddable engine. Script there is a glue: take output of one native function, transform it, and pass as input to other native function.
In places where UI needs maximum performance applications use native functions in C/C++, Rust, Go, etc. This allows to keep script VM compact and achieve maximum performance without sacrifices. Why do you need JIT or WebAsm (and tons of associated binaries) if you can compile what you need with battle-proof compilers to native code?
So good portions of jQuery were implemented natively. React[or] is also natively implemented - JSX is a part of script syntax (and so uses built-in native compiler), reconciliation (Element.merge()) is also native thus you don't need all that nightmare TS-to-JS, then load ReactJs script, then compile, then JIT-compile/warm-up, etc. All those ...
As of pure script performance ...
Slower than V8 but faster than, let's say, Python.
I'd really like to see some benchmarks about this, could you maybe make Sciter run the test suite QuickJS is benchmarked against and report back? https://bellard.org/quickjs/bench.html
> In places where UI needs maximum performance applications use native functions in C/C++, Rust, Go, etc.
That's cool, but I'm talking about JavaScript performance here, these kind of cross-language computations can totally be coded on top of Electron and I would imagine any other mature similar framework.
> if you can compile what you need with battle-proof compilers to native code?
The compiler might not be the problem here, not even the Chrome guys can manage to write completely memory-safe C++ for example, that's trivial to do in JavaScript and a reason why one might not want to write everything in C++ for example, among other potential reasons.
Typically we do not do such task in scripts. And indeed who would need ray tracing in script if you have native libraries for that? 100% that number crunching tasks will be slower in order of magnitude than native ones so why to bother?
For the comparison you can try https://notes.sciter.com/ that uses Sciter not just for UI but its logic layer is also using script (https://github.com/c-smile/sciter-sdk/tree/master/notes/res). The application has UI and complexity similar to VSCode, Slack, etc.
It is hard to come up with some formal benchmarks but startup times, CPU/RAM consumption, responsiveness can be estimated.
Those kind of synthetic benchmarks aren't there because ray tracing is what you would use JavaScript for, but for giving a measurable quantity about the speed of the interpreter.
Put it simply if V8 produces a number that's 10x higher than another interpreter you can be sure that it's going to be faster than that other interpreter pretty much across the board by a significant margin.
By the way V8 can compile some optimized JavaScript that executes at half the speed of optimized C++, not in "order of magnitude" slower, can Sciter do the same? I really don't think so, happy to be proven wrong with some numbers.
So can you run the benchmark suite with Sciter or not? Is Sciter even able to run it properly? Do you think that benchmark does an acceptable job at telling which interpreter is faster between the tested ones or not?
> The application has UI and complexity similar to VSCode
Sure it has, come on man, be real, there isn't even an app menu loading in this thing: https://i.imgur.com/MXw1LZX.png , this thing is crap.
These kind of claims are an insult to all the people working on VSCode.
> It is hard to come up with some formal benchmarks but startup times, CPU/RAM consumption, responsiveness can be estimated.
There are literally just already written benchmarks that one just runs and they output NUMBERS, how is that hard? Compare that to measuring "responsiveness".
that one has menu, check menu.htm in that sample: https://github.com/c-smile/sciter-sdk/tree/master/samples/id...
> So can you run the benchmark suite with Sciter or not?
Yes, I may do that but purpose is not clear. Their compiled C versions in Sciter will run definitely faster.
These functions have nothing with UI per se.
Yet, you can extend Sciter with native DirectX or OpenGL code (see: https://sciter.com/sciter-and-directx/) , that will definitely beat any possible browser/Electron solution. So script benchmarks are orthogonal to the reality.
They make sense in Electron case as JS is the only realistic option to write app code. But not in Sciter case. It is not a browser for that matter.
And applications that use Electron are not. Just because the only reasonable option (for many reasons) to write code there is script. And so each such application will have full blown web browser and web server (NodeJs) under the hood.
Last time I checked Evernote, mentioned in the page you linked, renders notes under macOS using WebKit, why don't they use Sciter?
Let's take some typical native GUI calculator application.
The code a) creates window by calling CreateDialog(...,template,...). That template sits in .RC file - that is UI layout and structure definition.
Then you have b) event handling code and c) so called business layer code (a.k.a. data model code) that does calculation that end up in UI again.
Same thing in applications that use Sciter. It is just that UI definitions are not in some proprietary format but in HTML/CSS. Rest is the same - event handling is done either in script (that will end up in some native calls) or directly in native code - Sciter allows event handlers to be defined in native code directly. So Sciter applications are native ones in this regard.
As of EverNote...
EverNote 2.0 was using what later will become Sciter Engine.
Please check my article: https://notes.sciter.com/2017/09/11/motivation-and-a-bit-of-...
At some point they hired technical director who made decision to switch to WebKit. No one knows reasoning behind that very bad decision (IMO) but the company lost innovation momentum somewhere around that time.
My https://notes.sciter.com/ is just a proof that you don't need WebKit for those tasks.
V8 in Electron comes bogged down with Chromium and its bloat. Sciter's engine does not. For building UIs, that's a huge difference.
But if you just need to create some relatively small utility, let's say, calculator.exe then it is pretty adequate for the task.
If you want to run something that is designed for Web browser then you need browser and server (Electron or Atom for example).
If making a calculator with web technologies is more important to me than making a very resource efficient one why would I _ever_ use Sciter for this that doesn't give me not proper web technologies to use and neither an actually resource-efficient calculator?
But even for more or less feature rich calculator, e.g. something like personal accounting/finances utility, you'd better have flexible UI.
Which would automatically mean Sciter would not be a good fit for this.
> you'd better have flexible UI.
If that's more important then why not going with proper web technologies?
I wonder how WPE [1] compares to that.
Sciter is a really cool technology. However I've always wanted to ask you - do you ever feel that your deviation from standards has reduced your market? I was considering Sciter for a project previously, but ultimately decided against it because it required me to write two separate implementations for desktop and browser.
There's obviously benefits from deviating from HTML / CSS / JS, they're very much products of history. Sciter's native (and seamless) custom HTML tags, some built-in preprocessing, being more immediately feature complete, all just wonderful. I'd just like to hear your specific reasoning, though.
And if you're able to comment on it, how many people maintain this project? It seems like a huge task, but most of the discussions I've seen hint toward it just being yourself.
Finally, how is accessibility support? This seems like a big point, but it's not directly addressed in the documentation I've seen. In one forum post I saw you say that Sciter assigns some screen reader semantics based on a custom behavior tag in the CSS?
Just an example why that happens: Sciter got flexes and grid 10 years ago as they are the must for desktop UI. Web platform got them practically only in couple of last years. And it is simply to late to change anything - many customers rely on them. But its quite easy to solve this problem using @media sciter {...} sections. Features are easily transformable: https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox....
Same is about script. classes, namespaces, symbols, async/await were in Sciter 7 years ago - I cannot change too much there. Support of existing customers is very critical for me.
> how many people maintain this project?
I did Sciter by myself only. Beside of customers there are three independent developers (Russia, Brazil and France) that requested and have access to Sciter source tree. I am accepting patches from them and customers. 3 AV vendors independently did security audit of the code. Yet Symantec (Norton Antivirus) provided Accessibility support implementation as for them Section 508 was the must.
These guys are obviously immensely impressive, but they're only one part of the chain. It frustrates me to this day that the UK market doesn't allow you to pick the DVB+IPTV STB you want and just expect it to work with any and all services.
That's not true anymore with webrender. It's available in FF for a while.
They started out as an SVG engine for set-top boxes (embedded devices running on TV's) since browsers at the time weren't fast/light enough for the underpowered chips in set-top boxes. Then when the devices got better chips, they realized perf still wasn't good enough for big 4k screens – and that multicore rendering could help.
So they've implemented a full HTML/CSS/JS browser from scratch, all to take advantage of a multicore architecture (today's browsers all render on a single thread) which has enabled (they claim) greater than 4x better framerate during web animations than the stable channels of Chrome/Blink and Safari/Webkit. Oh, and 60% faster layout on a quad-core machine.
They also claim "extremely low memory consumption", which would be quite appealing to many HN'ers I think, though that may only be true of their HTML engine and not of the full browser (eg; when using multiple tabs and hungry JS apps).