Google Web Starter Kit(developers.google.com)
developers.google.com
Google Web Starter Kit
https://developers.google.com/web/tools/starter-kit/
80 comments
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 (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).
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 (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).
As someone who last web-dev'd in the day of ASP.NET MVC, GWT, jQuery, and backbone.js, this post reads like one of those modern JS development satires [0]
I know you meant well, and this is just the state of the world, but I can't help but feel like a dinosaur just because I spent the last 5 years focusing on server/cloud infrastructure.
Is there any hope for someone like me if I ever want to step back into it? I ask sincerely. It seems like every best-practice framework's compelling proposition these days is that it's "like XYZ, but fixes this obscure edge case", where XYZ is something that only came out 2 years ago, so I never used it, never mind understood properly.
[0] https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
I know you meant well, and this is just the state of the world, but I can't help but feel like a dinosaur just because I spent the last 5 years focusing on server/cloud infrastructure.
Is there any hope for someone like me if I ever want to step back into it? I ask sincerely. It seems like every best-practice framework's compelling proposition these days is that it's "like XYZ, but fixes this obscure edge case", where XYZ is something that only came out 2 years ago, so I never used it, never mind understood properly.
[0] https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
The way to step back into it is to ignore the library froth, pick something that looks understandable from the principles you already know, and build something useful.
Many people spend X hours a day obsessing about whether css-turd-polish.io is better than Sassy.js v4. If you spend those hours working on something productive, you're automatically ahead.
The framework churn is increasingly a perpetual motion machine for conference talks. Don't go to conferences and you won't feel like you're missing anything.
Many people spend X hours a day obsessing about whether css-turd-polish.io is better than Sassy.js v4. If you spend those hours working on something productive, you're automatically ahead.
The framework churn is increasingly a perpetual motion machine for conference talks. Don't go to conferences and you won't feel like you're missing anything.
You can keep track of big new tools and libraries without hopping on every bandwagon, which I guess is why I haven't felt JS fatigue. I'd argue just knowing certain tools even exist can help you do a better job and enable you to make more informed decisions as you tackle new problems. Just create a mental index, in case you later find yourself having to tackle a problem for with the tool is a good fit.
What if I want to hire frontend devs for a green-field project—what tech-stack experience do I look for?
I'd strongly suggest using Webpack to build any new serious frontend projects. It's incredibly powerful and flexible enough to be able to adapt to any changes in the ecosystem without having to throw stuff away. As a data point, I know a large projects that slowly migrated away from AMD, favoring CommonJS, and later ES modules. Since ES modules are part of the standard, it makes sense to converge. This was achieved with comparably minimal effort, without throwing code away, and all while enabling newer code to be written in the modern style.
React is an incredibly safe bet as well. Facebook is so heavily invested in it that they have multiple engineers working on it full-time. Furthermore, since they actually use the framework, any breaking changes are required to have a clear migration path. They published a blog post [0] explaining their strategy for how they intend to handle version transitions, which I consider incredibly developer-friendly. Look at angular 1.x for an example of a horribly handled transition.
[0] https://facebook.github.io/react/blog/2016/02/19/new-version...
React is an incredibly safe bet as well. Facebook is so heavily invested in it that they have multiple engineers working on it full-time. Furthermore, since they actually use the framework, any breaking changes are required to have a clear migration path. They published a blog post [0] explaining their strategy for how they intend to handle version transitions, which I consider incredibly developer-friendly. Look at angular 1.x for an example of a horribly handled transition.
[0] https://facebook.github.io/react/blog/2016/02/19/new-version...
Don't bother with specific tech stacks, because as mentioned, the churn rate is really high. Instead, hire good problem solvers who you can tell from their interviews will be able to choose a framework that works well for your new projects, or adapt to the framework you've chosen yourself for your existing ones.
Understand that good programmers are kind of hard to find, but okay programmers with experience in XYZ stack are not. Why? Because any reasonably competent programmer can become familiar with a new framework or library in about a week or two. Being able to separate the signal from the noise, and architecture an application well within that framework? That's what you're looking for. The tools themselves aren't that important.
Understand that good programmers are kind of hard to find, but okay programmers with experience in XYZ stack are not. Why? Because any reasonably competent programmer can become familiar with a new framework or library in about a week or two. Being able to separate the signal from the noise, and architecture an application well within that framework? That's what you're looking for. The tools themselves aren't that important.
Of course, to follow this advice you have to be able to identify problem-solving ability, which is hard and why most hiring managers fall back on buzzword bingo--to say nothing of HR departments.
My approach with hiring is to try and find solid JavaScript programmers foremost. People with experience in the tech we use, or people with a lot of experience with other languages are nice to haves.
Anyone who has a solid grasp of (modern) JavaScript will be fine with any front end tech stack.
Anyone who has a solid grasp of (modern) JavaScript will be fine with any front end tech stack.
Well, I mean, sure... but, having hired all these random "solid JavaScript programmers", what do I tell them to use and/or learn? To do useful work, they all need to be using the same thing—so... how do I figure out what should be the standard for a project, if there's nothing forcing any particular option?
You can let them decide? Then follow agile principles to make sure they are delivering prototypes/features.
Ideally you would get a grasp of what they need to do and some idea on how they need to do it. If you don't then you should hire someone that does, or who you can feel almost absolute confidence in. Then let them do the hiring.
Just my two cents.
Ideally you would get a grasp of what they need to do and some idea on how they need to do it. If you don't then you should hire someone that does, or who you can feel almost absolute confidence in. Then let them do the hiring.
Just my two cents.
I build MVPs for a living, and I still use vanilla JS and jQuery. I can recruit engineers easily, and my clients really don't care. The technology really doesn't matter. Once the apps move past MVP stage, I let the team decide on what framework they want to build it with. It's generally hard to know what the "ideal" FE framework is until after you have something running. Each one has its own strengths and weaknesses.
In short, you're fine. Don't worry about it. Keep building things in jQuery. It works, there's plenty of documentation, and everyone's familiar with it.
In short, you're fine. Don't worry about it. Keep building things in jQuery. It works, there's plenty of documentation, and everyone's familiar with it.
I just went from "never touching ES6 and not writing JavaScript for five years" to "shipping a React app" in about two weeks. This stuff is not actually all that complicated.
I'd start here: https://github.com/verekia/js-stack-from-scratch
And then, once you've internalized what's going on here, break out create-react-app and just get to work.
I'd start here: https://github.com/verekia/js-stack-from-scratch
And then, once you've internalized what's going on here, break out create-react-app and just get to work.
Chasing technology is a huge mistake. Your end users, your clients, where the money comes from, could not care less if you are coding your website in Visual Basic (is that even possible?). Nope. They are after a solution to a problem. That is ALL they care about. Nothing else. Do not waste your time with this ever-repeating nonsense of chasing the shinny objects.
That doesn't mean you stop learning. It does mean you inject a slow low pass filter in your life and don't react to every little movement in technology. You can learn about them while realizing your end users don't care and, in general terms, these technologies have no material advantages in delivering what customers are after.
Engineers are not business people. Do no follow what someone with no business experience says because you'll find yourself jumping from tech to tech and no servicing your customers.
That doesn't mean you stop learning. It does mean you inject a slow low pass filter in your life and don't react to every little movement in technology. You can learn about them while realizing your end users don't care and, in general terms, these technologies have no material advantages in delivering what customers are after.
Engineers are not business people. Do no follow what someone with no business experience says because you'll find yourself jumping from tech to tech and no servicing your customers.
* If your client is non-technical, endeavor to somewhat describe the trade-off in using simpler technologies, if there are any that matter to them
Actually, you can learn modern frontend framework quickly from free tutorials, and you are up-to-date again, for example: http://yoember.com
If jQuery and Backbone worked for you then, they'll still work for you now. The popular new libraries and tools are all things that solve problems, but you can wait to use them until you think they will help you.
I think it depends a lot on the kind of app you're building. Many of these tools start to shine for larger and more complicated projects that are being developed by many engineers over a long period of time. The web community is pretty large, so there's constant competition over different ideas and approaches. For most tools and libraries, I usually read through the docs when I hear about it and create a mental index that it exists, in case I ever need to solve a problem for which it would be a good fit.
I'll note that plenty of these tools and libraries have been around longer than two years. If I remember correctly, Webpack came out in 2012 and React in 2013. I point out these two projects because they caused a fundamental shift in the way I approached web development, and neither is looking like it'll be going away soon.
My suggestion would be to try out create-react-app [0]. There's still some stumbling points, but it does a good job of showcases the general direction many people in the webdev development community have moved towards. It hides all the build stuff into a black box. As you become more comfortable with the ecosystem and the need arises, you can eject and access all these tools directly.
I totally agree that the webdev community should strive to do a better job at explaining the purpose of all these tools, but I don't think this problem is limited to them in the slightest. In fact, I can assure you I feel the exact same way you do when I look at many of these cloud / devops / server / backend tools.
Do I want chef, puppet, or ansible? Oh, but you need better dynamic configuration management and service discovery, so be sure to pick up consul or etcd. Remember KVM, jails, and vagrant? All those are dead, containers are the new hotness, say hello to Docker. If you wanna be web scale you'll really need Kubernetes, cuz you wanna be like Google, right? But also check out Deis or Flynn, so you can build your own cloud in the cloud. There's a few other HashiCorp products with nice-looking sites, but I don't even understand the problems they solve well enough to even try poking fun at em. Let's not forget databases! Remember MySQL? It cloned itself and changed its name to Maria. But it turns out that it totally sucks and everyone is using PostgreSQL. Those won't work if you're trying to be web scale, turns out RDBMs are a thing of the past, the future is all about NoSQL. Try out Mongo, it's so easy to use! But be sure to also check out Cassandra, CouchDB, and RethinkDB. They're all NoSQL, but different, but still the same [1]. If you're really set on being like Google, then CockroachDB is the only serious choice anyway. Is anything going slow? You'll have to add some caching with redis or memcached. It's time to jump on the real-time train too, so you'll need some pubsub magic, luckily you can use kafka, rabbitmq, or redis. I'll stop now, since I think this is already way too long. However, I'll note I didn't even mention big data, analytics, or monitoring.
[0] https://github.com/facebookincubator/create-react-app
[1] http://imgur.com/QXLL0XJ
I'll note that plenty of these tools and libraries have been around longer than two years. If I remember correctly, Webpack came out in 2012 and React in 2013. I point out these two projects because they caused a fundamental shift in the way I approached web development, and neither is looking like it'll be going away soon.
My suggestion would be to try out create-react-app [0]. There's still some stumbling points, but it does a good job of showcases the general direction many people in the webdev development community have moved towards. It hides all the build stuff into a black box. As you become more comfortable with the ecosystem and the need arises, you can eject and access all these tools directly.
I totally agree that the webdev community should strive to do a better job at explaining the purpose of all these tools, but I don't think this problem is limited to them in the slightest. In fact, I can assure you I feel the exact same way you do when I look at many of these cloud / devops / server / backend tools.
Do I want chef, puppet, or ansible? Oh, but you need better dynamic configuration management and service discovery, so be sure to pick up consul or etcd. Remember KVM, jails, and vagrant? All those are dead, containers are the new hotness, say hello to Docker. If you wanna be web scale you'll really need Kubernetes, cuz you wanna be like Google, right? But also check out Deis or Flynn, so you can build your own cloud in the cloud. There's a few other HashiCorp products with nice-looking sites, but I don't even understand the problems they solve well enough to even try poking fun at em. Let's not forget databases! Remember MySQL? It cloned itself and changed its name to Maria. But it turns out that it totally sucks and everyone is using PostgreSQL. Those won't work if you're trying to be web scale, turns out RDBMs are a thing of the past, the future is all about NoSQL. Try out Mongo, it's so easy to use! But be sure to also check out Cassandra, CouchDB, and RethinkDB. They're all NoSQL, but different, but still the same [1]. If you're really set on being like Google, then CockroachDB is the only serious choice anyway. Is anything going slow? You'll have to add some caching with redis or memcached. It's time to jump on the real-time train too, so you'll need some pubsub magic, luckily you can use kafka, rabbitmq, or redis. I'll stop now, since I think this is already way too long. However, I'll note I didn't even mention big data, analytics, or monitoring.
[0] https://github.com/facebookincubator/create-react-app
[1] http://imgur.com/QXLL0XJ
Isn't create-react-app something of a dead end? It's designed to not be modified. It also doesn't support SSR. I'd lean towards starting with Electrode.
create-react-app offers an 'eject' option, which makes all the configuration visible and adjustable. Ejecting can be used as a starting point from which you can further modify and customize a project.
I feel like Ember and EmberCLI don't get enough love for making it simple to just build web apps instead of having to spend all that up front time learning the toolchain
https://guides.emberjs.com/v2.13.0/getting-started/quick-sta...
https://guides.emberjs.com/v2.13.0/getting-started/quick-sta...
> 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-w...
From https://github.com/google/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-w...
From 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.> Last updated February 9, 2017.
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.
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.
Seriously... this HTML/JavaScript template is FOUR MONTHS OLD, for God's sake! Might as well be jQuery.
Looking at this page, and reading the comments here on HN, I'm glad I'm not a web developer. What a mess.
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.
The mess of Web development is choosing what to use. It's pretty fun once you get behind the wheel.
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.
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.
> The issue with web development is that there’s no good, or working solutions.
This complaint generally comes from the opposite direction—that the JS ecosystem provides "too much choice", which can lead to FOMO or analysis paralysis if you let it.
> 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)...
Gradle, Maven, Buck, Pants, Bazel…
This complaint generally comes from the opposite direction—that the JS ecosystem provides "too much choice", which can lead to FOMO or analysis paralysis if you let it.
> 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)...
Gradle, Maven, Buck, Pants, Bazel…
> This complaint generally comes from the opposite direction—that the JS ecosystem provides "too much choice", which can lead to FOMO or analysis paralysis if you let it.
That’s exactly the issue. You have two hundred choices, but all are broken. Every single choice is missing something. You could patch them together, and get something that kinda works...
...or the developers of the two hundred solutions could work together on a handful of solutions, and have a handful of working solutions.
> Gradle, Maven, Buck, Pants, Bazel…
Buck, Pants, and Bazel are basically unused for now, as none of them handle dependencies properly, and they are almost exclusively used in large, corporate codebases with vendored dependencies.
They are as relevant to this discussion as Perforce is to a discussion about version control: Most startups or users will never have to deal with it.
That’s exactly the issue. You have two hundred choices, but all are broken. Every single choice is missing something. You could patch them together, and get something that kinda works...
...or the developers of the two hundred solutions could work together on a handful of solutions, and have a handful of working solutions.
> Gradle, Maven, Buck, Pants, Bazel…
Buck, Pants, and Bazel are basically unused for now, as none of them handle dependencies properly, and they are almost exclusively used in large, corporate codebases with vendored dependencies.
They are as relevant to this discussion as Perforce is to a discussion about version control: Most startups or users will never have to deal with it.
It's on the way though. I'm amazed that writing javascript is starting to feel (a bit) like scala, once you add transpiling from ES7, lambda syntax, optional implicit typing, modules, a focus on immutability, etc. It's so much nicer than what javascript used to be while keeping full backwards compatibility
And we get to keep the miracle that is robust sandboxing for dynamic code download and execution, and a choice of browsers from vendors consistently following one spec.
And we get to keep the miracle that is robust sandboxing for dynamic code download and execution, and a choice of browsers from vendors consistently following one spec.
> It's on the way though. I'm amazed that writing javascript is starting to feel (a bit) like scala, once you add transpiling from ES7, lambda syntax, optional implicit typing, modules, a focus on immutability, etc. It's so much nicer than what javascript used to be while keeping full backwards compatibility
Even if you use TypeScript, the type system is subpar, the tooling for static analysis is mediocre, and you still need complicated transpilation steps.
As mentioned, I extremely hate the entire build and dependency management infrastructure of the JS world.
Even if you use TypeScript, the type system is subpar, the tooling for static analysis is mediocre, and you still need complicated transpilation steps.
As mentioned, I extremely hate the entire build and dependency management infrastructure of the JS world.
I'm using flowtype and it's certainly no Java, but it's just enough (for now) to build robust front-end SPAs
Would be interesting to transpile from more strongly typed languages also, that's probably where the mainstream is heading
Would be interesting to transpile from more strongly typed languages also, that's probably where the mainstream is heading
> There’s one option for dependency management and handling of compilation and preprocessing (gradle)
Even if Gradle was the only option, you'd still have two choices of which language to write the build scripts in -- newcomer Kotlin or the legacy Apache Groovy.
Even if Gradle was the only option, you'd still have two choices of which language to write the build scripts in -- newcomer Kotlin or the legacy Apache Groovy.
Both of which are designed to look and feel exactly the same. And even then, there’s two choices. Not twenty or two hundred.
So true. The other advantage of a stable environment is better tools. Having got into node based programming years ago the idea of going back to writing code for anything structural just fills me with horror. People love to talk about modularity but writing everything in code is like connecting everything up using a soldering iron.
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.
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.
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.
This is not a good recipe for long-term stability or usability. Doing even simple things is horribly and unnecessarily complicated and feature creep is inevitable. This doesn't lead to innovation, just accumulation.
Nothing stops you from sticking with PHP and jQuery if you think that's better.
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
scnr
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.
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?
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.
> 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.
Angular! Wait, Angular 2. No wait, Polymer. Sorry, how could I be so rude - Progressive Web App with no framework.
Irrespective of whichever Framework is chose, Google (Chrome Dev) emphasis more on making it highly compatible for Mobile Devices, not just on 4G but also on the slow networks of Emerging markets. That's been their recent pitch with PWA!
Yeah. As usual Google's strategy is fragmented and erratic.
Angular2 looks solid, but I'm happy with React despite the warts in the ecosystem.
Angular2 looks solid, but I'm happy with React despite the warts in the ecosystem.
> As usual Google's strategy is fragmented and erratic.
Tech trends are capricious - perhaps they are covering all the bases and self-disrupting? There is a 2014 Ars Technica article titled "Google’s product strategy: Make two of everything"[1].
https://arstechnica.com/business/2014/10/googles-product-str...
Tech trends are capricious - perhaps they are covering all the bases and self-disrupting? There is a 2014 Ars Technica article titled "Google’s product strategy: Make two of everything"[1].
https://arstechnica.com/business/2014/10/googles-product-str...
I prefer a combination of Dart and Google Web Toolkit.
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.
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?
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?
> I'm curious why people keep asking this?
I think this is pretty obvious. Dart was created to be an VM-optimizable language for the web.
I attended talks by it's creators in the early days, and this was the majority of the conversation.
Then other browsers refused to implement it and even stable Chrome never included DartVM, and the project announced it was giving up on that goal.
So with the raison d'etre gone, people wonder if the new language is still used. If infinite RAM had been invented three years ago, people would be asking the same question about Rust today, despite the fact that the language has more to offer than low-overhead maintainable memory management.
I think this is pretty obvious. Dart was created to be an VM-optimizable language for the web.
I attended talks by it's creators in the early days, and this was the majority of the conversation.
Then other browsers refused to implement it and even stable Chrome never included DartVM, and the project announced it was giving up on that goal.
So with the raison d'etre gone, people wonder if the new language is still used. If infinite RAM had been invented three years ago, people would be asking the same question about Rust today, despite the fact that the language has more to offer than low-overhead maintainable memory management.
Okay, thanks!
I was thinking that the decision not to ship with Chrome was very old news, but actually it was just two years ago [1]. Time flies!
Dart for the web is purely a compile-to-JavaScript language now. The last bit will be replacing Dartium with DDC [2].
The Dart VM is still around. It's used in Dart's command-line tools and in Flutter. Also, the Sass compiler is moving from Ruby to Dart. [3]
[1] https://techcrunch.com/2015/03/25/google-will-not-integrate-... [2] http://news.dartlang.org/2017/06/dart-124-faster-edit-refres... [3] http://sass.logdown.com/posts/1909151
I was thinking that the decision not to ship with Chrome was very old news, but actually it was just two years ago [1]. Time flies!
Dart for the web is purely a compile-to-JavaScript language now. The last bit will be replacing Dartium with DDC [2].
The Dart VM is still around. It's used in Dart's command-line tools and in Flutter. Also, the Sass compiler is moving from Ruby to Dart. [3]
[1] https://techcrunch.com/2015/03/25/google-will-not-integrate-... [2] http://news.dartlang.org/2017/06/dart-124-faster-edit-refres... [3] http://sass.logdown.com/posts/1909151
Sure. Some while ago I had an idea for a project and Dart sounded good. I did what I sometimes do with a tech I am thinking about trying: I checked out a few message boards a couple of times a week, and subscribed to reddit's subgroup. At least at that time there was not much activity and not long after Google cancelled the in-browser aspect. It started to seem to me that the up-talk also died away.
I, who do not know much about this thing for sure but I do know that Google will walk away from things, got the impression that is what was happening.
Not fair, maybe, but that's the answer to the question that you asked.
I, who do not know much about this thing for sure but I do know that Google will walk away from things, got the impression that is what was happening.
Not fair, maybe, but that's the answer to the question that you asked.
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
The right amount of configuration is zero.
create-react-app gets it.
This does not.
create-react-app gets it.
This does not.
Hmm, interestingly I got the foobar challenge when I visited the site.
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.
> .gitignore: node_modules
Wait, did I miss something? Wasn't it google who started the "vendor everything" philosophy in the first place?
Wait, did I miss something? Wasn't it google who started the "vendor everything" philosophy in the first place?
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...?
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.
I guess some see a risk of mutability(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. ️
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. ️
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.
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.
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 $$$.
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.
See anything with a "cute" license, such as WTFPL? Don't use it for work.
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.
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.
Another one of the biggest software companies around came to the opposite conclusion :(
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.
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.
Node would be even worse.
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.
That way we can track and keep them in sync without having the problems you described.
Yeah submodules are a nice way to do git-based vendoring. I don't understand why the golang community didn't go that route.
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)
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)
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
[1] https://github.com/developit/preact-cli
[2] https://webpack.js.org
[3] http://cssnext.io
[4] https://github.com/imagemin/imagemin-cli