But this earlier spoof may well be based, intentionally or not, on the SOAP piece you linked -- which was a hit on HN 7 years ago (https://news.ycombinator.com/item?id=2079631).
Thus prompting the observation and related question: These three areas - front-end, deployment, RPC - seem to have engendered a churn in standard approaches, and a corresponding cultish devotion to certain toolkits -- leaving them open for satire. But yet, there is also a need for a guru to explain WTF to do, because a lot of practitioners need to get these jobs done.
So, what is the deeper parallel between the areas? E.g., a lot of corporate resources suddenly poured into these problems, and everyone is funded to come up with, and promote, their own solution?
While criticizing the current state of affairs, it
gives a nice overview of many of the emerging technologies
and how they fit together, even if for some tasks
it feels retarded to pull such an entangled mess of
dependencies.
You can then go insane diving into any particular one :)
Yes, but I really don't like the "How it feels to learn Javascript" title. Realistically you wouldn't give such a wide array of options to someone who wants to learn how to accomplish something specific.
Yes, realistically if you were to have a conversation with an experienced advisor like the article is staging that wouldn't happen. However, the article reflected exactly how I felt trying to do more JS again a few months ago after not having done much JS for a few years.
Being primarily a Java dev, it felt to me like half of this was critiquing the churn rate of using different tools (warranted) and the other half was lamenting the fact that people built tools to solve the common problems they have when developing in large teams (largely unwarranted). Most of those tools have direct equivalents in the Java ecosystem (and there is tool-churn in Java too, just slower).
Facebook, Google, large startups, and the others which are building these tools are doing so to solve the problems they experience in their teams' front-end dev processes. Ironing out the kinks in the code assembly line. And they are of course doing so in a path-dependent fashion: add tool N+1 to solve problem N+1 given the existing toolchain. The result is a lot of tools and a lot of context to imbibe at once, but it doesn't mean they are solving nonexistent problems. Just problems you don't have, or don't know you have, or don't have yet, or can afford to leave unmanaged when developing a small site with just a couple people.
Yes, it is called "Enterprising the sh out of it". And yes, Java (and C#/.Net) has a huge problem with that and Javascript is well on its way.
Large companies love to get cool haircuts and wear torn jeans and talk about building fast and being agile and yet, they continues to build frankenprojects.
I can't speak to other projects, but I know the additional pieces of tooling I add to my buildchain are there to automate tasks that are otherwise undocumented/uncaptured and thus easily forgotten (Joel Test, step 2). On a team of ~50 core committers and ~100 intermittent committers across the globe (which isn't that big compared to other teams), if it doesn't have a CI build running and passing regularly, it will eventually break and stay broken. Examples: code generation, database schema generation and checking, dependency compilation, building artifacts. Other pieces of tooling I add to orthogonalize and amortize common tasks, e.g. Dagger2, Immutables, AutoFactory.
Again, I'm not familiar with flavor-of-week web dev stacks and I'm not defending all of it, but there are clearly steady-state benefits to tooling, even if the initial setup often ends up being a maze because it isn't in the critical path of core developers.
I think there is huge benefit to be gained from projects considering the aggregate bootstrap effort required to get the whole stack running. But I still think this fragmented, modular approach, even with the downsides discussed in this thread, is better than the likely alternative: depending and waiting on a company like Microsoft to deliver a monolithic development environment for which a Product Manager has spent literally years crafting and honing the bootstrapping experience before release.
I have run into the problem discussed in the article multiple times. The first time was with Java, specifically J2EE. It isn't that these are non-existent problems, it is that all of the solutions require a full pull of the entire context. That is bad for both learning and software architecture. I was going to start moving in the J2EE direction (I knew Java itself fairly well), but I realized that getting the most basic program up and running would require knowledge about about 7-10 frameworks. That was ridiculous. Additionally, Java was terrible about framework installation at the time, so that made it even worse.
My preference, and I think it is born out by successful long-term projects, is to always keep everything to a minimum. A lot of people say things like, "that's not the optimal way" or "you could make the page load faster" or "you could integrate with xyz".
But, at the end of the day, you have to measure bang for the buck. Bootstrap - VERY high bang for the buck. Jquery, likewise. Pretty much everything else doesn't start yielding dividends until you are at a facebook-level application.
Which, frankly, is fine for Facebook-level applications. But the problem is that people are using these for everything, which is totally ridiculous. How they find people to pay for all of this is what really blows my mind.
This is pretty much why I don't do front-end. I'm fully capable of it, but I just don't like keeping up with this flavor-of-the-week. It just doesn't feel like programming to me, or at least not the programming I enjoy.
Strangely, I see so many new developers rushing toward the front-end, which seems much more complicated in many ways than just building solid web API services, analyzing data, etc.
Fair enough. I've hit a sweet spot now in having done Ruby for ~8 years, so I can get away with saying, "having someone else deal with the front end. I just want to talk about data".
The new problems I'm working to learn to solve are with ML, NLP, etc. I'd like to step away from web services completely soon, and just live completely with data.
I'm in the same boat. I'm no longer interested in the plumbing, much more the type of questions that can be answered with large scale data, and other types of efficiencies that are dormant with 'pure' code.
I am curious, how did you transition into ml, nlp. I am thinking of transitioning to ml, as work is getting kind of boring for me, but most job requires at least a master in the relevant field. I am self studying right now, maybe going back for a master, but I felt I lack alot of necessary probability and linear algebra theorems. I can code svm, neural network from nothing. I understand basic markov chain, bayes network, but that is really just scratching the surface. Any recommendations?
The 2016 ml scene doesn't seem so different from the 2016 front-end wild west I gather from this thread. Unfortunately. Machine Learning is in rapid flux, the solid theory of svm and the like are getting abandoned for a lot of techniques that seems to work some times. Certainly some people have a very good intuition for what works, and how to make it scale, but there is no one authority and you have to keep constantly up to date.
For a developer role, and in the context of web applications(CRUD-ish) what do you think is the ceiling potential (in terms of earnings) Comparing JS/frontend positions vs backend development?
I don't do that type of analytics, but what I can see is that's it's quite hard to hire a good FE guy.
Backend can be hard as well when looking for specialized stuff like Elixir, OCaml, Scala, Rust, etc. On the other hand, pure Ruby - Python - Java - C++ that's fairly common and not as likely to fetch high salary, since you'd be competing with a larger talent pool.
> Strangely, I see so many new developers rushing toward the front-end
"Easiest" area of programming to get a decent job and enter the industry. It's so much easier to find a job in big cities if you know Angular or React. As long as you keep yourself up to date in frameworks and tools you can theoretically stay employed for a long time.
That said, I have heard of plenty of people who had done the above getting burn out or bored after about a decade.
The "flavor of the week" is mostly a meme. You would be fine just learning ES6, a front-end technology like Angular or React, and a bundler like Webpack. Learning Webpack is painful, but there are other choices.
The front-end is harder IMHO, but as another poster mentioned, the opportunities are tremendous.
>> You would be fine just learning ES6, a front-end technology like Angular or React, and a bundler like Webpack
In nearly every circle of developers I know, they insist you learn plain, vanilla JS first. Jumping in Angular without knowing what a JS object is, understanding how closures work, understanding callbacks, or understanding how JS's "this" works in detail. All things someone should be fluent with before they go jumping into Angular and React.
Also knowing there's a HUGE difference between Angular (which is a full MVC framework) vs. React (which is just the View part of an MVC framework) is a small, but important detail for someone just starting out.
I was assuming that JavaScript would already be known to a certain degree.
I would actually recommend React over Angular for a beginner, because (assuming Angular 2 here) they're going to have to learn Typescript too. That's a big undertaking.
A beginner could also use plain old ES5 with a JSX transpiler right in web page with React.
VueJs might be a better choice than both of those, but much more limited job opportunities.
I feel the perceived "hardness/complexity" of the front-end stack is largely due to the relative less mature nature of JS / CSS / and the ever evolving toolset.
From a pure computer science perspective, I feel the data structure, algorithms leveraged on the backend side has greater complexity potential.
No no no Ember is too old to take advantage of $featureX that you just HAVE to use. There's a couple forks like Coal or Ash that try to enable it but you're still stuck using Embers $designPatternThatWasHotShit5MinutesAgo instead of $newDesignPattern.
Yes, but the point was that the poster said that "flavors of the week" is just a meme, and then said all you need to learn is two current flavors of the week.
I laugh when people doing web work say native is the horror show, the last bit of "churn" I had to deal with was figuring out if JavaFx would be the new Swing, and that pretty much sorted itself out...
After a few years with a framework, for all it's worts, you know it inside and out, limitations and all, and you can work around them. For web stuff it feels like everyone excuses having a million and one solutions by shrugging it off and saying "figure out your problem then find what works for those problems". The issue being there are N frameworks for my problem and I only know N/2 of them well enough to even start evaluating if they solve it, and if there are limitations a new feature comes up against, I'm back to square one in searching for another little tool for this new requirement.
There's something freeing about only having a few solid tools at your disposal, vs a million smaller ones with divided mindshare, even if it can be limiting.
> I would transpile it from Typescript using a Webpack + SystemJS + Babel combo.
Don't find it surprising that the author intentionally makes his/her story more complex than necessary.
For example, you can use "Typescript+WebPack" instead and ditch all the blah-blah on Babel/SystemJs, but that wouldn't help the naritive much, now would it!
The toolset itself has the weirdest gaps. You can get to 80-90% of a website design really quickly with the standard angular+bootstrap or whatever. But when a client wants it to do "Feature X" that is in one of the gaps then you're stuck spending hours trying to either hammer the problem into one of the frameworks or roll your own solution. And it's very hard to explain how "Feature X" took nearly half the time of standard "Features A-W".
I don't think that it's fair to blame the frameworks. You should see it the other way 'round: They save you 80% of your time. The 80/20 rule is real (https://en.wikipedia.org/wiki/Pareto_principle), 20% of the whole work needs 80% of your time.
If you have problems explaining why features need their time, it's not about your frameworks, it's about explaining the clients in all honesty what happens. Or, if you want to get paid enough, you simply factor in some risks into your budget planning and up your budget. They don't have to know that you only needed 2h to get nearly everything up and running and 6h for that one sneaky feature. Use asymmetric information (https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...) to your advantage. It's not about the toolset, it's about your mindset.
I have to disagree. In my experience, the frameworks get me to 80% completion but I'm not spending the next 20% on achieving completion. I'm spending orders of magnitude more than that fighting the framework, trying to make it function the way my product needs to function.
In other words, all of the time saved to get to 80% is lost, and then some, because the framework can't do what my project needs.
I've seen this time and time again, with every framework I have ever used.
I've used Ember.js in the past and must admit that it got in the way and the whole team was magnitudes slower than it should be, although I would also see the bad codebase we had to build upon was a big factor of this, so I can relate to that.
But I've never experienced this problem on projects where I'm able to choose my tools. I use Django and Vue.js with webpack and I can estimate the time constraints for each feature accurately using that stack which is most important for me.
Maybe you've used too opinionated frameworks in the past. If that is the case, loosely coupled frameworks like ampersand.js or very flexible solutions like Vue.js will be a pleasure for you.
In regards to the Pareto Principle: The 80/20 rule means that you need 80% of your time to finish those 20% outside the scope of your framework, not 20%, so your observation fits with this.
It's more like spending 20% of the time on 80% of the features (the standard ones), then 80% of the time on 20% of the features (the details, hard stuff and integration).
It's not about "blaming" anything. But the fact is that software development is much harder to make an accurate estimate for, in many ways, than a highway project and this is because the tools we have available to use are not as mature as they could be.
I am a full stack guy who was doing 50/50 front-end vs back-end till last year. But since then, I've started moving more towards the back end as I simply am not able to keep up with the newer frameworks and libraries coming out everyday.
What is worse, a lot of employers have already decided that if your app isn't written in React + Redux + whatever-is-hot-today, it isn't worth doing. I like to keep my stack fairly simple, and my approach apparently doesn't work.
I still do a fair bit of front-end development, but only when its on my own terms.
I don't even mind the keeping-up part. What I don't understand is how anybody keeps the code base reasonably up to date. I want to build something that lasts.
I was talking to somebody at a place where they're throwing away a big custom code base in favor of gluing together a bunch of aaS stuff. Four years ago, the system was cutting edge. Then they had a big round of layoffs, and they only now can afford to do new work again. One of the big factors in the decision was just the cost of getting everything up to date. There was a bunch of failed flavor-of-the-week stuff that needed to be rewritten. There was a bunch of technical debt from using cutting edge stuff (e.g., library versions pinned to particular GitHub hashes, forks of libraries to get that one feature or work around that one bug). And there was just the proliferation of different technologies picked because they were the "best" for the local problem, but definitely not the best when you account for operations and maintenance cost.
I'm hoping that the roulette wheel eventually stops spinning and the JS world settles on something, anything where I can be confident that somebody can come back a couple of years later and be able to extend it without having to throw everything out.
I guess I'm behind the times in that I still use jQuery. Is it really worthwhile to go through everything described in this article to create a simple filterable table?
if ALL you are displaying is a table, then you can write a quick little jQuery(or native JS) function to remap the array and re-draw the DOM.
If your fancy little table is part of a large app, or even a simple app, it is much easier to implement the entire app using a framework like Angular. The model view concepts really help to tie things together.
Even for trivial SPAs it's often easier to roll the basic functionality yourself. Flipping over to something like Angular introduces technical and cognitive overhead that often isn't worth the trouble for something simple.
What about maintainability? You want everyone who touches your code to figure out your custom solution for data binding? Or you could just follow the conventions established by an industry popular framework that is instantly consumable by another developer?
what is that complexity threshold? Self determined no doubt.
Guy A believes his custom design is simple enough to comprehend by anyone. Guy B doesn't agree.
It doesn't really matter at the end of the day. If you work in a team environment, the toolset will be pre-determined already. You don't have a choice.
Very few teams have the opportunity to switch later on, and if they do, it's at the expense of the job of the person who chose to go without a framework.
Everyone has to refactor into new frameworks later on. Going without a framework early on doesn't add an expense, it actually just subtracts one. It is only if they had chosen the framework (and other code decisions) with perfect future vision that this cost would be mitigated.
I estimate that every 20% that a codebase grows it needs some amount of refactoring. Definitely anything that moves from skunkworks to production will need some pretty heavy rewrites, and will probably need a framework that better meets its newer needs. The question is how much cost was sunk in getting there. The refactor will have to happen no matter what.
But that's just the problem with the modern proliferation. Finding a developer who is proficient enough in all of the frameworks you might be using is difficult. It's not enough just to have a JavaScript developer, you have to specify about 20 frameworks that you are using. It's not possible to train everyone in all of these, so then, even your framework system becomes personal, because it is setup to your personal choices (much like a custom function!). Since new people can't reasonably be required to fully understand the totality of the system, they will still come up with personal hacks, precisely because the set of things to know is too large.
Remember, they don't know which part of the framework you are using or not, or which parts are important or not, so even if you are using it for one little thing, they probably have to learn most of it to understand how it interacts. Since so many frameworks overload standard functionality, it is impossible to know how a framework interacts with your code until you know all of these things.
Using 20 frameworks is about as efficient use of your time as having one you built yourself. The sweet spot for a medium-sized application is using 2-4 (maybe a few more if they are really standard or do really specialized functionality - i.e., a PDF library) for the most critical components, and still maintaining the remaining quirks yourself.
So, for example, Ruby-on-Rails + Bootstrap + JQuery goes a very long way, and doesn't put an undue burden on people trying to get to know your code.
It depends on where you draw the line for "trivial". Does it need routing/browser history? What browsers are you supporting, any legacy ones? Does the frontend do any kind of translations or visualizations with the data it's getting from the server? Does the layout have a bunch of panes and reusable views? Do you want your frontend code to be testable? All of that is an order of magnitude simpler using an actual SPA library or framework. And if you're not doing any of the above, you're probably better off making a server side rendered app with some AJAX sprinkled in anyway. At that point making it an SPA at all is probably overkill.
The huge frontend frameworks have an upfront learning cost and tend to be unfortunately leaky abstractions, but they're still much easier to maintain than a jQuery/JS mess with a bunch of DOM-manipulation code and HTML strings living right next to the business logic. They at least force the code into an understandable architecture and separate the view from business concerns. Experienced developers know how to structure their frontend JS already, but novice ones--the same ones that would feel the pain of learning a framework/ecosystem on top of JS when they first try to pick it up for an SPA--almost certainly won't.
Except then, no one else on your team has any idea what is going on and spends hours making minor changes. And it's probably not tested because jQuery is generally quite a bit harder to test so everyone is scared of making changes.
One time I directed an intern to implement an in-browser list filter functionality using an existing open source library. When I saw his work, he didn't use it. Indicated that he didn't fully understand how to use it. He wrote his own implementation using jquery. It technically worked for the few test cases we tried. It was a mess to look at, with Jquery hooks all over the place. Argh..
Yes, it's definitely worthwhile moving past jQuery, but no you don't have to do everything described in this article.
There's a lightweight framework called Mithril that when used with MSX will give you the feel of React, i.e. the state of your app flows in a straightforward way from the state of your objects, rather than from a series of imperative jQuery operations.
Just start with this example and customize to what you want to do:
This comment is kind of ironic, isn't it? OP asked whether he has to use a framework (albeit a seemingly-complicated one) and you suggest another framework for him to use. Not saying you're wrong, or anything. I just found it kind of funny.
What comment are you referring to where someone asks whether he has to use a framework? The comment I'm answering is this one:
I guess I'm behind the times in that I still use jQuery. Is it really worthwhile to go through everything described in this article to create a simple filterable table?
There's a vast difference between everything described in this article and using a framework.
No, not for a simple filterable table. Stick with jQuery for that. If you start to have many filterable tables that change based on multiple other criteria and live-update based on new data from the server then you should start to think about using a full-on frontend framework.
I'm looking into react, and I fix things in legacy code, but that's still mostly jquery, or native js. But backend I just get things done.. I much prefer working on teams where there are 'specialists' who do all the frontend and I just give them an API to feed into it.
Hilarious article, but seriously, can somebody tell me where I should begin learning all of this stuff?
What are the 2 or 3 top-priority things I should get started with, if I have experience with Django/HTML/JQuery, and want to expand into more advanced frontend programming?
Have you looked into stateless React + Redux? These libraries are interesting in their suggestions for app architecture, and their api's are minimal.
One day perhaps React and Redux will be replaced by something else, but I think the strategy of a GUI functional layer consuming a stream of events is here to stay, and I wouldn't be surprised if it spread to native app design.
I couldn't get through the entire thing. Even knowing that it's a fun/sarcastic piece of writing, the portrayed pain is all too real, as someone just starting to dive into the front-end.
In all honesty, can I still use jQuery for new projects without issues in 2016? Is there a real reason not to?
But honestly, I'd go with React if you can. The reason is, if the app starts taking off, and you end up with a team maintaining your app, you're much less likely to end up with an unmaintainable mess in two years than if you use just jQuery.
All applications, especially websites want frameworks. The framework is essentially a way to organize the massive amount of complexity boiled in. If you just roll with libraries, then you end up cobbling together a framework on top of it. You will then have to maintain this framework. This is fine when it's just you, it will coalesce into a bunch of conventions that's fairly easy for you to reason about.
But once you start involving others, then you're going to see your nice conventions get rekd like a bull in a china shop. Not everybody sees problems the same way you do.
If you pick the framework beforehand, then you don't need to maintain it, you can let the nice people at Facebook / Google do it for you. And whenever you finally get others involved, they're limited in the amount of architectural damage they can do because they have to stick to the conventions of the framework.
I agree - I think React is simple enough that there's no reason not to besides the overhead of JSX preprocessing (which I suppose isn't required but I would definitely recommend). It really is more of a library than a framework, which is great for starting out because there are fewer concepts to understand. Then when you start adding more people and your application gets more complicated and you need to manage your data flow in a more consistent way, you can add something like Redux after the fact incrementally. As long as you don't let components become too large, refactoring isn't too difficult.
React isn't that simple. You still have all the package manager/transpiler/build baggage. You still sacrifice pages that aren't blank if javascript is disabled of fails and all the potential SEO/accessibility costs of that.
And you suddenly end up with great globs of javascript in a page that might not need it.
I guess what I really meant to say is that you could levy the exact same concerns on many other libraries / frameworks. None of that is specific to React.
I guess I was also assuming that if the OP was considering using React in the first place, that they were doing more with jQuery than just minor interactivity improvements. But I suppose your concerns are valid if that assumption isn't true. I'm thinking app, not blog.
Maybe he was but I do worry that anyone new to front-end is being pushed towards frameworks rather than being told to start with the simplest approach possible.
I saw a comment from someone a few weeks ago who knew angular but had never used jQuery. I was rather baffled how that had come to pass!
This a great comment. Yes you can still use jQuery and yes it's still very powerful, but it lets you shoot your own foot off too much -- and your whole team's feet are in danger too.
Angular was a huge step up in "you won't shoot your foot off-ness" and React is a step further. You still can, but you realize that you're loading the gun most of the time and can take a step back.
And that is really all this churn is about -- trying to make things easier and more foolproof. We've introduced other problems trying to solve the first couple batches of problems (accidentally using the development version of Reach on production is one I see a lot), but we'll get there.
The PHP ecosystem has had quite a bit of churn in the last 5 years too, but the yelling about it doesn't seem to be as loud since people aren't forced into it since there are alternate languages.
But getting started is simpler with PHP, also. The framework you'll use (Laravel, Symfony) and is associated coding paradigms will probably be a different one than 4 years back (Codeigniter, CakePHP, w/e), but apart from that composer is pretty much the only new tool you'll use apart from that. No webpack/browserify/transpiling/gulp/bower/whatever.
1. 'if' it's an actual app and not a web page with a smattering of interactivity
2. 'if' by 'take off' you mean becomes a moderately complex SPA
3. 'if' there's no alternative that is simpler and more maintainable (another excuse to plug intercooler.js here)
There aren't enough people saying "Are you sure you need a front-end framework?".
I've worked on several projects that had <insert framework> for no real reason other than the dev wanted to learn it. There is a threshold where it makes sense to use React or similar - but that threshold is being set way, way too low.
React is really very simple. It only takes a short amount of time to learn it, and then when you do you won't get headaches all the time trying to keep track of state.
You don't need to know all the toolchains and crap if you just use create-react-app.
Good to know. Just trying to find a thread (in front-end dev) to latch on to was challenging.
So I threw out everything, and just started from HTML on Gitlab Pages. I've added on CSS, and just started adding in little JS functions. I can now (sort of) appreciate frameworks. React seems to be a popular choice.
I would argue that, for a lot of sites, plain HTML + CSS + little JS functions is the right choice, because building stuff in plain JS is more painful than with frameworks. Having to do it in plain JS makes you think more carefully if you really need this JS. (At least, it does that for me.)
Also, the site loads so much faster, esp. when HTTP/2 is not an option for you (because your hosting does not support it or whatever).
I won't argue, though, that a complex web app should be built on a proper framework.
I also like Vue.js and am surprised it's not getting mentioned much. But it's nice for starting out, in my opinion, since you can pretty much decide if you go all-in. It's quite possible to just use it to sprinkle some JS here and there, but also possible to build SPAs with it.
I did not have a simple experience with React. I did front end development for years, ending with jQuery-driven AJAX sites pulling from REST APIs (2013), and when I tried to learn React this year it was all voodoo.
Is there a good tutorial out there for lapsed front-end devs?
I'm confused what you mean by "multi-component pages". I work with a mildly complex React SPA using a library like Redux and we haven't really had issues with things becoming too complicated.
Maybe it's because I work everyday in a React codebase that is sitting at 150k+ lines of similarly structured code, but I don't find that to be complicated at all. Structure almost always adds overhead, but with the benefit of adding consistency and familiarity. The # of files does not indicated to me how complicated something is.
When I think complicated, I think of code that's hard to understand, hard to modify, or hard to find things you're looking for in. In that example, everything is exactly where you'd expect it to be:
1) Where do I render / present my data? In the presentation components.
2) Where do I take data from the store and pass it to my presentation components? In the container components.
3) Where do I modify data in my stores? In the reducers.
4) Where are my reducers exposed to my container components? In the actions.
Maybe this kind of structure is overkill for a Todo list, but for a complex SPA, this kind of structure is useful and almost makes it _easier_, not harder, to find the things you're looking for. The app I work in is constantly growing and getting more complicated, esp. in regards to the quantity of features, yet I don't find it to be getting harder to go back and find or change things. I think this is due to the functional nature and design of React combined with the architecture we chose that makes this possible.
And in terms of LoC, that example doesn't seem to be much different from the Angular / Backbone implementations of TodoMVC.
> You don't need to know all the toolchains and crap if you just use create-react-app.
I love the hand wavyness of this! Yes, you DO need to know the toolchain. Because if you don't, it is going to be murder on you if you need to track down why something isn't working.
Professional developers need to use professional tools and understand them deeply. There's no compromises here.
While I agree you need to know the toolchain, create-react-app is a professional tool, it works very well. I've struggled before configuring webpack/babel/etc. manually and while it may "murder" me down the road one can always eject if need be.
As long as you stop reading popular blogs and all HN javascript posts, you can use whatever you feel will get the job done. Likely, you'll get it done faster than someone who reads all the popular blogs and chases the shiny.
I'm in a weird position where I like JavaScript and Node but dislike frontend (or at least I am disliking it more and more).
With Node, I can get quite far with just a couple of dependencies that install quickly. I don't need transpilation unless I want to use TypeScript or PureScript and I can target any version I want. I find it very fun to mess around with Node and a bunch of little modules.
I am slowly "transferring" back to server-rended pages using Node or Elixir. Probably not good for my employment (even in NYC most JS jobs are frontend), but whatever.
If I was learning JS right now and didn't care about employment I'd just learn Node (which just means learning JS really) and experiment with stuff.
JavaScript, admittedly, has a few more quicks than the average language but I quite like it. I know a lot of people who also feel the same way. (And as many how, of course, hate JS.)
It still feels to me like we're in the early days of node and the dev infrastructure for "modern" sites. Hopefully, things stabilize soon(ish).
Article title is absolutely not correct, front-end developer is supposed to build an entire UI and corresponding client-side logic, not just write some abstract JavaScript code, code itself is nothing. So it's not about write JS code, but about building maintainable and scalable applications.
All that stuff is actually required to build something maintainable, especially modules. React is not a silver bullet, but nowadays SPA and components approach should be familiar for any front-end developer. I like Typescript was mentioned there.
1 - I've never referred to myself as an "engineer" since I don't see myself as one, nor do I have an engineering degree. This includes the fact I do not have a four year CS degree either.
2 - Front end development has now split. Being a web "designer" means you know HTML5, CSS3 which includes LESS, SASS, PostCSS and other CSS pre-procssors
3 - Being a web "developer" means you're more likely to be a Javscript developer. Meaning you're familiar with Angular, Backbone (I know its soooo 2014 isn't it?), React and other JS frameworks. Every interview I've done in the past two years has almost exclusively focused on JS and how well I know standard JS. Closures, inheritance, debugging, etc. Nobody cares if you know much else other than that.
Where are you interviewing? All I get is Angular and React questions for interviews where I stated up-front to the initial contact that I'm no expert on either and have tended to stay focused on core technology developments when studying on my own time.
There is no excuse for not knowing CSS as a front end/UI developer. That so few know much of anything about it nowadays, or think they don't actually need to is tragic, IMO.
It's bad enough the facts on the ground make it a virtual impossibility to circumvent JS altogether. The best we can do is always wearing gloves when handling it and to never write it manually.
JS, for the oversimplified thing it is, is just systematically overextended with the loads it has to carry now. No framework on earth will make that go away. And neither will ES6.
That's because when you started, all of the complexity was in the back-end; this has moved to the front-end, with backends becoming simpler and more focused on providing data.
The overall complexity was still order of magnitude smaller. There were no transpilers, shims, or complicated multi-step builds, and I knew every single library I was using.
This is what happens when management gives up and turns IT to developers. And I believe that happened when accountants took over because of Sarbanes Oxley. The accountants had no idea what they where getting into. Then the Tech Bubble happened and $$$ filled their eyes. Developers became GODs and now... This happened.
If you are doing a simple project, there is nothing wrong with just using jquery (or imho d3). If you know that your project is always going to be pretty simple or especially if you are learning.
I have been teaching a number of people javascript at my lab lately and I think its unwise to teach new javascripters using any of the modern tools or transpiling until someone runs into one the problems that those tools solve. Having been a javascript coder consistently from the jquery days until now, I am not pining for the simple old days of yore.
It can be hard to learn everything that goes into a big front end app these days but when used correctly all those tools are there for a reason.
You shouldn't use any of these tools just because people tell you to. If you can't see what problem something solves, then start at a simpler/lower level of abstraction until you run into that problem, and can appreciate the tool that solves it.
Of course, this advice doesn't apply if you actually need to write a production app, and aren't just playing around for learning purposes :)
If you stay on the surface and follow trends you will think front end web development is insanity inducing. But if you go deeper, develop your own thinking and deep patterns you will realize that the web platform is doing just fine and is progressing better than most languages/platforms out there.
I've found using Babel / React / transpile tool-chain is actually fairly impossible to use for the majority of developers. I've given up on it several times in favor of plain-ole-javascript and jQuery.
The amount of time it takes to ramp-up on the technical knowledge isn't insurmountable. The main issue is bloat in both code size and dependency chain instability. On a slow connection, you might find yourself battling against your tool chain for half the day. In the case you actually hit a code problem with the underlying technologies, it's going to be hours if not days searching Github for the patched version of the module. If you actually are able to path the specific dependency, it will probably break something else.
I do have hope though. We are starting to see a lot of really cool Babel / React components and projects. I think with a bit more time, we'll get stability in the eco-system as there are less deltas to the underlaying code dependencies and the browser vendors catch up with ES7 features.
This was spot on for me as a hobbyist who has returned to JS after a hiatus of roughly 3 years. On the one hand, it's exciting to see JS evolving into a sophisticated language with dozens of new constructs specced out. On the other hand, as a casual enthusiast I feel trapped between using a small subset of the features available, or wrestling with a tangle of temporary crutches while implementations catch up with the new standards.
196 comments
[ 3.3 ms ] story [ 212 ms ] threadhttp://harmful.cat-v.org/software/xml/soap/simple
But this earlier spoof may well be based, intentionally or not, on the SOAP piece you linked -- which was a hit on HN 7 years ago (https://news.ycombinator.com/item?id=2079631).
Thus prompting the observation and related question: These three areas - front-end, deployment, RPC - seem to have engendered a churn in standard approaches, and a corresponding cultish devotion to certain toolkits -- leaving them open for satire. But yet, there is also a need for a guru to explain WTF to do, because a lot of practitioners need to get these jobs done.
So, what is the deeper parallel between the areas? E.g., a lot of corporate resources suddenly poured into these problems, and everyone is funded to come up with, and promote, their own solution?
While criticizing the current state of affairs, it gives a nice overview of many of the emerging technologies and how they fit together, even if for some tasks it feels retarded to pull such an entangled mess of dependencies.
You can then go insane diving into any particular one :)
Facebook, Google, large startups, and the others which are building these tools are doing so to solve the problems they experience in their teams' front-end dev processes. Ironing out the kinks in the code assembly line. And they are of course doing so in a path-dependent fashion: add tool N+1 to solve problem N+1 given the existing toolchain. The result is a lot of tools and a lot of context to imbibe at once, but it doesn't mean they are solving nonexistent problems. Just problems you don't have, or don't know you have, or don't have yet, or can afford to leave unmanaged when developing a small site with just a couple people.
Large companies love to get cool haircuts and wear torn jeans and talk about building fast and being agile and yet, they continues to build frankenprojects.
Again, I'm not familiar with flavor-of-week web dev stacks and I'm not defending all of it, but there are clearly steady-state benefits to tooling, even if the initial setup often ends up being a maze because it isn't in the critical path of core developers.
I think there is huge benefit to be gained from projects considering the aggregate bootstrap effort required to get the whole stack running. But I still think this fragmented, modular approach, even with the downsides discussed in this thread, is better than the likely alternative: depending and waiting on a company like Microsoft to deliver a monolithic development environment for which a Product Manager has spent literally years crafting and honing the bootstrapping experience before release.
EDIT: wording
My preference, and I think it is born out by successful long-term projects, is to always keep everything to a minimum. A lot of people say things like, "that's not the optimal way" or "you could make the page load faster" or "you could integrate with xyz".
But, at the end of the day, you have to measure bang for the buck. Bootstrap - VERY high bang for the buck. Jquery, likewise. Pretty much everything else doesn't start yielding dividends until you are at a facebook-level application.
Which, frankly, is fine for Facebook-level applications. But the problem is that people are using these for everything, which is totally ridiculous. How they find people to pay for all of this is what really blows my mind.
As a matter of curiosity, would you mind unpacking this statement?
Not really sure if you mean to say the piece imparts a moral lesson. Or perhaps it relates to the writing aesthetics; Or something else
I prefer "jQuery soup."
http://words.steveklabnik.com/rails-has-two-default-stacks
Be thankful, at least it's not 2013, the new-js-framework-on-the-front-page-of-HN-every-day era.
Seems quaint now.
Strangely, I see so many new developers rushing toward the front-end, which seems much more complicated in many ways than just building solid web API services, analyzing data, etc.
If you do keep up, you'll get amazing job offers.
If you manage to really be on the edge, you can give talks as well, expose yourself as a consultant.
That's much easier in JS than with Ruby, Python or whatever else.
The new problems I'm working to learn to solve are with ML, NLP, etc. I'd like to step away from web services completely soon, and just live completely with data.
Backend can be hard as well when looking for specialized stuff like Elixir, OCaml, Scala, Rust, etc. On the other hand, pure Ruby - Python - Java - C++ that's fairly common and not as likely to fetch high salary, since you'd be competing with a larger talent pool.
I've found for FE work, esp for someone with good sense for the visuals, typical off-shore contractors in Asia do not provide the adequate skillset
"Easiest" area of programming to get a decent job and enter the industry. It's so much easier to find a job in big cities if you know Angular or React. As long as you keep yourself up to date in frameworks and tools you can theoretically stay employed for a long time.
That said, I have heard of plenty of people who had done the above getting burn out or bored after about a decade.
The front-end is harder IMHO, but as another poster mentioned, the opportunities are tremendous.
In nearly every circle of developers I know, they insist you learn plain, vanilla JS first. Jumping in Angular without knowing what a JS object is, understanding how closures work, understanding callbacks, or understanding how JS's "this" works in detail. All things someone should be fluent with before they go jumping into Angular and React.
Also knowing there's a HUGE difference between Angular (which is a full MVC framework) vs. React (which is just the View part of an MVC framework) is a small, but important detail for someone just starting out.
I would actually recommend React over Angular for a beginner, because (assuming Angular 2 here) they're going to have to learn Typescript too. That's a big undertaking.
A beginner could also use plain old ES5 with a JSX transpiler right in web page with React.
VueJs might be a better choice than both of those, but much more limited job opportunities.
That's totally fair and then I would completely agree with your comment.
From a pure computer science perspective, I feel the data structure, algorithms leveraged on the backend side has greater complexity potential.
And in 2015 you would have been just fine learning Ember or Angular 2.
And in 2014 you would have been just fine learning Angular 1 or Ember.
And in 2013 you would have been just fine learning Backbone and Ember.
And in 2012 you would have been just fine learning Knockout and Backbone...
WPF, XAML, iOS, Android, Qt.
None of them suffer from the same craziness of the web world.
I used to do web and don't miss it. Actually it was my experience in Web projects that changed my mind that web should have stayed HTML/CSS.
After a few years with a framework, for all it's worts, you know it inside and out, limitations and all, and you can work around them. For web stuff it feels like everyone excuses having a million and one solutions by shrugging it off and saying "figure out your problem then find what works for those problems". The issue being there are N frameworks for my problem and I only know N/2 of them well enough to even start evaluating if they solve it, and if there are limitations a new feature comes up against, I'm back to square one in searching for another little tool for this new requirement.
There's something freeing about only having a few solid tools at your disposal, vs a million smaller ones with divided mindshare, even if it can be limiting.
Don't find it surprising that the author intentionally makes his/her story more complex than necessary.
For example, you can use "Typescript+WebPack" instead and ditch all the blah-blah on Babel/SystemJs, but that wouldn't help the naritive much, now would it!
If you have problems explaining why features need their time, it's not about your frameworks, it's about explaining the clients in all honesty what happens. Or, if you want to get paid enough, you simply factor in some risks into your budget planning and up your budget. They don't have to know that you only needed 2h to get nearly everything up and running and 6h for that one sneaky feature. Use asymmetric information (https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...) to your advantage. It's not about the toolset, it's about your mindset.
In other words, all of the time saved to get to 80% is lost, and then some, because the framework can't do what my project needs.
I've seen this time and time again, with every framework I have ever used.
But I've never experienced this problem on projects where I'm able to choose my tools. I use Django and Vue.js with webpack and I can estimate the time constraints for each feature accurately using that stack which is most important for me.
Maybe you've used too opinionated frameworks in the past. If that is the case, loosely coupled frameworks like ampersand.js or very flexible solutions like Vue.js will be a pleasure for you.
In regards to the Pareto Principle: The 80/20 rule means that you need 80% of your time to finish those 20% outside the scope of your framework, not 20%, so your observation fits with this.
What is worse, a lot of employers have already decided that if your app isn't written in React + Redux + whatever-is-hot-today, it isn't worth doing. I like to keep my stack fairly simple, and my approach apparently doesn't work.
I still do a fair bit of front-end development, but only when its on my own terms.
I was talking to somebody at a place where they're throwing away a big custom code base in favor of gluing together a bunch of aaS stuff. Four years ago, the system was cutting edge. Then they had a big round of layoffs, and they only now can afford to do new work again. One of the big factors in the decision was just the cost of getting everything up to date. There was a bunch of failed flavor-of-the-week stuff that needed to be rewritten. There was a bunch of technical debt from using cutting edge stuff (e.g., library versions pinned to particular GitHub hashes, forks of libraries to get that one feature or work around that one bug). And there was just the proliferation of different technologies picked because they were the "best" for the local problem, but definitely not the best when you account for operations and maintenance cost.
I'm hoping that the roulette wheel eventually stops spinning and the JS world settles on something, anything where I can be confident that somebody can come back a couple of years later and be able to extend it without having to throw everything out.
If your fancy little table is part of a large app, or even a simple app, it is much easier to implement the entire app using a framework like Angular. The model view concepts really help to tie things together.
Even for trivial SPAs it's often easier to roll the basic functionality yourself. Flipping over to something like Angular introduces technical and cognitive overhead that often isn't worth the trouble for something simple.
If your application become sufficiently complex that it can't be easily grokked by a decent dev, that's when you know it's time to switch.
Until then it's just over engineering (which the JS community admittedly loves).
Guy A believes his custom design is simple enough to comprehend by anyone. Guy B doesn't agree.
It doesn't really matter at the end of the day. If you work in a team environment, the toolset will be pre-determined already. You don't have a choice.
I estimate that every 20% that a codebase grows it needs some amount of refactoring. Definitely anything that moves from skunkworks to production will need some pretty heavy rewrites, and will probably need a framework that better meets its newer needs. The question is how much cost was sunk in getting there. The refactor will have to happen no matter what.
Remember, they don't know which part of the framework you are using or not, or which parts are important or not, so even if you are using it for one little thing, they probably have to learn most of it to understand how it interacts. Since so many frameworks overload standard functionality, it is impossible to know how a framework interacts with your code until you know all of these things.
Using 20 frameworks is about as efficient use of your time as having one you built yourself. The sweet spot for a medium-sized application is using 2-4 (maybe a few more if they are really standard or do really specialized functionality - i.e., a PDF library) for the most critical components, and still maintaining the remaining quirks yourself.
So, for example, Ruby-on-Rails + Bootstrap + JQuery goes a very long way, and doesn't put an undue burden on people trying to get to know your code.
The huge frontend frameworks have an upfront learning cost and tend to be unfortunately leaky abstractions, but they're still much easier to maintain than a jQuery/JS mess with a bunch of DOM-manipulation code and HTML strings living right next to the business logic. They at least force the code into an understandable architecture and separate the view from business concerns. Experienced developers know how to structure their frontend JS already, but novice ones--the same ones that would feel the pain of learning a framework/ecosystem on top of JS when they first try to pick it up for an SPA--almost certainly won't.
Just start with this example and customize to what you want to do:
https://github.com/insin/msx/blob/master/demo/index.html
I guess I'm behind the times in that I still use jQuery. Is it really worthwhile to go through everything described in this article to create a simple filterable table?
There's a vast difference between everything described in this article and using a framework.
What are the 2 or 3 top-priority things I should get started with, if I have experience with Django/HTML/JQuery, and want to expand into more advanced frontend programming?
One day perhaps React and Redux will be replaced by something else, but I think the strategy of a GUI functional layer consuming a stream of events is here to stay, and I wouldn't be surprised if it spread to native app design.
In all honesty, can I still use jQuery for new projects without issues in 2016? Is there a real reason not to?
But honestly, I'd go with React if you can. The reason is, if the app starts taking off, and you end up with a team maintaining your app, you're much less likely to end up with an unmaintainable mess in two years than if you use just jQuery.
All applications, especially websites want frameworks. The framework is essentially a way to organize the massive amount of complexity boiled in. If you just roll with libraries, then you end up cobbling together a framework on top of it. You will then have to maintain this framework. This is fine when it's just you, it will coalesce into a bunch of conventions that's fairly easy for you to reason about.
But once you start involving others, then you're going to see your nice conventions get rekd like a bull in a china shop. Not everybody sees problems the same way you do.
If you pick the framework beforehand, then you don't need to maintain it, you can let the nice people at Facebook / Google do it for you. And whenever you finally get others involved, they're limited in the amount of architectural damage they can do because they have to stick to the conventions of the framework.
And you suddenly end up with great globs of javascript in a page that might not need it.
I guess I was also assuming that if the OP was considering using React in the first place, that they were doing more with jQuery than just minor interactivity improvements. But I suppose your concerns are valid if that assumption isn't true. I'm thinking app, not blog.
I saw a comment from someone a few weeks ago who knew angular but had never used jQuery. I was rather baffled how that had come to pass!
Having heard the same from other - "jQuery is OK, use React for new projects" - I'll focus on that then.
Angular was a huge step up in "you won't shoot your foot off-ness" and React is a step further. You still can, but you realize that you're loading the gun most of the time and can take a step back.
And that is really all this churn is about -- trying to make things easier and more foolproof. We've introduced other problems trying to solve the first couple batches of problems (accidentally using the development version of Reach on production is one I see a lot), but we'll get there.
The PHP ecosystem has had quite a bit of churn in the last 5 years too, but the yelling about it doesn't seem to be as loud since people aren't forced into it since there are alternate languages.
1. 'if' it's an actual app and not a web page with a smattering of interactivity
2. 'if' by 'take off' you mean becomes a moderately complex SPA
3. 'if' there's no alternative that is simpler and more maintainable (another excuse to plug intercooler.js here)
There aren't enough people saying "Are you sure you need a front-end framework?".
I've worked on several projects that had <insert framework> for no real reason other than the dev wanted to learn it. There is a threshold where it makes sense to use React or similar - but that threshold is being set way, way too low.
You don't need to know all the toolchains and crap if you just use create-react-app.
So I threw out everything, and just started from HTML on Gitlab Pages. I've added on CSS, and just started adding in little JS functions. I can now (sort of) appreciate frameworks. React seems to be a popular choice.
Also, the site loads so much faster, esp. when HTTP/2 is not an option for you (because your hosting does not support it or whatever).
I won't argue, though, that a complex web app should be built on a proper framework.
Is there a good tutorial out there for lapsed front-end devs?
The point of breakdown probably starts with Redux. There is no simple way of structuring multi-component pages in React. All is suddenly complicated.
When I think complicated, I think of code that's hard to understand, hard to modify, or hard to find things you're looking for in. In that example, everything is exactly where you'd expect it to be:
1) Where do I render / present my data? In the presentation components.
2) Where do I take data from the store and pass it to my presentation components? In the container components.
3) Where do I modify data in my stores? In the reducers.
4) Where are my reducers exposed to my container components? In the actions.
Maybe this kind of structure is overkill for a Todo list, but for a complex SPA, this kind of structure is useful and almost makes it _easier_, not harder, to find the things you're looking for. The app I work in is constantly growing and getting more complicated, esp. in regards to the quantity of features, yet I don't find it to be getting harder to go back and find or change things. I think this is due to the functional nature and design of React combined with the architecture we chose that makes this possible.
And in terms of LoC, that example doesn't seem to be much different from the Angular / Backbone implementations of TodoMVC.
I love the hand wavyness of this! Yes, you DO need to know the toolchain. Because if you don't, it is going to be murder on you if you need to track down why something isn't working.
Professional developers need to use professional tools and understand them deeply. There's no compromises here.
With Node, I can get quite far with just a couple of dependencies that install quickly. I don't need transpilation unless I want to use TypeScript or PureScript and I can target any version I want. I find it very fun to mess around with Node and a bunch of little modules.
I am slowly "transferring" back to server-rended pages using Node or Elixir. Probably not good for my employment (even in NYC most JS jobs are frontend), but whatever.
If I was learning JS right now and didn't care about employment I'd just learn Node (which just means learning JS really) and experiment with stuff.
It still feels to me like we're in the early days of node and the dev infrastructure for "modern" sites. Hopefully, things stabilize soon(ish).
All that stuff is actually required to build something maintainable, especially modules. React is not a silver bullet, but nowadays SPA and components approach should be familiar for any front-end developer. I like Typescript was mentioned there.
I think whoever said this referred to the various IPC methods on Windows, but I do not remember for sure. Seems like some things never change.
1 - I've never referred to myself as an "engineer" since I don't see myself as one, nor do I have an engineering degree. This includes the fact I do not have a four year CS degree either.
2 - Front end development has now split. Being a web "designer" means you know HTML5, CSS3 which includes LESS, SASS, PostCSS and other CSS pre-procssors
3 - Being a web "developer" means you're more likely to be a Javscript developer. Meaning you're familiar with Angular, Backbone (I know its soooo 2014 isn't it?), React and other JS frameworks. Every interview I've done in the past two years has almost exclusively focused on JS and how well I know standard JS. Closures, inheritance, debugging, etc. Nobody cares if you know much else other than that.
JS, for the oversimplified thing it is, is just systematically overextended with the loads it has to carry now. No framework on earth will make that go away. And neither will ES6.
I have been teaching a number of people javascript at my lab lately and I think its unwise to teach new javascripters using any of the modern tools or transpiling until someone runs into one the problems that those tools solve. Having been a javascript coder consistently from the jquery days until now, I am not pining for the simple old days of yore.
It can be hard to learn everything that goes into a big front end app these days but when used correctly all those tools are there for a reason.
You shouldn't use any of these tools just because people tell you to. If you can't see what problem something solves, then start at a simpler/lower level of abstraction until you run into that problem, and can appreciate the tool that solves it.
Of course, this advice doesn't apply if you actually need to write a production app, and aren't just playing around for learning purposes :)
The amount of time it takes to ramp-up on the technical knowledge isn't insurmountable. The main issue is bloat in both code size and dependency chain instability. On a slow connection, you might find yourself battling against your tool chain for half the day. In the case you actually hit a code problem with the underlying technologies, it's going to be hours if not days searching Github for the patched version of the module. If you actually are able to path the specific dependency, it will probably break something else.
I do have hope though. We are starting to see a lot of really cool Babel / React components and projects. I think with a bit more time, we'll get stability in the eco-system as there are less deltas to the underlaying code dependencies and the browser vendors catch up with ES7 features.