Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use HTTP/2 and SPDY #15

Open
goldibex opened this issue Jan 20, 2016 · 6 comments
Open

Use HTTP/2 and SPDY #15

goldibex opened this issue Jan 20, 2016 · 6 comments

Comments

@goldibex
Copy link

Thanks so much for building this tool, it's really outstandingly useful.

In keeping with the "the future is today" mentality of most of the newer JS frameworks, would you be willing to entertain a PR that introduced support for HTTP/2 and SPDY via node-spdy?

@goldibex goldibex changed the title Use Use HTTP/2 and SPDY Jan 20, 2016
@cgmartin
Copy link
Collaborator

As a simple development server I don't feel like this has much value. Is there a particular use-case for development that you have that requires HTTP/2?

Running lite-server in production is absolutely not recommended. :)

Another quirk is that this project is a simple wrapper around BrowserSync's server feature. If it can't do HTTP/2, then I assume we'd have large difficulty trying to work that in via lite-server. But if Browsersync ever does include that feature, it could be easily enabled through lite-server's overrides.

@johnpapa
Copy link
Owner

johnpapa commented Feb 3, 2016

I agree with Chris, but curiosity has got me ... I'd like to see what you have in mind just to satisfy that :)

@goldibex
Copy link
Author

goldibex commented Feb 3, 2016

Thanks all. Well, let me lay out my arguments for you here first -- if
they're totally unconvincing it may not be worth the effort.

  1. lite-server is part of the "future, now" Javascript ecosystem. It's
    advertised for use developing with JSPM and Angular 2, for instance. HTTP/2
    is the future of communication on the Web, so it makes sense to get people
    developing on that now.
  2. I have some very, very preliminary data showing that in development
    cases where hundreds of objects need to be loaded from the server (common
    enough with JSPM and even modestly sized projects these days), HTTP/2 can
    cut down time to first load for developers considerably.
  3. It's a little-ish issue, but I think it's also important to get
    developers saying the mantra "SSL only," starting from their development
    instances. I've already developed a tool that de-complicates the process so
    you don't have to worry about bright red SSL warnings more than, say, once
    a month. It's true that you could do the same thing against HTTP/1.1 also,
    but packaging it with a move to HTTP/2 makes it easier for developers to
    swallow -- honey on the rim of the medicine cup, as it were.

If this is at least a colorable argument to you, let me know and I'll take
a pass at it.

All best
Harry

On Wed, Feb 3, 2016 at 5:53 AM John Papa notifications@github.com wrote:

I agree with Chris, but curiosity has got me ... I'd like to see what you
have in mind just to satisfy that :)


Reply to this email directly or view it on GitHub
#15 (comment)
.

@jakeNiemiec
Copy link

+1

@Meligy
Copy link

Meligy commented May 27, 2016

Another +1 for this, especially as a development server.

When you load Angular2 via SystemJS, you have quite a large number of requests depending on your import tree.

This is not the production experience, but it kinda slows down the development experience (sample).

HTTP/2 might be a good solution for this development-only problem.

@j-perezr
Copy link

j-perezr commented Apr 7, 2017

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants