Browser-sync: Community question: What does 3.0 look like to you?

[shakyShane]

Completey ignoring any existing implementation, would would Browsersync 3.0 look like if we theoretically re-built it today.

You have to consider how different the Frontend world was 6 or 7 years ago when I had this mad idea to build Browsersync & now with a (still) steadily growing number of users, I'm curious where we take this tool in 2020.

Please post ANY ideas you may have, nothing is too crazy! Just consider your day-to-day work, and what could be better about it. After all that's the reason I built it in the first place.

(FWIW, I already have some of my own wacky ideas but I don't want to influence this)

and...... go.

[gmarziou]

What about an option to enable ghost mode only between different browsers and ignoring multiple tabs from same browser?

I'm a member of JHipster project, it is a project generator which enables Browsersync ghost mode by default, and some new users are confused about what's going on when they open several tabs in same browser.

[wesbos]

I've long wanted the benefits of browser-sync to merge with Parcel.

So tackling esm and then giving us all the benefits of browser sync on top of that would be awesome.

I'm not sure if this means making your own bundler, or using parcel/webpack/rollup under the hood.

I just know right now I don't reach for browser-sync right away, but I do when I need an external URL and local HTTPS without any work. This usually means it sits on top of an existing dev server like Parcel, Webpack, Next.js or gatsby.

Certainly take a look at what Parcel 2.0 and Pika Pkg are doing. Might be some interesting stuff you could do with them :)

[dylang]

The underlining server is currently Connect, which has a limited api.
It would be helpful for us if there was an option pick our own server by using a wrapper around a common middleware layer.

Express is probably the most popular. We happen to like Fastify for the performance.

[dylang]

The ability to provide our own logger would be helpful for making our output more consistent.

I changed our logger to match Browsersync, but Browsersync doesn't have the timestamps.

[dylang]

I wrote some custom code to wait to open the browser until webpack is done building to avoid opening a white screen that just sits there until it's done building, and then uses openBrowser from react-dev-utils to _re-use_ an existing tab from that project if it exists instead of opening yet-another-tab.

It would be nice if this was built in.

[dylang]

Out-of-the-box React Fast Refresh support. This seems to be the successor to Hot Module Reloading.
https://github.com/WebHotelier/webpack-fast-refresh

[dylang]

Keep the API for reloading the page! We use this to reload the page whenever nodemon reloads our server. For us, this is The Killer Feature that keeps us on Browsersync.

However, one change:

browserSync.reload();
browserSync.notify(reason);

It would be nice if reload accepted a reason which it would display on the page as it was reloading or when the browsersync script was ready. Today reload accepts a filename, and notify may not show up because it doesn't know when reload has finished and might display before reload happens and then not after it's done.

[dylang]

This has been on my developers' screens every day for more than three years, and I don't think anyone other than me has ever gone to the "UI" pages. I know this is a major feature of Browsersync, but it's just not part of our workflow.

I don't know if the terminal UI should be changed to help developers understand what's available, if this should be exposed in a different way like on the web page or in the browser console, or if it should be an optional addition to BrowserSync for those teams that want these features and not visible otherwise.

[Levdbas]

For me personally an updated version with the latest dependencies would be perfect to begin with. Everything I currently need is in browsersync from my end-user point of view.

[tristan00b]

I don't really know enough to be able to comment on how browsersync should be modernized, but I wanted to comment that this one of my favourite tools that I use a lot, and it functions well for me as it is. So I second @Levdbas 's comment. Even a point-update would be nice, just to get rid of the npm warnings. At the same time, however, I'm excited to see this project continue to grow!