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

Proposal to add Jekyll-Assets. #189

Open
envygeeks opened this Issue Jan 25, 2016 · 36 comments

Comments

Projects
None yet
@envygeeks

envygeeks commented Jan 25, 2016

I would like to put up and ask for review of https://github.com/jekyll/jekyll-assets so that all Github users can get the full arm of assets on their Github Pages sites.

With the next version we also plan to implement Jekyll safety to allow and disallow certain plugins if Github wishes however... at this time we already fall inline with Jekyll and assure that every given asset lands within Jekyll's own root.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Aug 16, 2016

Any update on this?

envygeeks commented Aug 16, 2016

Any update on this?

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Aug 19, 2016

Contributor

users can get the full arm of assets on their Github Pages sites.

@envygeeks thanks for following up. Can you explain a bit more about what you mean by that? What would the plugin allow you to do that you can't do now? Who's the target user? What's the target use case? Would love to learn more.

Contributor

benbalter commented Aug 19, 2016

users can get the full arm of assets on their Github Pages sites.

@envygeeks thanks for following up. Can you explain a bit more about what you mean by that? What would the plugin allow you to do that you can't do now? Who's the target user? What's the target use case? Would love to learn more.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Aug 20, 2016

Feels like an automated response @benbalter 😉. Jekyll as it stands is a very basic version of what Jekyll Assets can do and could never match what Jekyll Assets could do unless it took over and started doing it. Not only do we support SCSS/SASS better, but we support CofeeScript better, we support ES6,ES7, proper asset management, minimizing, optimizing, and dozens of other languages (except ERB -- for what should be obvious reasons.) Think Rails assets without Rails, and with more constraining.

Users want Jekyll Assets. This request isn't for me, I get dozens of emails a week, have dozens of tickets on my tracker (and Jekyll's tracker -- along with support for it from other Github Staff --) I host my own Jekyll, it's for the users who keep asking me about it and asking me to see if I can get it included.

The target user is anybody who wants real assets, or who wants to do real things with assets through Github pages without needing to pre-process locally and then upload that source to Github. I know more people who currently use Jekyll Assets or NodeJS stuff to preprocess before uploading to Github than I don't now days. Jekyll's built in SCSS is great for a basic site, but what happens if you wish to host a real site on Github? You've to pre-process, and that's pretty bad flow, when we could try to get Jekyll Assets embedded into Github Pages and increase it's power. Want ES6/7 + React + Redux without needing to pre-process locally or without having to use NodeJS? Now you can.

The cases are obvious, or should be, Jekyll Assets is the big brother to what Jekyll currently does, I'll admit it should be an optional addon, in that it shouldn't be loaded by default unless the user adds it to their plugins, but I think it should be an option. Where Jekyll wants CoffeeScript, I use ES7, where Jekyll wants SCSS at it's most basic, I want the full-arm of SASS with full support for importing optional external dependencies like bootstrap.

Users ask for Autoprefixing of their assets? Jekyll Assets got's your back, we already support it. Want bootstrap without having to maintain a local copy? We got your back, it's a plugin. Want ES6? It's supported. Want ES7? It's supported, want LESS? We got you covered. Want Jekyll on Github to process your assets and then host those assets on your own CDN? Got you covered. Want to process your assets with liquid so you have fluid assets? No worries, it's supported. Want to resize or adjust your images? We got that handled too.

envygeeks commented Aug 20, 2016

Feels like an automated response @benbalter 😉. Jekyll as it stands is a very basic version of what Jekyll Assets can do and could never match what Jekyll Assets could do unless it took over and started doing it. Not only do we support SCSS/SASS better, but we support CofeeScript better, we support ES6,ES7, proper asset management, minimizing, optimizing, and dozens of other languages (except ERB -- for what should be obvious reasons.) Think Rails assets without Rails, and with more constraining.

Users want Jekyll Assets. This request isn't for me, I get dozens of emails a week, have dozens of tickets on my tracker (and Jekyll's tracker -- along with support for it from other Github Staff --) I host my own Jekyll, it's for the users who keep asking me about it and asking me to see if I can get it included.

The target user is anybody who wants real assets, or who wants to do real things with assets through Github pages without needing to pre-process locally and then upload that source to Github. I know more people who currently use Jekyll Assets or NodeJS stuff to preprocess before uploading to Github than I don't now days. Jekyll's built in SCSS is great for a basic site, but what happens if you wish to host a real site on Github? You've to pre-process, and that's pretty bad flow, when we could try to get Jekyll Assets embedded into Github Pages and increase it's power. Want ES6/7 + React + Redux without needing to pre-process locally or without having to use NodeJS? Now you can.

The cases are obvious, or should be, Jekyll Assets is the big brother to what Jekyll currently does, I'll admit it should be an optional addon, in that it shouldn't be loaded by default unless the user adds it to their plugins, but I think it should be an option. Where Jekyll wants CoffeeScript, I use ES7, where Jekyll wants SCSS at it's most basic, I want the full-arm of SASS with full support for importing optional external dependencies like bootstrap.

Users ask for Autoprefixing of their assets? Jekyll Assets got's your back, we already support it. Want bootstrap without having to maintain a local copy? We got your back, it's a plugin. Want ES6? It's supported. Want ES7? It's supported, want LESS? We got you covered. Want Jekyll on Github to process your assets and then host those assets on your own CDN? Got you covered. Want to process your assets with liquid so you have fluid assets? No worries, it's supported. Want to resize or adjust your images? We got that handled too.

@mdxprograms

This comment has been minimized.

Show comment
Hide comment
@mdxprograms

mdxprograms Sep 2, 2016

Is this still being reviewed? This would be the complete package for me using jekyll on here.

mdxprograms commented Sep 2, 2016

Is this still being reviewed? This would be the complete package for me using jekyll on here.

@graingert

This comment has been minimized.

Show comment
Hide comment
@graingert

graingert Sep 7, 2016

GitLab allows any content generated by a build to be hosted as a GitLab Pages site.

This would allow anyone to use pages-gem as is, or add any further gems. It would even allow people to use any build format at all!

I think GitLab approach is the best approach, rather than fixing different paper-cuts in the existing Jekyll pages-gem.

Note: I'm not trying to push people to GitLab here, or suggesting that this is the solution instead of just supporting jekyll-assets, I just think everyone should be aware of how elegant the GitLab Pages solution is.

graingert commented Sep 7, 2016

GitLab allows any content generated by a build to be hosted as a GitLab Pages site.

This would allow anyone to use pages-gem as is, or add any further gems. It would even allow people to use any build format at all!

I think GitLab approach is the best approach, rather than fixing different paper-cuts in the existing Jekyll pages-gem.

Note: I'm not trying to push people to GitLab here, or suggesting that this is the solution instead of just supporting jekyll-assets, I just think everyone should be aware of how elegant the GitLab Pages solution is.

@mdxprograms

This comment has been minimized.

Show comment
Hide comment
@mdxprograms

mdxprograms Sep 7, 2016

Github allows the same thing for builds. But you have to build it from a separate branch and deploy the site directory to master or gh-pages to work. Does gitlab build in the same manner before deploying as github does? If so I'm not sure what the difference would be here?

mdxprograms commented Sep 7, 2016

Github allows the same thing for builds. But you have to build it from a separate branch and deploy the site directory to master or gh-pages to work. Does gitlab build in the same manner before deploying as github does? If so I'm not sure what the difference would be here?

@graingert

This comment has been minimized.

Show comment
Hide comment
@graingert

graingert Sep 7, 2016

@mdxprograms you don't need to push to a branch at the end of your build. GitLab just scoops up the build result.

graingert commented Sep 7, 2016

@mdxprograms you don't need to push to a branch at the end of your build. GitLab just scoops up the build result.

@mdxprograms

This comment has been minimized.

Show comment
Hide comment
@mdxprograms

mdxprograms Sep 7, 2016

Gotcha. So it will build with custom plugins once pushed?

mdxprograms commented Sep 7, 2016

Gotcha. So it will build with custom plugins once pushed?

@graingert

This comment has been minimized.

Show comment
Hide comment
@graingert

graingert Sep 7, 2016

@mdxprograms custom plugins, or anything that will run in a privileged Docker in under ~15 minutes.

https://pages.gitlab.io/

graingert commented Sep 7, 2016

@mdxprograms custom plugins, or anything that will run in a privileged Docker in under ~15 minutes.

https://pages.gitlab.io/

@mdxprograms

This comment has been minimized.

Show comment
Hide comment
@mdxprograms

mdxprograms Sep 7, 2016

Interesting! Thanks @graingert I'll check it out.

mdxprograms commented Sep 7, 2016

Interesting! Thanks @graingert I'll check it out.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Sep 7, 2016

Yeah, my clients would rather stick with what they know, which is either me, or Github, and I don't plan on paying for and hosting Gitlab most because of issues that are irrelevant to this issue. I'm still pushing to get this included in Github Pages as it's in my favor.

envygeeks commented Sep 7, 2016

Yeah, my clients would rather stick with what they know, which is either me, or Github, and I don't plan on paying for and hosting Gitlab most because of issues that are irrelevant to this issue. I'm still pushing to get this included in Github Pages as it's in my favor.

LeighHenderson added a commit to LeighHenderson/LeighHenderson.github.io that referenced this issue Nov 7, 2016

Discovered that the jekyll-assets gem is not actually approved for us…
…e with Github Pages (github/pages-gem#189. Ahh. Removed this gem and undid associated changes. Now looking into using autoprefixer in assets build tools such as Gulp, as suggested by the Autoprefixer readme (https://github.com/postcss/autoprefixer).
@khilnani

This comment has been minimized.

Show comment
Hide comment
@khilnani

khilnani Dec 25, 2016

@benbalter Checking in to see if any update. I used Jekyll on Github pages and having an asset pipeline that can concat, minify and convert es6 to JS would be very useful and also would reduce making specific accommodations for github pages.

For example, right now working with pure gh capabilities, i need to include the needed JS files individually and then have the Babel standalone lib process the ES6 code in the browser.

  <!-- global libs //-->
<script type="text/javascript" src="/js/libs/remarkable.min.js"></script>
<script type="text/javascript" src="/js/libs/prism.min.js"></script>

<!-- react core //-->
<script type="text/javascript" src="/js/libs/react.js"></script>
<script type="text/javascript" src="/js/libs/react-dom.js"></script>

<!-- things that use react //-->
<script type="text/javascript" src="/js/libs/classnames.js"></script>
<script type="text/javascript" src="/js/libs/react-remarkable.js"></script>

<!-- things that use the things that use react //-->
<script type="text/babel" src="/js/global.jsx"></script>

<!-- browser es6/jsx/babel parsing  //-->
<script type="text/javascript" src="/js/libs/babel.min.js"></script>

With the assets plugin could be reduced to simply

<script type="text/javascript" src="/js/bundle.min.js"></script>

I opened #375 specific to requesting Babel support, although my personal preference is to have Jekyll-Assets

Thanks!

khilnani commented Dec 25, 2016

@benbalter Checking in to see if any update. I used Jekyll on Github pages and having an asset pipeline that can concat, minify and convert es6 to JS would be very useful and also would reduce making specific accommodations for github pages.

For example, right now working with pure gh capabilities, i need to include the needed JS files individually and then have the Babel standalone lib process the ES6 code in the browser.

  <!-- global libs //-->
<script type="text/javascript" src="/js/libs/remarkable.min.js"></script>
<script type="text/javascript" src="/js/libs/prism.min.js"></script>

<!-- react core //-->
<script type="text/javascript" src="/js/libs/react.js"></script>
<script type="text/javascript" src="/js/libs/react-dom.js"></script>

<!-- things that use react //-->
<script type="text/javascript" src="/js/libs/classnames.js"></script>
<script type="text/javascript" src="/js/libs/react-remarkable.js"></script>

<!-- things that use the things that use react //-->
<script type="text/babel" src="/js/global.jsx"></script>

<!-- browser es6/jsx/babel parsing  //-->
<script type="text/javascript" src="/js/libs/babel.min.js"></script>

With the assets plugin could be reduced to simply

<script type="text/javascript" src="/js/bundle.min.js"></script>

I opened #375 specific to requesting Babel support, although my personal preference is to have Jekyll-Assets

Thanks!

@mdxprograms

This comment has been minimized.

Show comment
Hide comment
@mdxprograms

mdxprograms Dec 26, 2016

I still feel like jekyll-assets should be part of core at this point. The web moves fast and this setup is still a standard for many devs. @khilnani has pretty valid points as well as many others. @envygeeks has done an excellent job putting this together as well. It feels like such a standard for most modern Jekyll sites for me at least. In the same token though I can use netlify with no problem at all for hosting. Just have to take out GitHub in the domain and replace it with netlify 😉

mdxprograms commented Dec 26, 2016

I still feel like jekyll-assets should be part of core at this point. The web moves fast and this setup is still a standard for many devs. @khilnani has pretty valid points as well as many others. @envygeeks has done an excellent job putting this together as well. It feels like such a standard for most modern Jekyll sites for me at least. In the same token though I can use netlify with no problem at all for hosting. Just have to take out GitHub in the domain and replace it with netlify 😉

@khilnani

This comment has been minimized.

Show comment
Hide comment
@khilnani

khilnani Dec 26, 2016

Offline processing may be slightly more needed with the upcoming updates from Chrome

Warning in Chrome: "Fetching scripts with an invalid type/language attributes is deprecated and will be removed in M56, around January 2017. See https://www.chromestatus.com/features/5760718284521472 for more details."

khilnani commented Dec 26, 2016

Offline processing may be slightly more needed with the upcoming updates from Chrome

Warning in Chrome: "Fetching scripts with an invalid type/language attributes is deprecated and will be removed in M56, around January 2017. See https://www.chromestatus.com/features/5760718284521472 for more details."

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Dec 27, 2016

Contributor

@parkr, @jldec any thoughts here?

We definitely hear you. You have a solid case for wanting Jekyll Assets (and Babel) support. While I'd push back on the assertion that you need ES6/7 support to make a "real" website today, I can appreciate that many more advanced sites would benefit from server side javascript processing, but the vast majority of GitHub Pages sites don't use it, and I suspect many don't use javascript at all.

I'll defer to @parkr and @jldec as they know more about the space than I do, but I have two concerns:

  1. Beyond the upfront cost of reviewing and testing, this adds a lot of complexity (and maintenance and documentation debt) going forward. At the same time, we get lots of competing feature requests, and often need to spend our time where it can benefit the most users, or users that have no other option (as opposed to say, building locally). Again, I'm not saying the use case isn't valid, but when we look at our backlog, given some of the examples above, I see this as a performance optimization, which in my mind, is a "nice to have".

  2. There's not yet a clear standard or established beginner resources. Everything we add establishes a contract with our users. This becomes especially challenging in an eight year old product. We need to be sure that when we add something, that it's established, that it's here to stay, and that there's an ecosystem of resources to support users who adopt it. If I wanted to make a client side app with Jekyll Assets, where do I go? Should I use ES6 or ES7? What's the difference? Unless I'm misreading, these two statements above give me reason for pause:

    The web moves fast and this setup is still a standard for many devs... Offline processing may be slightly more needed with the upcoming updates from Chrome

Contributor

benbalter commented Dec 27, 2016

@parkr, @jldec any thoughts here?

We definitely hear you. You have a solid case for wanting Jekyll Assets (and Babel) support. While I'd push back on the assertion that you need ES6/7 support to make a "real" website today, I can appreciate that many more advanced sites would benefit from server side javascript processing, but the vast majority of GitHub Pages sites don't use it, and I suspect many don't use javascript at all.

I'll defer to @parkr and @jldec as they know more about the space than I do, but I have two concerns:

  1. Beyond the upfront cost of reviewing and testing, this adds a lot of complexity (and maintenance and documentation debt) going forward. At the same time, we get lots of competing feature requests, and often need to spend our time where it can benefit the most users, or users that have no other option (as opposed to say, building locally). Again, I'm not saying the use case isn't valid, but when we look at our backlog, given some of the examples above, I see this as a performance optimization, which in my mind, is a "nice to have".

  2. There's not yet a clear standard or established beginner resources. Everything we add establishes a contract with our users. This becomes especially challenging in an eight year old product. We need to be sure that when we add something, that it's established, that it's here to stay, and that there's an ecosystem of resources to support users who adopt it. If I wanted to make a client side app with Jekyll Assets, where do I go? Should I use ES6 or ES7? What's the difference? Unless I'm misreading, these two statements above give me reason for pause:

    The web moves fast and this setup is still a standard for many devs... Offline processing may be slightly more needed with the upcoming updates from Chrome

@graingert

This comment has been minimized.

Show comment
Hide comment
@graingert

graingert Dec 27, 2016

graingert commented Dec 27, 2016

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Dec 27, 2016

Contributor

Neither ES6 nor ES7 exist. There is only ES${currentYear}

@graingert can you explain what you mean by that?

Contributor

benbalter commented Dec 27, 2016

Neither ES6 nor ES7 exist. There is only ES${currentYear}

@graingert can you explain what you mean by that?

@graingert

This comment has been minimized.

Show comment
Hide comment
@graingert

graingert Dec 27, 2016

Should I use ES6 or ES7? What's the difference?

There is no difference, neither exist. Just target babel-preset-env with whatever browsers you want to use and go ahead and write JavaScript according to the latest ES2015 ES2016 ES2017...

graingert commented Dec 27, 2016

Should I use ES6 or ES7? What's the difference?

There is no difference, neither exist. Just target babel-preset-env with whatever browsers you want to use and go ahead and write JavaScript according to the latest ES2015 ES2016 ES2017...

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Dec 27, 2016

@benbalter the ECMA made JavaScript easier to understand by calling them ES2016, 2017 and Jekyll-Assets supports both through Babel, and hopefully will soon support TypeScript too, which is ES2017.

envygeeks commented Dec 27, 2016

@benbalter the ECMA made JavaScript easier to understand by calling them ES2016, 2017 and Jekyll-Assets supports both through Babel, and hopefully will soon support TypeScript too, which is ES2017.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Dec 27, 2016

Well TypeScript 2.0 is ES2017, or we assume it is, we take heavy advantage of some ES2017 features.

envygeeks commented Dec 27, 2016

Well TypeScript 2.0 is ES2017, or we assume it is, we take heavy advantage of some ES2017 features.

@mdxprograms

This comment has been minimized.

Show comment
Hide comment
@mdxprograms

mdxprograms Dec 27, 2016

@benbalter like @graingert had mentioned it's kind of agnostic on the version.

I suspect many don't use javascript at all

I use javascript for tons of things and about every site I take over or contribute to does as well. I don't see this being much different for other jekyll users. Whether they are adding a nav toggle or some click functionality it still exists for modern sites.

While I'd push back on the assertion that you need ES6/7 support to make a "real" website today

Not sure why I would use ES5 at this point to be honest. If it's the way of the web, might as well develop for it, especially if it makes it easier on the people developing the sites with efficiency in mind.

mdxprograms commented Dec 27, 2016

@benbalter like @graingert had mentioned it's kind of agnostic on the version.

I suspect many don't use javascript at all

I use javascript for tons of things and about every site I take over or contribute to does as well. I don't see this being much different for other jekyll users. Whether they are adding a nav toggle or some click functionality it still exists for modern sites.

While I'd push back on the assertion that you need ES6/7 support to make a "real" website today

Not sure why I would use ES5 at this point to be honest. If it's the way of the web, might as well develop for it, especially if it makes it easier on the people developing the sites with efficiency in mind.

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Dec 27, 2016

Contributor

I use javascript for tons of things and about every site I take over or contribute to does as well.

What I was trying to imply politely above, is that perhaps the users advocating for Jekyll Asset support are some of our more advanced users, and not our average user. 😄

Whether they are adding a nav toggle or some click functionality it still exists for modern sites.

If I'm adding a nav toggle or some click functionality, do I really need the overhead of a server-side compiler or an entire asset pipeline?

Not sure why I would use ES5 at this point to be honest.

I suspect we're ships passing in the night on this one. I was suggesting that you don't need any server-side javascript processing (or heck, even Javascript) to make a "real" website.

especially if it makes it easier on the people developing the sites with efficiency in mind.

I think this is the crux of the issue. I get the sense that those who have participated in this thread are developing sites on GitHub Pages with the primary goal of efficiency. While that's a very valid use case, and I don't want to diminish that in any way, I'm suggesting that the primary goal of other users may be ease of use (e.g., creating their first website), collaboration (e.g., creating a simple software docs site), or simplicity (e.g., a resume or portfolio).

Contributor

benbalter commented Dec 27, 2016

I use javascript for tons of things and about every site I take over or contribute to does as well.

What I was trying to imply politely above, is that perhaps the users advocating for Jekyll Asset support are some of our more advanced users, and not our average user. 😄

Whether they are adding a nav toggle or some click functionality it still exists for modern sites.

If I'm adding a nav toggle or some click functionality, do I really need the overhead of a server-side compiler or an entire asset pipeline?

Not sure why I would use ES5 at this point to be honest.

I suspect we're ships passing in the night on this one. I was suggesting that you don't need any server-side javascript processing (or heck, even Javascript) to make a "real" website.

especially if it makes it easier on the people developing the sites with efficiency in mind.

I think this is the crux of the issue. I get the sense that those who have participated in this thread are developing sites on GitHub Pages with the primary goal of efficiency. While that's a very valid use case, and I don't want to diminish that in any way, I'm suggesting that the primary goal of other users may be ease of use (e.g., creating their first website), collaboration (e.g., creating a simple software docs site), or simplicity (e.g., a resume or portfolio).

@mdxprograms

This comment has been minimized.

Show comment
Hide comment
@mdxprograms

mdxprograms Dec 27, 2016

@benbalter I can see the efficiency issue for sure for new users trying to do simple sites, but isn't this just an addition if we want it? I mean if it's not a part of core and we can still use it on github that would be the end goal. That way new users can still use the default setup, but using jekyll-assets will allow more involved sites if needed/wanted.

mdxprograms commented Dec 27, 2016

@benbalter I can see the efficiency issue for sure for new users trying to do simple sites, but isn't this just an addition if we want it? I mean if it's not a part of core and we can still use it on github that would be the end goal. That way new users can still use the default setup, but using jekyll-assets will allow more involved sites if needed/wanted.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Dec 27, 2016

If I'm adding a nav toggle or some click functionality, do I really need the overhead of a server-side compiler or an entire asset pipeline?

You already have the overhead of Jekyll and since this isn't a dynamic site this argument is flawed on it's face, taking a few extra seconds to process a site that might only update once a month can't use the same algorithm that you would use for Github.com which is a Rails app and has to take these types of things into consideration.

I'm suggesting that the primary goal of other users may be ease of use

How does Jekyll-Assets stop that? It's entirely optional and uses folders that Jekyll doesn't use. If it does that is a problem created by Jekyll and now Github is using Jekyll's flaws against a popular plugin. I'm not saying that's the case but if it is then... wow.

envygeeks commented Dec 27, 2016

If I'm adding a nav toggle or some click functionality, do I really need the overhead of a server-side compiler or an entire asset pipeline?

You already have the overhead of Jekyll and since this isn't a dynamic site this argument is flawed on it's face, taking a few extra seconds to process a site that might only update once a month can't use the same algorithm that you would use for Github.com which is a Rails app and has to take these types of things into consideration.

I'm suggesting that the primary goal of other users may be ease of use

How does Jekyll-Assets stop that? It's entirely optional and uses folders that Jekyll doesn't use. If it does that is a problem created by Jekyll and now Github is using Jekyll's flaws against a popular plugin. I'm not saying that's the case but if it is then... wow.

@khilnani

This comment has been minimized.

Show comment
Hide comment
@khilnani

khilnani Dec 31, 2016

@benbalter Agree in general that these use cases are more around advanced developers. Most code schools teach new web developers more about ES6/ES7 etc than coffee script. Its either React with JSX/ES6, or Angular with TypeScript. So, more incoming developers are using the tools than in the past. Personally, I'd more categorize it as mid/advanced users would go with React/Angular while beginners or simple sites would stay with JQuery or plain old JavaScript.

The key benefits i see are

  1. Keeps the tool set a mid/advanced developer would use at their real job, regular web site the same as when using github. eg. ES6, typescript, CSS prefixing etc. @jldec 's blog https://blog.pubblz.com/feature-wishlist-for-github-pages notes some of this as well.
  2. Leverages one of the selling points of github pages' 'just works' jekyll integration where a developer does not need to build their site offline and push static pages to the repo. I like that the ability to add posts via markdown, but also edit the site's code easily.... it just works.

Not having the assets plugin doesn't stop anything in my opinion. It just make life easier... similar to why developers use Grunt/Gulp etc. to minify, concat and process JS/CSS etc.

You have a good point around effort around setup and ongoing management of the dependencies and libraries for it. Definitely hear you on that and also with an 8 year old product (but, its a nice product). In any case, thanks for hearing the discussion out and considering.

khilnani commented Dec 31, 2016

@benbalter Agree in general that these use cases are more around advanced developers. Most code schools teach new web developers more about ES6/ES7 etc than coffee script. Its either React with JSX/ES6, or Angular with TypeScript. So, more incoming developers are using the tools than in the past. Personally, I'd more categorize it as mid/advanced users would go with React/Angular while beginners or simple sites would stay with JQuery or plain old JavaScript.

The key benefits i see are

  1. Keeps the tool set a mid/advanced developer would use at their real job, regular web site the same as when using github. eg. ES6, typescript, CSS prefixing etc. @jldec 's blog https://blog.pubblz.com/feature-wishlist-for-github-pages notes some of this as well.
  2. Leverages one of the selling points of github pages' 'just works' jekyll integration where a developer does not need to build their site offline and push static pages to the repo. I like that the ability to add posts via markdown, but also edit the site's code easily.... it just works.

Not having the assets plugin doesn't stop anything in my opinion. It just make life easier... similar to why developers use Grunt/Gulp etc. to minify, concat and process JS/CSS etc.

You have a good point around effort around setup and ongoing management of the dependencies and libraries for it. Definitely hear you on that and also with an 8 year old product (but, its a nice product). In any case, thanks for hearing the discussion out and considering.

@laciseber

This comment has been minimized.

Show comment
Hide comment
@laciseber

laciseber Jan 13, 2017

If I'm adding a nav toggle or some click functionality, do I really need the overhead of a server-side compiler or an entire asset pipeline?

@benbalter you really don't, I agree. However, if you were to build a very simple website using the latest Bootstrap alpha and use Github Pages with Bootstrap's original Sass files instead of the precompiled bundle, according to https://v4-alpha.getbootstrap.com/getting-started/build-tools/#tooling-setup you'd need Autoprefixer to get the browser support it is supposed to offer.

This is definitely not advanced user territory in my opinion. It's exactly what you're talking about: a simple software doc, someone's first resume/portfolio site. Using a very popular tool, with some slight tweaks -- a few modified Sass variables maybe. Definitely no "complicated" JavaScript transpiling.

(One very hacky way one could temporarily "solve" the Sass part of the above equation is to download the Bootstrap source and in it to do a postcss --replace --no-map --config grunt/postcss.js --parser postcss-scss scss/**/*.scss but only after having installed a bunch of npm modules.)

laciseber commented Jan 13, 2017

If I'm adding a nav toggle or some click functionality, do I really need the overhead of a server-side compiler or an entire asset pipeline?

@benbalter you really don't, I agree. However, if you were to build a very simple website using the latest Bootstrap alpha and use Github Pages with Bootstrap's original Sass files instead of the precompiled bundle, according to https://v4-alpha.getbootstrap.com/getting-started/build-tools/#tooling-setup you'd need Autoprefixer to get the browser support it is supposed to offer.

This is definitely not advanced user territory in my opinion. It's exactly what you're talking about: a simple software doc, someone's first resume/portfolio site. Using a very popular tool, with some slight tweaks -- a few modified Sass variables maybe. Definitely no "complicated" JavaScript transpiling.

(One very hacky way one could temporarily "solve" the Sass part of the above equation is to download the Bootstrap source and in it to do a postcss --replace --no-map --config grunt/postcss.js --parser postcss-scss scss/**/*.scss but only after having installed a bunch of npm modules.)

@mdxprograms

This comment has been minimized.

Show comment
Hide comment
@mdxprograms

mdxprograms Jan 13, 2017

If "this" being jekyll on github, being a "not advanced user territory" then I highly disagree. It is Github we are talking about. Developers around the globe use this service. Not sure why limiting a simple plugin is helping the developer community. If we want someone to have an ability to build a simple site with hardly any coding necessary on the flagship developer site then I'm fine using Gitlab in place of Github.

mdxprograms commented Jan 13, 2017

If "this" being jekyll on github, being a "not advanced user territory" then I highly disagree. It is Github we are talking about. Developers around the globe use this service. Not sure why limiting a simple plugin is helping the developer community. If we want someone to have an ability to build a simple site with hardly any coding necessary on the flagship developer site then I'm fine using Gitlab in place of Github.

@tekknolagi

This comment has been minimized.

Show comment
Hide comment
@tekknolagi

tekknolagi Feb 13, 2017

@benbalter Is there by chance any motion on allowing jekyll-assets on GH Pages, if not making it default for everybody?

tekknolagi commented Feb 13, 2017

@benbalter Is there by chance any motion on allowing jekyll-assets on GH Pages, if not making it default for everybody?

@SeanKilleen

This comment has been minimized.

Show comment
Hide comment
@SeanKilleen

SeanKilleen Feb 14, 2017

Wanted to add my 👍 for this here as well. Just came across a use case where it would have been highly convenient for me to switch to SCSS files but am unable to do so due to hosting on github pages.

Can do it in CSS, just unable to re-use variables, etc. Still looking into it but this is one of the first threads I came across, so assuming it's not on an option yet.

SeanKilleen commented Feb 14, 2017

Wanted to add my 👍 for this here as well. Just came across a use case where it would have been highly convenient for me to switch to SCSS files but am unable to do so due to hosting on github pages.

Can do it in CSS, just unable to re-use variables, etc. Still looking into it but this is one of the first threads I came across, so assuming it's not on an option yet.

@tekknolagi

This comment has been minimized.

Show comment
Hide comment
@tekknolagi

tekknolagi Feb 14, 2017

@SeanKilleen to clarify: you can use SCSS on GitHub Pages as-is, but jekyll-assets allows for more advanced control over assets and their contents.

tekknolagi commented Feb 14, 2017

@SeanKilleen to clarify: you can use SCSS on GitHub Pages as-is, but jekyll-assets allows for more advanced control over assets and their contents.

@chen-yumin

This comment has been minimized.

Show comment
Hide comment
@chen-yumin

chen-yumin Feb 19, 2017

Any update on this? I too feel jekyll-assets should be considered essential for GH pages.

chen-yumin commented Feb 19, 2017

Any update on this? I too feel jekyll-assets should be considered essential for GH pages.

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Feb 21, 2017

Contributor

@parkr any thoughts here?

Contributor

benbalter commented Feb 21, 2017

@parkr any thoughts here?

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Feb 22, 2017

Contributor

Hey, we could certainly look into it. As a team, we're spread pretty thin right now. The amount of work it takes to ship a new gem is not small: there is an extensive security review, documentation is written for it, any high frequency errors have to be properly pulled out so they can be emailed to the user, and the fantastic GitHub Support team has to take time to get up to speed with the functionality and possible errors so they can help users who encounter problems. Once it has shipped, then we have to make sure we stay up-to-date and do our due diligence regarding security/documentation/errors/support for each upgrade.

All that work aside, we have a number of features we're working on which take precedence over this kind of addition for now. We're very excited about what we're working on and think you won't mind us focusing on them once you see them in action. 😄

Contributor

parkr commented Feb 22, 2017

Hey, we could certainly look into it. As a team, we're spread pretty thin right now. The amount of work it takes to ship a new gem is not small: there is an extensive security review, documentation is written for it, any high frequency errors have to be properly pulled out so they can be emailed to the user, and the fantastic GitHub Support team has to take time to get up to speed with the functionality and possible errors so they can help users who encounter problems. Once it has shipped, then we have to make sure we stay up-to-date and do our due diligence regarding security/documentation/errors/support for each upgrade.

All that work aside, we have a number of features we're working on which take precedence over this kind of addition for now. We're very excited about what we're working on and think you won't mind us focusing on them once you see them in action. 😄

@mdxprograms

This comment has been minimized.

Show comment
Hide comment
@mdxprograms

mdxprograms Feb 22, 2017

Look forward to it! 🍾

mdxprograms commented Feb 22, 2017

Look forward to it! 🍾

@pathawks pathawks referenced this issue Mar 26, 2017

Closed

[Feature Request] MD5/SHA256 Liquid Hashing #5967

6 of 11 tasks complete

gmaslowski added a commit to gmaslowski/gmaslowski.github.com that referenced this issue Jun 6, 2017

bryanculver added a commit to bryanculver/minimal-jekyll-ghp that referenced this issue Jun 17, 2017

GitHub Pages doesn't support gem for the time being. See github/pages…
…-gem#189. Maintaining two versions for the time being.

Signed-off-by: Bryan Culver <me@bryanculver.com>
@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Jul 31, 2017

For those of you coming here, if you want this feature, just skip Github Pages building your source and have Travis-CI do it: https://docs.travis-ci.com/user/deployment/pages

envygeeks commented Jul 31, 2017

For those of you coming here, if you want this feature, just skip Github Pages building your source and have Travis-CI do it: https://docs.travis-ci.com/user/deployment/pages

@webberwang

This comment has been minimized.

Show comment
Hide comment
@webberwang

webberwang Aug 27, 2018

Any update?

webberwang commented Aug 27, 2018

Any update?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment