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

The Firefox UI Is Now Built with Web Components

briangrinstead.com

Post reply on HN
Print view View original

231–240 of 260 posts

Re: The Firefox UI Is Now Built with Web Components

#231

Post by jcelerier »

weberc2 wrote: post #174
buboard wrote: post #128

Earlier quoted context omitted.

There are a ton of cross-platform GUI libraries

As someone who loves the idea of a good cross platform GUI, there simply aren’t any. GTK and Qt are the closest, and GTK is garbage. Qt is awful, but manageable. You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator) or use a leaky Python binding (that still segfaults), but you can build things that don’t look awful. As far as I know, this is the only cross platform GUI tool for…

> You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator)

Qt's "dialect" is just C++ - the signals:, slots:, emit etc... things are just plain preprocessor macros which resolve to nothing (https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kerne...). If your editor does not support resolving empty macros it does not support C++ at all anyways.

Re: The Firefox UI Is Now Built with Web Components

#232

Post by weberc2 »

jcelerier wrote: post #231
weberc2 wrote: post #174

Earlier quoted context omitted.

As someone who loves the idea of a good cross platform GUI, there simply aren’t any. GTK and Qt are the closest, and GTK is garbage. Qt is awful, but manageable. You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator) or use a leaky Python binding (that still segfaults), but you can build things that don’t look awful. As far as I know, this is the only cross platform GUI tool for…

> You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator) Qt's "dialect" is just C++ - the signals:, slots:, emit etc... things are just plain preprocessor macros which resolve to nothing ( https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kerne... ). If your editor does not support resolving empty macros it does not support C++ at all anyways.

This misses my point. If I create a language and assign different semantics to the Python AST, an editor that supports Python does not meaningfully support my language. The syntax highlighting will work, but any semantic analysis will break.

That's what you get with Qt absent the moc (meta object compiler).

Moreover, there is still a host of reasons why Qt is a painful developer experience (even though it is probably the best cross platform native option). For example, even if you solve the editor problem, you can't reliably use C++ templates, and Qt has its own strings, lists, hashmaps, concurrency mechanisms, memory model, etc. And even if it were just C++, C++ itself is a pretty poor experience compared to other languages on the market these days.

So Qt might be the best thing on the market today, but it's not hard to imagine much better alternatives. For example, browser support for native system things that would render electron obsolete (especially as WASM matures) or perhaps Flutter as its desktop story matures. Or maybe even a mature intermediate GUI toolkit in a modern language.

Re: The Firefox UI Is Now Built with Web Components

#233

Post by spankalee »

interlocutor wrote: post #228
spankalee wrote: post #192

Earlier quoted context omitted.

It handles all of that.

That does not appear to be correct. https://github.com/Polymer/lit-html/wiki/How-it-Works#4-upda... Excerpt: update() simply iterates through each part and value (the parts array and values array are always the same length) and calls part.setvalue(v) for each part. https://lit-html.polymer-project.org/guide Excerpt: Behind the scenes lit-html creates HTML elements from your JavaScript templates and processes them so…

It is very correct: lit-html is amongst the fastest template systems in use right now. This is shown in every benchmark I've seen or made for it.

lit-html updates only the parts of DOM that are dynamic and change. It handles nested templates as values, only updating the whole nested template if the template itself changes, otherwise recursing and only updating that template's values if needed. Repeated DOM is handled either by simply updating state for each item in sequence (non-keyed), or by using the repeat() directive which will move DOM (keyed).

You absolutely don't need to manually update DOM. The whole point is to describe your DOM structure as a function of data, and to be to describe all the conditional / repeated parts in the template expression itself.

Re: The Firefox UI Is Now Built with Web Components

#234

Post by alexkoeh »

jasonlaster11 wrote: post #37
BoumTAC wrote: post #20

can it cause perfomance issue ? I know for example the devtool is written in react and it's a lot slower than chrome devtools (I don't know how chrome devtool is written) and the javascript debugger is sometime not even usable because it's so slow.

Hi, Firefox DevTools Debugger engineer here. We've focused on performance and quality over the past six months and believe it should be much better. If you're still seeing issues, feel free to record a performance profile and send it to us: - https://profiler.firefox.com/ - https://bugzilla.mozilla.org/enter_bug.cgi?product=DevTools&... I'd be happy to fix it!

Is it possible for Cmd+P to work when you don't have the Debugger tab in focus? That one of the few things I miss from Chrome dev tools.

Performance-wise it's been running great for me. The hard work you've put into this definitely shows.

Re: The Firefox UI Is Now Built with Web Components

#235

Post by ShinTakuya »

ajxs wrote: post #147
pault wrote: post #103

Earlier quoted context omitted.

The problem with electron isn't JavaScript, it's running an entirely seperate instance of an infamously memory hogging web browser, that comes with an enormous amount of features that aren't utilized by the application. The JavaScript runtime itself is not going to cause noticable slowdowns or memory use, especially so if you already have one running anyway as is the case for Firefox.

> running an entirely seperate instance of an infamously memory hogging web browser Without looking at the source-code: Doesn't this problem still exist, just in a different form? You're still running some kind of browser instance to render the UI, rather than using native methods.

Yes, but this is the UI of a browser. Arguably it could be more efficient to do it this way as you can strip out some of the libraries used for the native rendering.

Re: The Firefox UI Is Now Built with Web Components

#236

Post by jcelerier »

weberc2 wrote: post #232
jcelerier wrote: post #231

Earlier quoted context omitted.

> You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator) Qt's "dialect" is just C++ - the signals:, slots:, emit etc... things are just plain preprocessor macros which resolve to nothing ( https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kerne... ). If your editor does not support resolving empty macros it does not support C++ at all anyways.

This misses my point. If I create a language and assign different semantics to the Python AST, an editor that supports Python does not meaningfully support my language. The syntax highlighting will work, but any semantic analysis will break. That's what you get with Qt absent the moc (meta object compiler). Moreover, there is still a host of reasons why Qt is a painful developer experience (even though it is probably…

> This misses my point. If I create a language and assign different semantics to the Python AST,

but which semantic differences are you talking about ? It is plain C++. Function calls are function calls, the only difference being that some are auto-generated and some are your own code.

Re: The Firefox UI Is Now Built with Web Components

#237

Post by everybodyknows »

jasonlaster11 wrote: post #37
BoumTAC wrote: post #20

can it cause perfomance issue ? I know for example the devtool is written in react and it's a lot slower than chrome devtools (I don't know how chrome devtool is written) and the javascript debugger is sometime not even usable because it's so slow.

Hi, Firefox DevTools Debugger engineer here. We've focused on performance and quality over the past six months and believe it should be much better. If you're still seeing issues, feel free to record a performance profile and send it to us: - https://profiler.firefox.com/ - https://bugzilla.mozilla.org/enter_bug.cgi?product=DevTools&... I'd be happy to fix it!

To any other devs who like me who want to use Firefox Debugger, but were driven back to the devil Chromium by need for consistent, seamless copy-paste and select-middlemouse interaction: Give 70.0.1 a try. Much, much better. So much that I've dropped Chromium. (Ubuntu 18.04)

Re: The Firefox UI Is Now Built with Web Components

#238

Post by weberc2 »

jcelerier wrote: post #236
weberc2 wrote: post #232

Earlier quoted context omitted.

This misses my point. If I create a language and assign different semantics to the Python AST, an editor that supports Python does not meaningfully support my language. The syntax highlighting will work, but any semantic analysis will break. That's what you get with Qt absent the moc (meta object compiler). Moreover, there is still a host of reasons why Qt is a painful developer experience (even though it is probably…

> This misses my point. If I create a language and assign different semantics to the Python AST, but which semantic differences are you talking about ? It is plain C++. Function calls are function calls, the only difference being that some are auto-generated and some are your own code.

C++ has no notion of signals and slots or other metaobject utilities. Your editor cannot autocomplete those signals/slots like Qt Creator. Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.

Re: The Firefox UI Is Now Built with Web Components

#239

Post by Asooka »

Crinus wrote: post #218
interlocutor wrote: post #120

Earlier quoted context omitted.

What are you talking about? There is hardly any API. https://developer.mozilla.org/en-US/docs/Web/Web_Components/... It is extremely simple.

First time reading this. On one hand it looks neat. This is something i expected browsers to be able to do since i noticed that Mozilla (pre-Firefox) implemented (or ?) in JavaScript. On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like and the JavaScript side will do the rest. But being able t…

>On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like and the JavaScript side will do the rest.

This is already the case on a lot of sites, just not standardized. With the standard you could sandbox the javascript or maybe implement specific parsing for the most common web components.

Re: The Firefox UI Is Now Built with Web Components

#240

Post by tracker1 »

eloisant wrote: post #216
marcosdumay wrote: post #100

Earlier quoted context omitted.

From my POV, it didn't catch on because: - It had all the problems of Electron in a time where memory was a much more of an issue - Low quality documentation that didn't go into the details (although it had a great overview) - Performance problems due to the high abstraction level and bad JS interpreter - Memory leaking that appeared on several versions and disappeared on other versions, that randomly affected people…

It didn't catch on because Mozilla never gave a shit about XULRunner, and they were clear about it. In the late 2000's there were many companies who launched products based on XULRunner (Miro, Songbird, Joost, Tom-Tom...), but when they encountered bugs in the platform Mozilla's response was always "bug doesn't affect Firefox, we don't care". Even if you made a PR yourself (actually a patch at the time), good luck to…

I have to agree... I'd wanted to use it for a few things in the early 00's, but the support just seemed absent.
Post reply on HN