10 ms·

Google Web Starter Kit

255 points by lin0tune 9y ago

xg15 9y ago
> .gitignore: node_modules Wait, did I miss something? Wasn't it google who started the "vendor everything" philosophy in the first place?
- milankragujevic 9y ago
  Aren't people supposed to just require the dependencies in package.json and not distribute the large blob of code? And you run "npm install"? Isn't that the current web dev "way" of life...?
- sidmkp96 9y ago
  So? What's wrong with this? Why would someone check-in all the 3rd party code, when same can be described in package.json & downloaded again.
  - reimertz 9y ago
    I guess some see a risk of mutability(https://medium.com/@azerbike/i-ve-just-liberated-my-modules-9045c06be67c https://medium.com/@azerbike/i-ve-just-liberated-my-modules-...). But you can always use shrink-wrap or other package managers that guarantee immutability. Oh, I guess I should say I love npm/yarn and use it as a core of all my projects. ️
  - quickben 9y ago
    I started seeing the floating dependency approach at smaller places and personally consider it a bad pattern. You get everything you depend on, stuff it into a folder named third-party, and check it in forever (or until security bugs, features you need, etc). Include all and any licences, this is important. When dealing with any software that's supposed to be our there for decades, the last thing you want it to have unplanned work because of missing libraries.
    - reimertz 9y ago
      I have seen this first hand at a acquisition. Missing licenses resulted in the entire FE team working in finding missing licenses/find alternative module with proper license or worst case scenario; implement our own solution. This literally took 1 week. Shrink-wrap would have saved us a bunch of $$$.
      - quickben 9y ago
        Yes, it takes one to go through that experience once, to fully appreciate the effort. I also look at that one downvote to my post, and can't help but think that somebody is up for a very nasty surprise in his career.
      - Gigablah 9y ago
        You have to be careful about the type of licenses as well. Happened to me, luckily it was a tiny library and there was an alternative available. See anything with a "cute" license, such as WTFPL? Don't use it for work.
        hedora 9y ago
        What's wrong with WTFPL? I needed some wtfpl code for something, and asked a team of corporate lawyers to evaluate it. They deemed acceptable, and whitelisted it at one of the biggest software companies around.
        Gigablah 9y ago
        Another one of the biggest software companies around came to the opposite conclusion :(
  - revmoo 9y ago
    A lot of folks depend on third party sources for packages. Then Guthub goes down and tgey cand deploy their site.
- scrollaway 9y ago
  Vendoring packages doesn't mean vendoring in git. Vendoring in git is a terrible idea (which for some absurd reason the golang community has decided isn't...). It pollutes your tree, your history, your blames, your searches, makes your git repository massive, etc etc. Node would be even worse.
  - the_duke 9y ago
    Well, Go doesn't have a package system and no good external tool to circumvent it. So the choice is either maintain a fork of every dependency or vendor them, and vendoring is considerably less painful imo. (I'm not saying it's a good solution, mind you)
  - icebraining 9y ago
    We vendor in git by having a master repo, inside of which you have a submodule for our app and others for the dependencies. That way we can track and keep them in sync without having the problems you described.
    - scrollaway 9y ago
      Yeah submodules are a nice way to do git-based vendoring. I don't understand why the golang community didn't go that route.
davedx 9y ago
An opinionated Web Starter Kit with no libraries or frameworks included? What is Google's opinion on which way to build a web application, roll your own?
- SquareWheel 9y ago
  I'd say that's pretty situational, depending on the type of site you want to build. Including tools like SASS, gulp, etc should be applicable to most sites, though.
- sotojuan 9y ago
  > What is Google's opinion on which way to build a web application Angular! Wait, Angular 2. No wait, Polymer. Sorry, how could I be so rude - Progressive Web App with no framework.
  - andykellr 9y ago
    I prefer a combination of Dart and Google Web Toolkit.
    - jimhefferon 9y ago
      OK, so I'll ask. Dart is still alive? To a person just looking around, trying to find a tech that would still be here in five years, the signs seem not good.
      - skybrian 9y ago
        Yes, very much so; a fairly large team at Google is devoted to maintaining it. I'm curious why people keep asking this? Github is very active - many commits per day. There are multiple releases per year. Flutter (which uses Dart) got a fair amount of attention at Google I/O. Where do you look to decide on project activity?
        jimhefferon 9y ago
mattacular 9y ago
Nobody new to web is going to understand this stuff and people who would really understand this advice could already give it themselves. Not sure who the target audience for this is supposed to be but why do we need yet-another-web-boilerplate
tauntz 9y ago
> Powered by Material Design Lite That's a curious choice. MDL isn't being developed further and is being replaced by "Material Components for the web" https://github.com/material-components/material-components-web https://github.com/material-components/material-components-w... From https://github.com/google/material-design-lite https://github.com/google/material-design-lite: Limited support Material Design Lite is now in limited support, with development having moved to the Material Components for the web repository. No further development is taking place in MDL by the core team, but we are happy to review PRs, fix critical bugs and push out new releases. No breaking changes will be accepted.
- mattashii 9y ago
  > Last updated February 9, 2017. https://github.com/google/web-starter-kit https://github.com/google/web-starter-kit > Last release (v0.6.5) on December 13th That choice is not that curious if you correct for project age.
  - StevePerkins 9y ago
    Seriously... this HTML/JavaScript template is FOUR MONTHS OLD, for God's sake! Might as well be jQuery.
philtar 9y ago
Looking at this page, and reading the comments here on HN, I'm glad I'm not a web developer. What a mess.
- degenerate 9y ago
  The 'mess' is like trying to buy a car. Once you get through all the annoying sales pitches, conflicting opinions, dealer gotchas, options, and mental monthly payments... you're finally in your new car and happily rolling along, learning how it works and making it fit with your life. Then as time passes you see all your friends and strangers driving X, you hear about Y, and you really wish you could get your hands on Z, and all of a sudden your car feels inadequate so you hate it and complain about it until you can get your new car... or maybe you'll build your own car... hmm. The mess of Web development is choosing what to use. It's pretty fun once you get behind the wheel.
  - mrisoli 9y ago
    This is the best analogy about web development in a while and totally spot on, as long as you know your way around your own basic tooling it is pretty easy.
    - tyingq 9y ago
      I like it too, but depending on where you work, it might have been the "fleet manager" that picked the car, and you're just driving it. Not much difference until the "fleet manager" changes their mind for the next project.
      - igotsideas 9y ago
        My first car was a 96 ford escort. I hated that car. That is what we are driving at work (WPF). I want a tesla.
  - kuschku 9y ago
    The issue with web development is that there’s no good, or working solutions. Every car that’s up for offer is missing something. One of them can only be driven if you control every single circuit manually, the next is missing an engine, and another has no windows, roof, doors, or seats. Each of the tools would probably be useful for some purpose in a way, but with the entire toolbox of JS utils combined, it’s just a fractal of bad design. On the other hand, you can look over into the JVM world, and, well it just works. There’s one option for dependency management and handling of compilation and preprocessing (gradle), you don’t have to handle any complicated libraries or anything, you can very easily add annotation processors or asset preprocessors as easily as adding a new dependency, and basically everything works natively together. I want to add preprocessing so my JVM 8 code works on JVM 6 or later? I simply add the retrolambda preprocessor, and am done. One LOC. Configuring Babel in the JS world, on the other hand, ends up with several hundred lines of webpack or grunt or gulp configs, you end up dealing with either merging all assets or using system js or whatever the latest fad is. The JS world has recreated all the complexity of the JVM world, but worse.
FabianBeiner 9y ago
Am I missing something? This thing came out like three years ago. If this is news: EVERYONE, CHECK OUT THIS AMAZING THING CALLED BOOTSTRAP!!1! scnr
- mrisoli 9y ago
  I had the same question, repo has no commits since April 4 and only one release dating back to December last year, and, as another comment pointed out, it uses MDL which has been discontinued in favor of Material Components.
TheAceOfHearts 9y ago
I'd advocate most people avoid this if their intention is to write an app. As an alternative, I'd suggest evaluating create-react-app [0] or preact-cli [1] if you're looking for something lighter. The lack of testing setup and module support in this kit feels like a regression, although I'll concede that it really depends on your use-case. I've been using webpack [2] for a few years and wouldn't willingly go back to this style of writing web apps. Once you learn how to use it, the world is your oyster. You can write a loader or plugin to achieve pretty much any kind of requirement that comes your way. Consider replacing sass with cssnext [3], or even directly using postcss along with the few plugins you need. As an example, you can use native css variables during development and compile em away for production. Another great addition is the :matches selector, which makes for much cleaner selectors in certain cases. I never really found much value in most other sass features. Instead of running imagemin as part of your build process, consider installing imagemin-cli [4] and applying optimizations before checking in images. That way it only has to done once, regardless of how many times someone checks-out your repo. Even if you enable ES2015 compilation with babel, you don't get any polyfills. That means trying to use standard ES2015 globals like Map, Set, or Promise will not work on older browsers. If you're gonna tell people they can add ES2015 support by changing a single line, it would seem prudent to mention this gotcha. [0] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app [1] https://github.com/developit/preact-cli https://github.com/developit/preact-cli [2] https://webpack.js.org https://webpack.js.org [3] http://cssnext.io http://cssnext.io [4] https://github.com/imagemin/imagemin-cli https://github.com/imagemin/imagemin-cli
- caludio 9y ago
  I agree that this heavily opinionated "starter kit" might be not what you want to give to a beginner (also it feels quite obsolete nowadays), but I quite disagree that create-react-app is a better choice. I think that CRA is either useless as it is too simple and confusing (in its first run, before you "eject"... what are those react scripts, for example?) or too far away down the road of "choose what technique is best for your project" once you "eject". I rather consider using a "true" starter kit, with no helpers and not many applied opinions to it (like, no redux for example and/or no decision on how to handle CSS). With this principle in mind, I wrote my starter kit https://github.com/claudioc/react-with-typescript-starterkit https://github.com/claudioc/react-with-typescript-starterkit (yes, there are many of them already, but I try for it to be a middle ground between something that you want to use to bootstrap an real new app and something you study to learn the _what_ you need to start and begin by yourself).
js4all 9y ago
Hmm, interestingly I got the foobar challenge when I visited the site.
douchescript 9y ago
Gulp, how quaint
- xxxmaster 9y ago
  Indeed
- aoeuasdf1 9y ago
  what do you prefer to use?
caub 9y ago
gulp sucks
andrewstuart 9y ago
The right amount of configuration is zero. create-react-app gets it. This does not.
ableton 9y ago
I'm glad to see they are using gulp. I know webpack is the hot new technology, but in my limited experience with webpack, gulp is easier to use and is more intuitive. Webpack has a lot of loaders, but I feel like gulp gives more flexibility out of the box. When I want to do something with gulp that I don't know how to do, I feel like it is easier to implement with gulp, because gulp seems to be a bit lower level. I noticed that they updated the docs for webpack since I last visited, so maybe I will try again.

255 points by lin0tune 9y ago

xg15 9y ago

> .gitignore: node_modules Wait, did I miss something? Wasn't it google who started the "vendor everything" philosophy in the first place?

milankragujevic 9y ago
Aren't people supposed to just require the dependencies in package.json and not distribute the large blob of code? And you run "npm install"? Isn't that the current web dev "way" of life...?
sidmkp96 9y ago
So? What's wrong with this? Why would someone check-in all the 3rd party code, when same can be described in package.json & downloaded again.
- reimertz 9y ago
  I guess some see a risk of mutability(https://medium.com/@azerbike/i-ve-just-liberated-my-modules-9045c06be67c https://medium.com/@azerbike/i-ve-just-liberated-my-modules-...). But you can always use shrink-wrap or other package managers that guarantee immutability. Oh, I guess I should say I love npm/yarn and use it as a core of all my projects. ️
- quickben 9y ago
  I started seeing the floating dependency approach at smaller places and personally consider it a bad pattern. You get everything you depend on, stuff it into a folder named third-party, and check it in forever (or until security bugs, features you need, etc). Include all and any licences, this is important. When dealing with any software that's supposed to be our there for decades, the last thing you want it to have unplanned work because of missing libraries.
  - reimertz 9y ago
    I have seen this first hand at a acquisition. Missing licenses resulted in the entire FE team working in finding missing licenses/find alternative module with proper license or worst case scenario; implement our own solution. This literally took 1 week. Shrink-wrap would have saved us a bunch of $$$.
    - quickben 9y ago
      Yes, it takes one to go through that experience once, to fully appreciate the effort. I also look at that one downvote to my post, and can't help but think that somebody is up for a very nasty surprise in his career.
    - Gigablah 9y ago
      You have to be careful about the type of licenses as well. Happened to me, luckily it was a tiny library and there was an alternative available. See anything with a "cute" license, such as WTFPL? Don't use it for work.
      - hedora 9y ago
        What's wrong with WTFPL? I needed some wtfpl code for something, and asked a team of corporate lawyers to evaluate it. They deemed acceptable, and whitelisted it at one of the biggest software companies around.
        Gigablah 9y ago
        Another one of the biggest software companies around came to the opposite conclusion :(
- revmoo 9y ago
  A lot of folks depend on third party sources for packages. Then Guthub goes down and tgey cand deploy their site.
scrollaway 9y ago
Vendoring packages doesn't mean vendoring in git. Vendoring in git is a terrible idea (which for some absurd reason the golang community has decided isn't...). It pollutes your tree, your history, your blames, your searches, makes your git repository massive, etc etc. Node would be even worse.
- the_duke 9y ago
  Well, Go doesn't have a package system and no good external tool to circumvent it. So the choice is either maintain a fork of every dependency or vendor them, and vendoring is considerably less painful imo. (I'm not saying it's a good solution, mind you)
- icebraining 9y ago
  We vendor in git by having a master repo, inside of which you have a submodule for our app and others for the dependencies. That way we can track and keep them in sync without having the problems you described.
  - scrollaway 9y ago
    Yeah submodules are a nice way to do git-based vendoring. I don't understand why the golang community didn't go that route.

davedx 9y ago

An opinionated Web Starter Kit with no libraries or frameworks included? What is Google's opinion on which way to build a web application, roll your own?

SquareWheel 9y ago
I'd say that's pretty situational, depending on the type of site you want to build. Including tools like SASS, gulp, etc should be applicable to most sites, though.
sotojuan 9y ago
> What is Google's opinion on which way to build a web application Angular! Wait, Angular 2. No wait, Polymer. Sorry, how could I be so rude - Progressive Web App with no framework.
- andykellr 9y ago
  I prefer a combination of Dart and Google Web Toolkit.
  - jimhefferon 9y ago
    OK, so I'll ask. Dart is still alive? To a person just looking around, trying to find a tech that would still be here in five years, the signs seem not good.
    - skybrian 9y ago
      Yes, very much so; a fairly large team at Google is devoted to maintaining it. I'm curious why people keep asking this? Github is very active - many commits per day. There are multiple releases per year. Flutter (which uses Dart) got a fair amount of attention at Google I/O. Where do you look to decide on project activity?
      - jimhefferon 9y ago

mattacular 9y ago

Nobody new to web is going to understand this stuff and people who would really understand this advice could already give it themselves. Not sure who the target audience for this is supposed to be but why do we need yet-another-web-boilerplate

tauntz 9y ago

> Powered by Material Design Lite That's a curious choice. MDL isn't being developed further and is being replaced by "Material Components for the web" https://github.com/material-components/material-components-web https://github.com/material-components/material-components-w... From https://github.com/google/material-design-lite https://github.com/google/material-design-lite: Limited support Material Design Lite is now in limited support, with development having moved to the Material Components for the web repository. No further development is taking place in MDL by the core team, but we are happy to review PRs, fix critical bugs and push out new releases. No breaking changes will be accepted.

mattashii 9y ago
> Last updated February 9, 2017. https://github.com/google/web-starter-kit https://github.com/google/web-starter-kit > Last release (v0.6.5) on December 13th That choice is not that curious if you correct for project age.
- StevePerkins 9y ago
  Seriously... this HTML/JavaScript template is FOUR MONTHS OLD, for God's sake! Might as well be jQuery.

philtar 9y ago

Looking at this page, and reading the comments here on HN, I'm glad I'm not a web developer. What a mess.

degenerate 9y ago
The 'mess' is like trying to buy a car. Once you get through all the annoying sales pitches, conflicting opinions, dealer gotchas, options, and mental monthly payments... you're finally in your new car and happily rolling along, learning how it works and making it fit with your life. Then as time passes you see all your friends and strangers driving X, you hear about Y, and you really wish you could get your hands on Z, and all of a sudden your car feels inadequate so you hate it and complain about it until you can get your new car... or maybe you'll build your own car... hmm. The mess of Web development is choosing what to use. It's pretty fun once you get behind the wheel.
- mrisoli 9y ago
  This is the best analogy about web development in a while and totally spot on, as long as you know your way around your own basic tooling it is pretty easy.
  - tyingq 9y ago
    I like it too, but depending on where you work, it might have been the "fleet manager" that picked the car, and you're just driving it. Not much difference until the "fleet manager" changes their mind for the next project.
    - igotsideas 9y ago
      My first car was a 96 ford escort. I hated that car. That is what we are driving at work (WPF). I want a tesla.
- kuschku 9y ago
  The issue with web development is that there’s no good, or working solutions. Every car that’s up for offer is missing something. One of them can only be driven if you control every single circuit manually, the next is missing an engine, and another has no windows, roof, doors, or seats. Each of the tools would probably be useful for some purpose in a way, but with the entire toolbox of JS utils combined, it’s just a fractal of bad design. On the other hand, you can look over into the JVM world, and, well it just works. There’s one option for dependency management and handling of compilation and preprocessing (gradle), you don’t have to handle any complicated libraries or anything, you can very easily add annotation processors or asset preprocessors as easily as adding a new dependency, and basically everything works natively together. I want to add preprocessing so my JVM 8 code works on JVM 6 or later? I simply add the retrolambda preprocessor, and am done. One LOC. Configuring Babel in the JS world, on the other hand, ends up with several hundred lines of webpack or grunt or gulp configs, you end up dealing with either merging all assets or using system js or whatever the latest fad is. The JS world has recreated all the complexity of the JVM world, but worse.

FabianBeiner 9y ago

Am I missing something? This thing came out like three years ago. If this is news: EVERYONE, CHECK OUT THIS AMAZING THING CALLED BOOTSTRAP!!1! scnr

mrisoli 9y ago
I had the same question, repo has no commits since April 4 and only one release dating back to December last year, and, as another comment pointed out, it uses MDL which has been discontinued in favor of Material Components.

TheAceOfHearts 9y ago

I'd advocate most people avoid this if their intention is to write an app. As an alternative, I'd suggest evaluating create-react-app [0] or preact-cli [1] if you're looking for something lighter. The lack of testing setup and module support in this kit feels like a regression, although I'll concede that it really depends on your use-case. I've been using webpack [2] for a few years and wouldn't willingly go back to this style of writing web apps. Once you learn how to use it, the world is your oyster. You can write a loader or plugin to achieve pretty much any kind of requirement that comes your way. Consider replacing sass with cssnext [3], or even directly using postcss along with the few plugins you need. As an example, you can use native css variables during development and compile em away for production. Another great addition is the :matches selector, which makes for much cleaner selectors in certain cases. I never really found much value in most other sass features. Instead of running imagemin as part of your build process, consider installing imagemin-cli [4] and applying optimizations before checking in images. That way it only has to done once, regardless of how many times someone checks-out your repo. Even if you enable ES2015 compilation with babel, you don't get any polyfills. That means trying to use standard ES2015 globals like Map, Set, or Promise will not work on older browsers. If you're gonna tell people they can add ES2015 support by changing a single line, it would seem prudent to mention this gotcha. [0] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app [1] https://github.com/developit/preact-cli https://github.com/developit/preact-cli [2] https://webpack.js.org https://webpack.js.org [3] http://cssnext.io http://cssnext.io [4] https://github.com/imagemin/imagemin-cli https://github.com/imagemin/imagemin-cli

caludio 9y ago
I agree that this heavily opinionated "starter kit" might be not what you want to give to a beginner (also it feels quite obsolete nowadays), but I quite disagree that create-react-app is a better choice. I think that CRA is either useless as it is too simple and confusing (in its first run, before you "eject"... what are those react scripts, for example?) or too far away down the road of "choose what technique is best for your project" once you "eject". I rather consider using a "true" starter kit, with no helpers and not many applied opinions to it (like, no redux for example and/or no decision on how to handle CSS). With this principle in mind, I wrote my starter kit https://github.com/claudioc/react-with-typescript-starterkit https://github.com/claudioc/react-with-typescript-starterkit (yes, there are many of them already, but I try for it to be a middle ground between something that you want to use to bootstrap an real new app and something you study to learn the _what_ you need to start and begin by yourself).

js4all 9y ago

Hmm, interestingly I got the foobar challenge when I visited the site.

douchescript 9y ago

Gulp, how quaint

xxxmaster 9y ago
Indeed
aoeuasdf1 9y ago
what do you prefer to use?

caub 9y ago

gulp sucks

andrewstuart 9y ago

The right amount of configuration is zero. create-react-app gets it. This does not.

ableton 9y ago

I'm glad to see they are using gulp. I know webpack is the hot new technology, but in my limited experience with webpack, gulp is easier to use and is more intuitive. Webpack has a lot of loaders, but I feel like gulp gives more flexibility out of the box. When I want to do something with gulp that I don't know how to do, I feel like it is easier to implement with gulp, because gulp seems to be a bit lower level. I noticed that they updated the docs for webpack since I last visited, so maybe I will try again.