>Plus, now I have to learn what Redux is, and how Vue is the next best thing that happened since Angular 2.0. How to use styled-components to make JavaScript in React do what CSS can do on it’s own.
I'm glad I get to call the shots where I work, and I've steered my team clear of all of this stuff. If you have a deep knowledge of the core technologies -- HTML, JS, and CSS -- you can build a great front end with a reasonable amount of time and effort. If something breaks, it's likely going to be our own code, and much easier to diagnose and fix.
Shouldn't we be looking at the task at hand and picking the best tool for the job though?
Using a framework because it happened to work last time isn't a good criteria for selection. More and more I'm seeing over-engineered projects that took longer to build than they needed to and are currently harder to support than necessary, all because someone wanted to use their favorite tool.
Plus more people are familiar with a popular open source framework than OPs. There's 100s of thousands of react devs. But only OP knows OPs framework. Most people need to use an existing framework before they try to write their own, because a lot of people try to write frameworks not knowing what frameworks actually do or what is involved.
Either way, the code must follow some sort of conventions or use patterns -- and if you invent your own conventions other people are less likely to understand them. Although if no one ever invented their own conventions we'd never innovate. I just think people should at least try out a bunch of frameworks before deciding they want to make one.
A framework is (like it's namesake) a frame that you can build around, it's a tool that enforces restrictions on you by design. Obviously there is some overhead to learning that framework, but the idea is that the framework is built by someone who spends their day-job building the framework. They are going to do a better job of designing a framework than you will in most cases.
Yes, you can build something great without them, but for any moderately sized project, you will end up re-inventing a set of rules and restrictions to apply to your own internal code. You will in-essence create your own framework.
And that's fine, I'm almost positive that your "framework" will do some things very well, probably better than most of the competition, but you need to ask yourself what your main goal is. Are you setting out to build a framework? And/Or are you trying to build a product?
If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one. Doubly so if that framework isn't designed to be reusable at least in your organization. Not to mention the overhead of having all new devs have to learn it anyway.
However if the answer is that you are setting out to build your own framework (because the current ones have a limitation that you can't deal with, or some problem that you need to solve yourself), then by all means go for it! But that can't be given as "general advice" as for many people (I'd guess most people), as they don't have those same goals as you do.
Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases. (but not all cases!)
Yes, frameworks are tools, but they're typically overspecialized and poorly designed. If vanilla JS is a cnc machine, Angular is an injection mold for a toy truck. If you're building a toy truck, that's awesome.
If you're building anything else, say, a hand mixer, you're going to spend just as much time on the cnc machine trying to design toy truck whisk attachments as you would have spent just building a new mold with the incredibly powerful cnc you already have.
That metaphor doesn't help with the default thinking behind a large proportion of engineering decisions.
It goes like this:
This is hard
=> I want to do one or two slightly different things
=> Building custom things feels like valuable work
=> Use the CNC machine!
This is exactly the thinking that created the Juicero[1] (which actually uses many CNC parts), and we all make fun of them even though the same process is a huge driver behind decisions everywhere. It's like an engineering strawman. Create engineering problems because those are easier than actually building the thing.
The word 'overspecialized' is a bit sour for web frameworks. There are billions of web sites, most of which are astoundingly similar. Squint at the front-end UI and most engineers are basically building Asana, over and over again, like a boot stamping on a human face – forever. The ways they are differentiated are generally not related to code at all, instead business or meta-engineering needs (e.g. NYT dataviz graphics production, or a small team trying to maximize output).
In contrast, everyone needs a router/nav, a wrapper around XHR/an API, some rendering to HTML, and some buttons to do things. If you think Angular (which, stripped down, is ~20kb gz and very basic indeed), or really any framework is too specialized for some set of needs which includes the above four things, you are attacking a very frightened-looking scarecrow with the might of the U.S. Navy. Framework churn is part of this problem; people think they have such big engineering tasks ahead only the new shiny thing can solve it.
The point is, needing the whole CNC is _very rare_. Anyone who thinks that all of the big or even little front-end frameworks are too specialized should go look in the mirror. If, when you do that, you literally see a company with 300 engineers or incredibly specialized needs – like immersive interactive media, or you need IE6 compat, then go build your crazy stuff while the rest of us churn out decent apps with near-zero friction.
But Angular isn't simply "a router/nav, a wrapper around XHR/an API, some rendering to HTML, and some buttons to do things". That's JQuery you're describing. Angular determines the shape of the extensions you can build for it, and general, standard components don't fit its philosophy out of the box.
With the cnc, you can pick parts and modules from a much bigger pool, then cut your enclosure to match. A widgetized, self-contained module is much easier to adapt to a particular use than a framework, for the same end result.
I can't say I agree that a library any easier to use within or outside of a framework.
No matter what if you are using 3rd party libraries you will be writing some "glue". You will need to hook into their API and have it work in your application. Yes frameworks tend to enforce a structure on what that API has to look like (at least from a macro view), but that's a pro of them, not a con, and it's almost never "required" (you could just as easily use the library directly. If you can build a "connector", then you can use it directly whenever needed if it's not much code).
Yes, you may need to write more adapter code than you would if you weren't using a restrictive framework, but once written that "adapter" can be treated like a widgetized self-contained module. And it's instantly understandable to the rest of your dev team because it acts just like the other components/widgets in your codebase, using the same data flow, using the same UI system, etc...
If you're having trouble integrating a library into your framework, then the library is probably the one that's poorly designed. I say this as the 'maintainer' for ng2-dragula (glue code for dragula), which is equally great and terrible.
Great: the dragula library handles lots of common drag/drop patterns.
Not great: it relies 100% on the jQuery model of 'truth in the DOM', and the glue code makes a feeble attempt at flipping that around. When you drag, it literally moves the element and notifies you that it has done so. If you want to customize it, you reply to callbacks that give you the literal elements, and maybe read a data-attr off them. The glue code can automatically mutate an array to match what happened in the DOM, which has been an unmitigated disaster judging by the hundreds of GitHub issues mostly about this one thing.
The problem isn't the restrictive framework that doesn't let you do what you want, it's the API that's not designed for rendering from a non-DOM data model. If you ask 'would it be easier with vanillaJS?' the answer is no – it would still be a stupid way to write drag and drop code, unless you were coding your vanillaJS in an equally abhorrent way.
It will be harder if the parts and modules use ad-hoc specifications instead of adhering to some common framework (e.g. 5v or 3.3v power levels, imperial or metric sizing for drive axles, mounting screws, etc.).
> They are going to do a better job of designing a framework than you will in most cases.
My own framework will do exactly what I need. No more, and no less. It will only solve problems that I actually have, not ones that I don't. My framework will suit my needs better than theirs will, each and every single time.
>If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one.
Time is not the main factor. I would rather have something lightweight that does exactly what I want, and only what I want, than some sort of generic one-size-fits-all thing. I don't want to deal with upgrades that are not backward-compatible. I don't want to spend days debugging someone else's to figure out what I did wrong.
> Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases.
I'm not telling anyone to do anything. I'm only sharing my own personal views on the subject of the article. For a lot of people, I don't doubt that React or Angular is the best course, for a variety of possible reasons.
It's obvious to me that you and I approach the craft of software development from two entirely different angles. It's obvious that you perceive a great deal of value in these framework, so your best bet is to continue using them.
If time isn't the main factor, then by all means you have the right idea! But I've never really been in a situation where I can afford the time and manpower to do everything myself, so my view is skewed by that.
And I do apologise for going off on the tangent there about not telling people to do X or Y. I got a little wrapped up in it and that comment was less targeted at you and more at other people I see advocating for it.
Also, I wouldn't say I perceive a great deal of value in these frameworks, just that I use them like tools where they make sense. Across our codebase we have 2 react applications (one with webpack, one with just script tags), one node.js application without any real framework, and one jquery+vanilla-js codebase. We use the frameworks where they make sense, and don't where they don't. And while i'm absolutely certain that a purpose-built framework would serve us better in many areas than something like react will, I don't have confidence in my skills to create something that will stand the test of time. I know what I don't know, and I'm pretty sure that I made the right choice externalizing that work on to someone who has a team of people working just on that aspect.
I try to spend my time where it's best used, and in the vast majority of cases I've found that it's best spent working directly on my problem domain, and not on aspects like state management, rendering performance, cross-platform compatibility issues, and more where it's not needed.
I don't think there's that big a problem with how many front-end frameworks there are, and the pace of development. I think the problem is people who feel they have to use the latest and greatest feature and they have to know all the frameworks.
At my company we picked a stack and stuck with it. That happened to be React and Redux. I hear Angular 2 and Vue are really great frameworks but I feel under no pressure to really investigate them because we're doing fine as it is.
Two years later and we've barely changed aside from some package versions. We've got a very stable front-end with high code quality and component reuse.
You don't have to listen to the hive-mind. Frameworks don't rust.
Agreed. Honestly at this point I'll take boring. I'd welcome boring. People really need to stop upgrading 0.1 second after something comes out. Take the Java world. You can have a lot of criticism for the language or the platform, but the reality is people get shit done without upgrading right away. It's not even part of the culture. This allows people to master the platform and tools.
In the JS world, there's no mastery. People just keep jumping to newest versions and spend all of their time fighting the new problems. Just. Stop.
The company I work for almost standardized on react/redux. We're not done getting rid of our old stack that people are already looking at Relay Modern, Apollo, MobX, etc. If it wasn't for our investment in a massive home grown React component library, there would probably be VueJS all over the place.
So we lose the ability to help each other. Every team is different, dealing with different problems. We can't build libraries since we don't have a platform to target. That to me makes us much weaker.
So I welcome boring. I welcome the day when people are no longer interested in it so they stop spamming npm to check if a new version of their favorite library is out to upgrade to it when the existing one is working fine.
The issue is leadership. If someone high enough forces standardization, then you are good to go. Just like the old days of only being an 'X' language shop and using only 'Y' framework.
I think the irony is that all the freedom I used to see frontend people using is coming back to bite them and their mindset is slowly moving towards what backend people have been doing for a long time.
The issue is leadership, you're right. But it's not leadership at an individual company level. It's at a community level.
Right now, if you're in a tech hub and you tell FE people "Sorry, we're standardizing on <thing from last year> and we're gonna hold off on major release upgrades without a good reason", you're gonna lose some people and have trouble hiring or deal with constant internal complains. Why? Because their buddies in <other company across the street> aren't dealing with that restriction.
You need some serious charisma to tell people you're sticking with last year's tech and get away with it. If you're in an environment where you can do that AND still hire fast enough to grow, consider yourself lucky and hope your boss never quits :)
True. In the Midwest I guess we are a little more conservative. I have hit the latest and greatest fatigue and am happy to stabilize on something for day to day work. If I want to try something new, I can start a side project.
>In the JS world, there's no mastery. People just keep jumping to newest versions and spend all of their time fighting the new problems. Just. Stop.
The frontend framework we use has had six major releases in a year and a half. And I am talking, rip the guts out and change how it works major releases (How semantic versioning is supposed to work).
Like I appreciate that they are doing active development and making it better (because it is getting better, to be honest), but I still feel like you could fix bugs in some minor versions and do like cut major releases to like every six months at least.
Agreed - I've often thought that having to learn these new frameworks will ultimately lead to terminal juniority. I get that each framework does things differently, and you can learn new patterns from each one, but ultimately you're just re-learning the wheel. Not advancing your skillset.
When we evaluated what tech to migrate to from Angular 1.4, we looked at React and Angular 2. We were also hiring, and the overwhelming majority of devs we spoke to had experience or wanted to work with React.
The marketplace is directed by both buyers and sellers.
Ah, the optimism of youth. Frameworks don't rust if you don't mind sticking with the security bugs of 10-year-old kernels. If you need to upgrade your OS, you need to upgrade your programming languages, which means you need to upgrade your frameworks.
Everything rusts pretty quickly. Maybe you don't need the new features, but you definitely need the new bugfixes.
It's either that or backporting bugfixes to every single past release, right? Is that what you propose? Or a "middle way" with LTS releases?
I mean, you could have separate bugfix and feature releases for a relatively low cost, but that would only alleviate the problem for the duration of a release cycle.
You mark releases as "Stable and supported" and have corporations subscribe against releases. If you are subscribed to a release, you get bug fixes for that release. If someone does not have a subscription to a release, it does not get updated, and if there is no current subscription for that release, you don't accept new ones.
You always allow people to move forward their subscriptions, but never backwards. You provide migration paths for each supported release.
"Here are the keys to a private artifact repo. We will update N major/minor/whatever versions."
I am low-key building a marketplace for this, because this really should exist. The problem, as a marketplace, is identifying projects both important enough that people will pay for it and aren't* already functionally owned by a company that has a vested interest in their own project management.
(Are you a maintainer who's interested in something like this? Are there projects you would pay for this for? I want to hear from you. com dot edropple at ed)
I work at one such large org. We would pay good money for a 5 year support contract for a fixed version of a framework getting backported security (and maybe a few feature) updates.
The problem with publishing bugfixes separate from new features is that you end up with an ever expanding tree to maintain, and you eventually run into problems where bugs become intertwined with features and the right thing to do is extremely hard.
It's a little much to ask from an unpaid open source maintainer, and if you really want it that bad you should be willing to pay for it. Companies like Red Hat have made a living off of people willing to make that tradeoff.
This is why you should choose a frontend framework with a LTS (long-term support) program. (For example, Angular 4 or Ember.) You don't have to upgrade to the latest version of the framework, just the latest LTS version which will have all the relevant bug/security fixes. Only when the framework starts to drop support for the LTS version do you have to deal with upgrading and learning whatever new features they have added since then.
6 months for v.4, then 1 year. Which is still absurdly short. That's not even long enough for sane, normal versioning (e.g. Python 2.6 through 2.6.9 was like 5+ years). These people are crazy.
For Ember at least, the LTS is 4 releases, however all versions are backwards compatible up to the point at which they bump the major version. So you can just keep upgrading whiteout changing code for potentially years.
You make a good point, although I was exclusively referring to front-end JS frameworks. Of course you'd want to update Spring, .NET and whatever else you're using due to vulnerabilities.
But to the point you were making - it's not impossible that browsers could evolve to the point where our current version of React is unusable and it's been long relegated to the buzzword graveyard. Of course in that situation we'd have to maintain our own React branch or rewrite in whatever was a popular front-end framework at the time.
My point is that getting stressed out about the front-end JS framework churn isn't helpful to anyone. Pick a stack and stick with it, and only move when it's simply not productive to stay.
To be fair, I would put react in the same generation of frameworks as Angular 2 and Vue. It just got to the same basic virtual dom + modular components design earlier than the rest. Vue and Angular 2 don't really offer much besides marginal performance boosts (react fiber, preact etc erase this) and a more familiar way of programming for programmers in the last generation of frameworks angular 1/ember.
When people downvote enough to grey out what seems to me to be a decent opinion, I wish they'd at least offer a counterpoint. I agree with bbatha, if this is such a downvote worthy sentiment, I'd like to hear why so I can improve my own thinking.
With all due respect, React and Redux are still "in" and one of those buzz word frameworks right now. Your sentiment would mean a lot more if you were still having success with something like Angular 1.
You aren't proving you are resilient to changes by using one of the most current buzz-word filled frameworks out there for two years. The real test happens when your framework of choice truly becomes obsolete, like with what happened to Angular 1.
Is React still "in"? I thought the recent BSD+Patents furore had made it uncool, but perhaps this doesn't bother developers as much as I originally thought.
A lot of that was overblown, I haven't seen a change in sentiment in the projects I work on. It's not like the patents clause was new, it was just Apache Foundation deciding to ban it that way. So as long as you're not working on an Apache project, you're unaffected.
I completely agree. We are using Angular 1.x at my day job and my team and I are feeling the pain. Manual DOM manipulation compared to React's virtual DOM feels like what it must have used to feel like comparing jQuery to Angular 1.
Perhaps frameworks don't rust in the sense that they deteriorate in terms of capabilities over time. But that doesn't mean that they don't become obsolete. Especially when you're building a product and trying to stay competitive, all the while all the the innovation surrounding a framework has packed up and left for a nicer camp.
We're using Angular 1 too, chosen just over two years ago.
The two-way binding/digest nature has really become our enemy. Everything we write has to account for digests and we've wound up with some terribly ugly code to account for digest problems.
Angular 1 is great for hobbyists and it makes implementing simple forms easy but when you use it for an enterprise app, it hurts.
Our app is still vastly better than decade-old 1.0 we've replaced, but we sure hate the digest now.
>We're using Angular 1 too, chosen just over two years ago.
Good god. You chose Angular 1 two years ago? As in 2015? When its horrific shortcomings were already known and the Angular devs were working on Angular 2.x?
At my old workplace we had a few legacy Meteor projects that absolutely _nobody_ wanted to maintain. In addition to that we could not hire anyone who was both suitably qualified and excited enough to work on Meteor.
We still had to maintain them though as the clients had no money to what would effectively revamp the entire stack to something a lot more maintainable.
Working with a (relatively) unpopular & outdated framework seriously took its toll on both the quality and the developer passion. We had a few really talented people leave simply to avoid working on these projects.
Edit: To echo sixsence's sentiment: Our React & Redux projects have proven themselves to be very resilient over the past few years.
Do you state in you job ads that it is meteor position? Some self selection of applicants might help - you don't need someone super excited, just someone responsible and willing to do that work. At least, that is how our company found long term people for unpopular positions. Turned out they exists, just are hidden and don't know your job is match.
(I personally don't mind working with less popular tech part of time as long as I also work with something that sounds good in CV.)
Just pick one and stick with it. There's some serious FOMO going on in the JavaScript community. When you read articles talking about all the great benefits they see from switching frameworks, what you don't see are the gains they'd have if they just rewrote everything in the same language/framework, taking advantage of the increased experience since the original write.
Web dev is fun because the browser is a freaking awesome plateform.
However, it is _despite_ of JS.
There's not a single characteristic of this language that makes it better than any other mainstream high level language out there. We use it because we have no reasonable alternative on the browser. It has always been a pain to use, requiring:
- avoiding part of the language that is badly designed to escape traps.
- recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc.
- fight with the various implementations to find some code that will work for most of your customers.
- use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS.
The fact that the community is now shooting itself in the foot by providing so many incompatible, badly documented and breaking-compat-all-the-time tools is just icing on the rotten cake.
P.S: since this comment is getting upvotes, I will say that having used in prod vanilla, jquery, react, angular and Vue, I will stick with Vue for the next years. I'm done. My quest is over. It takes 3 hours of reading to be productive with it. It requires no tooling and yet can be used with existing tooling. It's fast. It's well documented. I can now focus on writing software again.
> - avoiding part of the language that is badly designed to escape traps.
This is universally true for any mainstream language where age > 10 years.
> - fight with the various implementations to find some code that will work for most of your customers.
That's an understandable tradeoff from the ability to write code that can run on thousands of different devices. It's very much preferable than writing native code for each platform and all the various implementations that would require.
JS, and the web platform in general, is solving problems that are hard in nature. Considering the constraints imposed by these problems, quite a few features of JS are superior to many other languages.
Consider the wide range of devices that a JS code must support. There is some pain in supporting all of them, but compared with Android development, the transpilers and shims available in JS seems like magic. Cross platform programming is hard, and JS seems wierd because any JS code must consider it, while many C programmers never need to think about it. Taking cross-platform into account, I prefer copying some shims from MDN to using IFDEF WIN32's.
Or consider GUI development. The nice API for working with DOM, lots of available UI components, and specially the asynchronous programming model made possible by Promises is really nice by GUI-programming standards.
Also the good parts/bad parts mindset belongs to the past. I can't remember the last time I even thought of using == vs ===, prototype hacks or similar "bad" parts. The usual post about strange behavior of ">=null" on HN is just amuzing, not problematic for my JS coding experience. As said in other comments, maybe everybody should just stick to using their prefered JS framework and master it.
Async is super simple in JS. Yes callback hell can be an issue, and it may be ugly, but there's many a time where I wished for it in Python and ended writing a script in NodeJS.
Python has asynchronous coroutines (the async/await thing) so you don't really need to do callbacks as far as I know. I personally find that syntax much easier to follow than callbacks.
> - recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc.
It's not so bad now. The language is evolving and gaining these kind of features (modules, standard methods to manipulate data structures). Lodash is just like #include <stdlib>.
> - fight with the various implementations to find some code that will work for most of your customers.
Again this has gotten better over the years. We write vanilla ES5 code with Angular 1.4 and it pretty much just works in every browser. With transpilers it's even better.
> - use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS.
TypeScript and the various babel transforms generally give you a superset of JavaScript, not a different language. JSX lets you write more JavaScript, not less, compared to frameworks that have templating systems.
I'm a bit surprised at these comments if you're writing JavaScript today, for me it's much more accurate of the state of affairs 5-10 years ago.
First-class functions are the star feature of JS. It's what makes it a great language for making UIs (like on the web) and single-threaded web servers (like with Node).
If you don't like the language, that's fine. There's no shortage of languages out there.
I don't have a lot of arguments against tooling/framework issues in the JS world now. The proliferation and churn and quality limits are part of what make things very much not-fun for me. Good thing I can ditch to the server side and other places when I need a break. :) I think things like Vue, though, mark a point where developers are stepping back after the recent madness and asking themselves exactly what problem their tools and frameworks are really trying to solve and starting to do better.
But when it comes to the language itself... speak for yourself. Up until about 5 years ago, I thought JS development was a blast, and I was enjoying it enough that I was using Rhino as my alternate language for the JVM and having fun there too.
And I've built things in a dozen languages, so this isn't didn't-know-much-else-ism.
The fun didn't start, though, until I stopped expecting it to be something else.
"avoiding part of the language that is badly designed to escape traps" == understand the language well enough that what you expect to happen is what actually happens (and accept that just because you're familiar with one behavior in other languages doesn't obligate any other language to replicate it -- those expectations do not necessarily constitute the principle of least surprise).
"recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc." == understand the features that exist in JS well enough that you know how they can do the job you expected features from other languages to be required in order to do
And that's been true of any fun language I've found. There are some languages that never became fun for me because either I don't want to do things the way that the designers do (and in some cases because I expect the designers don't want anybody to have fun, they just want it to be a tool), but all the ones that did become fun required me to actually learn them first. And if somebody actually likes dynamic scripting languages at all, I'm baffled if JS-the-language isn't something they can't achieve contented productivity in. In fact, I'd go so far as to say I'm skeptical that a developer who can't achieve that in JS can genuinely achieve it in Python or Ruby.
"remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS."
For one thing: coffeescript has never been anything other than JS semantics, saying that using babel is an attempt to avoid using JS is like arguing that using Python 3 is an attempt to avoid using Python, and JSX is entirely orthogonal to this topic as it's essentially a templating tool that happens to be a language extension (like E4X) instead of a string processing library.
For another thing... I do remember that 10 years ago that among the contenders for JS libraries there were a number whose central conceit was that the problem with web development was that JS wasn't enough like development in some other language. Prototype's ethos, for example, seemed to be that it wasn't enough like Ruby.
jQuery was like "nope, the chief pain point is our browser APIs, what if we had some that were more amenable to concise practical use, took advantage of JS's functional strengths, and were normalized across browsers?"
I think it's pretty obvious in retrospect who had the key insight.
And I think that most of the progress from this point will come from people who have the same insight: understand JS's strengths, play to them, don't treat the browser or the language as if they need to be some other platform, think about what the general project pain points really are.
Vue is the only glimmer of hope a JS project gave me for the last 5 years.
I actually sent a donation the very first afternoon I started to read their doc, because I decided that even if I would not end up using it, I wanted the author to be supported for just existing in the universe.
Out of curiosity, what did Vue do for you that React didn't? I've been writing React for three years now and I can't find a compelling reason to even try Vue out.
- You don't need tooling to use it. You can use tooling, but you don't need any. It makes it freaking easy and fast to start a small project with Vue and increment on that. Webpack can wait.
- Vue doesn't force components on you. Since most of my "widgets" are not reusable anyway, I really loves this. I write components only when I need to, usually a dozen per projects.
- You don't have to pass state around using callbacks and props to make it works without a store. State is just an easy mutation away. I'm not facebook, most of my projects don't need a flux pattern, and having Russian dolls data passing shenanigans just so I can update my UI is a pain.
- Vue documentation is stellar. It's wonderful. Like a walk in the parc with a friend.
- Vue is so easy to start with. React took me a while to click. Vue took me 20 minutes. It's incredibly easy to train new people coming to your project. And as a professional trainer, the difference with students is just night and day.
- Vue is very, very efficient. The lib is so small. But yet it's faster than react.
- Vue has a lot of helpers that you can tell have been made by a pragmatic author. onclic.prevent and v-on:customevents are poetry to me.
- After after hours and hours of react, I still have to look at the docs. I still have surprises. With Vue, the surprises stopped after day 3.
- I hate JSX. Matter of taste of course. I like the Vue template language, but Vue can optionally use JSX if you prefer it.
- Some very vocal people in the React community are dishonest. They will tell you you can use react without tooling or JSX because technically you could. But technically is not pragmatically. Nobody would. And you are on your own if you try. I hate fan boyism. Compare to Vue: the author even has a comparative page of most frameworks with Vue. He co-wrote the react part with react authors to get it fair. That, I like.
Vue for me means not being tied to the whims of Facebook or Google (Angular) and the directions they need to take their development. Google's reputation for ditching projects and their extremely, IMO, convoluted documentation makes them not even a consideration for me.
React + (early flux and later mobx) made web development fun again for me. I was burned out at the end of the jquery era with all the different homemade structures and the limitations of browsers.
Then I came back to React and babel/gulp (later webpack). Suddently there was structure in the front end that was easy to get into a project and contribute. Building components just felt right. Also js was almost a modern language now and I could use it even if the browsers did not actually support it yet.
I feel the same way... web development was hard, until I've learned about es6/babel, webpack, redux and react (I'm using morphdom as react replacement, but idea is the same). Now web dev is easy and fun. I have state, components, events and routes. That's it. Update the state and stay calm.
The idea to concisely manage the state together with dom diffing, are my personal favorite game changers.
Can you provide some guidance/links to a backend Java developer who wants to learn & use a quality long-term, front-end tech stack? Is there a kickstart example project for your preferred stack? Note that I prefer to avoid nodeJS for any back-end production use but am ok with it as part of the dev toolchain, if required. Thank you.
Stick to https://github.com/facebookincubator/create-react-app/ and you'll be golden. If you need more config later, you can "eject", but this is a one-command-and-go kind of thing that is well maintained and works great.
I would say just start with the React tutorial and use the react-create-app (uses webpack etc in the background and is a npm package) that they use in it. Then after the tutorial I would go into the docs and read through them and maybe test some.
After that I would pick the state management tool I want. Either Redux or Mobx as both are popular and have their advantages and disadvantages. I think it is worth going through both their official tutorials as they are pretty good.
There are of course tons of videos but I think the official tutorials are a great start and using react-create-app instead of trying to dig into webpack and all that is really good at the beginning.
I fully agree. I had that "click" moment with react that really made larger, more complex interfaces seem manageable. Granted that it's still not easy, but most of the time complex apps are tricky to develop and maintain, making sure that they work across a whole load of different devices and their varying screen sizes.
With the huge number of frameworks/libraries/guidelines out their for JS developers, if you can't find a combination that works for you... then front-end work just isn't for you. A lot of people moan about the massive choice of frameworks and libraries. But even the most popular, most maintained and most loved ones will be replaced in a number of years. So find your combination, learn it inside out and ride it's wave until it's time to learn something new that changes paradigms and mindsets.
I teach a course at upenn on intro to javascript. Perhaps the most useful advice I give to my students is that often the simplest tools will get the job done i.e. you don't need React, Redux frontend stack because for most cases jquery will get the job done much quicker. Only worry about the frontend libraries when you feel it's getting out of hand, otherwise, the simple, straightforward tools will suffice.
I guess it depends on how you define simple. To me, React is far simpler than jQuery because of its declarative nature. It’s simple to reason about and easy to maintain and change. I would say it’s a much more straightforward tool than jQuery. However, advising them to delay state management (Redux, MobX) until needed is definitely a good idea.
The desire to constantly switch JS frameworks is really confusing. I find each one different, exciting in their own way and fun to learn. However, and this is a big however, none of them radically change the work you'll create, so I'm happy with React, and not interested in learning just to learn. Maybe in a year or two, I'll try Vue, it won't be too hard to pick up.
If you're at BigCo making internal apps, each one is basically dressing on a way to make various interactive UI states. How you get there is no big deal. How the data flows is no big deal. What test runner you use is no big deal.
As a JS dev, my passion is to learn completely non-JS related things. Cryptography, Blockchain, CS Fundamentals I missed. These are much more interesting than the churn.
Speaking as someone who has seen the ebb and flow of frameworks galore on the front-end and back-end, I've found many devs swing back and forth between love and loathing. It's just a natural evolution of how we use tools, and quite often the over/under application of those for the problems we're trying to solve with them.
We've never had more options available to all of us to build complex systems, applications and services using highly-targeted tools. The new-framework-a-day pace at which these become available to us is fine, but honestly doesn't move the needle for most of us.
A former leader of mine once said: you build things with tools, not popularity contests. I've found keeping such a perspective makes my stress level manageable.
Well, that's what happens when you move the problems from the server to the browser (routing, dynamic data, auth, etc). instead of focusing only on UI you are working on a complete application.
I like making SPAs, but there is really no need to do that. In many cases making an SPA is not even desirable.
Despite its flaws I tend to stick with Backbone whenever I need to do anything sufficiently complex on the frontend, and jQuery if it's any simpler. When writing software for money I've always found it pays to take a conservative approach.
I wouldn't jump too far ahead when writing software for money, it's always better to use something you know will work and have enough familiarity with to adjust around its deficiencies.
But I think Angular 2, React and Vue are all getting to that point if not there already.
I totally agree with the sentiment. While others tend to use SPAs with their complex build system and lifecycle for everything, I follow principles of ROCA [1]. I don't understand why people think it is better and faster to make complex clients that include logic, that has to be verified on the server anyway. Everything I saw / see in the enterprise world is reinvented for client-side development again.
Honestly I love the Javascript Eco system. I love change and js is only getting better and better. Learning a new framework is fun. On top of that it keeps js development marketable. The wages for front end development have sky rocketed which imo is amazing.
It sounds like he doesn't dislike JS, he dislikes what web development has become.
I dislike build tools and all the little doo-dads that we have to have now. Like, sometimes I just want to write some CSS and launch it with `npm start`
Well create an index.html, inline a style tag in said file, write some CSS, npm init, npm install http-server -g, update package.json to with this script "start": "http-server", and profit.
I think this is a good description of how front-end development has become a "tool zoo", where new versions of libraries and frameworks are often radically different, and new libraries/frameworks keep popping up. I compare this to Python, where most of the time learning a new library will keep paying off for years and years. It makes front-end development an expensive (educationally) place to work, and the maintenance costs of the code are substantial.
I must admit having a hard time relating to all the complaints over js churn and the new world of...compiling code. I hated website dev in the past, hated using jQuery, hated being driven insane by the css cascade, hated wasting all my time on arbitrary and stupid browser incompatibility bugs with magic arcane solutions.
I develop apps---not traditional websites---so I know this colors my experience. But every single tech change that I've made the past 4 years has been motivated by a real need. (Of course this assumes I have control over the tech: I'm grateful that I've only been forced to work on one Angular project for work!)
I started using React in December 2013 after a shootout of the competing view libraries at the time because I didn't like having to be Sherlock Holmes to figure out how to change someone else's (or my own!) wild jQuery code, and I always inarticulately felt like I was fighting against a natural flow when using the old MVC frameworks. I now haven't churned my basic framework for almost 4 years. And don't expect to for many more! (I know that to an extent I got lucky: it's easy to forget now how much shit I got at the time for using dumb React lol compared to Angular). Ember is fascinating, I'm glad Preact, etc is around as a backup...but churning would solve no problem for me, and most jobs I'd get (for years now) require React, so why worry about changing?
I've been a redux user for over 2 years now. I eagerly switched over the codebase I was working on because it solved a need I had: getting rid of a bug-prone, undocumented state solution of my own design which everyone else had to figure out for themselves. I expect I will switch out redux one of these years. But haven't seen anything to motivate it yet. Mobx-state-tree is very interesting, but until I see the benefits are worth the switch, why churn?
I did really hate having to worry about babel, webpack, etc since it distracted from writing actual product code, though ES6 was just so obviously better than old JS that it was worth it. But now create-react-app and its siblings make the dev environment a matter of typing a single command. Contrary to this article, it points out errors that could easily have gone undetected in the the old world of wild web dev. No churn here. CRA all the way. Until I run into a need for something new.
Styling solutions are something I have actually churned. But because I knew I wasn't committing, all css-in-js library code I write is in two or three "ui library" files. The app code itself only uses a jsx prop interface. So swapping these libraries on a mature app takes an afternoon at best. Though for the first time I now expect that I'll stick with Glamorous. I expect I'm going to stop churning here because I'm aware of no problem I personally have that Glamorous does not solve, unlike previous css-in-js libraries.
I don't know, this guy's rant just put me in the mood for ranting lol. Anyway, I'm glad this guy found his real interest now might be as an animator and UX designer and I wish him the best! Those are important contributions too, possibly more important.
It's been fun again since I stopped worrying about keeping up with framework churn and all the tooling. I still feel bad when people ask what framework we use and I can rattle off a list of trendy new stuff but I quickly remind myself how asinine that is and go back to making perfectly fine, successful-in-production JS apps with stable boring things like ES5 and Backbone.
I think Framework-itis is a result of front-end developers—who are often junior developers who may not even have CS degrees—inculcating the false message that they are not "real" developers. As an industry, we have treated front-end development work as entry-level, occasionally even frivolous work, as it grew organically out of the left-over work that systems developers gave to the designers.
Developing a framework doesn't look very much like doing front-end work; frameworks are generic, planned, and built from scratch, whereas the typical front-end developer is used to making highly-specific, ad-hoc changes to existing code (either because they've come in on a project started as a proof-of-concept by more senior developers, or they've used a boilerplate generating tool). Being more like so-called "real" software development, only "real" developers should be allowed to work on something ostensibly so important and complex as a "framework".
The front-end developer has been indoctrinated into believing she (and it's very often a she, 'cuz design work is women's work, amiright?) has no business writing code, and that the code she does write is woefully "WRONG, WRONG, you're doing it wrong! What are you even trying to do?" by the karma-craving, bottom-feeders of StackOverflow. To avoid further public shaming—lest there be some hidden defects their inexperienced eyes cannot detect, no matter how trivial the bit of code may be—they avoid the actual act of writing code as much as possible and spend an inordinate amount of time searching for packages that may be imported from the gods. Thus left-pad, and the ensuing post-hoc rationalization in that debacle's aftermath that such trivial micro-packages are somehow a good development practice.
I don't think there are a uniquely numerous quantity of framework projects in front-end land. Systems developers make custom tools all the time. But systems developers don't have a general fear, uncertainty, and doubt about their own work sewn into them, so it's more common for systems developers to jump into writing their own code than looking for pre-existing tools in whatever they might deem as trivial. Instead, I think a plethora of front-end tools reach a unique tipping-point level of popularity giving the perception of many more tools total, because of a general fear of falling behind. The front-end developer sees themselves as having no business criticizing their "betters" and must therefor accept what is handed down to them without question. If the front-end developer cannot prove they are a good little worker bee by keeping pace with any and all frameworks their benevolent employer or more-senior, more-"real" coworkers may spring on them, they risk having to go back to working as a barista.
Something to think about while replying to a seemingly "simple" questions.
I think I know what the history of web dev for the last 20 years has been, considering I've lived and worked through it. Your comment doesn't change anything. There has always been a client-side component of web apps. While in modern times it has become more richly interactive and complex, it's pretty clear the people who work on it have not received a similar upgrade in respect.
> After I was done with the front-end of a project, I hated that I had to do the back-end. I also was not good at it.
After many, many years of tutoring students in a variety of subjects, there is definitely a connection between the last sentence and the first. People who work hard to get good at a particular subject often find themselves enjoying it a lot more. But humans don't care much for delayed gratification. If we have work that we could be doing that we enjoy more than some other work, than the hated work gets put off. Often indefinitely, as no skill in it ever gets developed, the more it is put off.
The last time I've really touched JavaScript is about a year ago, I'm just working with Python these days.
Thinking back, I had 2/3 newsletters about JavaScript and whenever I've read them there was a headline "why X is better than Y", "Y has no chance against Z" "Good old X is better than Z,Y".
I was always feeling, that I'm missing out on something and that I needed to learn new things. Switching to python actually made writing code enjoyable again.
122 comments
[ 0.33 ms ] story [ 32.4 ms ] threadI'm glad I get to call the shots where I work, and I've steered my team clear of all of this stuff. If you have a deep knowledge of the core technologies -- HTML, JS, and CSS -- you can build a great front end with a reasonable amount of time and effort. If something breaks, it's likely going to be our own code, and much easier to diagnose and fix.
Using a framework because it happened to work last time isn't a good criteria for selection. More and more I'm seeing over-engineered projects that took longer to build than they needed to and are currently harder to support than necessary, all because someone wanted to use their favorite tool.
But conversely, common problems and issues with frameworks are easy to find via Google and StackOverflow.
A framework is (like it's namesake) a frame that you can build around, it's a tool that enforces restrictions on you by design. Obviously there is some overhead to learning that framework, but the idea is that the framework is built by someone who spends their day-job building the framework. They are going to do a better job of designing a framework than you will in most cases.
Yes, you can build something great without them, but for any moderately sized project, you will end up re-inventing a set of rules and restrictions to apply to your own internal code. You will in-essence create your own framework.
And that's fine, I'm almost positive that your "framework" will do some things very well, probably better than most of the competition, but you need to ask yourself what your main goal is. Are you setting out to build a framework? And/Or are you trying to build a product?
If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one. Doubly so if that framework isn't designed to be reusable at least in your organization. Not to mention the overhead of having all new devs have to learn it anyway.
However if the answer is that you are setting out to build your own framework (because the current ones have a limitation that you can't deal with, or some problem that you need to solve yourself), then by all means go for it! But that can't be given as "general advice" as for many people (I'd guess most people), as they don't have those same goals as you do.
Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases. (but not all cases!)
If you're building anything else, say, a hand mixer, you're going to spend just as much time on the cnc machine trying to design toy truck whisk attachments as you would have spent just building a new mold with the incredibly powerful cnc you already have.
It goes like this:
This is exactly the thinking that created the Juicero[1] (which actually uses many CNC parts), and we all make fun of them even though the same process is a huge driver behind decisions everywhere. It's like an engineering strawman. Create engineering problems because those are easier than actually building the thing.The word 'overspecialized' is a bit sour for web frameworks. There are billions of web sites, most of which are astoundingly similar. Squint at the front-end UI and most engineers are basically building Asana, over and over again, like a boot stamping on a human face – forever. The ways they are differentiated are generally not related to code at all, instead business or meta-engineering needs (e.g. NYT dataviz graphics production, or a small team trying to maximize output).
In contrast, everyone needs a router/nav, a wrapper around XHR/an API, some rendering to HTML, and some buttons to do things. If you think Angular (which, stripped down, is ~20kb gz and very basic indeed), or really any framework is too specialized for some set of needs which includes the above four things, you are attacking a very frightened-looking scarecrow with the might of the U.S. Navy. Framework churn is part of this problem; people think they have such big engineering tasks ahead only the new shiny thing can solve it.
The point is, needing the whole CNC is _very rare_. Anyone who thinks that all of the big or even little front-end frameworks are too specialized should go look in the mirror. If, when you do that, you literally see a company with 300 engineers or incredibly specialized needs – like immersive interactive media, or you need IE6 compat, then go build your crazy stuff while the rest of us churn out decent apps with near-zero friction.
[1]: https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensi...
With the cnc, you can pick parts and modules from a much bigger pool, then cut your enclosure to match. A widgetized, self-contained module is much easier to adapt to a particular use than a framework, for the same end result.
No matter what if you are using 3rd party libraries you will be writing some "glue". You will need to hook into their API and have it work in your application. Yes frameworks tend to enforce a structure on what that API has to look like (at least from a macro view), but that's a pro of them, not a con, and it's almost never "required" (you could just as easily use the library directly. If you can build a "connector", then you can use it directly whenever needed if it's not much code).
Yes, you may need to write more adapter code than you would if you weren't using a restrictive framework, but once written that "adapter" can be treated like a widgetized self-contained module. And it's instantly understandable to the rest of your dev team because it acts just like the other components/widgets in your codebase, using the same data flow, using the same UI system, etc...
Great: the dragula library handles lots of common drag/drop patterns.
Not great: it relies 100% on the jQuery model of 'truth in the DOM', and the glue code makes a feeble attempt at flipping that around. When you drag, it literally moves the element and notifies you that it has done so. If you want to customize it, you reply to callbacks that give you the literal elements, and maybe read a data-attr off them. The glue code can automatically mutate an array to match what happened in the DOM, which has been an unmitigated disaster judging by the hundreds of GitHub issues mostly about this one thing.
The problem isn't the restrictive framework that doesn't let you do what you want, it's the API that's not designed for rendering from a non-DOM data model. If you ask 'would it be easier with vanillaJS?' the answer is no – it would still be a stupid way to write drag and drop code, unless you were coding your vanillaJS in an equally abhorrent way.
My own framework will do exactly what I need. No more, and no less. It will only solve problems that I actually have, not ones that I don't. My framework will suit my needs better than theirs will, each and every single time.
>If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one.
Time is not the main factor. I would rather have something lightweight that does exactly what I want, and only what I want, than some sort of generic one-size-fits-all thing. I don't want to deal with upgrades that are not backward-compatible. I don't want to spend days debugging someone else's to figure out what I did wrong.
> Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases.
I'm not telling anyone to do anything. I'm only sharing my own personal views on the subject of the article. For a lot of people, I don't doubt that React or Angular is the best course, for a variety of possible reasons.
It's obvious to me that you and I approach the craft of software development from two entirely different angles. It's obvious that you perceive a great deal of value in these framework, so your best bet is to continue using them.
And I do apologise for going off on the tangent there about not telling people to do X or Y. I got a little wrapped up in it and that comment was less targeted at you and more at other people I see advocating for it.
Also, I wouldn't say I perceive a great deal of value in these frameworks, just that I use them like tools where they make sense. Across our codebase we have 2 react applications (one with webpack, one with just script tags), one node.js application without any real framework, and one jquery+vanilla-js codebase. We use the frameworks where they make sense, and don't where they don't. And while i'm absolutely certain that a purpose-built framework would serve us better in many areas than something like react will, I don't have confidence in my skills to create something that will stand the test of time. I know what I don't know, and I'm pretty sure that I made the right choice externalizing that work on to someone who has a team of people working just on that aspect.
I try to spend my time where it's best used, and in the vast majority of cases I've found that it's best spent working directly on my problem domain, and not on aspects like state management, rendering performance, cross-platform compatibility issues, and more where it's not needed.
At my company we picked a stack and stuck with it. That happened to be React and Redux. I hear Angular 2 and Vue are really great frameworks but I feel under no pressure to really investigate them because we're doing fine as it is.
Two years later and we've barely changed aside from some package versions. We've got a very stable front-end with high code quality and component reuse.
You don't have to listen to the hive-mind. Frameworks don't rust.
Unless the framework is iron [1], of course
[1] https://github.com/iron/iron
In the JS world, there's no mastery. People just keep jumping to newest versions and spend all of their time fighting the new problems. Just. Stop.
The company I work for almost standardized on react/redux. We're not done getting rid of our old stack that people are already looking at Relay Modern, Apollo, MobX, etc. If it wasn't for our investment in a massive home grown React component library, there would probably be VueJS all over the place.
So we lose the ability to help each other. Every team is different, dealing with different problems. We can't build libraries since we don't have a platform to target. That to me makes us much weaker.
So I welcome boring. I welcome the day when people are no longer interested in it so they stop spamming npm to check if a new version of their favorite library is out to upgrade to it when the existing one is working fine.
I think the irony is that all the freedom I used to see frontend people using is coming back to bite them and their mindset is slowly moving towards what backend people have been doing for a long time.
Right now, if you're in a tech hub and you tell FE people "Sorry, we're standardizing on <thing from last year> and we're gonna hold off on major release upgrades without a good reason", you're gonna lose some people and have trouble hiring or deal with constant internal complains. Why? Because their buddies in <other company across the street> aren't dealing with that restriction.
You need some serious charisma to tell people you're sticking with last year's tech and get away with it. If you're in an environment where you can do that AND still hire fast enough to grow, consider yourself lucky and hope your boss never quits :)
The frontend framework we use has had six major releases in a year and a half. And I am talking, rip the guts out and change how it works major releases (How semantic versioning is supposed to work).
Like I appreciate that they are doing active development and making it better (because it is getting better, to be honest), but I still feel like you could fix bugs in some minor versions and do like cut major releases to like every six months at least.
The problem is the marketplace and the companies that will demand the skills when one is job searching.
When we evaluated what tech to migrate to from Angular 1.4, we looked at React and Angular 2. We were also hiring, and the overwhelming majority of devs we spoke to had experience or wanted to work with React.
The marketplace is directed by both buyers and sellers.
Ah, the optimism of youth. Frameworks don't rust if you don't mind sticking with the security bugs of 10-year-old kernels. If you need to upgrade your OS, you need to upgrade your programming languages, which means you need to upgrade your frameworks.
Everything rusts pretty quickly. Maybe you don't need the new features, but you definitely need the new bugfixes.
I mean, you could have separate bugfix and feature releases for a relatively low cost, but that would only alleviate the problem for the duration of a release cycle.
What form would the transaction take?
You always allow people to move forward their subscriptions, but never backwards. You provide migration paths for each supported release.
People will pay for it.
http://www.kalzumeus.com/2013/06/17/if-your-business-uses-ra...
https://news.ycombinator.com/item?id=5893961
I am low-key building a marketplace for this, because this really should exist. The problem, as a marketplace, is identifying projects both important enough that people will pay for it and aren't* already functionally owned by a company that has a vested interest in their own project management.
(Are you a maintainer who's interested in something like this? Are there projects you would pay for this for? I want to hear from you. com dot edropple at ed)
It's a little much to ask from an unpaid open source maintainer, and if you really want it that bad you should be willing to pay for it. Companies like Red Hat have made a living off of people willing to make that tradeoff.
But to the point you were making - it's not impossible that browsers could evolve to the point where our current version of React is unusable and it's been long relegated to the buzzword graveyard. Of course in that situation we'd have to maintain our own React branch or rewrite in whatever was a popular front-end framework at the time.
My point is that getting stressed out about the front-end JS framework churn isn't helpful to anyone. Pick a stack and stick with it, and only move when it's simply not productive to stay.
To be fair, I would put react in the same generation of frameworks as Angular 2 and Vue. It just got to the same basic virtual dom + modular components design earlier than the rest. Vue and Angular 2 don't really offer much besides marginal performance boosts (react fiber, preact etc erase this) and a more familiar way of programming for programmers in the last generation of frameworks angular 1/ember.
You aren't proving you are resilient to changes by using one of the most current buzz-word filled frameworks out there for two years. The real test happens when your framework of choice truly becomes obsolete, like with what happened to Angular 1.
But I agree, I do not think everyone is jumping ship to Vue (or whatever) over the license.
Perhaps frameworks don't rust in the sense that they deteriorate in terms of capabilities over time. But that doesn't mean that they don't become obsolete. Especially when you're building a product and trying to stay competitive, all the while all the the innovation surrounding a framework has packed up and left for a nicer camp.
The two-way binding/digest nature has really become our enemy. Everything we write has to account for digests and we've wound up with some terribly ugly code to account for digest problems.
Angular 1 is great for hobbyists and it makes implementing simple forms easy but when you use it for an enterprise app, it hurts.
Our app is still vastly better than decade-old 1.0 we've replaced, but we sure hate the digest now.
Good god. You chose Angular 1 two years ago? As in 2015? When its horrific shortcomings were already known and the Angular devs were working on Angular 2.x?
We still had to maintain them though as the clients had no money to what would effectively revamp the entire stack to something a lot more maintainable.
Working with a (relatively) unpopular & outdated framework seriously took its toll on both the quality and the developer passion. We had a few really talented people leave simply to avoid working on these projects.
Edit: To echo sixsence's sentiment: Our React & Redux projects have proven themselves to be very resilient over the past few years.
(I personally don't mind working with less popular tech part of time as long as I also work with something that sounds good in CV.)
Web dev is fun because the browser is a freaking awesome plateform.
However, it is _despite_ of JS.
There's not a single characteristic of this language that makes it better than any other mainstream high level language out there. We use it because we have no reasonable alternative on the browser. It has always been a pain to use, requiring:
- avoiding part of the language that is badly designed to escape traps.
- recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc.
- fight with the various implementations to find some code that will work for most of your customers.
- use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS.
The fact that the community is now shooting itself in the foot by providing so many incompatible, badly documented and breaking-compat-all-the-time tools is just icing on the rotten cake.
P.S: since this comment is getting upvotes, I will say that having used in prod vanilla, jquery, react, angular and Vue, I will stick with Vue for the next years. I'm done. My quest is over. It takes 3 hours of reading to be productive with it. It requires no tooling and yet can be used with existing tooling. It's fast. It's well documented. I can now focus on writing software again.
This is universally true for any mainstream language where age > 10 years.
> - fight with the various implementations to find some code that will work for most of your customers.
That's an understandable tradeoff from the ability to write code that can run on thousands of different devices. It's very much preferable than writing native code for each platform and all the various implementations that would require.
Basically agree with your other points.
Consider the wide range of devices that a JS code must support. There is some pain in supporting all of them, but compared with Android development, the transpilers and shims available in JS seems like magic. Cross platform programming is hard, and JS seems wierd because any JS code must consider it, while many C programmers never need to think about it. Taking cross-platform into account, I prefer copying some shims from MDN to using IFDEF WIN32's.
Or consider GUI development. The nice API for working with DOM, lots of available UI components, and specially the asynchronous programming model made possible by Promises is really nice by GUI-programming standards.
Also the good parts/bad parts mindset belongs to the past. I can't remember the last time I even thought of using == vs ===, prototype hacks or similar "bad" parts. The usual post about strange behavior of ">=null" on HN is just amuzing, not problematic for my JS coding experience. As said in other comments, maybe everybody should just stick to using their prefered JS framework and master it.
usually do not have to think about it anymore.
It's not so bad now. The language is evolving and gaining these kind of features (modules, standard methods to manipulate data structures). Lodash is just like #include <stdlib>.
> - fight with the various implementations to find some code that will work for most of your customers.
Again this has gotten better over the years. We write vanilla ES5 code with Angular 1.4 and it pretty much just works in every browser. With transpilers it's even better.
> - use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS.
TypeScript and the various babel transforms generally give you a superset of JavaScript, not a different language. JSX lets you write more JavaScript, not less, compared to frameworks that have templating systems.
I'm a bit surprised at these comments if you're writing JavaScript today, for me it's much more accurate of the state of affairs 5-10 years ago.
If you don't like the language, that's fine. There's no shortage of languages out there.
But when it comes to the language itself... speak for yourself. Up until about 5 years ago, I thought JS development was a blast, and I was enjoying it enough that I was using Rhino as my alternate language for the JVM and having fun there too.
And I've built things in a dozen languages, so this isn't didn't-know-much-else-ism.
The fun didn't start, though, until I stopped expecting it to be something else.
"avoiding part of the language that is badly designed to escape traps" == understand the language well enough that what you expect to happen is what actually happens (and accept that just because you're familiar with one behavior in other languages doesn't obligate any other language to replicate it -- those expectations do not necessarily constitute the principle of least surprise).
"recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc." == understand the features that exist in JS well enough that you know how they can do the job you expected features from other languages to be required in order to do
And that's been true of any fun language I've found. There are some languages that never became fun for me because either I don't want to do things the way that the designers do (and in some cases because I expect the designers don't want anybody to have fun, they just want it to be a tool), but all the ones that did become fun required me to actually learn them first. And if somebody actually likes dynamic scripting languages at all, I'm baffled if JS-the-language isn't something they can't achieve contented productivity in. In fact, I'd go so far as to say I'm skeptical that a developer who can't achieve that in JS can genuinely achieve it in Python or Ruby.
"remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS."
For one thing: coffeescript has never been anything other than JS semantics, saying that using babel is an attempt to avoid using JS is like arguing that using Python 3 is an attempt to avoid using Python, and JSX is entirely orthogonal to this topic as it's essentially a templating tool that happens to be a language extension (like E4X) instead of a string processing library.
For another thing... I do remember that 10 years ago that among the contenders for JS libraries there were a number whose central conceit was that the problem with web development was that JS wasn't enough like development in some other language. Prototype's ethos, for example, seemed to be that it wasn't enough like Ruby.
jQuery was like "nope, the chief pain point is our browser APIs, what if we had some that were more amenable to concise practical use, took advantage of JS's functional strengths, and were normalized across browsers?"
I think it's pretty obvious in retrospect who had the key insight.
And I think that most of the progress from this point will come from people who have the same insight: understand JS's strengths, play to them, don't treat the browser or the language as if they need to be some other platform, think about what the general project pain points really are.
I actually sent a donation the very first afternoon I started to read their doc, because I decided that even if I would not end up using it, I wanted the author to be supported for just existing in the universe.
Of course I ended up using it anyway.
For me the selling points of Vue are:
- You don't need tooling to use it. You can use tooling, but you don't need any. It makes it freaking easy and fast to start a small project with Vue and increment on that. Webpack can wait.
- Vue doesn't force components on you. Since most of my "widgets" are not reusable anyway, I really loves this. I write components only when I need to, usually a dozen per projects.
- You don't have to pass state around using callbacks and props to make it works without a store. State is just an easy mutation away. I'm not facebook, most of my projects don't need a flux pattern, and having Russian dolls data passing shenanigans just so I can update my UI is a pain.
- Vue documentation is stellar. It's wonderful. Like a walk in the parc with a friend.
- Vue is so easy to start with. React took me a while to click. Vue took me 20 minutes. It's incredibly easy to train new people coming to your project. And as a professional trainer, the difference with students is just night and day.
- Vue is very, very efficient. The lib is so small. But yet it's faster than react.
- Vue has a lot of helpers that you can tell have been made by a pragmatic author. onclic.prevent and v-on:customevents are poetry to me.
- After after hours and hours of react, I still have to look at the docs. I still have surprises. With Vue, the surprises stopped after day 3.
- I hate JSX. Matter of taste of course. I like the Vue template language, but Vue can optionally use JSX if you prefer it.
- Some very vocal people in the React community are dishonest. They will tell you you can use react without tooling or JSX because technically you could. But technically is not pragmatically. Nobody would. And you are on your own if you try. I hate fan boyism. Compare to Vue: the author even has a comparative page of most frameworks with Vue. He co-wrote the react part with react authors to get it fair. That, I like.
Then I came back to React and babel/gulp (later webpack). Suddently there was structure in the front end that was easy to get into a project and contribute. Building components just felt right. Also js was almost a modern language now and I could use it even if the browsers did not actually support it yet.
The idea to concisely manage the state together with dom diffing, are my personal favorite game changers.
After that I would pick the state management tool I want. Either Redux or Mobx as both are popular and have their advantages and disadvantages. I think it is worth going through both their official tutorials as they are pretty good.
https://facebook.github.io/react/tutorial/tutorial.html
http://redux.js.org
https://mobx.js.org
There are of course tons of videos but I think the official tutorials are a great start and using react-create-app instead of trying to dig into webpack and all that is really good at the beginning.
With the huge number of frameworks/libraries/guidelines out their for JS developers, if you can't find a combination that works for you... then front-end work just isn't for you. A lot of people moan about the massive choice of frameworks and libraries. But even the most popular, most maintained and most loved ones will be replaced in a number of years. So find your combination, learn it inside out and ride it's wave until it's time to learn something new that changes paradigms and mindsets.
(Also, hey neighbor—I live right off campus)
If you're at BigCo making internal apps, each one is basically dressing on a way to make various interactive UI states. How you get there is no big deal. How the data flows is no big deal. What test runner you use is no big deal.
As a JS dev, my passion is to learn completely non-JS related things. Cryptography, Blockchain, CS Fundamentals I missed. These are much more interesting than the churn.
Stopped reading right there. CSS-in-JS is one of the main reasons I'm even using React to begin with.
We've never had more options available to all of us to build complex systems, applications and services using highly-targeted tools. The new-framework-a-day pace at which these become available to us is fine, but honestly doesn't move the needle for most of us.
A former leader of mine once said: you build things with tools, not popularity contests. I've found keeping such a perspective makes my stress level manageable.
I like making SPAs, but there is really no need to do that. In many cases making an SPA is not even desirable.
But I think Angular 2, React and Vue are all getting to that point if not there already.
[1] http://roca-style.org/
I dislike build tools and all the little doo-dads that we have to have now. Like, sometimes I just want to write some CSS and launch it with `npm start`
Fear not, we have the technology.
This rings true to me. It's also partially why I don't really mind front-end development like I used to.
I develop apps---not traditional websites---so I know this colors my experience. But every single tech change that I've made the past 4 years has been motivated by a real need. (Of course this assumes I have control over the tech: I'm grateful that I've only been forced to work on one Angular project for work!)
I started using React in December 2013 after a shootout of the competing view libraries at the time because I didn't like having to be Sherlock Holmes to figure out how to change someone else's (or my own!) wild jQuery code, and I always inarticulately felt like I was fighting against a natural flow when using the old MVC frameworks. I now haven't churned my basic framework for almost 4 years. And don't expect to for many more! (I know that to an extent I got lucky: it's easy to forget now how much shit I got at the time for using dumb React lol compared to Angular). Ember is fascinating, I'm glad Preact, etc is around as a backup...but churning would solve no problem for me, and most jobs I'd get (for years now) require React, so why worry about changing?
I've been a redux user for over 2 years now. I eagerly switched over the codebase I was working on because it solved a need I had: getting rid of a bug-prone, undocumented state solution of my own design which everyone else had to figure out for themselves. I expect I will switch out redux one of these years. But haven't seen anything to motivate it yet. Mobx-state-tree is very interesting, but until I see the benefits are worth the switch, why churn?
I did really hate having to worry about babel, webpack, etc since it distracted from writing actual product code, though ES6 was just so obviously better than old JS that it was worth it. But now create-react-app and its siblings make the dev environment a matter of typing a single command. Contrary to this article, it points out errors that could easily have gone undetected in the the old world of wild web dev. No churn here. CRA all the way. Until I run into a need for something new.
Styling solutions are something I have actually churned. But because I knew I wasn't committing, all css-in-js library code I write is in two or three "ui library" files. The app code itself only uses a jsx prop interface. So swapping these libraries on a mature app takes an afternoon at best. Though for the first time I now expect that I'll stick with Glamorous. I expect I'm going to stop churning here because I'm aware of no problem I personally have that Glamorous does not solve, unlike previous css-in-js libraries.
I don't know, this guy's rant just put me in the mood for ranting lol. Anyway, I'm glad this guy found his real interest now might be as an animator and UX designer and I wish him the best! Those are important contributions too, possibly more important.
Developing a framework doesn't look very much like doing front-end work; frameworks are generic, planned, and built from scratch, whereas the typical front-end developer is used to making highly-specific, ad-hoc changes to existing code (either because they've come in on a project started as a proof-of-concept by more senior developers, or they've used a boilerplate generating tool). Being more like so-called "real" software development, only "real" developers should be allowed to work on something ostensibly so important and complex as a "framework".
The front-end developer has been indoctrinated into believing she (and it's very often a she, 'cuz design work is women's work, amiright?) has no business writing code, and that the code she does write is woefully "WRONG, WRONG, you're doing it wrong! What are you even trying to do?" by the karma-craving, bottom-feeders of StackOverflow. To avoid further public shaming—lest there be some hidden defects their inexperienced eyes cannot detect, no matter how trivial the bit of code may be—they avoid the actual act of writing code as much as possible and spend an inordinate amount of time searching for packages that may be imported from the gods. Thus left-pad, and the ensuing post-hoc rationalization in that debacle's aftermath that such trivial micro-packages are somehow a good development practice.
I don't think there are a uniquely numerous quantity of framework projects in front-end land. Systems developers make custom tools all the time. But systems developers don't have a general fear, uncertainty, and doubt about their own work sewn into them, so it's more common for systems developers to jump into writing their own code than looking for pre-existing tools in whatever they might deem as trivial. Instead, I think a plethora of front-end tools reach a unique tipping-point level of popularity giving the perception of many more tools total, because of a general fear of falling behind. The front-end developer sees themselves as having no business criticizing their "betters" and must therefor accept what is handed down to them without question. If the front-end developer cannot prove they are a good little worker bee by keeping pace with any and all frameworks their benevolent employer or more-senior, more-"real" coworkers may spring on them, they risk having to go back to working as a barista.
Something to think about while replying to a seemingly "simple" questions.
After many, many years of tutoring students in a variety of subjects, there is definitely a connection between the last sentence and the first. People who work hard to get good at a particular subject often find themselves enjoying it a lot more. But humans don't care much for delayed gratification. If we have work that we could be doing that we enjoy more than some other work, than the hated work gets put off. Often indefinitely, as no skill in it ever gets developed, the more it is put off.
I was always feeling, that I'm missing out on something and that I needed to learn new things. Switching to python actually made writing code enjoyable again.