Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lightweight SQLite Editor for Windows

github.com

Post reply on HN
Print view View original

91–100 of 114 posts

Re: Lightweight SQLite Editor for Windows

#91

Post by bayindirh »

Aeolun wrote: post #56
leke wrote: post #39

Earlier quoted context omitted.

dBeaver is written in Java, but it feels very lightweight. I'm running it on a Linux desktop I've been using since 2014. It's also cross platform so I run it at work on a Windows laptop.

You think? Just looking at the interface and all the buttons/options screams ‘exhaustive/heavy’ to me. It’s pretty fast for a Java tool, but I wouldn’t call it snappy.

Written correctly, Java can be both very fast and light. Eclipse IDE, written with Java consumes less resources than a comparable Atom/VSCode instance, with more features enabled.

Re: Lightweight SQLite Editor for Windows

#92

Post by vetinari »

bayindirh wrote: post #91
Aeolun wrote: post #56

Earlier quoted context omitted.

You think? Just looking at the interface and all the buttons/options screams ‘exhaustive/heavy’ to me. It’s pretty fast for a Java tool, but I wouldn’t call it snappy.

Written correctly, Java can be both very fast and light. Eclipse IDE, written with Java consumes less resources than a comparable Atom/VSCode instance, with more features enabled.

Electron apps are not exactly lightweight either; it is about first time that someone uses them in an argument.

Query Analyzer was written with win32-api. No electron, no java, no c#, nothing (thought it might used MFC, not sure about that). It was snappier on Pentium 3 than Dbeaver is on M1 or Threadripper. Existence of slow molasses like Electron won't change that.

Re: Lightweight SQLite Editor for Windows

#93

Post by bayindirh »

vetinari wrote: post #92
bayindirh wrote: post #91

Earlier quoted context omitted.

Written correctly, Java can be both very fast and light. Eclipse IDE, written with Java consumes less resources than a comparable Atom/VSCode instance, with more features enabled.

Electron apps are not exactly lightweight either; it is about first time that someone uses them in an argument. Query Analyzer was written with win32-api. No electron, no java, no c#, nothing (thought it might used MFC, not sure about that). It was snappier on Pentium 3 than Dbeaver is on M1 or Threadripper. Existence of slow molasses like Electron won't change that.

I didn't use DBEaver, but written some Java and using Eclipse for 20 years.

Java's UI libraries are extremely prone to wrong initialization. If you skew from the reference guide's implementation, Java's libraries try to mend the problems themselves, but this adds observable latency to the UI.

Of course, Java is never as fast as natively compiled language, but asymptotically approach to that speed and come pretty close. The funny thing is, some of the today's native applications are both heavier and less responsive w.r.t. their Java counterparts. This is because we tend to add loads of dependencies which aims to simplify development in said language, but that price is always paid at the end. Either once by the developer, or repeatedly by the user.

Re: Lightweight SQLite Editor for Windows

#94

Post by Circuitstorm513 »

trelane wrote: post #23
hochmartinez wrote: post #19

Linux version, please!

If it were written for Linux first, it would even be available for Windows simultaneously.

It would also be much more bloated (and not feel native) on Windows. Qt is what now? 30 or 50 MB? GTK probably much better these days. For that size you can almost go to Electron and get better look and feel (at the cost of RAM) ;-)

Re: Lightweight SQLite Editor for Windows

#95

Post by kyrra »

scary-size wrote: post #90
kyrra wrote: post #89

Earlier quoted context omitted.

Googler opinions are my own. I know little about BQ. My understanding of Big query is that at least some of the tech it's based on allows for handling very large datasets. I'm talking being able to search BI that is petabytes in size. I don't think it's really designed for small datasets. If you can stick the data in SQLite, I think you're using the wrong tool. Searching around, it looks like BI Engine may help in ca…

That's true. Most of our production data is in the "petabyte" category. But often we start out with a small amount of data, for example for a new feature or product. That's when a lot of the exploration and query building happens. Once that's done, we leverage BigQuery to scale this up, serving a few hundred million users. There's a platform/standardisation component to this as well. We want our devs to use a single…

Totally makes sense, I guess I do the same thing internally (using partitioned tables, so the queries are a lot smaller, or making sure to only select the minimum columns to prove my query is correct). I also have no clue if my internal queries end up using something like BI Engine where it'll cache data in memory (much of this is opaque to me), but turn around is at least a few seconds per request. Your point is valid here, thanks for raising it.

Re: Lightweight SQLite Editor for Windows

#96

Post by whizzter »

RedShift1 wrote: post #62
whizzter wrote: post #31

Earlier quoted context omitted.

You didn't happen to look at those files? main.cpp is 8900 lines, dialogs.cpp something almost as long. It's probably super performant but I wouldn't volounteer to maintain that codebase unless getting paid (And the commit history only shows the author...)

A good IDE makes it very easy to navigate through files like that. You navigate to functions, structures, variables, etc... instead of files.

That's nice until it breaks down, besides doesn't help much if you have 2400 lines long functions ( cbMainWindow ) that mixes Win32 API drudgery with indentation logic and SQLite fiddling.

Sure it's an cute and to-the-point codebase, but even if I have experience with using these API's I'd never volunteer to work on this codebase because it's obviously also one that's a creation of the authors memorized experience.

Re: Lightweight SQLite Editor for Windows

#97

Post by oblio »

jansommer wrote: post #84
jansommer wrote: post #77

Earlier quoted context omitted.

That is not the default Win32 combobox. I don't know what you're using, but it's not the plain c api.

binjooou: The whole point for me when using win32 is to use the default look, since it's a better ui compared to todays flat design. But I acknowledge that there could be a little less dpi work associated with enabling visual styles.

The best UI is the UI your users are used to, and 1% of Windows users are used to the Win 2000 gray UI.

Win XP came out 22 years ago.

Re: Lightweight SQLite Editor for Windows

#98

Post by oblio »

TheRealPomax wrote: post #58

But why is it Windows only? Even as a Windows user, my professional day is spent on a Mac even if my Windows machine is running at the same time. What arcane library does it rely on that it can't just cross-compile for all three operating systems?

Great question. What arcane libraries do all those Mac-specific text editors, IDEs, etc that Mac users rave about use, that they can't be cross-compiled for all three operating systems?

Re: Lightweight SQLite Editor for Windows

#99

Post by jansommer »

jansommer wrote: post #84
jansommer wrote: post #77

Earlier quoted context omitted.

That is not the default Win32 combobox. I don't know what you're using, but it's not the plain c api.

binjooou: The whole point for me when using win32 is to use the default look, since it's a better ui compared to todays flat design. But I acknowledge that there could be a little less dpi work associated with enabling visual styles.

oblio: Have you seen the other comments for this post? There's plenty of people who think the default win32 gui is awesome.

Re: Lightweight SQLite Editor for Windows

#100

Post by dataflow »

jansommer wrote: post #77
dataflow wrote: post #75

Earlier quoted context omitted.

I didn't assume you'd give a helpful answer, but I didn't expect you to give that kind of an answer, either. You're always welcome not to respond if this is taking too much of your time. I figured maybe at least one of us would learn something about high DPI issues, hence why I engaged. And I did just try what you said and the combo box fine to me: https://imgur.com/a/Mb83tPj

That is not the default Win32 combobox. I don't know what you're using, but it's not the plain c api.

This is most definitely the default combo box. In fact, I just tried the version without visual styles as well, and that one looks fine under high DPI too (see screenshot). At this point I'm very confused what you are doing. Perhaps you're not on Windows 10?
Post reply on HN