411–420 of 443 posts
Earlier quoted context omitted.
Opera and IE were no different in architecture.
What are you referring to? Opera and IE certainly used different rendering engines: Trident for IE, Presto for Opera (before it moved to Blink).
Earlier quoted context omitted.
What bothers me about being older is my first browser was Internet Explorer, then I got to play with MOSAIC's slow arse in school, then used Opera/Mozilla, and so on. Got to see where it came from. And the new stuff, especially Firefox, is coming full circle in how friggin' slow they run to serve the lowest common denominator of web pages. It's annoying. I miss Web 1.0. Add just a bit of dynamic functionality plus br…
Disable javascript. Seriously. Disabling js has given me the fastest turn-round on page-load times. It's usually not the browser, but loading 15 different un-optimized JS engines that causes the problem.
Earlier quoted context omitted.
I am 29, started coding at 14, I've built UIs based on mIRC Scripting, VB/Winforms, C++/Qt, C#/WPF, Java/Android layouts. Using IDEs such as Visual Studio, Eclipse, Qt Creator and Android Studio. I must say: Atom Editor is great. Using HTML/CSS/JS to build desktop/mobile apps really makes sense to me, especially given that: - You only have to support one rendering engine. - You have access to the latest Web Component…
The fact that you are being(edit: was) downvoted for constructive opinion shows unwarranted prejudice of HN hivemind towards web technologies. HN discussions on this topic are effectively useless, any constructive truth finding is drowned. edit: I'll take my downvotes with pleasure. The fact that I am able to use Atom or Nylas N1 or Nuclide on linux with 0 problems alone is enough to welcome proliferation of web tech…
Earlier quoted context omitted.
> They already do. Electron, Web Components, etc... And nobody can agree on which to use. It's not standard if it's just "some set of components some people reuse". A far cry from standardization. > Compare the performance of vanilla JS vs. asm.js. That's not what I'm comparing. I'm comparing the performance of native toolkits vs web toolkits on asm.js. It pales in comparison, and the battery usage is through the roo…
> "And nobody can agree on which to use. It's not standard if it's just "some set of components some people reuse". A far cry from standardization." Atom uses Electron, VS Code uses Electron, Light Table uses Electron (starting with v0.8). As for the web side, web apps are a young field, what else would you expect? There are certainly popular UI elements, Bootstrap for example. If you want to make an web app that loo…
Earlier quoted context omitted.
Yes! JS, Python and Ruby are just "dead simple" "scripting" languages that only serve to "make a shitload of money" and aren't "real programming". Real programmers (like me) use C. Seriously, no. Just no. And if I wanted to prevent people from writing "the most disastrous code in the whole universe", teaching C instead of JS would be much, much lower in the list than teaching how to split code into modules/libraries,…
> And if I wanted to prevent people from writing "the most disastrous code in the whole universe", teaching C instead of JS would be much, much lower in the list than teaching how to split code into modules/libraries, write testable code, etc. And for me that would be much much lower than teaching how to keeps things simple. The whole modern web has a bad case of over engineering, everything is modules of modules of…
I didn't make fun of C. I made fun of a comment posted by a C programmer, which is very different. I have absolutely nothing against C.
> C will teach you to keep you programs simple and efficient, because the language requires it
From what I've read, the OpenSSL codebase is definitely not simple, and I'm not sure it's efficient either—it would depend on how you define efficiency. So your affirmation seems factually incorrect.
Other than that, I agree with your post. Simplicity is awesome. No point in using Angular to build a landing page if static HTML can do the job just as well. (Edit: let me take that back. There can be a point: the pleasure of experimenting and learning something new.)
Earlier quoted context omitted.
But, sadly, they aren’t replacing XUL with HTML. Instead, they plan to render the UI natively, with only "some" parts in HTML. So, instead of XUL + HTML, we’re going to get GTK + WinForms + Cocoa + HTML. Great, eh? And we lose the ability to style it with addons – your themes can only change the background image of the header bar, that’s it. And the remaining addons can’t modify the UI (tree style tabs, bottom tabs,…
Yes the plan is to replace XUL with HTML. I have no idea where you heard otherwise.
Official statement from the Mozilla post in the discussion regarding removal of support for "heavyweight" themes. Emphasis mine.
That’s a pretty clear statement that it won’t be 100% HTML.
Also, the fact that "arbitrary styling and scripting" won’t be possible is another issue.
Tell me how I am supposed to write an addon that adds tab-previews as thumbnails when you hover over a tab like Vivaldi is doing it: http://i.imgur.com/vqysJs1.png ?
How am I supposed to write an addon that colors the navbar and the current tab in the theme color given by the HTML, or, if not existing, the favicon?
With current addons I can do that, with the new addon system, I’m seriously fucked.
Earlier quoted context omitted.
I'm all for writing new apps in HTML, I think Atom and VSCode are awesome, but I'm not for rewriting huge legacy apps to be HTML apps for no good reason. The reasons given, that XUL requires maintenance that Mozilla engineers don't enjoy doing, is a joke considering the amount of effort to maintain XUL is less than 1% of the amount of effort to move Firefox to HTML. No one has listed the ten awesome features that we'…
> The reasons given, that XUL requires maintenance that Mozilla engineers don't enjoy doing, is a joke considering the amount of effort to maintain XUL is less than 1% of the amount of effort to move Firefox to HTML. Ah, but maintaining XUL means working on old code (which is boring), but moving Firefox to HTML means working on new shiny code (which is exciting). https://www.jwz.org/doc/cadt.html
I think this is the 3rd time I've heard Thunderbird is/is going to be unmaintained and that I should avoid it, but I'm yet to see a good alternative. Claws was crashy and didn't DPI scale properly on Windows, OS X Mail had strange behavior with my IMAP server and I just wanted a consistent UI with my Windows and Linux system. My next option is webmail but there's no good IMAP webmail client that seems to be able to h…
> probably Alpine, a CLI based client I think that Mutt might be a better option in that I think it is still maintained.
