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…
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…
Google Web Starter Kit
51–60 of 81 posts
Re: Google Web Starter Kit
#52Earlier quoted context omitted.
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…
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…
Re: Google Web Starter Kit
#53create-react-app gets it.
This does not.
Re: Google Web Starter Kit
#54Earlier quoted context omitted.
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…
What if I want to hire frontend devs for a green-field project—what tech-stack experience do I look for?
Anyone who has a solid grasp of (modern) JavaScript will be fine with any front end tech stack.
Re: Google Web Starter Kit
#55An 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?
> 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.
Angular2 looks solid, but I'm happy with React despite the warts in the ecosystem.
Re: Google Web Starter Kit
#56Earlier quoted context omitted.
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…
What if I want to hire frontend devs for a green-field project—what tech-stack experience do I look for?
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.
Re: Google Web Starter Kit
#57Gulp, how quaint
Re: Google Web Starter Kit
#58I'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…
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…
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.
Re: Google Web Starter Kit
#59Earlier quoted context omitted.
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…
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…
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…
Re: Google Web Starter Kit
#60Earlier quoted context omitted.
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…
What if I want to hire frontend devs for a green-field project—what tech-stack experience do I look for?
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...