Comment by TheAceOfHearts | Hacker News Reader

Comment by TheAceOfHearts | Hacker News Reader

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

[1] https://github.com/developit/preact-cli

[2] https://webpack.js.org

[3] http://cssnext.io

[4] https://github.com/imagemin/imagemin-cli

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

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.

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?

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.

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.

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.

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

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.

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.

* 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

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

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

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.

Reply on news.ycombinator.com