Gulp, how quaint
what do you prefer to use?
Google Web Starter Kit
71–80 of 81 posts
Re: Google Web Starter Kit
#72Earlier quoted context omitted.
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.
Another one of the biggest software companies around came to the opposite conclusion :(
Re: Google Web Starter Kit
#73Earlier 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…
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…
* 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
Re: Google Web Starter Kit
#74Earlier quoted context omitted.
> 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 t…
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.
Re: Google Web Starter Kit
#75I'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…
polyfill.io is worth too
Re: Google Web Starter Kit
#76Earlier quoted context omitted.
> 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 t…
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 o…
> 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.
Re: Google Web Starter Kit
#77Earlier quoted context omitted.
> 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.
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.
> 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...
Re: Google Web Starter Kit
#78Earlier quoted context omitted.
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 o…
> 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 st…
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
Re: Google Web Starter Kit
#79Earlier quoted context omitted.
What if I want to hire frontend devs for a green-field project—what tech-stack experience do I look for?
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 sta…
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.
Re: Google Web Starter Kit
#80Earlier quoted context omitted.
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?
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.