19 ms·

This actually looks pretty interesting. They started out as an SVG engine for set-top boxes (embedded devices running on TV's) since browsers at the time weren

• emerongi 6y ago
  Are we stuck with HTML/CSS/JS forever? For today's interactive applications, those 3 are clearly insufficient. Can't the standards commitees come up with a new "web language" that actually satisfies the needs of 2020? Or is the goal to just have everything run on WebAssembly? Kudos to the author.. but I was hoping it would be a "for real new" browser.
  • rcarmo 6y ago
    They already did. You probably don't want to go through the SMIL spec on an empty stomach, though.
  • Spivak 6y ago
    Will the current web stack be the preferred language of applications that run in a browser forever? Maybe not. Having the browser just be a WASM target with (potentially) more than one rendering and layout engine doesn’t seem that far fetched. 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.
    • emerongi 6y ago
      I agree. The current stack is here to stay and we will need to support it. However, as a web developer, I spend insane amounts of time dealing with simple issues that stem from the fact that we are building complex applications on top of it. Modal window has a JS select element in it? Now the whole select list has to have an absolute position to make sure it flows out of the modal. Oh wait... now the thing won't reposition itself when the user starts scrolling. 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.
      • hombre_fatal 6y ago
        Just sounds like grass-is-greener hopefulness to me. 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.
        • corty 6y ago
          Try Delphi/Lazarus, Qt or maybe even VisualBasic. 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...
      • c-smile 6y ago
        > However, as a web developer, ... modal window has a JS select element in it? 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.
      • 6y ago
  • vbezhenar 6y ago
    Can you elaborate, why is it clearly insufficient? There are myriads of web applications made with HTML/CSS/JS. So it's clearly sufficient for any kind of web applications IMO. 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.
    • filleduchaos 6y ago
      People always jump to criticizing JS, but frankly HTML and CSS are my biggest pain points whenever I work with them. Any reasonably complicated UI inevitably turns into a soup of divs. Why would you stick with markup and styling heavily tailored towards documents for an application platform if you could start fresh with something else? 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. 0. https://developer.mozilla.org/en-US/docs/Web/Houdini https://developer.mozilla.org/en-US/docs/Web/Houdini
  • fulafel 6y ago
    JS is already largely a compile target. Aside from ClojureScript, TypeScript, ReasonML etc even human authored JS is usually compiled to more legacy browser friendly JS.
    • err4nt 6y ago
      That's gotten trendy in the recent past, but I think you have a generation or wave of developers who literally don't realize it's an interpreted language and you can write short, very sweet vanilla JS and have it run almost everywhere without needing any ahead of time optimizations. _Modern_ JS in _modern_ engines is a dream!
      • ex3ndr 6y ago
        If you will try to profile your app on V8 you will find that almost everything is in binary code, not interpreted.
        • kizer 6y ago
          In this sense it means not requiring a precompilation step. JITing is an implementation detail; also modern engines compile to a bytecode first during interpretation.
      • fulafel 6y ago
        Thhis got me to look up some of the ages, for anyone else curious: ClojureScript is 9-ish year old, CoffeeScript 10+, TypeScript 7.
  • err4nt 6y ago
    Each of these languages you mentioned is extensible, so to a large degree you can shape them to fit your needs! 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.
  • pjc50 6y ago
    Realistically, the standards comittees follow where the implementations lead. And the problem with implementations is that all the large companies making them would much prefer to be either monopolists or drastically advantaged by the choice of technology. Whose native toolkit should it most resemble: Microsoft's, Apple's, or Google's? 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)
  • zamalek 6y ago
    HTML isn't so bad these days because of grid and flexbox, but it is certainly no XAML. 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/ https://yew.rs/docs/ [2]: https://rollupjs.org/guide/en/ https://rollupjs.org/guide/en/
  • pravus 6y ago
    No, but I think it will take a little re-imagining of what a "browser" should be. In my own opinion I find it very odd that we are using what is effectively a static publishing model to do so many dynamic activities. Modulo all the hacks that have been added since, the original intent and architecture of the web seems to be to share scientific papers for researchers at CERN. It's essentially a single file-server namespace with the ability to embed references to other parts of the namespace inside objects already attached to the namespace in some way. Sprinkle in JavaScript and CSS animations and now we have "applications". 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.
  • kizer 6y ago
    I’m basically going to treat the whole web platform as a compilation target. As long as the result is accessible, I’d like to forget about the “big three” for some time.
• AshleysBrain 6y ago
  That rationale doesn't seem to add up - if you render the same content in 1080p and 4K, the only change is the amount of memory bandwidth for filling pixels. Multicore support in the layout engine will help speed up layout calculations (and maybe CSS), but the amount of work involved in that ought to constant regardless of the display resolution.
  • iforgotpassword 6y ago
    If you'd just scale up the image yes, but rendering svgs, fonts, effects like shadows at 4x the resolution isn't just a matter of memory band with.
• legulere 6y ago
  Servo also uses multicore rendering. It would be interesting how flow solved concurrency issues. As far as I know all UI engines and web engines work single core as concurrency bugs are almost inevitable in that area without special language support like from rust.
  • londons_explore 6y ago
    Current engines also do multicore rendering. Theres a single thread that decides what goes where on the page, but the actual rendering (ie. putting text and images into gpu buffers) is done by a thread pool. Thats why on iOS safari if you scroll fast enough you see a checkerboard pattern... that means that tile isn't yet rendered...
    • saagarjha 6y ago
      Safari got rid of that long ago. That would play fairly poorly with iOS 13's ability to drag the scrollbar around :)
      • esprehn 6y ago
        All browsers still "checkerboard" including Safari. No browser that I'm aware of shows an actual checkerboard pattern anymore though, they paint white (or the layer background color).
• c-smile 6y ago
  > multicore architecture 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 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.
  • chrisseaton 6y ago
    > This works if browser is the only application that runs on machine. 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.
    • paulryanrogers 6y ago
      While true one concern is that proliferation of threads/processes per application could reach the point where context switching and thread management alone consume a lot of the capacity. IIRC super computers often need special interconnects and software to minimize the distribution costs of so many cores.
      • PaulDavisThe1st 6y ago
        "supercomputers" are designed (typically) to run CPU-bound tasks. User applications with GUIs are almost never CPU-bound, so the comparison is not really appropriate.
        • paulryanrogers 6y ago
• newsbinator 6y ago
  > "extremely low memory consumption" Might be nice as an Electron replacement
  • elviejo 6y ago
    My thoughts exactly... Now I have too many electron apps... So anything that helps to diminish my RAM consumption is welcome.
    • vbezhenar 6y ago
      Good electron replacement should re-use your installed browser engine. That would reduce RAM consumption dramatically, while providing better security (because browsers usually update faster than individual apps).
      • flatiron 6y ago
        You just created a “website”
        • rattray 6y ago
          You mean, "website with native API's and (optionally) custom native chrome". Developers don't use electron because it'll get its own browser engine instance.
          • pythux 6y ago
            Depends, there is a bunch of Electron apps that work just fine as websites (e.g. Slack, Spotify, Microsoft Teams, etc. As far as I know). I personally prefer running those in a browser tab to both save resources and benefit from privacy enhancing tools like content blockers, etc. I would be curious to know how many of the Electron apps actually need these extra native APIs.
            • flatiron 6y ago
• htk 6y ago
  Yesterday I stumbled upon a post here about a guy trying to use a Pi as his main machine for a couple of days, and one of his conclusions was that he needed 8GB of ram to run Chromium acceptably, and I thought, hardware evolved to these amazingly small and powerful machines but software is bloating faster. All this is to say that software such as Flow might be the way to go back to more performant ways of doing “essential” computing.
  • arexxbifs 6y ago
    I used a Raspi 3B as my main desktop for a while a couple of years back. It worked fine for most things I wanted to do, except for web browsing. NetSurf was good enough for most things, but I had to use Chromium for online banking. It was slow, but it worked. Sure, 1 gig is a bit cramped these days but the problem in general are the web sites, not the browsers.
    • iforgotpassword 6y ago
      I'd say it's a vicious circle. Chrome folks look at real world performance and optimize for that. Web devs see their site performing better and add more shit until their dev machine is almost bogging down. Rinse and repeat.
      • entha_saava 6y ago
        Yeah it is mostly web devs being crap. No problem with sites like HN.
    • stephen_g 6y ago
      I tried installing a modern Xubuntu desktop on a 3B+ a few weeks ago. You can hardly even open Chromium or Firefox these days (maybe with a lighter desktop it would be slightly better)...
      • arexxbifs 6y ago
        I think the best choice is still Raspbian. I was running Raspbian+Fvwm2 at the time.
• t-writescode 6y ago
  Isn’t Firefox at least partly rendering multi core now? Wasn’t that the reason Rust was built by them?
  • kizer 6y ago
    The new engine is still a WIP which you can download and play with on MDN. But I’ve read that parts of FF proper are now using rust. Situation is murky to me.
  • sanxiyn 6y ago
    Firefox's CSS selector matching is now multi core, written in Rust, imported from Servo. Other things are work in progress.
• chx 6y ago
  > So they've implemented a full HTML/CSS/JS browser The JS is SpiderMonkey, the rest indeed is written from scratch: https://twitter.com/flowbrowser/status/1200098712816631809 https://twitter.com/flowbrowser/status/1200098712816631809
• viraptor 6y ago
  > today's browsers all render on a single thread That's not true anymore with webrender. It's available in FF for a while.
  • kizer 6y ago
    In the benchmarks provided on Flow’s site webrender was still 5x slower, and about 2x faster than FF regular.
• cs02rm0 6y ago
  I used to write STB apps for an SVG ekioh browser, probably over a decade ago now. We were in the UK but had no UK customers. 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.