Live data from Hacker News

Google Web Starter Kit

developers.google.com

61–70 of 81 posts

Re: Google Web Starter Kit

#61
post #54
post #52

Earlier quoted context omitted.

What if I want to hire frontend devs for a green-field project—what tech-stack experience do I look for?

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.

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?

Re: Google Web Starter Kit

#62
post #30

Earlier 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…

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

Re: Google Web Starter Kit

#63
post #47

Earlier 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…

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.

Re: Google Web Starter Kit

#64

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…

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.

Re: Google Web Starter Kit

#65

Earlier quoted context omitted.

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.

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.

Re: Google Web Starter Kit

#66

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…

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.

Re: Google Web Starter Kit

#67

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…

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.

Re: Google Web Starter Kit

#68

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…

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

Re: Google Web Starter Kit

#69
post #62
post #30

Earlier quoted context omitted.

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…

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

Both of which are designed to look and feel exactly the same. And even then, there’s two choices. Not twenty or two hundred.

Re: Google Web Starter Kit

#70
post #30

Earlier quoted context omitted.

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…

> 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 preprocess…

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

Post reply on HN