23 ms·

Why Is Front-End Development So Unstable?

• tw1010 8y ago
  "Unstable", "Issue", "Problem". The opposite of the front-end world is not something to desire. Change means people are fixing problems and giving away their solutions for free. To desire less change means wishing fewer people gave away their work.
  • ozim 8y ago
    I am ok with that. If more people giving away their work ends up with "left-pad" situation. Also most of git hub repos are crap to be abandoned after couple months. As in article if people share code to be "ninja", "rockstar" devs that is wrong approach and I don't want that code. Because solution is not honest, not reliable and probably will be dumped as soon as "rockstar" will find another flashy term where he can gain more "ninja" points.
  • PrimHelios 8y ago
    Change is good, the issue is instability and volatility. Things have breaking changes far too quickly.
  • tiberius1900 8y ago
    Change is not necessary a good thing. Bad change is worse then no change at all. However, when it comes to programming frameworks, rapid, unstable, change is generally not very desirable. Take a look at the most popular open-source OS/kernel in the world: Linux. It's a Unix-clone using a monolithic kernel made in a time when Lisp machines existed and microkernels were all the rage. It used ANSI C which, to be fair, was new at the time, but stuck with it, in the face of C99 and C++. And, as a windowing system, it still uses X11, a system designed in the mid '80s. There has been a very slow migration towards Wayland (which is now already 10 years old). As it's scripting language it uses bash (1989), which inherits a lot of it's characteristics from the Bourne shell (1977). Yes, in the case of Linux may be a little bit biased as OS development back than was still more mature than front-end is now, but still, the principle still holds: "slow and steady wins the race".
• baybal2 8y ago
  >Why is Front-End Development So Unstable? Because on average, the skill level in the whole webdev community is low. Below that of "a dev with average schooling, and average industry experience" Webdev has close to no barriers for entry, and is under the strongest influence from the fact that the evaluation of deliverables is not done by another tech professional out of all software development jobs The combo above makes things that are unheard of in other software development niches possible, like meeting borderline or de-facto frauds running webdev businesses selling "ultrasophisticated" corporate websites on Wordpress to F500 types for few $k USD per hour of dev time, or well entrenched in-house "developers" in tech giants who made it to six digits on technobabling to non-tech managers and copy and paste. All of this is evidently projecting onto to the tech solutions used in the trade, and the popular image of the webdev development process. And over the time, popular stereotypes are becoming self fulfilling prophesies: Angular - was an okish framework at near 1.0, but marketing messaging made it look like an "enterprise stuff," and their devs eventually turned it into it - purposelessly overengineered monster filled with SOAisms; jQuery - got bad fame for unusable, animation rich websites made by least talented part of the dev community, and this infamity has both sealed its further development, and was responsible for attracting even more unskilled devs into making websites with crawling slow animation; And like this for few pages, as well as for the notion of webdev world being "unstable." Many people here who are not novices to webdev can probably call few sites that had a "single piece of JS code continuously maintained over 10 years" or more. I myself knew people who were making yandex.ru homepage in nineties, they say that a very sophisticated ajax autocomplete code there was developed and maintained continuously since 2004
  • overcast 8y ago
    Damn dude, why so negative? Reading through your comment history, it's apparent. Life is too short to be miserable on the internet.
    • baybal2 8y ago
      Well, I can say that I am just coming out of few years long miserable period of my life that came after I was kicked out of Canada thanks to "LMIA disaster" after spending 6 years of my life securing my future in the country. Right now, I am easily passing under the points system, but nah, after such shameless bait and switch with immigration policy, there is no way I am going back. Good things, I am out of webdev as an industry, and finally working in a more serious function in an engineering consulting now - something I was aiming at from my teen years, when I was still not in "money over job satisfaction" mode of thinking.
• kuon 8y ago
  I work with elm now for frontend. It has often been criticized for being too conservative and slow paced in its development. But the result is that code is easier to maintain, libraries have a great quality and most of the time there is only one, obvious, way of doing something.
  • freedomben 8y ago
    Somewhat unrelated, but a couple of questions for you: 1. How did you learn elm? 2. Was elm your first functional language? (Not wanting the "javascript is a functional language" battle here plz) 3. What is your backend written in? Do you maintain that? 4. What libraries do you make use of? 5. Any regrets?
    • z5h 8y ago
      I wrote this in Elm: https://ixberg.com https://ixberg.com. (feel free to sign up, use it, share it). I learned Elm by going to an intro course at Lambdaconf, and watching this https://frontendmasters.com/courses/elm/ https://frontendmasters.com/courses/elm/ and coding in it. Elm was my first PURE functional language. I've done some Scheme before. Backend is Firebase. No special libraries in particular. No regrets.
      • LandR 8y ago
        Am I missing something on ixberg.com, I can't sign up? Only have sign in but that is not clickable?
    • kuon 8y ago
      1. By chance, after a long and tiring typescript project, I looked for something else. 2. No, my first functional language was clojure script, which I tried before elm, I liked the concept but just couldn't bare the syntax. 3. Phoenix elixir, I do maintain it. (in fact I'm more of a backend programmer) 4. Now I work mostly with style-element (the alpha, called stylish elephant) which is the only "framework like" library I use. Otherwise I use different utility libraries for date, color manipulation (hsluv which I wrote the elm implementation), data structure manipulation (many in elm-community, like list.extra)... I use way less libraries that I would with JS, and that's good. 5. No.
• dustingetz 8y ago
  It's because of all the icky data-sync for the client/service round trips. An async, slow, failure-prone concern wired throughout the entire codebase. I/O hurts everyone in subtly different ways and it's hard to solve so you see a lot of churn. service/database has this problem too (the ORM flamewars of the 00s) but to a much less degree because it is in a happier place on the latency chart: https://gist.github.com/jboner/2841832 https://gist.github.com/jboner/2841832
  • nicoburns 8y ago
    I agree with this. It also doesn't help that frontend code usually has to run on several versions of at 3 different runtimes. With backend code you can freely either stick with an older platform for stability, and adopt a new platform for new features. With frontend you don't have that choice in the same way.
  • dustingetz 8y ago
    Continued: Churn is further compounded by the Lisp Curse; an individual hacker can scratch his itch in Javascript all by himself and then stick it on github, the other three 1995 langs (Java/Ruby/Python) never quite reached this level of empowerment of individuals. That's great but also means an explosion of activity from smart inexperienced hackers who don't quite have a full understanding of the problem they are trying to solve because they are just one person. And when the problem is I/O that's a recipe for going in circles. http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html
  • rubber_duck 8y ago
    Not really - those things exist in native frontend as well but it's more stable than js. Writing GUI is not trivial, people take stuff like data binding/templates/MVC etc. for granted nowadays, go check out early desktop UI libraries like say win32/MFC/winforms/gtk+. Took a long time to get to stuff like WPF, Qt quick, etc. With browser there were several constraints : ES5 is extremely error prone and scales very poorly to larger codebases slow JS VMs missingt for sane layout like flexbox 1. Got better with npm, we pack, es6 transpilers, typescript/flow and tooling built along the way 2./3. Got solved by finally depricating everything < IE9 (IE in general if you're lucky) and tooling I'd say angular is relatively stable now and decently productive once you get a hang of their patterns, I've been using it for different frontend projects since early betas, written ionic apps for mobile with it - have very few complaints about the framework, some of the stuff didn't always work along the way (like ahead of time compilation, i18n) but recently (5+) I've had 0 issues with the framework and I'm quite productive with it. I think the alternatives will mature as well and things will settle.
• perlgeek 8y ago
  > 2.5 years for the youngest isn’t that old in the scheme of things - it’s less than half the support lifespan of your typical desktop OS, for example - but it’s still a ways off our caricature. Let's compare it with some server-side technologies: Python/Django: 2005 Python/Flask: 2010 Nginx: 2004 Perl/Catalyst: 2006 Maybe I'm biased towards older software, but the difference to the popular frontend stuff is striking. The only thing in the frontend with a comparable history (that I can think of) is jQuery -- and I still use it today, but it seems many developers frown upon it these days. And it's a library, not a framework.
  • outsidetheparty 8y ago
    Node probably belongs on this list (2009, it's older than I thought).
    • tracker1 8y ago
      I used it before then, but could see why a lot wouldn't touch it until well after 2013-2015 or so. Despite following and using pretty early on... it wasn't until 0.8 that a lot of the core issues were really resolved and it stabilized a lot at that point. The ensuing iojs split, joyent handoff, and node org was a lot of turmoil. Add to that, the fact that NPM is its' own company, and not part of the Node Foundation could be mildly concerning. Don't get me wrong, I love node/npm but it wasn't really a catalyst until a little later than 2009.
  • zitterbewegung 8y ago
    I think more developers should use jquery to prototype an app and move torward a framework when it is needed. The same should be said when adopting redux when using react . Also webpack for building and moving beyond SQLite for data .
    • aaron-lebo 8y ago
      They really shouldn't. Modern browsers have lots of the selector magic built-in, and frameworks that are very, very small can handle the rest without the spaghetti.
• freedomben 8y ago
  This is a really well-written and well-thought out piece. The author touches on a number of points but never gets polemical. This piece resonated with me particularly well: > Be wary of self-promotion > Over the last few years I’ve seen much more aggressive self-marketing in the JavaScript world, possibly due to the rise of paid online training materials and the employment/consulting advantage of being a Github ‘celebrity’. I’ve no problem with people being incentivised for good content, but increasingly I feel I see dishonest tactics: self-citation; invented, proprietary terminology (so searching takes you back to the author’s materials), and name-squatting (e.g. ‘Standard.js’) This is becoming a big problem in JS world, particularly over the last 3 to 4 years. Like the author, I have no problem with people taking credit and being respected, but we as a community are becoming much too centered around people/personality than technology. I've been guilty of this in the past too (love you Pete Hunt ;-) but it's not healthy IMHO.
  • deleted 8y ago
    [deleted]
  • Karrot_Kream 8y ago
    I'm finding the growing celebrity culture of programming to be troubling. I find that programming is becoming less and less about code or architecture and more about evangelism and marketing, but I'm not sure what changed in the incentive structure for this to happen, and I would like to find out. Aside: This has made me reconsider being a career programmer.
    • mseebach 8y ago
      It's an extremely large and diverse field. There are plenty of us who aren't celebrities and don't care about celebrities (except to the extent that it is caused by deep expertise). Just like you ignore reality TV celebrities, ignore these guys. It's just noise. Turn off Twitter and read "Growing Object-Oriented Software, Guided by Tests" instead.
      • davidjnelson 8y ago
• patorjk 8y ago
  > What is to be done? ... Consider non-microlib architectures What about what happened with Angular (1), the 3rd library on your list? That whole framework was deprecated in favor of Angular (2). Additionally, the list of front-end libraries given doesn't really reflect the landscape front-end devs have traversed. Years ago, I remember working on an app that heavily relied on YUI around the time that library was shutdown. I also heard stories about how ExtJS 4 wasn't backwards compatible. I'm not sure I buy into the author's thesis about the reason for front-end fatigue.
  • reitanqild 8y ago
    There's a clear upgrade path (with tooling) between Angular.js and Angular 2, 4, 5, 6. There's now also https://update.angular.io/ https://update.angular.io/ to help.
    • patorjk 8y ago
      Angular 1.x is not listed in https://update.angular.io/ https://update.angular.io/. Additionally, there was no initial update path between Angular 1 and Angular 2 until the community cried foul. It's been a while, but after they finally released an Angular 1 to Angular 2 bridge, I read several tutorials and books that discussed the upgrade path but said to absolutely not use it in production. It would kill the performance of your app. That sort of made the value of an Angular 1 to Angular 2 bridge pretty weak. If one were to migrate to Angular 2, it would seem more time efficient to just to start fresh rather than spend time on a wonky bridge between the two frameworks.
      • reitanqild 8y ago
        At AngularConnect last year I now migration of large applications was a topic and if you are interested I think it should be available online. Also: angular.js isn't dead, it is just stabilized. Yes, no more features (from Google) but it should be safe to use and also I think they signalled quite clearly that they would be happy to let the community pick it up.
  • emodendroket 8y ago
• mseebach 8y ago
  > Put yourself in the shoes of a junior-to-mid-level JavaScript developer, writing a new application for the first time. > But how could you do better, Junior Developer? Who was there to guide you? The Senior Developers, too, are learning as they go. We’re caught in this avalanche too, just trying to keep up to date and remain employable. No, this is exactly the problem: junior developers making major architecture decisions unassisted. The "senior" developer who is "caught in the avalanche" isn't senior by any reasonable definition of the word. Development in general, and, it seems, front end web development in particular, is both easy and hard. Somewhere between batteries-included frameworks, blogs, YouTube channels and MOOCs, it's very easy to get from zero to something good looking and more or less functional pretty quickly. But this can easily hide the complexity that pretty quickly creeps in, and reasoning about complexity is one of the crucial things that a senior developer brings to the table.
  • kotrunga 8y ago
    > But this can easily hide the complexity that pretty quickly creeps in, and reasoning about complexity is one of the crucial things that a senior developer brings to the table. Yes- so true. Taking a web app / whatever from the beginning stages to handle proper complexity, anything from scaling to ... the business wanting cough forcing cough a "quick fix".
  • michaelbuckbee 8y ago
    We're missing the context here. For many (most?) web apps I feel like things have kind of gone wrong if the front end requires "major architectural decisions". That's not a knock against the greatness of React, etc. so much as it's my observation that most web apps are small and from a technical standpoint quite boring, a smattering of static pages, a couple web forms, etc.
  • jillav 8y ago
    Yes exactly. Building something fast without understanding the complexity behind can be both a blessing and a curse. It's a blessing for the one who needs to deliver. It's a curse for the one who needs to learn. To be efficient in the long term, and not get lost among the framework wars, one must use what was learned in Engineering School, University or from seniors : write specs, set priorities, plan ahead. Use or build the tool that suits your need, do not follow trends. Think like an engineer.
• tribby 8y ago
  well, ever since the proliferation of mobile touch devices (it's been less than a decade) there's been this somewhat perverse history of "mobile-first" really meaning "native-first." tons of mobile websites are still essentially ads for their counterparts in app stores. this is for lots of reasons (mostly to do with financial incentives for both app makers and app stores), but ultimately the web still isn't as good as native. the chaos of the front-end world is a reflection of web developers trying to solve that, rather than those working on operating systems, web browsers, standards, etc. the other reason is that vue hasn't be around very long ;)
• dhruvarora013 8y ago
  I'd actually say that its less about instability and more about rapid experimentation. There's two main catalysts - the youth of single page web apps and the openness of the modern web. The complexity of your everyday website is increasing as they move from static sites to web apps. The pressure to be as responsive and fluid as a mobile app is high, and that requires solutions for data management and synchronicity. There is no standardized way to solve these yet. When you tie this increasing complexity with the free-form structure of the web (there is no recommended way to build a web app unlike mobile apps or to a lesser extent desktop apps), and then add the growth of JavaScript from a toy language to a full-blown complex ecosystem, you get even fewer established practices. This is not to say that there will never be best practices but rather that what you're seeing is a language scaling with its needs without having a central dictatorial entity at its helm. You're seeing unprecedented growth and that can easily be confused with chaos and instability.
  • vram22 8y ago
    >The pressure to be as responsive and fluid as a mobile app is high, and that requires solutions for data management and synchronicity. Can you explain what you mean by that? Is it related to mobile apps supporting notifications, as one point?
  • vram22 8y ago
    >The pressure to be as responsive and fluid as a mobile app is high, and that requires solutions for data management and synchronicity. Can you explain what you mean by that? Is it related to mobile apps supporting notifications, as one point. maybe?
• carapace 8y ago
  Programming industry is the only one more fashion-driven than the fashion industry. This is a known issue going back to the dawn time. The big secret is that for most of us this is "works as intended". We like to program. Imagine being a mountain climber who loves climbing and gets paid (well!) to climb mountains. With real mountains, eventually you get to the top and you have to stop. With programming, the act of climbing the mountain creates more mountain above you. As long as you can find people to pay for it, you can keep climbing. If you like programming please shoosh so the marks don't get wise. If you just want to get shit done use Elm-lang and get on with your life.
  • reitanqild 8y ago
    The first part of your post is brilliant and then comes this: > If you just want to get shit done use Elm-lang and get on with your life. If this was sarcasm it would make sense but there's little else in the post to suggest that. Elm is one of the hippest languages right now. It also depends on a single maintainer AFAIK, and also has a limited community. I'd also like to program Elm but suggesting to move to that from React or Angular? I'll leave that to my 10 years younger self. A better description might be: use whatever you know and try to keep code on the server side as long as possible.
    • carapace 8y ago
      I hasten to point out that that "fashion-driven" line is somebody else's. The internet says RMS or Larry Ellison. My point about Elm isn't that it's the silver bullet, rather that it's a tool that makes the meta-game easier.
  • spc476 8y ago
    Nice idea, but some hipster developer at a company we query decided it would be A Good Idea (TM) to switch from using DNS to query their data to a REST API over HTTPS that returns JSON. Normally, this would be a "whatever" type thing, but see, the code I work on is in a critical, real-time path (as a phone call is being made). We were promised that Java client code would be provided, but see, we don't use Java. Sigh.
• softwarefounder 8y ago
  It's only unstable if you drink the JavaScript cool-aid, and change frameworks frequently. I've been using Knockout 3.* for the past five years, no issue here. Edit: Looks like some Angular and React devs have started downvoting :)
  • zo1 8y ago
    Knockout is incredibly lightweight and easy to get into. However, it's not the "in" framework like Angular and kin, so it gets a lot of bad reactions. The biggest reason for this, I believe, separate to any technical benefits/advantages, is that the "big" and "in" frameworks have a gigantic knowledge-base hosted on the entire internet. Because of the sheer amount of people on that ship, they've all collectively encountered and tried/solved/figured-out a large amount of usages and combinations of the library. What that means is that mediocre and/or "shallow"-knowledged developers can easily leverage that to solve problems they might encounter by copy-pasting solutions. Rather than solving it for themselves. Now, that doesn't necessarily mean they're not capable of doing it, it simply means that they have to spend more time figuring out the problem and/or learning the framework in order to be able to do so. Most people would rather opt out to doing a quick search, copy-pasting, adapting to their specific context, and moving along to the next problem. So, when they have to deal with something like KO, they know what it's going to entail: Hours of learning, or digging into internals and figuring out the quirks of the framework.
  • k__ 8y ago
    Whining about downvotes is generally frowned upon.
• freedomben 8y ago
  I do wonder how much of the instability relates to the strong opinions that the JS community often has (I'm guilty of this too). Any broad stereotype is going to be wrong a lot, but it does feel like JS devs on average are a lot more opinionated about the way things ought to be. They are also more disgusted and unhappy working in codebases that don't conform to their standards. I truly don't mean this as a bad thing, in fact I put myself in this category. Obviously it can be a bad thing if it causes you to be unable to work with others, but it can also make for elegant, consistent, and hackable codebases that boost productivity and minimize bugs.
• kehrlann 8y ago
  I believe classifying libs/frameworks by number of stars is not enough ; "when" these frameworks got stars, or how many stars they got in the past 6 month, is probably important. Not sure jQuery or angular 1 got many stars lately...
  • Blackstone4 8y ago
    Agreed. The quality of the stars are important. What percentage of people star repo's where they've read the Readme but never used the code or used the code and decided it was bad quality and never unstarred the repo
• PaulHoule 8y ago
  Is there a difference between "Medium" and "Self Promotion"?
  • seattle_spring 8y ago
    I tried barking up that tree a year or 2 ago when Medium took over HN.
    • PaulHoule 8y ago
      I built a system for filtering my HN feed and one of the first rules I put in was "no links to sites that have pop-ins" and tedium matched that. (Not like I have an automated way to do that but it is not too hard to add sites like that to a block list.)
• pavlov 8y ago
  This part puzzles me: > "Put yourself in the shoes of a junior-to-mid-level JavaScript developer, writing a new application for the first time. > "It starts innocently enough. You have a completely clean slate and want to keep things simple. You are a devout Agilist and YAGNI is your watchword. So you begin with a ‘simple, barbones framework’. That sounds good, doesn’t it? (Even if it did not, that’s often the only choice you’ve got). > "Being barebones it does little, so the task falls on your shoulders to choose some helper libraries. If you are doing frontend work, it might be helpers for Redux for forms and API requests. If backend, it might be middlewares for Express." Why is the default answer to the problem of "it does little" to "choose some helper libraries"? Shouldn't it be: "I'll write some code to make it do more"? Why does this first-time app developer need Redux? Why would she need a helper for Redux to do API requests? These days you can just call fetch() — it really doesn't get any easier. All the APIs that one gets in the browser or in Node.js are already very high-level and easily understandable by entry-level developers. If anything, piling more leaky abstractions on top will just make things more complex. How did it happen that junior JavaScript developers feel so insecure about using the standard stuff? Maybe it's because more senior developers have spent two decades crapping on the standard stuff. Therefore, as a self-appointed spokesperson for the veterans, I hereby grant all junior JavaScript developers full permission to just go ahead and program whatever they want without having to look for a single library or creaky build tool — and they shouldn't feel bad about it in the least.
  • Omnius 8y ago
    > How did it happen that junior JavaScript developers feel so insecure about using the standard stuff? I know a lot of "developers" that are learning frameworks and not javascript. When you start in a black box then you look for other black boxes to fill in the gaps you need. I am not even opposed to that. I strongly believe in never re-inventing (unless its academic) what can be used and has been tested, but when the developers are not javascript developers but react, vue, angular developers. Then you get this gap where the inexperienced are afraid to outside of what others have built.
    • pavlov 8y ago
      One has to learn somehow, and reinventing is an important part of that. Aspiring artists will paint nude figures and flower arrangements and white cubes on draperies, even though these subjects were done to death centuries ago. Junior programmers should feel the same way about doing things that have already been done: someone probably has done it better, but I still have to do it for myself, maybe a few times over to get the hang of what's the point.
• rossdavidh 8y ago
  I give the author credit for thoughtfully trying, but not much of this seems to actually explain why it is Javascript that has this problem, more than Python or Ruby or Java or C#. The reason for Javascript's excessive churn must, I think, be related to its most typical use case as a browser client-side language, and in particular to its use in single-page apps. The rest of it are all good points, but I'm not sure they explain why Python, etc. don't have this problem (as bad, anyway).
• EvanYou 8y ago
  FWIW, the GitHub age isn't entirely accurate because both React and Vue had major rewrites and the current default branch doesn't hold the entire development history. Vue's first public release was Feb of 2014 and React is just celebrating its 5th birthday.
  • evilduck 8y ago
    Likewise, Ember holds the record on that list at 6.5 years, it was forked from SproutCore which goes back even further.
    • k__ 8y ago
      Wasn't it just renamed from SproutCore?
      • evilduck 8y ago
        My point was that Ember is older than the repo age indicates. “Forking” vs “renaming a project and creating a new repo” sounds an awful lot like the same thing to me anyways.
• underwater 8y ago
  Calling out Vue.js as a possible solution is hilarious. Selling a trending technology as a silver bullet is exactly the problem he complains about in the article. Comparing the development methodology of Facebook - the company behind React - and this mindset is illuminating. Facebook famously rewrote PHP and added extensions like XHP rather than start their codebase from scratch. React follows a similar philosphy. It can be incrementally introduced into a codebase without radical rewrites. These lessons are largely ignored in the open source community, where everyone will gladly tell you how your tech is all wrong. This is actually really easy to avoid. Just focus on solving the problems you have and only adopt technology that is relevant to you.
  • _bxg1 8y ago
    In my experience, Vue is much easier to integrate gradually than React. You can't knock it just because it's relatively "trendy". Do your research.
    • oulu2006 8y ago
      That's been our experience as well. I much prefer the more holistic approach to development that Vue.js provides over React. And we did spend a year working with React, so it's not just something we did off the cuff.
    • jrs95 8y ago
      It's also much easier to adopt if you have a lot of people who aren't familiar with React or even SPAs in general. Templates feel more familiar to them than JSX. And if you're building something complex enough to need it, Vuex is a hell of a lot simpler to learn than Redux. In general, you don't have to know anything about functional programming to use Vue and it's core libraries, and that can be pretty nice if your team isn't familiar with it.
  • k__ 8y ago
    Yes, I still don't get th Vue hype.
    • 8y ago
• piinbinary 8y ago
  This offers a good explanation for why the most popular options are generally the ones that developers choose, but not why the thing that is currently popular shifts as fast as it does. Why did React take the limelight while Angular fell out of favor? What caused that shift in what is popular?
  • kearneyandy 8y ago
    My personal experience with this was that Angular 2 was announced, which was completely non backwards compatible. So there were a bunch of people that 1) Needed to rewrite their code 2) Distrusted Angular to be stable React had a philosophy of small reusable components and incremental upgrade. This is a particularly attractive idea for people experiencing the above. I think this is probably part of the shift in popularity.
• fealios 8y ago
  React is only 3 years old?!?!
  • chrisco255 8y ago
    It's 5.
  • seattle_spring 8y ago
    No... It was release in March of 2013, making it more than 5 years old.
• rb808 8y ago
  This problem is way deeper than web front ends. There were/are dozens of frameworks for Windows and Unix front ends too, before browsers were invented. Every year or two some new tool became popular which made all the previous ones obsolete.
  • gaius 8y ago
    Not really. On Unix it was Motif vs OpenLook. On Windows it was MFC vs OWL. On Mac it was PowerPlant vs MacApp. And that was it really, and you could have stuck with one for over a decade and never been short of work.
• tzs 8y ago
  There is an interesting take on this by a Reddit user named 'jerf' over on the Reddit discussion: https://www.reddit.com/r/programming/comments/8n00k2/why_is_frontend_development_so_unstable/ https://www.reddit.com/r/programming/comments/8n00k2/why_is_... I think this is the same as the HN user 'jerf', but am not certain.
  • wvenable 8y ago
    I think I'd add to this comment that you can't solve a lot of these problems with more code because in the browser code size is a very significant factor. On the desktop, or even on mobile, code size isn't very important. So we can have big libraries that do a lot of work.
• meredydd 8y ago
  Web frameworks are churn-y because they are incredibly leaky abstractions covering really awkward impedance mismatches. This means that they are never quite satisfactory - and that just to use one, you need to be capable of building a new one yourself. Think of a typical web app. Your data exists: 1. As rows in a database, accessed via SQL 2. As model objects on the server, accessed via method calls and attributes 3. As JSON, accessed via many HTTP endpoints with a limited set of verbs (GET/PUT/POST/DELETE) 4. As Javascript objects, accessed via (a different set of) method calls and attributes 5. As HTML tags, accessed via the DOM API 6. As pixels, styled by CSS. -- Each time you translate from one layer to the next, there's a nasty impedance mismatch. This, in turn, attracts "magic": ORMs (DB<->Object); Angular Resources (REST<->JS Object); templating engines (JS Object<->DOM); etc. Each of these translation layers shares two characteristics: (A) It is "magic": It abuses the semantics of one layer (eg DB model objects) in an attempt to interface with another (eg SQL). (B) It's a terribly leaky abstraction. This means that (a) every translation layer is prone to unintuitive failures, and (b) every advanced user of it needs to know enough to build one themselves. So when the impedance mismatch bites you on the ass, some fraction of users are going to flip the table, swear they could do better, and write their own. Which, of course, can't solve the underlying mismatch, and therefore won't be satisfactory...and so the cycle continues. Of these nasty transitions, 4/5 are associated with the front end, so the front end gets the rap. (I gave a lightning talk at PyCon two weeks ago, about exactly this - stacking this up against the "Zen of Python" and talking about some of the ways we avoid this in Anvil: https://anvil.works/blog/pycon18-making-the-web-more-pythonic https://anvil.works/blog/pycon18-making-the-web-more-pythoni...)
  • chrisweekly 8y ago
    Some good points... but I think you're too pessimistic. Some tiny subset of those fraction of users you mention manage to do something different / better. React is one example. GraphQL is another.
  • bjterry 8y ago
    This is a great comment and an amazing insight. What's particularly interesting is that people have attempted to collapse (almost?) every stage of that abstraction hierarchy individually, but none of them have been so successful as to take over the world. If you were writing a desktop application, you would still have at least three of the layers (serialized data on disk, in-memory data, and the rendering of the objects), but without the dramatic impedance mismatch that the web platform introduces everywhere.
• zer00eyz 8y ago
  I think the instability is a byproduct of what it is. Today we have https://caniuse.com https://caniuse.com but this sort of tool in one form or another has existed for a long time - I think that mobile, and native mobile have only compounded the problem. Frameworks, and ecosystems (Node, and what it spawned) are practically a requirement to get things done. But abstracting issues away from front end developers, hiding them behind hacks and fixes only serves to make things worse, and harder. The foundation of the front end isn't just broken, it is a fuckstorm... and we keep piling more stuff on top of that foundation trying to make it make sense, make it rational. With each layer we add creating new sets of issues that only get worse over time. Then someone "smart" enough to build something a bit better does just that, and we get this: https://xkcd.com/927/ https://xkcd.com/927/ The reality is that the fish stinks from the head and in this case, blame google, apple, MS, and Firefox - https://medium.com/@dmitriid/ok-w3c-and-whatwg-dont-die-but-7952221fcbe4 https://medium.com/@dmitriid/ok-w3c-and-whatwg-dont-die-but-... Javascript isn't much better https://ariya.io/2014/05/the-curious-case-of-javascript-nan https://ariya.io/2014/05/the-curious-case-of-javascript-nan --- (Note the above links are just my favorite "examples" of these issues not even a good indicator of the real problems therein, everyone has their own grievances) And this IS the heart of the issue. Any one sane, any one with a high level of skill isn't going to want to work in an environment where they aren't in control where someone can yank the carpet out from under them at any given moment. No one is going to stay long when new browsers and missing packages create more work, or work that has to be re-done to deal with some edge case or issue that literally came out of nowhere. Front end people see those of us working on server side code where we have a HIGH degree of control (orders of magnitude) and realize how bad it is for themselves. Simply put any one who is good invests the time and energy to get OUT of that line of work. Tallent will quickly migrate away from the broken foundation of the front end. This only serves to exacerbate the situation, as a new "smart" person onboards thinking "I can do this better" and being right to some degree.
• chrisco255 8y ago
  I think this is a piece by someone who has not really been in front end web development as a career (or does not specialize in it) for very many years. The author's thesis is that 'poor choice architecture' is what drives churn in front end. I disagree. The churn in JS tech has reduced over the past few years. Some of the churn was in part due to limitations of the web platform. ES5 was limited in features. The web has evolved a lot, and now we don't need to depend on every framework re-inventing things like modules. React has been around for 5 years now, and it's still the dominant choice for front end architecture. This is not by accident. React solves some of the biggest challenges in front end development with a clean, minimalistic component API, a virtual DOM abstraction to minimize re-renders, JSX (still superior to underpowered template languages), and one-way data flow (which makes refactoring and state management easier). Also functional component model has implications that it can render to any target. React is not just a web development innovation, it's a UI innovation. There has never been a desktop UI framework with this much flexibility and power. You can target web, native mobile, native desktop, create custom canvas-rendering if you like, render to touch bar, VR, etc...no limits. The author sort of implies that a one-size-fits-all framework or some standard way of doing things across all projects would lead to less frustration and less churn in the JS community. We've seen many attempts at this (Ember, Angular, etc). The thing is, not all projects have the same needs. The web is a big place. There are simple web pages with mostly text content (and little need for JS) all the way to rich apps with interactive video, real time chat, dynamic graphs and complex customized data feeds for each user. There is no one-size-fits-all comprehensive framework that will ever meet those demands. For the easy projects, they're overkill and for the complex, long-lived projects, you're likely to beat your head against the limitations of the framework. The innovation that has come in state management, style management, and component-based design in the past few years is unrivaled by any other UI community. I think the article is a surface level grasp at the situation. It implies that the JS community is spinning its wheels instead of producing solid long-lasting paradigms for application development. I disagree.
  • _Tev 8y ago
    It nicely shows HN bias when comment like this is downvoted into oblivion. "JS framework churn" is a thing of the past, with only a few I-hate-JS types trying to keep it alive. and I'm not sure it even applied to people actually working with JS even in the past.
• _bxg1 8y ago
  At some point, when modules get "micro" enough, the effort of managing them and learning their usage outweighs the effort of implementing the thing yourself. Most JavaScript projects seem to walk that line quite closely. I'm a React developer at work, but I recently gave Vue a try at home. This is one of the things that most stood out to me about it. React makes a selling point out of the fact that it's "just rendering". It doesn't try to do everything for you, it tries to do one thing really well. That sounds great, but it leaves out a factor. Having your primary framework be "simple" and "lean" doesn't translate to your project being simple and lean, because your project still needs all that other stuff. You just now have to get it from somewhere else, which often adds more complexity than it's worth. When I downloaded Vue all I had to do was add a script tag to my HTML document and start writing a modern reactive UI. No other modules or frameworks. No build system. No special JS-targeted languages. Vue does everything you need, and it does it all pretty well, and sometimes that's more valuable.
  • philliphaydon 8y ago
    I learned React at home, then learned Vue. I fell in love with Vue because i clicked on the getting started, threw a bit of code in a html file, and ran it, and it worked, then I played around and changed things, the moment i ran into something like "oh how do i do this?" the documentation is second to none for client side frameworks, I found what I was looking for quickly. Then I started to find other stuff like vetur, the vue cli, and I felt like I was just building stuff, and it worked, and I wasn't pulling in other plugins just to get stuff done. The barrier to entry was much lower IMO. Just wish I could switch from Angular X to Vue at work :(
    • _bxg1 8y ago
      Vue gave me that wonderful jQuery bootstrapping experience, but with a modern data-driven DOM. It's so pleasant.
  • sayword 8y ago
    The script tag approach is nice and lowers the threshold for the curious, but looking back, I'd recommend starting with vue-cli right away, because as your app grows you'll run into limitations of that setup, esp. with more advanced babel features, runtime transforms, ... The warning about using the cli in the vue docs is imo a bit exaggerated, you get some nice prompts and an equally smooth experience :)
• throw2016 8y ago
  There are a set of converging interests causing pain in the ecosystem. First a company promoting a project, then people hoping to provide services, consulting or training, and third people hoping to get a job or padding their current resumes. None of these people have a particular interest in the technology or its merit, its anything they can make money or benefit from and then forums like HN and others are used to aggressively push out these technologies. By the time people start catching on about flaws, over-engineering or needless complexity the latter 2 groups have already moved on to something new. Rinse and repeat and HN is very much a part of this. There is very little tolerance for skepticism and proper scrutiny of anything 'new' and in the hype train. These are usually dismissed with ad hominems about 'grey beards' or people 'scared' of change. Since everything is so 'new and cutting edge' there is no respect for any authority or experience and scrutiny becomes impossible. And since self interest is involved the arguments become needlessly charged.
  • mmt 8y ago
    I assume that observation applies to more than just front-end development. At least I've personally seen the effect more generally. I think another self-interested actor is the "nobody ever got fired for buying IBM" manager, except that, today, it's not IBM. IBM has, of course, been replaced by whichever technology is currently in high repute. They need never gain technical knowledge themselves. Granted, in some cases, that's actually a case of legitimate delegation to their engineers (whose conflicting interests you've addressed), but, since they have the same access to the Internet as everyone else, that can't be assumed. > And since self interest is involved the arguments become needlessly charged. I hadn't fully considered that until now. That isn't to say that I'm not a cynic, but, rather, that, for example, the average HN commenter may not want to come to terms with having, even to a slight degree, such self interest. That can lead a form of needlessly charged argument, defensiveness, that wouldn't necessarily be obvious otherwise. In a professional setting, it can lead to seemingly-irrational decisions in the face of overwhelming evidence that the other way is better.
• nunez 8y ago
  Because web browsers are so different, there are millions of ways of getting around it and most devs would rather make their own solutions
• linhuiwu 8y ago
  because browsers changes a lot.
  • _greim_ 8y ago
    This here is the actual reason. Medium posts and micro-libs are fringe factors by comparison.
• keyle 8y ago
  It's also very unstable and young because requirements keep moving, and developers keep figuring out more 'auto-magic' and simply better ways of implementing UIs. UI used to be simple, a page, a few links, click through to other pages. Then we needed templated pages, because we had a lot of pages. Then full blown 'applications' were ported to the web, and life was a nightmare of double-headed dragons and dark holes with pikes. Jquery provided some help here but it was more in terms of nuts and bolts, than as an architecture. Then came all the MVC libs which really helped enforcing a structure for large apps. Then came Angular and all of its madness, but a positive step ahead, giving us usable SPA. React brought some sanity back and now Vue (in my opinion, don't shoot) brings the sanest/cleanest way forward. My guess is what we do on the web will change once again, in a few years, and we will throw all that out and start again with new framework. Whether it will be in AR or still on the web, there are still many problems to solve. E.g. the whole 'responsive' thing.
  • mirkules 8y ago
    To expand on your point, somewhere along the line, the web went from a content delivery mechanism to a full GUI + content delivery mehanism. The allure and advantages to developing a full GUI on the web are many, including portability and availability. But the downside is that you are suddenly developing to the lowest common denominator - the browser - which not only has to support the "old" web but complicated GUIs (something it was never designed for), which in turn means all sorts of "magic", as you put it, to make it work (i.e. crazy DOM manipulations). And because browsers were never designed for this, there is no One True Way to develop a simple user action. Search for "drag and drop in javascript" for example. So what happens is, everyone invents their own way of doing stuff, which turned into a race of who is more popular/clever, resulting in a gajillion ways to do the same thing.
    • tracker1 8y ago
      There are drag/drop APIs defined... but people make abstractions... This happens even in desktop UI development. There are LOTS of front-end libraries.. but it takes a lot of effort to make them, so there are still far fewer. The web is easily flexible, and configurable in terms of how you deliver your UX... you aren't hamstrung into creating something that looks like it was made in 1996.
• tenaciousDaniel 8y ago
  I was exhausted by front end development, so I thought I'd try something new. I ended up first looking into AI, and then into Blockchain. Long story short, I have run back to the relatively calm and serene world of the front end, with my tail between my legs. The front end may be moving quickly, but in the grand scheme of larger technological change, it's far more stable than we give it credit for.
• 0xcolton 8y ago
  Having worked as a frontend dev for a while, my observation is this - because the UI is closer to the user, and closer to the product side (for consumer-facing apps), it has faster iteration cycles, doubling or tripling the rate of technology decisions that are made. You'd never rewrite an API twice in a year, but maybe you'd rebuild your site or interface that often, if you're responding to users. With increased demand for tools comes more supply - more libraries and frameworks with more stars and follows. The reason we don't see this in the mobile world is because it's a much more closed ecosystem - there's no open spec for mobile like there is for browsers.
  • dnomad 8y ago
    Yeah, there's a perfect storm that happens on the frontend. (1) Users are more empowered and expected to continually change requirements all the time. (2) The underlying technology is broken. Specifically, there is no component model that makes it easy to compose existing components. Every frontend app reinvents not just the wheel but the tools to cut the stone. (3) There is no UI component model provided by the browser. Every webapp looks and behaves completely different from every other webapp. There are no common metaphors, common components, common fonts, common icons or even best practices. Every company writes their own UI kit and interface guidelines. (4) Thanks to the highly intelligent fuckers at Google/Facebook/Yahoo everybody has very high expectations when it comes to Web UIs. These guys are also driving rapid innovation in the space. Unlike Windows apps -- which haven't changed much in 25 years -- Webapps seem to become dramatically different every 3-5 years. The result is the wild west meets post-apocalyptic disaster where everything is constantly changing and the developers don't have the tools to actually manage or control this change.
    • josephcooney 8y ago
      I agree. Throw into the mix non functional aesthetic changes. Even if the actual requirements/functionality didn't change new design trends would mean you'd be at minimum re-skinning/themeing your site/web app every 18 months or so just so it doesn't look "dated".
    • jonnytran 8y ago
• spankalee 8y ago
  Asking this question without looking at the underlying platform is ignoring a huge source of insight into the problem and its solutions. Growing up from a document viewer to an app platform in the particular way it did left the web as the most important and ubiquitous GUI app deployment and runtime platform, but without a dev-accessible native GUI component system. No other major modern UI platform was _ever_ in this state. This left all the work of creating the most basic widget system to userland, while at the same time the platform's features available to that userland were relatively paltry to begin with. As those features of JavaScript and DOM grew, frameworks were released frequently because newer ones were designed to take advantage of newer features. This lead to a huge amount of fragmentation. Which brings us to now. Outside of threading, the runtime features are much more suitable to an app platform now, and finally the web has a native UI component system in Web Components. I think there's one or two more big shifts ahead of us toward Web Components and better utilizing Workers, and then things will settle down because we'll finally all be using the same platform features. Even if we still have opinionated and helpful layers on top, the foundation will be more stable and standardized.
  • paulddraper 8y ago
    > Growing up from a document viewer to an app platform in the particular way it did left the web as the most important and ubiquitous GUI app deployment and runtime platform, but without a dev-accessible native GUI component system. Exactly this. Web technologies cannot be understood without understanding the history of the web itself. You could just as easily imagine, say (random example), Internet + Gopher + Lisp playing the role of Internet + HTTP/HTML + JS. It was somewhat inevitable chain of events, plus "right time, right place"for particular choices of tech.
    • thisrod 8y ago
      > It was somewhat inevitable chain of events The question that intrigues me is why Tcl/Tk didn't take off around 1995. We could have had internet apps about a decade before web apps were feasible. The only answer I can think of is that no one in 1995 would have contemplated running a Tcl script that their computer had just downloaded from a random host, but Javascript boiled that frog gradually. I'd be keen to hear other ideas.
• Achshar 8y ago
  I always find it curious that almost no one is talking about not using a framework to begin with. I have been writing complex UI with vanilla js for some time now, never had any issues or took longer than I expected to get a job done.
  • burakemir 8y ago
    You have to ask yourself whether, in the process of building that complex UI, you haven't invented another framework. After the first few web apps, one necessarily sees the repetitive elements and wants to capture that in libraries and abstractions. Routing URLs? Reuse that widget? This is just coding instinct. I think it is possible to have a stream of projects where each new one gets its framework copied and pasted from the previous. That does not mean it's not a framework, just one without name and documentation. Then there are projects of a certain size that you wouldn't want to do like this. Stakes too high, more than 1-2 developers. Then you can either brush up your framework and give it a name and documentation and contribute to the 'problem' of too many frameworks. Or use something that others use and is just as suitable.
• ggregoire 8y ago
  Sorry but I find font-end development pretty stable. Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal? In my career I also had to learn Java, PHP, C#, Node.js, bash, batch, Python… Build apps with Spring, CakePHP, Symfony 1 & 2, ASP.NET MVC 3 & 4… Query database with Hibernate, Entity Framework, Linq SQL… Handle dependencies with Maven, Nugget… Store data in Postgres, MySQL, SQL Server, Mongo, Redis, Redshift… Host on OVH, Digital Ocean, Heroku, AWS… Learn REST and GraphQL, SVN and Git, Linux and Windows Server, Vagrant and Docker… And according to HN, what's really hype right now is Rust, Go, FoundationDB, Kubernetes, and so on… Any idea why back-end development is so unstable? :)
  • guessmyname 8y ago
    I think the title is referring to the ecosystem and not the technology. • How many frameworks for Java, Python, Bash, etc did you have to learn? • Did you switch from Redis to X because the former was deprecated N months later? • Are OVH, Heroku, AWS updates getting in the way of your development process? Learning a technology by itself like Node.js is not a problem, the problem is that front-end development nowadays requires so many small and fragile tools just to build a web application compared to the number of tools that you would need in another language like C# where the most recognized libraries are several times more stable and change with much less frequency. Mentioning things like database engines, cloud platforms and version control tools is out of the scope of the discussion because they are encapsulated tools, and at least the ones that you mentioned (before you updated your comment) have a very low release rate, and to my opinion are very-very stable in comparison with the JavaScript ecosystem. > Having to learn a new library every 3-4 years (usually when starting a new job) is it really a big deal? Yes, it is. > In my career I also had to learn … Not for the same project and/or development cycle, but surprise me if I that's the case. > And according to HN, what's really hype right now is Rust, Go, FoundationDB, Kubernetes, and so on People stick to them and that's it, I don't know any serious company changing their tech stack every N months just because they are trendy on HN. Several years later they may switch to a new tech stack because the project requirements have changed but not because the author of one of the thousand libraries that you are importing decided to carelessly modify a feature that another dozen libraries use, consequently breaking not just your code but also many others. Or, in another scenario, your package manager doesn't betray you by destroying all your file system during a careless upgrade [1]. > Learn REST and GraphQL, SVN and Git, Linux and Windows Server, Vagrant and Docker You are missing the point entirely… We are talking about how "unstable" front-end development is, not how many tools you have to learn. If I could learn 10-20 tools for front-end development and be certain that they will not drastically change in a year or so, or at least get deprecated, then — and only then — I would not have to worry so much about available updates via the main and (unfortunately) only package manager that the JavaScript community have. [1] https://github.com/npm/npm/issues/19883 https://github.com/npm/npm/issues/19883
• beders 8y ago
  It's because we keep trying to use something designed for displaying hypertext documents as platform for interactive applications. It's dumb and successful.
• deleted 8y ago
  [deleted]
• andrewstuart 8y ago
  It's unstable because there are millions of developers working with front end technologies and that community is rapidly finding better ways of doing things. And when better ways are found, because development is so time consuming and difficult, people move to embrace those new and better ways. I'm glad of the rapid change because there is alot more improvement needed at the front end. Consider for example the vast amount of crushingly complex configuration that is required for many front end development tasks - this is yet to be addressed, although giant leaps have been made - such as create-react-app - thank god. JavaScript has to become "zero configuration" to the greatest extent practical, and JavaScript programmer should dump configuration heavy tools as soon as they possibly can for zero configuration tools.
  • rimliu 8y ago
    s/better/different/ Compared to how much code size and complexity for the tooling increased the benefits for the end user are tiny, if there are any at all. We are just getting SPAs which do not work with JS off where a simple static page would do perfectly.
• _ZeD_ 8y ago
  for the same reason of the eternal september
• tlrobinson 8y ago
  So here’s the thing... browsers are generally excellent at maintaining backwards compatibility (see “SmooshGate” for christsake). Old frontend frameworks still work just fine, therefore when you complain about frontend development be “unstable” you’re complaining about other people creating or adopting new frameworks/tools. If these things really aren’t worth learning you are free to continue using the old ones.
  • emodendroket 8y ago
    Well, you aren't really, because you have to work with other people who want the latest and greatest.
• jonnytran 8y ago
  Yes, no one takes the time to research. Most popular does not equate to good. I took the time to do the research back in 2013 and found that Ember basically solves all the problems OP talks about. Tom Dale, one of the creators of Ember, blogged over a year ago [1] about how Ember has been around since the days of Backbone. As the years rolled on, other frameworks became obsolete, but Ember evolved (with sane upgrade paths) and is still relevant. 1: https://tomdale.net/2017/04/making-the-jump/ https://tomdale.net/2017/04/making-the-jump/
• nullundefined 8y ago
  This is pretty funny. Frontend isn't "unstable". We have made it unstable with "modern" frameworks and libraries. The web is one of the most stable things ever built. There are sites from the early 90s still chugging along. That's more than you can say for most "front ends". The better question is why did we fuck everything up so badly and call it "modern" as if the other methods of doing frontend development are prehistoric caveman shit. That's the fucking joke.
• tracker1 8y ago
  I do find a bit of the argument hyperbolic... My preference today is Koa + about 3-5 modules (including 1-2 custom) on the backend and React, Redux, Redux-thunks, redux-first-router and fetch (in most browsers) on the front end. For UI, will generally suggest bootstrap or material-ui (the library). create-react-app does take a lot of the guesswork out of the front-end. In the end, front/back-end tech grows at an incredible pace. Look at go, rust, .Net Core and a half dozen other options that sprung up in the past 6-8 years and all the frameworks around them. It isn't new. Last generation(s) it was Python, Ruby, C#, Java and on, and on... this isn't new.
• Yaggo 8y ago
  Front-end is the ultimate incarnation of Bazaar model.
• donkeyd 8y ago
  > Imagine being a junior developer The junior developer has it easy. Imagine being the tech lead for a startup that has to pick the framework that'll be used to build an application that needs to e maintained and that they'll need to hire developers for to maintain. I was this person, I made a choice and now every single person is casting doubt on it. The choice wouldn't have even mattered, It's near impossible to find experienced front-end developers of any kind right now and everybody will always ask "why not [this framework I'm familiar with]?"
• rusk 8y ago
  I think the quality standard is different. Front end has to "look good" and be "good enough to use". Little finnicky errors are often tolerated as a user can be expected to work around a certain issues. Since issues can be quickly spotted code hygiene and rigorous software quality practices aren't as important. Also, performance and resource utilisation aren't as important, to a degree anyway. Back-end, unsupervised, or high-performance code on the other hand is largely invisible to the end user. It has to run for long times without error and if something goes wrong can be tricky to get at, diagnose, and repair. These requirements demand a higher level of code-hygene. Coding standards, logging, documentation, automated testing etc. etc. which makes developing this kind of code much more expensive than you would expect for something that you ultimately "can't see" (unless something goes wrong). I've seen organisations struggle with this dichotomy where they're trying to do both without appreciating these distinctions. Product managers getting annoyed that it takes so long to get GUI changes in, while engineers getting annoyed that their (necessary) tech process overhead often gets shorted because "it doesn't add value". You can get away with taking short-cuts on the front-end, that you can't get away with elsewhere but ultimately this leads to a messy, unwieldy codebase with mountains of tech-debt and once you get to a certain point it makes sense to just throw it out and start it again. Though "starting again" is considered to be something you should never do [0] with front-end stuff it's a little easier to get away with because, like I say it's all visual, and a good bit easier to test and play with and tease out the subtleties. [0] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  • godinaa 8y ago
    I disagree. Rigorous code standards are just as necessary on front-end code as back-end. In my experience, no code review, poor design or documentation, and lax standards lead to jittery experiences. For example, people write complex blocking code that causes the page to freeze for moments while that processing is happening. People write event handlers that execute too often and slow user interaction.
    • rusk 8y ago
      My point was though, that such issues can be quickly picked up just by using the application, and you can usually elicit the causal factors by prodding at it. Often times such issues in non-UI code can go for years without it being noticed. But broadly speaking yes I agree, but one or two of my line managers in the past would not.
• elcapitan 8y ago
  The article is right about the frontend side, but I think it doesn't look to good on the backend either. The actual code side (frameworks, libraries and languages) is relatively stable, but mostly because most of the complexity nowadays goes away from monoliths and into services, of which many are off the shelf, and plagued with the same issues as all the trendy javascript frameworks. Nosql-database du jour that solves some problems allegedly very efficiently, messaging systems, thousand ways to script infrastructure and virtualization.. the hype is not in the code and libraries, it's in the infrastructure components, but that doesn't make it any better.
• zmix 8y ago
  The short answer is: Because they abandoned XML on the web.
• deleted 8y ago
  [deleted]
• augbog 8y ago
  > Before we get carried away, it’s worth validating whether the meme really has basis in reality. Do front end technologies actually change that quickly? > In the sense of major view technologies, probably not. Consider this list of the highest ‘starred’ JavaScript front-end technologies on Github: Seriously? So you're basing front end technology changes based on stars on Github? Also I think it's wrong to say that front end technologies have "changed." It's just people have discovered better or just different ways of building things and that should be okay. I agree with the portion how it can be overwhelming to a junior developer, but it is also easier in some ways. In truth, if you are a junior developer (or hell any developer really), your focus should be less on choosing the right technology and more on understanding what technologies fit what needs.
  • Cthulhu_ 8y ago
    I think the stars were mainly to get some kind of data, given how it's hard to get real live data. The article itself resonates with a non-data-powered feeling I've had for years. The front-end change meme is from a few years ago, during the highly unstable period shortly after Angular and (with it) single-page applications rose up, then suddenly Angular 2 was announced (which made everyone feel like their investment and commitment to Angular 1 was a wasted effort), React climbed up and got a few alternative implementations, React state management got a couple of alternatives (and a lot of thought went into those; I see that era as more of a philosophical era), and there was some drama on both the Angular and React side, causing people to split off and do things like create a new programming languages (Atscript), Angular the good parts (Aurelia), and (a bit late to the party), Vue.
• deleted 8y ago
  [deleted]
• api 8y ago
  Three reasons I think: (1) The closer you get to the front end (especially GUIs), the further you get from algorithms and other mathematical certainties and the closer you get to something that's more a matter of design and fashion. People get tired of GUIs looking and feeling a certain way and they change, and that often requires a code re-work because changes in GUI look and feel can break previous abstractions. (2) Form factors and display technologies change. Mobile completely annihilated 30 years of GUI work for example. To a lesser extent high-DPI screens have done a number on some older GUI systems. The stuff under the hood changes too but more slowly and in less fundamental ways e.g. an SSD is mostly a "disk" from an abstraction point of view even though the tech is wildly different. Command lines are fundamentally unchanged since the 1970s. VT emulations have become more advanced but the basic paradigm is incredibly stable. (3) GUIs look deceptively easy but in reality they're incredibly hard. A modern GUI layer is at the same level of complexity as a modern game engine like Unreal. The list of edge cases and layouts and modes and languages and interaction metaphors and input devices and so on and so on you have to support is very long. Software engineers routinely underestimate this difficulty and try to re-invent GUIs and GUI abstractions in a quest to be clean and small and simple. They're then forced to shoehorn everything a modern GUI requires into these clean and simple abstractions, breaking them and turning them into overloaded monstrosities. Simple clean systems get ugly when you try to extend them too far. A more elegant design could be achieved by starting with the premise that the problem is big and hairy and developing heavier and more flexible abstractions accordingly.
• player2121 8y ago
  To me this attributes more towards general evolution of the browsers which naturally leads to more complex requirements for the modern web-app. I remember that in 2010, when we started re-writing our desktop apps during our transition to web, the initial requirements were such that it was still possible (although very hacky) to use the latest version of ASP.NET. Then 6 months later we received a new set of requirements which rendered this _latest_ stack useless. We literally had people sleeping under the desks pulling all-nighters trying to transfer a session state between browser and server without dropping an egg. That's was around time when backbone.js came out. If we compare the things that browsers can do _now_ with what was possible 5y or 10y ago, no wonder why we have so many new frameworks. Browsers are trying to catch up with (or even replace) an OS as a main container for running an application and because it's hard to release all features _at once_ without agreeing on standards, we have a situation when people have to choose a new library each time a new major API/feature is available. And this what I see is the main reason why `front-end development is so unstable` WebAsm is coming which will again lead to yet another huge re-write.
• hajile 8y ago
  The real complaint right now should be Babel v7 -- or more specifically, the community around it. Babel v7 has been in development for quite a while. It's still changing and isn't even a RC yet. I understand the need to test new compiler builds, but production isn't the place to do that (especially not until a RC is released). A beta designation is meaningless if its used as though it were just a normal production release. Using a beta compiler in production tools, libraries, etc shows EXTREME inexperience. I have a number of dependencies that I cannot update because the new versions rely on various v7 builds (ranging from ancient alphas to bleeding edge betas). I suspect the issue is that most JS dev teams are small with projects small enough that edge cases are uncommon and easier to find and fix. Stackoverflow dev survey shows that the average US dev is 28.7 (down from 31.6 in 2015) with an average of 10 years of experience despite 58% having less than 5 years of experience. That means that on average, you have a very young team. Further, the vast majority of teams most likely do not have ANYONE with more than 5 years behind them. It's not surprising that such things aren't recognized for the disaster-in-the-making that they are. Web technologies have settled down and stabilized dramatically over the past 3 years. I suspect that as more web devs gain more experience, we'll see this continue as rashness is replaced with a more conservative approach.
• Kenji 8y ago
  The typical explanation (a la r/programming) seems to be something or other about webdevs being naturally impatient, faddish and incompetent Okay, let's look at the facts, I'm open to any explanation but this is the most convincing one. 2.5 years for the youngest isn’t that old in the scheme of things 2.5 years is NOTHING. N O T H I N G. C++98 clocks in at 20 years now and it's one of the most stable drivers of software. HTML is 25 years old and basic websites from back in the day still work. You are churning through frameworks an order of magnitude too fast! 2.5 years for the youngest isn’t that old in the scheme of things [...] but it’s still a ways off our caricature. This sentence alone is a caricature and the fact you cannot see that makes the caricature even worse. The advantage of this architecture is that you can easily adapt as new practices emerge, which makes sense at a time of rapid innovation (like the past few years). The disadvantage is that it increases your surface area for breaking changes and demands a great deal (often too much) vetting and selection of said microlibs. Completely true. Library choice is hard. That's why you make extra sure you avoid as many dependencies as possible and pick reliable and industry-proven libraries with the largest possible projected lifetime. In particular, you go look if there is still active maintenance and development. And this is the thrust of my argument: what’s wrong with JavaScript isn’t the language [1], the web, or any technology in particular, but a poor ‘choice architecture’ that makes developers slaves to fads and trends. Again, I agree here. Modern JavaScript’s greatest asset - and liability - is NPM. It provides an enormous wealth of modules, catering to just about any specific purpose one can conceive, but very difficult to filter and curate. Which ones are really being supported? Which ones are actually functionally correct? Which ones aren’t really just vectors for evil malware? The only heuristic a JavaScript developer can really use is popularity - number of downloads and Github stars - which exacerbates faddishness. Are you serious??! "The only heuristic a JavaScript developer can really use is popularity?" What happened to library evaluation? What happened to, you know, actually reading and reviewing the code you pull into your project? What happened to the actual craft of programming? What are programmers, dumb plumbers who put together a Frankenstein monster of microlibs, or innovative craftsmen who construct reliable, fast and elegant solutions with as few moving parts as possible? Is this the quality of work you are content with? Have you no pride? There are other ways to validate a library, of course: you can read through Github issues and search for StackOverflow questions. You can do some testing or even examine the sourcecode for yourself (in most cases). But this takes time, which isn’t really warranted when choosing e.g. a date parsing doodad. Oh yeah, those other ways to evaluate a library, what a waste of time. Don't bother about actually looking into it, just look how many "likes" it has. This is what's wrong with front end devs, they want to move too fast while lacking absolutely fundamental programming knowledge. I will concede that this is something of a cultural weakness of JavaScript developers. As an interviewer I often like to ask candidates how they choose technologies, and it depresses me somewhat that popularity is the almost always the only marker they know. That is sad. These people are not fit for a software development role and should not be hired. Software engineering is at least partly a research job and we need to train junior programmers research skills. But even if we did, the odds would still be stacked against them. The odds are stacked against ignorant people who don't want to put in the hours that are actually necessary to (learn to) vet libraries. Just let your senior devs choose libraries then, or at least review dependencies the juniors pull in? So you do a Google search, which reveals a Medium post that heartily recommends X.js. It later transpires the post was written by X’s author, though she never announces that particular conflict of interest (she does, however, provide a GitTip jar). Not that you could tell - all Medium articles look the same, so you can never rely on a ‘brand’ to identify reputable material. Back in the day, people used to understand what they do. Now they just google and copy-paste something. If you look at one medium article and decide to add a dependency, you cannot be helped anymore. This time you find a link on Twitter - with over a hundred hearts! I wanna puke. You see, Y.js was “object oriented”. You thought this was a good thing, vaguely recalling something from first year ComSci about Smalltalk and message passing. But apparently it is Very Bad. A programmer who does not know what object oriented means, and programs JavaScript, a language where you handle objects day in day out, should be fired. It gets worse. The post claims that even mentioning OOP in a JavaScript interview will render you utterly unemployable! You are seriously disoriented now. Thankfully help is at hand - in the form of his $50 dollar JavaScript webdev course. You take a note of the link, thinking how lucky you are to have found it, and give another clap in gratitude. (Nineteen thousand and one). Nineteen thousand and one ignorant morons who should not be professional programmers. But how could you do better, Junior Developer? Who was there to guide you? The Senior Developers, too, are learning as they go. Ok you have a problem there if you don't have senior developers who can provide guidance. That's the whole reason you have mentors. There's no point in paying more for a senior dev if they lack the knowledge and leadership skills. That's the whole reason why they cost more! So. You take the path of least resistance: you choose the Github project with the most votes, the most stars. And that is why JavaScript dev is driven by fads and hype. No, to conclude, people who are gullible, incompetent, ignorant and frankly, stupid are what's wrong with JavaScript dev. If you want to see hardcore devs who actually have skills, go look at operating systems programmers. All the problems you named literally just don't exist there. Front-end attracts untalented and inexperienced programmers because you immediately see colourful pictures when you preview a couple of lines of front-end code.
• chauhankiran 8y ago
  I know that the star is a de-facto way to calculate the popularity of particular repo. But, let me put aside this calculation for a moment, then I myself have stats around 250 repos and more than 40% of it, I have starred just because to refer it sometime later, not because I like it or love it, just for future ref., when I have to work on something that might need help or ref. from that particular repo. So, if there is something that have a way bookmarks the repo then chances are hight these repos have lesser stars. Also, there is popular trend nowadays I see that 100 other developers have starred one repo for some particular reason that chances are hight that other 5 developers might star it because they just follow the developer, who have starred.
• brillout 8y ago
  OP mentions using a framework. Alternatively to Next there is Reframe (https://github.com/reframejs/reframe https://github.com/reframejs/reframe) My main problems with Next is that it is - not ejectable (and locks you in), - not a universal framework (you cannot create an app that has a static `/about` page but a dynamic `/search` page. With Next your app is either all static or all dynamic.) (I'm Reframe's author.)