[HN Gopher] Show HN: FixBrowser - a lightweight web browser crea...
___________________________________________________________________
Show HN: FixBrowser - a lightweight web browser created from
scratch
Hello, I'm working on a web browser that focuses on being truly
lightweight and designed for privacy. At some point I've realized
that much of the complexity and resource requirements of web
browsers comes from JavaScript. This is because every part needs to
be dynamic and optimized for speed. So a few years ago I've
started to work on a web browser that intentionally doesn't
implement JavaScript, instead it contains an updated set of scripts
that fix and improve various websites. I've been using this
approach using a proxy server for a few years as my primary way of
web browsing with good results. It uses a whitelist approach where
no resources are loaded from different domains by default (the fix
scripts can override it to load images from CDNs, etc.). This
avoids any trackers by default. You can find more details on the
homepage of the project: https://www.fixbrowser.org/ I'm
currently running a fundraiser to get it really going. All the
foundation blocks are there it just needs some more work. Any
support is welcome.
Author : jezek2
Score : 298 points
Date : 2024-12-25 03:08 UTC (1 days ago)
(HTM) web link (www.fixbrowser.org)
(TXT) w3m dump (www.fixbrowser.org)
| forgotmypw17 wrote:
| This is awesome, like a new Dillo!
|
| Thank you so much for making this project.
|
| I'll be adding it to my test suite.
| benatkin wrote:
| Wow, 25 years old! https://dillo-browser.github.io/
| pbronez wrote:
| And still under active development! Looks like they had two
| releases this year.
| sylware wrote:
| You have netsurf which is a CSS renderer, better than dillo
| since it is written in C and not some computer language with a
| grotesquely and absurdely complex syntax/size.
| forgotmypw17 wrote:
| Thank you for reminding me to give NetSurf another try. No
| package in Ubuntu for some reason, but relatively easy to
| compile from source.
| ajot wrote:
| Weird, Debian has NetSurf in its repos (netsurf-gtk, or
| netsurf-fb if you want to render it directly to framebuffer
| with no UI toolkit)
| forgotmypw17 wrote:
| Thanks, I was able to install netsurf-gtk just fine.
|
| It would be nice if `apt install netsurf` returned
| something more helpful than "Unable to locate package
| netsurf"
| sylware wrote:
| netsurf is using the GTK+ toolkit.
|
| The thing is I was about to build my own browser with
| netsurf components (but probably with my own toolkit)...
| then I stumbled upon the fact that it won't help much
| more than to use links or lynx since sites are getting
| javascript-walled. At best I would get a CSS renderer,
| coded in plain and simple C99+.
|
| Since Big Tech controls the software to access their
| online service, they will give hell to any promising
| real-life alternative.
|
| To say that the only sane way out of this, is not even
| coding a plain and simple C99+ real-life javascript web
| engine, but ensure by law/regulation that all
| "utility/critical" sites have a working and sane
| noscript/basic (x)html portal (as 100% of them had a few
| years ago...............)
| benatkin wrote:
| You don't say that it's an experiment or just for learning how to
| write a project. You suggest it will be competitive in simplicity
| or speed. I find this hard to believe.
|
| A project based on servo would be more credible. Sure, those
| developers are building JavaScript engines. However, their
| browsers are highly modular and you could do a build without
| JavaScript, a lot more easily than with the major browser
| engines.
|
| In addition, it uses your own programming language, and there is
| no source repo.
|
| Edit: I see the purpose of it better now. It would perform very
| well, but not compared to other browsers that had the same
| modifications. However, since other browsers don't have the same
| modifications, it would work comparatively well for the sites it
| would work with.
|
| If you wanted to make it run fast with while supporting a lot of
| sites, and still be simple, I think using Servo would be a
| quicker path. They've already solved a lot of layout problems.
|
| Good luck with it.
| codetrotter wrote:
| > there is no source repo.
|
| However, they do provide a zip file containing source.
|
| At least it's open source although for some reason they are
| choosing to not use a version control system.
| jezek2 wrote:
| It's mostly for practical reasons. I use Monotone for VCS
| which is not an active project (but a good SW regardless).
| Then there is the issue with having additional stuff in the
| repository that is meaningful just for me but I don't intend
| to release it (or not in the current form).
| jezek2 wrote:
| Using a full browser engine with JS disabled is not the same as
| you won't get the architectural benefits of not having to
| support dynamic changes by JS at all.
|
| It allows for a much simpler one-way processing from one stage
| to another. In comparison a full browser must maintain data
| structures for fast dynamic changes by JS, making it much more
| complex. I've written about it in a more detail in the About
| section.
|
| Embedding of a full browser engine as an option is planned,
| I've chosen CEF as the most suitable choice. It could be used
| for specific tabs or websites (eg. applications) while being
| integrated with the rest of the browser. However CEF is not
| very portable so it won't be available for all planned systems.
|
| This way you would use it only for websites/applications that
| need it while saving resources when browsing the rest of the
| websites.
| rapnie wrote:
| Idea. Wasm packaging and then running FixBrowser embedded in
| a webapp. Then use any browser with that webview providing
| safe whitelisted browsing.
| barlog wrote:
| Thanks, author.
|
| It must take courage to disclose your product to HN.
|
| We need to return that courage with an attempt.
|
| First, the evaluation. Then constructive comments.
| cyberax wrote:
| Wow. This is awesome in all the wrong ways. I can't decide if I
| hate it or love it.
|
| It uses its own language, it's really written from scratch to
| such an extent that it uses direct C API for Cocoa on macOS
| instead of the usual approach of just using a couple of Objective
| C files. The code is not in a version control, and I have not
| seen a single comment apart from the copyright headers.
| jezek2 wrote:
| Haha I like this take.
|
| Using of C API for Cocoa is for compatibility reasons, using
| ObjC API is fully supported by Apple so it's not an hack in any
| way. Normally the used SDK dictates the minimum version of the
| OS and it's harder to support multiple versions. With using
| ObjC API directly any MacOS from 10.6 up can be supported
| easily.
|
| I've used similar approach for Haiku, it uses C++, this is more
| hacky but given their strong stance on binary compatibility it
| is fine and worked well across multiple releases without any
| changes so it's clearly a valid approach :) The reason is that
| I had big issues to get a C++ cross-compiler working for Haiku
| - supporting many platforms is not an easy task when you want
| to provide prebuilt binaries from a single VM.
|
| As stated in other comment, I'm using Monotone VCS for version
| control and have other reasons as well.
|
| As for the code comments, generally I don't need them, the code
| tends to be self-describing. And when I need them it is for
| describing something intricate which I generally find out later
| when I need it, at that point I document it because it's
| clearly needed, but also at that point I know _exactly_ what to
| document. Better to avoid intricate things though.
|
| On the other hand I should focus more on the architectural
| documentation that I've partially written but needs to be
| improved and expanded.
| coolcoder613 wrote:
| It's good to hear you are supporting Haiku. Are you around on
| the Haiku forum or IRC?
| jezek2 wrote:
| Yeah, I'm on the Haiku IRC.
|
| Haiku impressed me so much that even when I'm unlikely to
| use it as an user (mostly because I have already usable
| setup that I like), I've found it very good and polished.
| So I've decided that all my software will get 1st class
| support for Haiku :)
| codetrotter wrote:
| > I've decided that all my software will get 1st class
| support for Haiku
|
| That's seriously awesome. Kudos :)
| wmlive wrote:
| Since this is using Cocoa and one of the targets is MacOS,
| have you considered using the GNUstep framework {instead
| of|in addition to} gtk* for the Linux side of your browser
| project?
| jezek2 wrote:
| I'm targetting GTK because it's the most common toolkit and
| it is easy to interoperate from other languages. I will
| also attempt to do a Qt/KDE support at some point in the
| future, but C++ is more complicated with binary
| compatibility. GNUstep seems like something that not many
| users have installed.
| swiftcoder wrote:
| > it uses direct C API for Cocoa on macOS instead of the usual
| approach of just using a couple of Objective C files
|
| This is how almost all other languages implement Cocoa support,
| btw. With a few weird exceptions like Apple's Objective-C++
| compiler, most everyone implements FFI by chaining together
| LanguageA -> C -> LanguageB.
|
| Otherwise you'd have to build an N-to-N matrix of cross-
| compilers, and it becomes a whole mess.
| freeone3000 wrote:
| This very approach seems to pre-determine a centralized internet,
| where the dynamic behaviour that you care about belongs on a
| short list of websites whose functionality can be implemented by
| hand...
|
| I suppose my idealism is running hard into reality. Obviously,
| this project _is_ feasible and _does_ work for many sites (not
| YouTube or Netflix, due to lack of <video>, but does work for
| CNN and HN and acoup.blog and...). I want to live in a world
| where either this is wildly successful and everybody _knocks it
| off_ , or a world where this is completely impractical because
| everyone is doing Cool Art Things and this simply would be
| impractical. But this world where it's practical, but unloved...
| do not like that.
| slackfan wrote:
| Huh? We had this exact thing with cgi scripts and html 4.1, and
| dynamic behavior that we cared about was on a lot of websites.
| spencerflem wrote:
| I think that's what OP was getting at - if FixBrowser was
| very popular, then servers would use CGI etc. for dynamic
| behaviours, but its not and they don't.
|
| Instead the community is relied upon to reimplemented the
| behavior in FixScript which means by necessity only a smaller
| number of popular sites will load correctly m
| devindotcom wrote:
| cool. i support stuff like this even if it isn't quite usable for
| me or, really, practical even if it was! but i like to know it's
| there and if it was reasonably complete i would for sure keep a
| stable version on my machine.
| hxii wrote:
| This project, the approach contained within, the wording,
| license, the programming language used, the lack of a publicly
| accessible repository all have, in my opinion, a highly
| opinionated, "artisanal" approach (the reasoning behind which I'm
| not entirely able to comprehend) that seem to scratch the authors
| itch, but otherwise disregard the state of the web and what basic
| expectations other users have.
|
| Regardless, good luck to the project. Would be interesting to see
| the end result.
|
| To the author - there are certain social (and developer)
| expectations I would suggest you look into, e.g information about
| you (considering you are asking for donations; who am I donating
| to?) and a public repository people contribute code to. King of
| my own castle approach won't really work here.
| swiftcoder wrote:
| > that seem to scratch the authors itch, but otherwise
| disregard ... basic expectations other users have
|
| Isn't that kind of the whole ethos of free software? The
| current capitalistic view that open source is a (unpaid) job
| producing a product seems... unsustainable
| mbrock wrote:
| the current capitalistic view is that open source is a way
| for corporations to cooperate and it seems be working fairly
| well
| hxii wrote:
| I understand the ethos of free software, but there's a
| significant difference between a personal project with unique
| quirks and a public project seeking monetary and development
| contributions.
|
| Deliberately going against commonly accepted practices--like
| not providing a public repository--can be counterproductive
| to the project.
|
| For example, the 'submit code changes via email' approach
| comes across as 'you can help, but I'll privately decide if
| your help is good enough' which might discourage potential
| contributors.
| GoblinSlayer wrote:
| >you can help, but I'll privately decide if your help is
| good enough
|
| That's literally how opensource works.
| palata wrote:
| It definitely is, but it seems like a whole lot of
| developers do not know it.
|
| Which makes sense: they have to learn about it, and it
| takes time.
| swiftcoder wrote:
| > you can help, but I'll privately decide if your help is
| good enough
|
| That seems pretty much identical to how most of the high-
| profile open-source projects run.
|
| Ever tried submitting a patch to Android? or even the Linux
| kernel?
| GoblinSlayer wrote:
| What do you need a publicly accessible repository for?
| amatecha wrote:
| this is awesome - thank you! I look forward to trying it!
|
| I wonder if you could apply for some funding from
| https://nlnet.nl/ ?
| christina97 wrote:
| Hot tip: don't include a field for requests on your donation
| form!
| jezek2 wrote:
| Good point, I've renamed it suggestions unless someone else has
| better wording for it :)
| shinycode wrote:
| With all the SPA out there I find it hard to believe we are
| building js-less websites today ... maybe it's a browser made to
| navigate the past and small blogs ?
| GoblinSlayer wrote:
| I think a lot can work this way. Something is intentionally
| webapps, like google, those won't work, yes.
| danlitt wrote:
| In my experience, missing out on SPAs is not a particularly
| extreme hardship.
| hsbauauvhabzb wrote:
| I mean, as long as you don't mind not being able to access
| the vast majority of published content, news and social
| media, that is.
| MrVandemar wrote:
| News? Tripe riddled with advertising and tracking. Social
| Media? Opium for the masses. "Content"? Increasingly
| consists of ChatGPT regurgitant.
|
| I don't see any loss of value there.
| GoblinSlayer wrote:
| IME news sites are noscript compatible. The only
| exception is forbes. Oh and advertising doesn't work
| without scripts.
| mrweasel wrote:
| There's a few weird ones. I worked with a company that has
| what in my mind should be a static website, but it's not.
| It's headless Wordpress, with a Next.js frontend. It's just
| an informational websites, like what they do, contact
| information, services offered and a "blog", which is just one
| or two article published per month. The bloody thing is a
| single page app, routing is done in Javascript, rendering is
| Javascript... I don't understand it at all. It's a type of
| page that needs no Javascript at all, and yet it's built
| entirely as a Javascript frontend.
| MrVandemar wrote:
| > I don't understand it at all. It's a type of page that
| needs no Javascript at all, and yet it's built entirely as
| a Javascript frontend.
|
| Likely the solution was driven by the developer, not the
| needs of the people wanting that information, or the needs
| of the business.
|
| I would hazard a guess that the author of the site either
| only knew one way to make a site, or they wanted to learn
| how to make a site that way, possibly as a portfolio piece.
| GoblinSlayer wrote:
| For me it's banks and maps.
| bazzargh wrote:
| telnet mapscii.me :)
| teddyh wrote:
| Cool, but:
|
| * No option for alternate character aspect ratios; what
| if your characters are square, like an 8x8 font?
|
| * They are using a quite old database dump of
| OpenStreetMap.
|
| * No option to jump directly to a coordinate and zoom
| level.
| marginalia_nu wrote:
| A lot of apparent SPAs also offer a simple server side rendered
| version of the website for search engines and AI agents.
|
| You can for example read medium articles just fine with w3m.
| jezek2 wrote:
| There is a plan for using CEF engine for a specific tab or
| website. The user would be able to make the website work with a
| single click and it would remember it. You would still have the
| advantage of a lightweight browser just in a lesser degree.
| ramon156 wrote:
| Really cool project! Maybe this is a bit nitpicky, but the
| paragraph on the front page is a bit wonky. Some words are
| missing
| BaudouinVH wrote:
| Please tell me you are doing this all by yourself, OP.
| austin-cheney wrote:
| The opinionated approach feels restrictive to me. My best
| recommendation to avoid slowness, privacy violations, and other
| nasty things is to not include certain features as opposed to
| eliminating JavaScript.
|
| For example if we know large SPA frameworks and/or slow websites
| require use of convention A then simply not include support for
| convention A. This is a fail by design approach instead of a
| blacklist approach.
|
| Here are some things to block to radically increase performance:
|
| * string parsing: innerHTML, querySelectors, console.log
|
| * allow a quota of load time requests and then stop taking http
| requests until a person interacts with the page (or just break
| the page). If you set the quota at 10 then any pages with greater
| numbers of requests will just stop loading. That alone will
| eliminate 99% of spyware and dramatically shift user behavior.
|
| * drop requests for JavaScript from different origins than the
| page will improve both performance and privacy
|
| The biggest thing to help with privacy is to not support CORS.
| That will do more than eliminating JavaScript.
|
| These things are still highly restrictive but much less so than a
| blacklist approach.
| Yoric wrote:
| Feels much harder to both implement and debug, though.
| austin-cheney wrote:
| That completely misses the point. Privacy and performance
| advocates don't care how hard life is for JavaScript
| developers. JavaScript developer convenience as the top
| priority results in the very slow privacy violating sites
| things like this browser exist to ignore.
| Yoric wrote:
| No, I mean for the developer of the web browser.
|
| I have worked on a web browser. It's fricking hard. Remove
| JavaScript and DOM entirely, and it gets much easier.
|
| Now if you start to implement select parts of the spec, it
| becomes even harder when something fails to know whether
| it's a feature (because you don't like that part of the
| spec) or a bug (because you misunderstood or misimplemented
| some part of the spec that you wanted to implement
| correctly).
| austin-cheney wrote:
| I agree with that about 90%. The standards do not come as
| a single universal package. Browsers cherry pick what
| they want to support or what support to drop as they can
| release new features. The challenge there is picking
| features to support but ensuring they work independently
| and without regression. It takes testing the incumbents
| have spent years developing.
| GoblinSlayer wrote:
| It's a whitelist.
| shiomiru wrote:
| > string parsing: innerHTML, querySelectors, console.log
|
| I don't have numbers, but I doubt an in-browser JS
| implementation without these APIs would be useful on many
| websites. Even HN uses innerHTML.
| Antwan wrote:
| Does this come bundled in TempleOS?
| rollcat wrote:
| First off, this is really impressive. After Opera and Microsoft
| dropped their engines and adopted Blink, and Mozilla gave up on
| Servo, I've been becoming increasingly worried for the future of
| the open web. Kudos for trying to get the matters in your own
| hands, and for getting this far with your project.
|
| Now for the nit picking. From the FAQ:
|
| > For example the HTTP code has no implementation of features
| that can be used for tracking (such as ETags).
|
| True, ETags can be used for precise client tracking (just like a
| cookie with a unique client ID); but they are also useful for
| caching resources client-side, thus reducing data usage, server
| resources, client processing, etc.
|
| Since the browser/backend is already using a whitelist approach,
| I would like to suggest optional support for ETags for websites
| that the user decides to trust.
|
| Also, unless FixBrowser/FixProxy becomes relevant enough to show
| up on the pie chart besides Chrome, Firefox, and Safari,
| individual users can be easily fingerprinted based on e.g. IP
| ranges and the mere fact that the client behaves differently.
| This is an uphill battle, but I'm glad that efforts like this
| even exist.
| ffsm8 wrote:
| i'm not disagreeing with you, just wanted to add another point:
|
| tracking _is_ buildin into http /browsers, even without JS. Its
| just no longer on the client, making it harder for 3rd parties
| to aggregate the information across domains (e.g. google, meta,
| etc).
|
| e.g. loading images/tracking pixels on hover (css) to track
| mouse movements
|
| the only way to make tracking impossible is by only allowing
| pure HTML with a tiny subset of CSS for styling. like a
| markdown browser.
|
| while thats a valid technology choice, I'm not sure how many
| ppl would ever use such a thing, it'd be incompatible with the
| vast majority of websites.
|
| the only one's that come to my mind would be even better as
| RSS/Atom Feeds, so - from my perspective - it'd have a bigger
| potential if it just creates these feeds by parsing the
| websites. But you'd still have to preload them with a browser
| on a server somewhere for the sites that actually require JS /
| SPAs without hydration.
|
| And once you're there, youre already in a market with multiple
| options
| deaddodo wrote:
| > and Mozilla gave up on Servo
|
| They didn't "give up" on Servo. Servo was always intended as a
| test-bed for Firefox engine technologies. It was just some
| weird false hope in the OSS community that it would be some new
| "super browser".
|
| They integrated what they were looking for into Quantum and
| then the community took the browser portion and forked it
| off+continued development (albeit, without Mozilla
| sponsorship).
| ecef9-8c0f-4374 wrote:
| They fired the developers and later gave the project to the
| Linux foundation. Maybe "give up" is not a perfect fit. But
| they "abandoned" it for sure.
| ksec wrote:
| >At some point I've realized that much of the complexity and
| resource requirements of web browsers comes from JavaScript.
|
| I am wondering how much of this is true?
| ezequiel-garzon wrote:
| Indeed, CSS is so massive it has long been a collection of
| standards. Good luck implementing all that.
| mbrock wrote:
| the author describes how their render-once approach lets them
| implement CSS in a simpler way since they don't need to
| retain information for arbitrary dynamic changes in the
| stylesheets and content
|
| they also probably don't implement most of CSS
| david_draco wrote:
| I guess this implies that rescaling the window, or rotating
| your phone, will not update the view. Then you'd have to
| reload the page. That trade-off seems okay to me.
| 8organicbits wrote:
| Constrained features can work great in certain niches,
| imagine using this in a kiosk (where resizing isn't
| possible).
| jezek2 wrote:
| Yeah, the layout would still resize but it could be non-
| ideal in some cases as it would be based on media queries
| for another width.
|
| For the rotation I could process a second layout on the
| background and switch to it instantly if rotated.
| Similarly hover effects will be limited. Things affecting
| visibility of the blocks/layers should work (for menus),
| small adjustments of layouted text too, but anything that
| is more complicated won't be. It currently uses a
| hardcoded hover effect for links.
| shiomiru wrote:
| I believe Netscape worked like this back in the day.
| (ETA: as in, resizing the window would reload the page.)
| mosdl wrote:
| Resizing would just reflow (ie re-render it) the page,
| not reload it.
| Alifatisk wrote:
| No screenshot?
| 8organicbits wrote:
| There are several on the about page.
|
| https://www.fixbrowser.org/about
| 8organicbits wrote:
| Really cool, I think there are places where something like this
| could be really useful.
|
| It could be cool to pair this with a SSR backend and package it
| into a Electron-like desktop app. You'd get basic UI, but it
| could be very lightweight. The biggest complaint about electron
| has long been memory usage. Could work great for kiosks too.
| frfrrf wrote:
| >Planned support for systems in the near future: Linux GTK3/4
|
| FLTK is better then GTK on linux. Since version 1.4 FLTK supports
| HighDPI displays and Wayland
| https://www.fltk.org/articles.php?L1947 GTK3/4 and Qt5/6 are
| bloatware!
| sylware wrote:
| FLTK is c++, then a definitive nono?
| frfrrf wrote:
| Look at FLTK's source code. It's a minimal set of C++. Like C
| with classes.
| sylware wrote:
| Then it is c++, then a definitive nono.
|
| Plain and simple C99+ port?
| frfrrf wrote:
| >Then it is c++, then a definitive nono.
|
| Language with OOP is good for GUI!
| sylware wrote:
| Language with OOP like c++ and similar (rust/java/etc) is
| ultra-complexity builtin the syntax itself which spills
| to their compilers (basically clang(apple)|gcc). That
| reasons alone is enough to do GUI with other languages.
| frfrrf wrote:
| >Plain and simple C99+ port?
|
| C89 bindings https://github.com/MoAlyousef/cfltk
| sylware wrote:
| The second your require a gigantic and insanely complex
| c++ and similar compiler for your SDK, it's over.
| frfrrf wrote:
| As for complexity and gigantism:
|
| https://openhub.net/p/qt5 (8,876,034 lines of code)
|
| https://openhub.net/p/gtk (1,031,203 lines of code)
|
| https://openhub.net/p/fltk (467,564 lines of code)
| sylware wrote:
| You have an "amplification" due to the language used: you
| cannot compare the "cost" of C lines with c++ lines. They
| don't pull the same SDK dependency in the end.
|
| Basically, to be fair, in qt5 and fltk cases you should
| add an amplification factor of at least "10" (probably
| not big enough since c++ syntax and tens of times more
| complex than plain C99+).
| frfrrf wrote:
| Compare dependencies:
|
| GTK3 https://gitlab.archlinux.org/archlinux/packaging/pac
| kages/gt... GTK4 https://gitlab.archlinux.org/archlinux/p
| ackaging/packages/gt... and FLTK https://aur.archlinux.or
| g/cgit/aur.git/tree/PKGBUILD?h=fltk-...
|
| If you build FLTK with Wayland support, then add deps:
| wayland, libxkbcommon, pango.
| sylware wrote:
| You don't seem to understand my point: the second you are
| using c++, it is over.
| luke8086 wrote:
| This was also my first thought, but looks like it's already
| designed to be toolkit-agnostic, like NetSurf. So it should be
| easy to port to fltk or anything else. $ ls -1
| fixgui_\*.c fixgui_cocoa.c fixgui_gtk.c
| fixgui_haiku.c fixgui_win32.c
| ivanmontillam wrote:
| I was not able to donate, PayPal again doing its shenanigans (my
| country of origin not supported to donate).
|
| Anyway, what I typed there was: I read that you don't support JS
| intentionally. That's fine and dandy. If I were to create a
| browser from scratch, I'd probably do that.
|
| However, what I'd really like to see is the ability to plug many
| scripting engines: Maybe you want to make V8 pluggable, or
| SpiderMonkey, or let's open the box: plug Python! That might
| enable the possibility to have a front-end stack that is HTML,
| CSS and Python (without the JS in the middle).
|
| It would open a whole new spectrum of Web development, one that
| is not subjugated to the pitfalls of JS.
|
| WebAssembly kind of opened that door, but a native interpreter
| would be good to have.
|
| P.S.: I'm aware Brython exists, but it feels like a cheat to me.
| dartos wrote:
| Honestly that sounds terrible for the web.
|
| JavaScript is weird, but it was specifically made and has
| evolved entirely for making non blocking, snappy, event driven
| user interfaces.
|
| Python was not.
|
| Also, you'd end up breaking the very standards that make the
| web open. If websites only work on 1 browser because it's the
| only one that supports Python, then you've just lost the open
| web.
|
| That's the whole idea around WASM. A standard compile target
| that's designed for the sandboxes environment of websites.
| ivanmontillam wrote:
| Python was an example of my point, but I was thinking even
| more along the lines of any scripting language that employs
| pre-processors, so the code inlining works.
|
| Much like PHP does with open and closing tags, in the early
| days of Web development, I remember doing websites with
| Dreamweaver that way.
|
| How'd you feel about a client-side PHP subset?
| dartos wrote:
| > Python was an example of my point, but I was thinking
| even more along the lines of any scripting language that
| employs pre-processors, so the code inlining works
|
| I'm sorry, I'm not really understanding what you mean here.
|
| > client-side PHP subset
|
| I'd dislike it for the same reasons as before.
|
| Php was made to and evolved largely for generating HTML on
| a server. Not to have snappy, non blocking, event driven
| user interfaces.
|
| And since PHP is not a standardized the same way JavaScript
| is, any browser may or may not implement it the same was as
| another.
|
| We'd be back in the early 2000s world of browsers
| incompatibilities.
|
| What would native browser support for php give you vs a
| wasm implementation of it?
| jmathai wrote:
| Seems reasonable to implement a portion of an open spec for
| niche use cases like this.
|
| Every browser takes several gigs of ram once you have more
| than a couple tabs open. I'm in the niche looking to trade
| off some functionality to gain some efficiency.
| Beijinger wrote:
| https://www.uzbl.org/
| dartos wrote:
| A browser which implements a subset of the specs that major
| browsers implement is still part of the open web.
|
| A browser which implements unique functionality breaks away
| from the open web.
| int_19h wrote:
| Python has await/async; what else do you need for non-
| blocking, snappy, event-driven UI?
| pavlov wrote:
| Back in the late 1990s, multi-language support was part of the
| original design of the <script> tag. Microsoft's market-leading
| browser defaulted to VBScript rather than JavaScript. But of
| course people wanted interoperability rather than writing
| separate scripts for IE and Netscape.
|
| Python is ill-suited for browser scripting because it boldly
| claims to have "batteries included", i.e. it has a sprawling
| standard library, and most of it is entirely incompatible with
| the browser environment's sandboxing and async execution model.
|
| So Python for browser scripting would be a limited subset. And
| if you go there, what's really the point of writing programs in
| an incompatible version of a language whose sole reason to
| exist is the supposed ease-of-use...
| ivanmontillam wrote:
| > _Python is ill-suited for browser scripting because it
| boldly claims to have "batteries included", i.e. it has a
| sprawling standard library, and most of it is entirely
| incompatible with the browser environment's sandboxing and
| async execution model._
|
| Per a previous comment[0], Python was an example of my point,
| but I was thinking even more about any scripting language
| that employs pre-processors so the code inlining works.
|
| > _Back in the late 1990s, multi-language support was part of
| the original design of the <script> tag. Microsoft's market-
| leading browser defaulted to VBScript rather than
| JavaScript._
|
| That in the context of the browser wars back then. Today that
| war is kind of settled, still fighting to take down some
| Chrome's dominance of course.
|
| > _But of course people wanted interoperability rather than
| writing separate scripts for IE and Netscape._
|
| But my point is that it would be a kind of start, JS is too
| dominant for the front-end community. If you don't know JS
| you're just dead in the water.
|
| You have to inherently like JS to be an effective front-end
| developer. That's an unfair constraint.
|
| WebAssembly kind of opened that door, but we are still in
| these early days.
|
| --
|
| [0]: https://news.ycombinator.com/item?id=42508950
| GoblinSlayer wrote:
| >Python is ill-suited for browser scripting because it boldly
| claims to have "batteries included"
|
| And javascript simply downloads its own batteries. "Only on
| first visit, I swear".
| bratwurst3000 wrote:
| could you explain what you mean with batteries? Preloaded
| bibs? thanks
| anonnon wrote:
| Yeah, that's what Python's "batteries included" slogan
| means. Perl and Python not only ship with lots of
| libraries, but have built-in functions for file
| manipulation and running arbitrary shell commands as part
| of the core language:
| https://news.ycombinator.com/item?id=42509544
| tecleandor wrote:
| Usually, with programming languages, that refers to
| having a wide standard library that allows you to
| complete many basic or common functions without
| downloading 3rd party or additional libraries.
|
| https://protocolostomy.com/2010/01/22/what-batteries-
| include...
| anonnon wrote:
| You could actually use Perl and Python with IE 4 through
| Windows Script Host if you installed the versions from
| ActiveState (ActivePerl, ActivePython, and also ActiveTcl),
| which provided ActiveX scripting engines for those languages.
| I actually wrote some small Perl browser LAN apps using this
| for myself. It was a huge security hole in that anyone who
| install ActivePerl, Python, or Tcl could be rooted if they
| visited a web page with the appropriate malicious script tag,
| as these languages provide out-of-the-box support for file
| manipulation and other potentially dangerous actions.
|
| You could also use the AS distros to write classic, pre-.NET
| ASP applications. I know of at least one startup that
| actually did this (ActivePerl + classic ASP + IIS on Windows
| NT/2000), or at least seemed to based on their job postings.
| doublerabbit wrote:
| Browser script integration was close to being TCL but
| JavaScript won or what was called LiveScript from NetScape.
| owl_vision wrote:
| {{ What It is and How It Works
|
| The "guts" of the LHEATcl plugin is a dynamically loadable
| library (DLL) containing the compiled object files from
| Tcl/Tk, FitsTcl, POW, etc. Currently, there is just one,
| monolithic LHEATcl DLL, unlike the LHEA standalone Tcl
| scripts such as fv where there one DLL for each package
| (Tcl, Tk, fitsTcl, POW, etc) . This library is placed in
| your browser's plugins directory. Currently Netscape4.x and
| Internet Explorer 3.x, 4.x, and 5.0 are supported.
| Netscape3.x is not supported because the Javascript we use
| to setup a window to run the tclet in doesn't work in
| Netscape 3.x. When your browser starts up it scans the
| plugins directory. If it finds the LHEATcl plugin library,
| it adds the LHEATcl plugin to its list of plugins and
| registers the plugin to process files of mime type
| "application/x-tcl". For details of how this information is
| stored in the library file, see the documentation for the
| Netscape plugin SDK. }}
|
| https://heasarc.gsfc.nasa.gov/Tools/maki/plugin/LHEAapi.htm
| l
| karteum wrote:
| Python may not be the best example, but some other languages
| also exist and are both less "weird" than
| https://github.com/denysdovhan/wtfjs and fast (e.g. see
| http://luajit.org/ which is far less complex than V8).
| TripleChecker wrote:
| Thanks for sharing! I would love to try it with MacOS support.
|
| Also, in case helpful, a few typos we caught:
| https://triplechecker.com/s/493676/fixbrowser.org
| pbronez wrote:
| Neat tool! Will try it.
| TripleChecker wrote:
| Thanks!
| jezek2 wrote:
| Thanks, fixed.
| sylware wrote:
| Careful, if you are to get something real-life-working on the
| major javascript-walled sites out there, Big Tech will try to
| make your life hell (and that includes shadow-paying hackers to
| destroy your software).
| otherayden wrote:
| Any examples of this happening? If so, id really like to read
| about it
| sylware wrote:
| Since, in the end, the benefit of the crime is all for those
| Big Tech Web engines, the requirement of the proof is
| inverted (or those hackers are beyond stu..., unlikely). And
| Big Tech is proven guilty of anti-competitive practices all
| the time, they are recurring offenders (unless you have been
| living in a cave for decades).
|
| Basically, untill proven otherwise the recurring offenders
| which are the sole benefit of this crime are guilty.
| jezek2 wrote:
| In such extreme cases a possible solution is to use this
| approach: https://www.fixbrowser.org/faq#gatekeepers
| dr_kiszonka wrote:
| Interesting tid bit:
|
| What language is it written in?
|
| FixBrowser is written in FixScript. [...] FixScript is a memory
| safe, thread safe and integer overflow safe language with minimal
| native surface area, greatly reducing any security problems.
| Ideal for processing potentially malicious websites.
|
| It is also very portable (only a C compiler is needed), it even
| has an ability to emulate threads for environments that lack it
| (eg. WebAssembly - important for mobile support).
|
| https://www.fixbrowser.org/faq
|
| https://www.fixscript.org/blog/introduction
| klibertp wrote:
| Shown on HN: https://news.ycombinator.com/item?id=34315137
| bilekas wrote:
| Am I correct in seeing this as a custom language for a custom
| browser? That kind of makes this a bit more impressive but
| equally more challenging if nothing else to find other
| members to help with develop!
| klibertp wrote:
| Yup, FixScript is a new language. Author says in a blog
| post[1]:
|
| > It started as a very simple scripting language for a
| specific need. But when I caught myself using it also for
| the main program it became obvious that the language is
| much more than just for the scripting.
|
| It has some interesting parts; the "base" vs. "classes"
| syntaxes remind me of Vala. Using syntax to disambiguate
| some things at compile time reminds me of Raku (including
| typed variables). It also has syntactic macros (similar to
| Erlang parse transforms) called "token processors", so the
| syntax is fully extensible - invalid tokens are kept by the
| parser and passed to token processor, so in principle you
| could completely ignore the original syntax (something you
| can't do in Rust or Nim).
|
| In any case, the language is rather small and simple (it
| reminds me of Janet a bit); picking it up shouldn't be too
| big of a hurdle, I think.
|
| [1] https://www.fixscript.org/blog/introduction
| Beijinger wrote:
| I miss https://www.uzbl.org/
| anujdeshpande wrote:
| Love seeing alternative approaches to browsing! If the aim is to
| avoid Google's dominance in the browser world, also check the
| efforts by https://ladybird.org/ The author is quite active on
| X/Twitter and posts regular updates.
| jezek2 wrote:
| Yeah I'm watching that project, it's great. Once it will be
| mature I will evaluate it against CEF (Chromium Embedded
| Framework).
|
| I plan to add an optional support of embedding CEF so that you
| can use it for specific tabs or websites directly from
| FixBrowser instead of having to switch to another browser.
|
| In the future there could be a similar support of embedding
| Ladybird engine.
| globalnode wrote:
| Im more interested in how FixProxy works, is it basically a
| filter that disallows tracking and javascript? with optional
| whitelists for sites you trust. I think this would be more useful
| for users who like to take privacy and control into their own
| hands. There is basically no reason to write your own browser if
| you approach the problem like this. I suppose this is what ublock
| is to a degree.
| jezek2 wrote:
| Yeah it processes the HTML+CSS, applies the fix scripts so web
| pages that wouldn't work without JS are fixed to be usable.
| Then it applies whitelist to all HTML elements/attributes and
| CSS rules. This is then converted back to HTML+CSS for the web
| browser to show.
|
| It is very useful, I've been using it myself for multiple years
| with good results.
|
| Having own browser is to reduce the memory requirements
| further. Even with FixProxy the normal browsers use a lot of
| memory, sure it's better than normally but still a lot.
|
| With FixBrowser the memory requirements are much lesser and
| it's much more portable, for example to older systems or
| computers with weak specifications.
| terrycody wrote:
| Sorry but doesn't support javascript, will it make websites
| broken then?
| jezek2 wrote:
| That's why I've introduced the fix scripts that can fix the
| websites to be usable without JS:
| https://www.fixbrowser.org/faq#fix-scripts
|
| I've been using this approach for the last few years with good
| results. Only few websites (typically web applications) I need
| to open in a regular browser otherwise majority of my browsing
| works without JS just fine (thanks to the fix scripts).
| jillesvangurp wrote:
| Yes, most of the web will flat out not work without js.
| Especially the bit that has lots of users and commerce going
| on. If your target audience is hermits that don't engage
| socially online, that don't buy stuff online, and that are
| stuck in a time bubble in the late nineties when they were
| young and naive (talking about myself here as well), then this
| might be the best thing ever. But forget about getting a
| younger or wider audience showing any interest for this. The
| web is a content first platform. Interest is content driven,
| not technology driven. That's why web technology is such a
| dog's breakfast of meh.
|
| I get the idealism, sentiment, and nostalgia. But the web has
| always been a mediocre platform, a straight jacket, a bit of a
| terribly disgraceful kludge. Fixing it by crippling it further
| doesn't make it better.
|
| The good news is that there are other ways forward. I like
| what's happening with WASM. WASM fixes browsers to be suitable
| for running any kind of code. There are some silly examples out
| there of browsers running emulators with legacy operating
| systems running a 25 year old browser. Or stuff like winamp.
| But the main point is that we're no longer restricted to using
| javascript/css/html. We can now use pretty much any language,
| any framework, any kind of rendering engine. Browsers can now
| run hardware accelerated 3D graphics.
|
| Browsers as a virtualization platform are rapidly catching up
| with Sun's vision of thin client computing a quarter century
| ago. And just around the same time that the web is rapidly
| expanding across devices and modalities. Mobile, AR/XR/VR,
| entertainment consoles, etc.
|
| Browsers are backwards in the sense that they started with a
| very limited/crippled platform that was then extended slowly
| and haphazardly over the course of nearly 35 years with enough
| technology that you can run pretty much anything inside them
| now.
|
| A more logical architecture would be to start with a minimal VM
| that is powerful enough to run anything you'd want to run and
| then run all the rest inside (including legacy crap like
| CSS/HTML/JS, Flash and all the rest.). Sun had some of the
| right ideas but got hung up on the wrong technologies.
| jezek2 wrote:
| That's why I've introduced the fix scripts that can fix the
| websites to be usable without JS:
| https://www.fixbrowser.org/faq#fix-scripts
|
| With it you can use it to browse most websites. And these
| that don't work you can open it in a regular browser. There
| is even a plan to have integration of CEF (Chromium Embedded
| Framework) that allows to use the full browser experience for
| a specific tab or website directly from FixBrowser.
|
| I've been using this approach for the last few years with
| good results.
| ceddym wrote:
| bruh there's a reason why others gave up on their engines, but i
| think first, you should implement javascript and don't try to go
| around it.
| jezek2 wrote:
| If you mean Microsoft abandoning their engine then their
| reasoning sounded as an excuse because they clearly have the
| capacity to work on it. They simply decided for other internal
| reasons to stop and just blamed it on Google/YouTube as it gets
| good PR points.
|
| Anyway, that's why I've come up with the fix scripts that can
| make websites work with JS disabled. It can fix problems and
| even improve the usability of various websites.
|
| I've been using this approach succesfully for a few years
| already with good results. So there is no reason to just
| abandon the idea when it's proven to work.
| rep_lodsb wrote:
| Yes! This is _exactly_ what I want in a web browser!
| alphabet9000 wrote:
| very cool
| ForHackernews wrote:
| If you're interested in lightweight, zero-JS browsers you might
| want to check out Dillo, recently brought back to life:
| https://news.ycombinator.com/item?id=38847613
| archargelod wrote:
| This is my favourite quote now:
|
| > From the development point if there is something that truly
| requires multiple developers to implement it is most certainly
| too complex and should be made simpler or a separate project.
|
| [0] -
| https://old.reddit.com/r/ProgrammingLanguages/comments/zwp51...
| amelius wrote:
| The reason why something requires multiple developers could
| also be time to market. I'm sure a lone developer can build a
| fully-fledged webbrowser, but it would take them 100 years. And
| at that point we've probably moved on to holographic
| interfaces.
| jezek2 wrote:
| Yeah that quote/post is related to the FixScript language and
| it's libraries. I consider each project individually based on
| it's characteristics.
|
| As for FixBrowser fortunatelly I'm not working on a full
| fledged web browser and it has significantly reduced
| complexity.
___________________________________________________________________
(page generated 2024-12-26 23:01 UTC)