Proposal to add Jekyll-Assets.

[envygeeks]

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]

Any update on this?

[benbalter]

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]

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]

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

[graingert]

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]

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]

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

[mdxprograms]

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

[graingert]

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

https://pages.gitlab.io/

[mdxprograms]

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

[envygeeks]

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.

[khilnani]

@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]

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]

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]

@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]

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

…

On 27 Dec 2016 15:00, "Ben Balter" ***@***.***> wrote: @parkr <https://github.com/parkr>, @jldec <https://github.com/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 <https://github.com/parkr> and @jldec <https://github.com/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 <#189 (comment)>, 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 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#189 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZQTEKXP8HKMNpT1aXhsXDZXKbQOr2jks5rMSgdgaJpZM4HLTIX> .

[benbalter]

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

@graingert can you explain what you mean by that?

[graingert]

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]

@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]

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

[mdxprograms]

@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]

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]

@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]

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]

@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]

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]

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]

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

[SeanKilleen]

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]

@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.

[yumin-chen]

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

[benbalter]

@parkr any thoughts here?

[parkr]

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]

Look forward to it! 🍾

[envygeeks]

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]

Any update?

[sheerun]

yes please..