11 ms·

Ask HN: Is all programming constantly changing or just front-end JavaScript?

• maxxxxx 8y ago
  In a lot of areas the tools are fairly stable and progress is more linear. That’s what I liked about C/C++ development where you could go deep and really learn details. The JavaScript world feels to me a little like reinventing the wheel every few years and recreating the same thing over and over. Maybe it needs a few more years/decades to shake out issues and reach some stability. I think part of the problem is that JavaScript/HTML/CSS are so flexible that it’s really easy to create new stuff.
• brightball 8y ago
  It’s the result of a language that already had 85% of the tools needed for its domain where the changes in frameworks come down more to preference than anything else. The same thing happens in PHP world where you have all the tools needed built into the language so most of the frameworks are essentially “arranging stuff”. In other web frameworks for other languages, you tend to see them creating the actual tools you need to use that language effectively on the web so it’s easier for the community to coalesce around it than whimsically reinventing things every day.
• acangiano 8y ago
  Assuming you're using well-established technologies, your knowledge doesn't become obsolete as quickly. Not even close. I can take a Rails developer who stopped using Rails 5 years ago and get them up to speed in less than a week.
• rolleiflex 8y ago
  From what I could see, the amount of churn in the Javascript world is unsurpassed by anything in software or product, almost to an order of magnitude. I ended up being a product designer (my main, academic education), a frontend, and a backend with varying levels of expertise in my lifetime, so I have some direct experience. My current advice as of April 2019 is to keep calm, if you can stay away from JS, do it, if you can't, pick Vue, avoid Webpack, use Typescript, and forget the rest. That should go fine for the next couple years, if you can manage to remove Webpack, even longer.
  • epicureanideal 8y ago
    What do you think is problematic with Webpack? Or do you think it will simply become unnecessary at some point?
  • notduncansmith 8y ago
    I like your advice to avoid Webpack and prefer TypeScript, but I think the advice to lean away from JS in general is poorly-founded. JS is a powerful, portable language with lots of opportunities to add value. It’s a good language to have in your toolkit along with others, and you can make a good living by learning to write good JS programs.
    • rolleiflex 8y ago
      That is true. I meant it as in: ‘If you can avoid writing something in JavaScript, do so’. Obviously, there are contexts where it is the only game in town — I have big hopes for WebAssembly for that reason.
  • Jorge1o1 8y ago
    What's the matter with Webpack? It carries quite a lot of advantages, like tree-shaking, code splitting, and lazy loading. These are real, tangible performance benefits, so I'm going to need some kind of compelling evidence as to why avoid Webpack.
    • untog 8y ago
• LyndsySimon 8y ago
  My intuition is that it's a function of how many people are doing the type of work you're doing and how fast the environment within which your code runs changes. Front-end JS is where both of these factor are at their peak - it's often the first stack new developers use, and there are a lot of devs doing it. Add in the speed with which the browser landscape changes and the (relatively) recent expansion of JS onto the server ... and everywhere else ... and you kind of have a perfect storm. The other extreme is probably something like legacy systems development - like maintaining and expanding banking and financial systems - or embedded environments where the hardware has a long life expectancy and is not easily upgradable.
• RickS 8y ago
  As somebody that's in JS all day but rarely touches backend, hearing about go, rust, kubernetes, docker, etc make it feel like backend is similarly fast-changing. The difference seems to be in the narrative about the older tech. The "rails is still fine" crowd is loud, which is great. There is no equivalent for older JS tech. Though I would be willing to believe that's because things like jQuery are full of dated patterns that lead to bad times.
  • droobles 8y ago
    I think jQuery and IIFE/AMD modules are fine. Tools for the job, React might be overkill for some smaller apps, and jQuery is a hassle with larger SPA/PWAs.
    • adrianhel 8y ago
      But why bother with jQuery? Vanilla is pretty decent. Prefer React/Vue for the big stuff. But you can't beat vanilla when you need perf and control.
  • colecut 8y ago
    As a backend developer I am in the "jquery is fine" crowd =) I'm always able to accomplish what I need without a lot of headache, though I'm not making gigantic SPA frontends. There are very few people using go and rust for website backends. And kubernetes and docker are about deployment, not development. If you are a backend developer, working in Ruby/Rails, or Php/Laravel, or Python/Django, or whatever, then I think you have a more than sufficient set of tools to do what you need to do, without worrying about much outside of that. It's a much more sane and stable experience than trying to be a frontend JS dev today.
  • Myrmornis 8y ago
    > hearing about go, rust, kubernetes, docker, etc make it feel like backend is similarly fast-changing. That's just hacker-news discourse. As for go and rust, backend programming languages aren't changing very much for most people. Python and Java are the most numerically significant languages and the experience of being a backend engineer in those languages doesn't change rapidly. (Python has just spent about 10 years releasing v3 and, while it is a great thing, honestly the difference that will have the most impact on peoples' brain-time is that you can interpolate variables into a string from the local scope using an 'f' prefix, and that `print` now requires function call syntax.) Backend infrastructure is exciting and subject to radical change, however.
• carapace 8y ago
  Prolog proceeds at a stately (not to say glacial) pace.
• erichmond 8y ago
  Clojure doesn't move much at all. Python and Ruby seem to move a little, JS does seem like it moves extremely fast.
• _bxg1 8y ago
  Much of JS's turbulence in the past 5 years has centered on it coming into its own as a "real" programming language/ecosystem. Modules, a headless VM, reactive patterns for user interfaces. All of these are things that other languages started out with, whereas JavaScript started out as, well, a scripting language. It was just sprinkled atop HTML pages, not running the whole show. So my guess would be that things are going to slow down soon. Not completely; JS might remain one of the most turbulent ecosystems. But I think there will be a sharp dropoff in churn.
  • emilecantin 8y ago
    Yeah, Javascript just lived through its "adolescence", with all the changes and hormonal swings such a phase entails.
• patrickg_zill 8y ago
  Just the front end in general and JS. I have code I wrote in TCL in 2001 that still works and runs in production today.
• mike_ivanov 8y ago
  Sir, have you ever heard about Common Lisp? Here - please take home this free brochure. Edit: the "brochure" - https://lisp-lang.org/ https://lisp-lang.org/
• ummonk 8y ago
  The way of doing things in front end was rather crappy until 5 years ago. Front end development was basically in development and not ready for production yet until the creation of react. I expect it to slow down and behave more like a mature framework / language now.
• doodpants 8y ago
  No, there are plenty of areas of software development that are much more stable. Nearly 6 years ago, I took a new job to develop a Windows desktop application using C# and WinForms. It hasn't changed much since then. There have been a few updates to the C# language to add some syntactic sugar, and to better handle certain niche concerns, but nothing that's had any major impact on how we typically implement things.
• ng12 8y ago
  Honestly, I don't think it's really changed all that much. I think React/Vue/Angular/etc are confusing for people who don't write a lot of front-end applications but honestly I'm writing the same code I used to write years ago with jQuery except now it's a whole lot easier and more maintainable. I think what has changed is a lot more people are writing SPAs (sometimes for good reasons, sometimes for bad ones) and are shocked by the complexity. It's like any other type of development: pick the right tools for your job and know them well.
• ungzd 8y ago
  I have impression that other way round, changes in js are one of the slowest amongst programming languages. We have lots of js in our project, and it's mostly the same js as when I first learned it in early 2000s. No ES6, because it's completely unsupported in Android Browser and IE. Why bother with transpiling for just shorter syntax for functions? We had Sprockets and I'm not sure if there's adequate transpiling of ES6 for it. So, browsers are stuck with ES5 forever, does that mean that JS is evolving fast? And ES6 itself is ancient, it was released when iOS still had skeuomorphic UI. On the other hand, while playing with IoT project I had to use C++ recently, and it feels like entirely different language than 10 years ago. Even Ruby had syntax changes in last few years, and lots of small standard library changes. Maybe fashion and "best practices" in js world change frequently, but not the language itself. Featurewise it's still on the level of Python 2.2.
  • horsawlarway 8y ago
    I understand where you're coming from, but you're basically talking about interpreter support here - not the language. This would be like me taking the old Borland 4.0 C++ compiler and then telling you that C++ is SO slow to change. It hasn't moved since 1994! Which is wrong. The language spec has clearly updated. ECMAScript is not defined by browser support, even if you should be taking browser support into consideration before choosing tooling. Just because you're not choosing to use new language features doesn't mean they don't exist.
  • schwartzworld 8y ago
    Obviously if you are deliberately avoiding new language features, you're still going to be writing the same JS as you were in the early 2000s. I could write Python 2.7 and it would be pretty much the same thing. However, a lot of ES6+ features offer more than just syntactic sugar. For example, arrow functions remove a lot of weirdness regarding 'this'.
    • ungzd 8y ago
      There's two javascripts: one that really works in browsers, and it's still ES5. And other javascript, that works on abstract virtual machine implemented inside Babel. And only the first one is "real" javascript.
• rco8786 8y ago
  It's all changing, but it seems that front-end JS is changing the fastest. That's (IMO) due to a handful of reasons. But three standout in particular... 1) The state of Javascript's standard library is getting better but still pretty bad. So people continually reinvent new ones. 2) Every company with a frontend (see: Every Company) has to work with Javascript (esoteric compile-to-js aside) on the front-end, so the sheer number of people/companies using JS is larger than basically any other language or framework. 3) Javascript is increasingly the first (and sometimes only) language that new developers learn and tinker with. And we get the resulting ideas/platforms/frameworks/etc/etc that people invent as they're learning.
  • rhlsthrm 8y ago
    Agree with the first two points, but do you really think "new developers" are the ones who are creating the "ideas/platforms/frameworks/etc/etc"?
    • zbentley 8y ago
      I do. Maybe not the tools that become popular, but new developers often consider publishing their first side project or personal tool to be a valuable milestone. I think a lot of green developers' JS tools don't make it to the mainstream, but they certainly do make it more difficult to filter hype from substance. That's not a valid reason to discourage contributions: more people hacking on more stuff and making more discoveries, even at the cost of fragmentation, is far more valuable than putting a chilling effect on contributions (and there are other ways to mitigate fragmentation).
• foobar_ 8y ago
  Every 15-20 years everything changes, the new generation ditches the old, repeating the same mistakes nth time but making some progress.
  • dylan604 8y ago
    2 steps back, 3 steps forward. Sometimes, during spring cleaning, you have to make a bigger mess to get to a cleaner state than when you began. It's a timeless issue. Continue to patch existing codebase with known flows that are so severe that it will never allow for full completion, or scrap the whole thing and start over using $newHotness that has the potential to get you where you need to go?
    • foobar_ 8y ago
      Yup. Rewrites are tricky but doable. I think the best way to rewrite is to do it inside out, sorta like DNA replication or gradually move things into micro services of sorts. Porting however is more difficult IMO, like rewriting everything in Rust or from jQuery plugins to React.
• moron4hire 8y ago
  It's not really unique to JS. We've had framework churn for a long time in lots of language communities. Look at Java and all the different desktop UI frameworks and build frameworks it has. .NET has at least three, first-party UI frameworks that are still in active use, not to mention the dozens of 3rd party frameworks in the wild. Don't even get me started on Data Access frameworks. What is unique about the modern era is that A) there are a lot more developers than ever, and B) it's easier to get a niche of other developers into supporting your vanity framework project. So if there were always going to be X% of developers getting behind any particular project, A means that B hits a critical inflection point of N total developers that make it achieve self-sustainability. Once a project becomes self-sustainable, it looks important. But going back to point A, all these new developers don't have the experience necessary to evaluate whether or not a project is worthwhile on its own merits, beyond "well, N number of people use it". For a long time, front-end work was denigrated as "lesser" because it was typically done as an afterthought, foisted on designers, not deemed "important" or "hard" enough for "real" programmers (please note my use of weasel quotes to indicate I don't personally believe it to be so, that's just how the development community has treated it over the years). So, being treated as something of a read-headed step child, the front-end community has lacked a certain level of adult supervision that could help guide its growth in a stable, manageable way. The "blind leading the blind", so to speak, out of complete necessity. I guess it was a little easier in the late 90s and early 00s in that businesses were much more reluctant to use open source code. It was a lot harder to get buy-in on anything that "wasn't invented here". But that doesn't mean there wasn't a lot of "invention" going on. Your job as a developer growing to become a "senior" is to learn how to ignore the churn of shiny new things and do what is right by your projects. This has always been the case.
• layoutIfNeeded 8y ago
  Be grateful for JS. It keeps people occupied who would otherwise shit up other languages’ communities. It’s the Great Filter of languages.
  • deleted 8y ago
    [deleted]
  • dang 8y ago
    Could you please stop posting unsubstantive comments to Hacker News so we don't have to ban you again? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
• mises 8y ago
  * Yes, JS is changing stupidly quickly. * C++ has changed a lot starting with C++11, and is still changing quickly. However, not nearly as quickly as JS. * C is still stuck in the age of the dinosaurs. The tooling has gotten a little better with clang, cmake, etc. (though these are as much a result of its close relationship with C++ as anything). * Assembly is not moving, mostly because it's dying. There's one notable exception: ARM. * PHP is changing much faster than it has for a long time. * I learned rails about 4-5 years ago and haven't done much with it since, but it doesn't seem very different (though this could be wrong). * Rust, go, zig, and other new languages are all vying to replace legacy languages such as C/C++, even for high-performance, low-level applications. This may be part of the reason some things that didn't change previously are now changing: competition. Ditto with PHP and node. * One other item of note I haven't really explored: functional programming seems to be the new hipster technology, and as a consequence is rapidly evolving. It's kind of crazy in many places, which, to your earlier point, does indeed hinder productivity. For many people, more time is spent learning new frameworks, programming paradigms, etc. than actually doing work. Oh, and I'm only commenting on the parts I have at least some experience with. I'm not sure for other areas. I've also heard a lot about swift on ios, along with cocoa. Even windows has uwp and has really been pushing its modernized c#/xaml ecosystem.
  • toast0 8y ago
    > * Assembly is not moving, mostly because it's dying. There's one notable exception: ARM. What? Assembly is not moving, because it's complete. You can pick Intel or ATT syntax, and then you just need to handle new mnemonics when your processor or choice ads new opcodes. Certainly, assembly has a smaller market share than in the past, but there's nothing to replace it for critical sections, so I don't see how it's dying, since it won't ever be dead.
    • mises 8y ago
      > it's complete That might be a better way to phrase it, you're right. I've got nothing at all against it, and appreciate using it for certain applications. I meant less dying in the sense that it will go away entirely and more that it is slowly becoming relegated to critical applications (i.e. very few applications are written in it).
• gcbw2 8y ago
  Every programming language consistency is inversely proportional to the scale of adoption. And by adoption i mean how popular it is with actual companies using it and pushing delivery over code-quality, with an ever growing pool of junior devs. Adoption as hobby languages or slim startups full of very experienced devs doesn't count. > PHP PHP is in usage decline (by the demographic outlined above). So it is getting more consistent (take a look at it during the 3->4->5 timeframe, you will think JS is moving slow) > [ruby on] Rails This is even on a steeper incline than PHP today. So expect more consistency i guess. > everywhere or Java is always popular (it's the bread and butter of the demography defined above!), and people make money selling IDE plugins (something hard to grasp out of the java world) which accelerates the inconsistency. So it is always a crap shot. A pile of incompatible concepts every time a new senior dev passes trhu the project. Not to mention in the last years every project moved full steam to scala and then back. So every 4yr you can see the same project and not have any idea what is going on because they moved from ant to maven or gradle, or rewrote half (only half) the project in another jvm language, or now every method and class is full of never seen before toolkit annotations, etc. GoLang started as a nice perl/bash script replacement and is becoming the new web application server as it gains adoption. Which was first bringing consistency and parallelization to what used to be done with perl or bash, is now full of weird ways to manage packages, which are mostly implementation of web authentication and what not. erlang is in sweet spot. Some bigCo uses it as hiring bait, and there is lot's of smaller companies using it. There still isn't a mass of jr devs pumping out features on erlang projects, so consistency is at an all time high. With frameworks that actually add to the ecosystem instead of flipping everything on its head for silly syntax sugar. Cpp had a bump in adoption recently because of CND related projects and more focus on ssl and things like that. So the new standard bodies are busy at work churning in new things nobody asked for, but that so far everyone is loving.
• Scarblac 8y ago
  JS is unique in that it started out as really quite a bad language, but due to external circumstances (the success of WWW browsers) it became the most-used one. So lots of people work on dealing with its warts.
• ufmace 8y ago
  I'm doing Rails now, and I'd say no, it's just JS. Since Rails 4 was released particularly, most things upgrade between versions with only minor hiccups. The changes are mostly adding new modules to have a standard way to do various common things, but the old ways generally don't stop working. You can upgrade to the latest Rails and switch over to the new module, or not, at your leisure. New Ruby versions come out pretty regularly too, and the changes are mostly improvements on speed and memory usage, and addition of new syntax types. I don't think there have been any breaking changes since Ruby 2.0 was released. I've worked in a few other languages, and I don't think anything else has the vibe of rewriting your whole system around a whole new popular framework every few years.
• halfnibble 8y ago
  The biggest change I can think of in my Python/Django development over the past few years is: print "" >>> print("")
  • LyndsySimon 8y ago
    I don't necessarily agree with that, but it might be a matter of when I started. My first Django projects were done with 0.96 if I recall properly. Environment management has changed a ton - first with pip replacing easy_install and directly using setup.py, then with a bevy of tools for managing development and deployed environments (Vagrant, Docker, Spinnaker, K8s, etc.), and nowadays with more advanced packaging tools like pipenv or poetry. Along the way we've seen the maturation of CI and all of those supporting tools - linting, style enforcement, and coverage all growing rapidly.
  • jjgreen 8y ago
    True that, I had a load of code in 2.7 which I was dreading migrating to 3, but pretty much that change sorted it.
• jppope 8y ago
  I would argue that the frontend js changes are mainly to do with user expectations for what constitutes a well designed user interface. People expect more, and we have to give it to them to survive. Addressing your specific question => have the backend languages/ frameworks changed? meh. sorta. They've made incremental changes, but the meat and potatoes look the same from 4-7 years ago for the opinionated frameworks. However, the massive backend change that is probably more relevant to your questions is the shift in how we do infrastructure. Cloud based Version control, Microservices, Containers, Kubernetes, Docker, IaaS, Serverless, CICD systems... all of these things are transformational changes to backend ecosystems- both in scale and in the way that we interact. It has also made it so we write less code which is actually an increase in velocity for what we can produce. thats my $0.02 anyway
  • alexpetralia 8y ago
    Nice comment. I agree - I think innovation in backend development has really been subsumed by DevOps and data pipeline architectures, which have both really changed quite a bit.
    • eitland 8y ago
      Java and .Net is steadily improving. But unlike the JS world things are mostly backwards compatible and there exists stable (some have argued too stable) dependable frameworks. We are starting to see this in the frontend world as well with Angular. After throwing everything away between 1 and 2 it is now mostly smooth (until Google decides to ditch it for something else).
      • hutzlibu 8y ago
        JS is not backwards compatible? Where?
        • eitland 8y ago
          JS the language probably is AFAIK. I and many others in this thread are talking about the JS ecosystem.
• armadsen 8y ago
  No, it’s not, or at least not as fast as the current churn in frontend JS dev. I started doing Cocoa dev on the Mac in 2005. There have been changes to be sure, the biggest being the introduction of Swift I’m 2014. But I’m still using AppKit. I can (and do) still use Objective-C alongside Swift. And I have a pretty big codebase dating back to 2006 that still compiles and runs fine even with the latest version of Xcode. (I realize this isn’t backend dev, but there are other kinds of programming besides web development :-))
  • ummonk 8y ago
    >And I have a pretty big codebase dating back to 2006 that still compiles and runs fine even with the latest version of Xcode. I mean, the same is true for any webpage written using JS + html + css in 2006.
• tobinfricke 8y ago
  I program in C, C++, and Python at my day job, and those languages are pleasantly stable.
  • rabidrat 8y ago
    That's good to hear. I was worried that C++17 was a major revision to the language. At least Python hasn't had a major release since 2010 (Python 2, anyway).
    • antoineMoPa 8y ago
      Most places seem to use very old C++ versions.
      • 0xffff2 8y ago
        I managed to get approval to bump my group up to C++11 a couple years ago thanks to some significant new features in the STL like usable smart pointers. So far none of the successive standards have offered anything sufficiently worthwhile to move us off C++11. It's possible that a new standard will introduce a killer features, but I wouldn't be too surprised if we simply stayed on C++11 forever.
      • aardvark291 8y ago
        The trick towards succcessful C++ development is to be very judicious in picking the features that you use. So not jumping to immediately using all the new features is a good sign.
    • airstrike 8y ago
      > At least Python hasn't had a major release since 2010 (Python 2, anyway). I'd argue PEP 484 is possibly more transformative than the change from print 'foo' to print('foo') https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/
      • mrguyorama 8y ago
• chrisco255 8y ago
  While I think things have changed a lot since 2012 (when I started) I don't think they've changed that much since 2015. The language and ecosystem went through a lot of churn as single page apps and front-end complexity exploded. In 2012, there were something like 10 different popular JS frameworks to pick from and most of them have been all but replaced by the top 3, which seem to have stabilized: React, Angular 2+, and Vue. ES2015 brought a lot of changes to the language itself. But recent years have been less dramatic minor syntactic improvements. Front-end web has unique challenges and constraints that other front ends don't have to worry about as much. A web app has to download the full payload of the app code and execute in one sitting. Yes, there's a myriad of ways to optimize this (such as caching, server-rendering, etc), but having to understand that just adds to the complexity of web development (and places evolutionary pressure on JS frameworks). A web app has to look and run well in a huge range of screen sizes and devices and browsers. Android and iOS apps can target minimum versions of an OS or can usually ignore devices older than a few years. Browsers can't break backwards compatibility. There is no common, prescribed tooling for the web like Android, iOS, and Windows enjoy, for example. This is a trade-off. I think the web sees more innovation and creativity as a result. But there's something to be able to spin up Visual Studio or xCode without having to worry about researching the trade-offs between 5 different approaches to tackle UI development. Ultimately, I think JavaScript gets a bad rap, but the churn is intimately bound to its role as the universal programming language of the web. The web is no walled garden and it has evolved dramatically over the past decade. We should celebrate that JS has been flexible enough to grow with it.
• francisofascii 8y ago
  I had primary been a C# dev, then switched to JavaScript/TypeScript for a few years. Lots of change in those years: JQuery, Angular 1, Angular 2, TypeScript, etc. Then I recently switched worked on a C# project. Other than a few Dot Net Core changes, it was basically the same, and easy to switch back to C# land. Not I am back in JS land. This time using Angular elements. When I left, I was getting used to declaring local variable with let instead of var. Now local variables are not let, they are mostly declared with const, which reinforces the notion that nothing is ever really "constant" in JavaScript world :)
  • munk-a 8y ago
    Aha! And Angular is already one of those tech pieces that's "on the way out". I've had similar experiences working primarily on the backend where paradigms may slowly shift but the tools for their declarations are _thankfully_ pretty stable.
    • mattlondon 8y ago
      I don't think angular is in the way out - there is still a lot of active development on it with a lot of users. React and Vue have more mindshare sure, but angular2+ is still heavily used as I understand it.
    • stringyham 8y ago
      Angular is not on the way out, at all
• munk-a 8y ago
  I think a big contribution to the rate of change of JS is that there is not yet a division between frameworks that do display stuff and frameworks that do utility/heavy lifting - this is partially due to the fact (IMO) that a lot of systems isolate heavy/complicated logic (especially business specific stuff) to a backend which JS queries to source data to operate over. All of the current frameworks are intimately tied into display logic and that display logic is constantly in flux with shifting trends, device/accessibility support and shifting coupled technologies (css-flex, css-grid...). This lack of an isolation is causing people to jump frameworks to capture support for newer design trends and the like but... I think it's getting better. I'm not a front-end dev but react is the first offering I've seen that seems to really strongly reinforce a decoupling point between display and logic. Really though, look at the realm of application development, in that realm users are accepting of crazy out-of-date UIs so the sterotypical "Oh this was definitely built with Java" (with substitutions for MFC and Qt) is sort of accepted. So, I may be off base. All I know for certain is that there was a period in the 00s when I was really hopeful that all website design would be handled seamlessly by my designer coming in and throwing some style-sheets on everything and no changes to markup would be required - that time has passed and the responsive web is baking in a really strong assumption of native-application-like functionality, this isn't bad or good - it just is. So, in summary, I'm still hoping that the majority of front-end work can shove a crowbar between the declaration of logic and the rendering, but I feel like the rate of UI change and shifting display thingies will forever outpace attempts to provide a unified toolset that actually captures the majority of intended uses.
• nopacience 8y ago
  Yes, frontend is changing very fast. I feel like people love to follow the most absurd ideas in front end. So what happens is, someone gives the absurd idea and others immediatly follow. And now thats what front end is like
• rajangdavis 8y ago
  I think javascript is changing more rapidly because: 1. It's on the back-end and front-end. 2. Lots of corporate sponsorship of Node. 3. Adoption of other languages' functionalities (namely async/await from C#, sets from Python, symbols from Ruby (could be wrong here), hash rocket from Ruby/Scala). 4. Teams building their JS libraries to serve the unique needs of the team (Uber's fusion.js, React and Redux for Facebook, Google's AngularJs/Angular/Material Design). 5. Browsers converging on JS spec which allows for arguably more cross platform development. 6. Node is a "good enough" solution for managing IO when it was introduced (hesitating to say perfect because Ryan Dahl has mentioned that he would have done a lot of things differently and has introduced deno as means to correct what he thought were the warts of Node).
• ixtli 8y ago
  It's an illusion. I think this is just one of the rare examples where people can't arbitrarily roll their own new language because they're unhappy with bits and pieces of C++ or Python. Consider that in the same span of time we have kotlin, groovy, scala, elixir, erlang, r, go, rust, swift, etc., as well as many yearly flavors of C++. Its just that every time someone makes one of these it fractures the total attention paid to the the langauge/framework so they tend to become niche and peter out. Javascript, on the other hand, is 1) profitable and 2) chosen because no matter what you really cant† choose a different language to do this work in the browser. This has the effect of concentrating all work in a very specific place. Image if instead of some people writing ruby, go, java, etc. you combined all of their equivalents of npm into one giant thing that everyone worked on all the time. I think it would look very similar to npm. Oh and don't forget that framework development is not only driven by new engineering practices and concepts, but by new features that get added by Mozilla and Google like async/await and OffscreenCanvas. There's just much, much more to whole ecosystem when you're dealing with modern javascript than really any other language. Also, Javascript is just LISP in C-style clothing so you also end up drastically different programming styles (take, for example d3's style versus jquery versus react versus three.js: all valid, all quite different and with different requirements like webpack.) This maps rather directly to when people made scala and groovy, imo. They're just like JSX/ES6+ but we consider them all different languages as opposed to "lots of javascript." † even here there are some attempts to do this with typescript and rust that compile to restricted javascripts.
• abuchanan 8y ago
  Been meaning to write a blog post about this, but my 2 cents is this: The degree of change in a programming language ecosystem is inversely proportional to the expected lifespan of the systems being built using that language. One caveat for the pedantic - yes, as the expected lifespan becomes zero, so does the rate of change. (i.e. you have a dead language) The lifespan of a system gets longer the closer you move from the UI through the business logic and finally to the underlying data. It isn't uncommon for a business to rebuild its frontend website every 1.5 years or so, whereas their systems-of-record might be expected to last a decade or more. Since JavaScript is used most frequently on the frontend (for obvious reasons), and new frontend projects kick off more frequently, there is less need for backwards compatibility, fewer risks to trying the new and shiny framework, etc. I'll probably get internet slapped for saying this, but I would predict that JavaScript never does become the preferred language for the system-of-record type backends no matter how quickly it evolves. In fact, precisely BECAUSE it evolves so quickly. What makes it a great fit in the one niche, makes it a poor fit in the other. Lest this be taken as JavaScript bashing, note that the same thing happened to Java in reverse. It was evolving too slowly for the frontend niches it tried to move into years ago.
• mattlondon 8y ago
  Backend has changed hugely with the advent of docker, kubernetes, cloud in general. Languages as well are changing a lot: golang, rust, hell even Java started a new release cadence with new stuff (lambdas, streams) You don't have to move to the latest way if doing things all the time in either front or backend. You do not have to follow the latest fashions. There are loads of backend frameworks that no one remembers because Django/ruby/spring became "good enough" and won, but back in the day there were many competitor frameworks for what was then frontend development. But we've largely forgotten about them all, as we will largely forget about the current gaggle of js frameworks once something "wins" with a good enough solution. Tl;Dr - The way we develop frontend has changed from largely server side to now being SPAs. Things will calm down in the coming years as one framework becomes "good enough" and ends up becoming the de jour standard. The knowledge and concepts never change though. What we're doing today in Vue and RxJs etc is as old as the hills as far as computer science is concerned.
• prewett 8y ago
  I think much of JS's churn has been the problem that the UI primitives (HTML) are unsuitable to what people want to do. When you can't even vertically center something without reading a bunch of web pages that tell you something like six different techniques, you can imagine that people are going to make a library to do make it easy to do. But since the foundation is crap, and good API design is actually hard, the result is not very good. So someone tries to fix it later, and runs into the same fundamental problems. I think JS the language is in better shape, but even then it is hampered by poor decisions early on. (Integer arithmetic done with double-precision floating point underneath the hood? And it supports bit twiddling, but only if it is really an integer and not a floating point number? And implicit conversions? What could go wrong...) But it is also hampered by other problems. I used WebWorkers recently to compute normals to large amounts of triangles on think, rather than transferring them over the network. In any normal language, I'd add a mutex around the data and spin up some worker threads. But in JS I can either copy the data, or give it away and that thread can't access it again. Since I need the triangle data and don't want the hassle of giving it away and then having the WebWorker give it back again (along with the normals), and then having to manage putting it in the right spot, as well as what happens if I need to access triangle data that's currently being processed, this is a major pain. I understand that the WebWorker design makes it impossible for the browser tab to hang on a deadlock or have all the fun threading errors, but as a programmer, JS is the one language that forces poor performance on me. So you can imagine someone like me, but with more influence, saying, "hey, we need a redesign to fix this." But since the previous designers presumably knew how all other languages work and rejected that approach, the redesign probably won't really fix the problem, for similar reasons why we didn't get WebPThreads the first time around.
  • zackmorris 8y ago
    I agree with pretty much all of what you said. One thing I might change though, is that I'd prefer a copy-on-write (COW) metaphor for WebWorker and SharedArrayBuffer, similar to how Clojure state works. So you'd pass an array by value, but there would be no performance penalty unless values are mutated. I'd also like to eliminate shared state between threads and switch to channels like how Go or Erlang work. These should also be COW. I feel that HTML/CSS is an evolutionary dead end. People think in terms of tables when they do desktop publishing. So forcing them to translate to CSS and back is a task for compilers, not humans. Most people working in web development today are too young to remember that this was all a solved problem in the 80s with WYSIWYG. We let the asynchronous nature of the internet determine the architecture of our markup, which was a mistake in hindsight. I'd vote to rearchitect the web to be synchronous and run under a single-threaded runtime that makes no distinction between front and back end. Then let the runtime handle representational state transfer, a bit like Rsync but for the DOM. This would work like virtual memory (so the developer wouldn't have to worry as much about where state resides) and executation would block until a remote procedure call (RPC) is lazily evaluated deterministically without timeout or having to remain always connected. Then with that prerequisite implemented, we could revisit fluid layout in a formal way, derived from first principles. This might mean transpiling things like SCSS variables to non-turing complete grammars (context-free grammars) like CSS. I'm a little foggy on the terminology for this so someone please correct me if I have it wrong. In other words, we should be able to derive the position of our elements from other positions. So we should have a markup language like: elementX.center.x = body.center.x elementX.width = body.width/2 myX = elementX.right elementY.left = myX + 1 But this would only be processed in one-shot mode. I think a markup like this could be created on top of HTML/CSS but it could be difficult due to quirks. Without basic metaphors like these, web development can never move from being a craft to a field. It will forever be reduced to hand waving and having to drink the kool-aid. Which is fine for now, but will add increasingly more friction as the web development market gets more saturated.
• ggregoire 8y ago
  I've been doing frontend dev for 10 years and had to change my stack & way of working only 3 times: - HTML templates (served by Symfony/ASP.NET/Rails/Django) + jQuery + dependencies manually downloaded/updated/deleted/added to the index.html - ~2014: Angular SPA + Grunt + dependencies managed with Bower and added manually in the index.html - ~2017: React SPA + Webpack/Babel + dependencies managed with NPM and added automatically in the index.html with Webpack. The last one is by far the stack with which I'm the most productive and I encounter the less bugs. I feel like frontend dev is finally mature and enjoyable. But anyway, jumping from one stack to another one was quite easy. A few days of learning. - I've been doing backend dev for 10 years too and had to change my stack & way of working as often, if not more. Jumping from one (or several) languages/frameworks/databases/ORMs/web servers/containers/package managers/testing tools/and so on, usually take several weeks of learning. Imo, the "frontend world is crazy/changes too fast" is way over exaggerated.
  • s_y_n_t_a_x 8y ago
    This has been about my experience too. Down to the exact technologies and years.
    • shaunpersad 8y ago
      Same here! Though I never truly felt comfortable in Angular. React was a game-changer for me though.
  • TheAceOfHearts 8y ago
    This is similar to my own experiences. During the past decade the JavaScript ecosystem had to evolve and adapt to handle increasingly more advanced requirements. Multiple tools and libraries rose up to meet the challenge, and the best ones have slowly floated to the top. It's not like the winning tools are even that recent: I think Webpack was already around before 2012, TypeScript was released in 2012, and, if I remember correctly, React was released around 2013. Fun fact: babel was called 6to5 when it was initially released. Webpack can sometimes be difficult to configure because the problems which it sets out to solve are also complicated. To be fair, their old docs were quite lackluster, and the creator's coding style was uncommon, which made reading through the source a bit challenging. I know a lot of people are critical of Webpack, but I was overjoyed when I first discovered it, as it enabled me to correctly solve a huge number of issues. Once adopted, it let me drastically simplify our build pipeline, as well as our development and testing environments. I can sympathize with non-frontend developers because I also feel overwhelmed sometimes when I look at all the tooling related to backend / devops / infrastructure stuff. But I understand people build and use these tools because they're usually solving fairly complex real-world problems. I suspect that many people that complain about JavaScript don't care much about the frontend and they just want to get it out of the way as quickly as possible. They want to pick up whatever standard tools the community has centered around and hammer together something without having to dive in too deep. If the developer looks down on frontend development and they encounter a difficult problem which they're unable to solve, then they must deal with the cognitive dissonance. To give a concrete example of something I've struggle with: I can barely make sense of the containers ecosystem. Using docker-compose during development to bring up an application's external dependencies is amazing. However, I generally haven't had much success configuring and using docker to run an app locally. There's always performance issues, or I can't get something to work correctly, or I can't figure out how to get a good workflow going. Since we're on the topic: if anyone knows a practical example of a regular web app (e.g. rails or node, but I'm not picky) which has a few workers and which depends on a few services (e.g. Postgres, RabbitMQ, Redis, MinIO), I'd love to check it out. Oh, and I haven't even mentioned deployments and Kubernetes, which seems like a whole nother dragon. If you're not a fan of frontend development I'd suggest using server-side rendering with occasional scripts dropped in for extra functionality. Think carefully about your application and its requirements; not everything needs to be a Single Page App. Depending on the kind of application you're building, you might want to evaluate next.js [0] and create-react-app [1]. [0] https://nextjs.org/ https://nextjs.org/ [1] https://github.com/facebook/create-react-app https://github.com/facebook/create-react-app
• antoniuschan99 8y ago
  My professor in school (2008) said if you want a chill job in Technology you should be a DBA because that changes the least compared to the other stacks.
• werber 8y ago
  I've been in Java shops and .net shops and PHP shops and the only constant is js. I think ubiquity comes with turbulence
• dec0dedab0de 8y ago
  Ive been using Django for almost 10 years, and it is still basically the same. There have been some breaking changes betweem versions but they have all been very easy to pick up. Even the python 2-3 nonsense has been relatively painless.
  • astrofinch 8y ago
    Django has a strong focus on backwards compatibility and has seen steady popularity for a long time.
• tarabanga 8y ago
  > a ton of change to the very basics of how we work I do data work on Python (20%) and R (80%). Of these, - Both base Python itself (2 -> 3 -> 3.6) as well as the major data libraries (e.g. pandas) changed a lot. - Not base R but the major libraries (e.g. dplyr, ggplot2, knitr) changed significantly. So, for me, yes, a ton of change to the very basics of how I work happened when using Python and when using R's newer libraries.
• gfs78 8y ago
  Things are not changing that much faster. What changed was the business model of software companies. In a distant world the tools took years of closed work to get to version 1 and version 2/3/4 each took a couple of years too. And in most cases what you got was the whole package (Visual C++ with the C++ compiler, the IDE and MFC for example). Nowadays is all in the open in github or similar. Feedback and updates are faster, community involvement is higher but things are less stable because all the polishing (architecture, interfaces, etc.) is done, from the perspective of the framework writer, "in production". Basically is the agile business model of release early and often applied to software tools.
• vbezhenar 8y ago
  I'm Java developer for the last 10 years. I learned Java 1.5 back in the day. This knowledge is useful. I added some syntax sugar over the years and Java 8 was huge release with lambdas and significant standard library improvements, but old knowledge is relevant. I learned a lot of J2EE libraries. Enterprise beans, Portlets. Most of this knowledge is obsolete. But servlets and web services are still relevant. I learned Spring and Hibernate back in the day. Well, Spring evolved a lot, but basics stayed the same, so that knowledge is revelant. Same about Hibernate. All my JVM internals knowledge is relevant. I learned Maven back in the day. Recently I switched to Gradle because it seems to be better system, but Maven is not obsolete and I could continue to use it. Though those systems are extremely easy and it's not a huge investment to learn them anyway. Recently I added Kotlin to my tool set. But this language is heavily based on Java, so all knowledge about Java, JVM and standard libraries is relevant. So yeah, Java is pretty stable platform and very few things were obsolete. Most of my knowledge is stayed relevant. JavaScript is crazy world. I have to dive into it once every few years. Everything changing. My old projects don't have a chance to work with new libraries (especially fun with dynamic typing). JavaScript really needs One Big Architect With Beard who will make everything right for everyone to accept.
• geodel 8y ago
  Using the terminology of Hardware, firmware, software where changes are slowest in hardware and fastest in software. I suspect JS introducing something which is even faster than software. May be called Slipperyware. By the time one grasp it slips out and take form of yet another framework.
• jaequery 8y ago
  it seems to me that the devs who been at it for a while, sees the frontend landscape as huge chaos. but the newcomers coming into the scene, seem to either love or embrace the fast pace changes. i'm not really sure what to think of this situation.
• souprock 8y ago
  It's just with JS/frontend. In 20 years, the change I've seen is very little. Pointers became 64-bit. C99 brought nicer initialization and the ability to declare variables after statements. Optimizers got cruel, particularly with aliasing. Vectorization and SMP can be put to use.
• guiomie 8y ago
  I used to work in .net, and found that it moved really fast also few years ago. But I think the js world is indeed the craziest. I've went from jquery, to angularjs, to angular2, to polymer and now for my latest project I'm going no-frameworks JS. I've had enough. Using Custom Elements (HTMLElements) is good enought for me, the latest ECMA makes it easy to do string formatting in the render function. It's not perfect, but I dont have to deal with all the pains of npm or webpack or any other distraction.
• citrusx 8y ago
  You know, if you look at the current timeline, you'll see that much of the "JS churn" has basically stopped. I mean, yeah - people are trying new things, and products are being maintained. But, the landscape today is really very similar to what it was a year ago. Yeah, there was a sort of "golden age" of innovation where we went from jQuery -> Angular 1 -> React, with Elm, Ember, and Angular 2+ as sidecars. And, the common libraries and tools have also slowed down in the same way. We've finally solved a lot of the big problems, I think. Advancement will never end, but I think we'll be able to keep up with it from here on out.
• Tiktaalik 8y ago
  I'm 10+ years as a game developer working largely in UI and I'm just learning JS now to make use of a new framework built by Coherent Labs. Previously the main tool set was Scaleform, which makes use of Flash scripting. I don't feel game dev has changed that much. Only very, very recently has it started to change at all. In game dev land it's just C++ or C# if you're a unity shop, and things haven't changed too much. For a long, long time things weren't different at all, but with the new C++11, and C++14 things are getting a bit different. Right now I'm working in a fairly modern codebase, and it's been a learning experience for many of my coworkers to get up to speed on some of the new features introduced with C++14. Probably the biggest change is occurring with the way that games are developed, with Object Oriented development practices kinda going away and games being developed in a more Data Oriented way using Entity Component Systems (ECS). Unity for example currently has an ECS system in preview release. It's been pretty interesting to start learning more of the JS ecosystem. Even though I've only been working at it for a few months I've already had the tea table upended on me by our partners deciding to redo some stuff in typescript, so there's another new thing for me to learn.
• catpolice 8y ago
  I think the churn rate is higher with front-end stuff, but I don't think it's really due to any special property of the technology. Honestly, I suspect that the rate of change in a given ecosystem is roughly correlated with the number of programmers actively working in it. The number of front end web developers has been skyrocketing since the late 90s - a lot of people who've been in the industry for a while don't realize how many more of them there are compared to 5, 10 or 15 years ago. There's been growth elsewhere too, but just in the past few years the number of new bootcamp front-end developers I've seen seems to sort of swamp most other sectors. I suspect that since much of the innovation in that space has been driven by open source efforts, the amount of change is in part driven by the number of eyes on problems and the number of people interested in trying new things. There are a jillion new JS projects on github every month, and some of them catch on, so there are always new options.
• davimack 8y ago
  Basically nothing down in database-land has changed, from what I can tell. Added features, but everything in those languages is designed to be backwards compatible (unless you're talking PL-sql, which has had some major shifts, to bring it in line with the rest of the world). And that's having done database stuff since Paradox for DOS and Access 2.0 (I think - might have been 3, but ... ancient days, anyway). For the rest of my stack, it's mostly Visual Studio, and it's shifted a bunch over those 25 years: VB5 -> VB6 -> VB.NET until .NET 2.0 -> C# Whatever changes there have been in HTML & JS, I've gone through, plus some of the DHTML weirdnesses that came along the way. I'm going to say that, other than databases, there's about the same amount of needed change. And even with databases, those do change, in that you might want to get a bit more of a life and use something other than MSSQL for a change, which amounts to such a shift as the others have been.
• deleted 8y ago
  [deleted]
• nostrademons 8y ago
  All programming is constantly changing, but web front-end is probably among the subfields changing fastest. It seems to have slowed down significantly since about 2014 or so. I've been programming professionally since 2000, and I'll say the biggest change is actually that the market structure has changed. Back then, programming specialties were primarily divided by platform: you were a "mainframe programmer" (probably working with COBOL, RPG, DB2, etc.), a "UNIX programmer" (C, C++, awk, sed, perl, shell), a "Windows programmer" (Win32, MFC, later .NET), a "Java programmer", a "Mac programmer" (Pascal, C, later Objective-C, with the Mac Toolbox and later Carbon/Cocoa frameworks), an "avionics programmer" (Ada, C, with a good knowledge of physics), a "scientific programmer" (Fortran, Matlab, later Python/NumPy/SciPy), etc. The idea of a "web programmer" was just getting started, and the technologies (Coldfusion, ASP, JSP, PHP, Flash) were very immature, and largely outgrowths of the platform you used to run the webserver on. Sometime around 2009 every software system became a distributed system, with multiple clients and a wide range of backend services running on different boxes, and so specialties bifurcated by your role within that ecosystem. So now you have web front-end engineers, mobile engineers for Android & iOS, back-end engineers, data scientists, data engineers, deep-learning experts, infrastructure engineers, SRE/DevOps, security people, scalability/performance experts, etc. You're even starting to get blockchain engineers, though they don't fit into the current distributed systems model. Some of these fields change less quickly than others; frontend (particularly web), deep-learning, and blockchain have been changing rapidly, while things like infrastructure, backend, SRE, and scalability change a little less rapidly. All of them are changing, though. It's the legacy platforms like the mainframe engineers and avionics engineers that haven't really changed much - but the flip side is that the current hypergrowth in the software industry has largely passed them by.
• singhrac 8y ago
  I'm a scientific programmer (not a ton of experience but understand history). It's changed a lot over time but it feels like nothing was much better than writing Fortran / bindings to Fortran until very recently (of course, take my recency bias into account). Yet, still, significant amount of "critical code" are written in Fortran. It's a slow-moving world in part because there is a lot of corner case complexity / significant logic. Parallelism in the form of CUDA / transparent GPU via Python is changing that a bit, but some algorithms are still not parallelizable.
• elamje 8y ago
  I'm not sure, I just want functional programming to become widely adopted <3
• peelle 8y ago
  Been doing back end for 13 years, and I try to visit a programming conference or two a year. I think on average back end churns slower. Every year I'll hit a conference, and hear about the latest and greatest, but only a fraction of that stuff sticks around, and gets integrated. I believe most company's won't swap language/framework/libraries until absolutely necessary. So the adoption of new things you might see at a company is much slower than someone who job hops every 3 years. The company I am at now, had a C++, cout << "<html>..." version of the site for 6+ years. The version that replaced that is a younger language with a MVC, but it's already been 9+ years since that was implemented, and it'll probably be a few more years until anything else supplants that. Another thing that I think affects front end is the browsers. I don't know the stats, but I believe that Chrome/FF/Edge release more features, experimental features, and bug fixes per year, than your average language, or OS. This cascade of releases in turn effect front end code, and libraries. It's a wave pool, not a ripple in the pond.
• andrea_sdl 8y ago
  Well, it's quite clear that JS is seeing a transformation at higher speeds, but a the same time I feel like the backend offerinngs are now more diverse and they do, too, evolve. Spring in java is pushing somewhat on functional programming and lambdas are now another way to work in java, which means you can achieve a some kind of real func programming. We have some beautiful newcomers like Elixir which are trying to fill a gab, so yeah: I think the JS world does seem like it's going faster (and it sure does until it reaches a "mature" state), but at the same time we have great evolutions across all the stacks. Obviously not everything changes, some things stay the same, that's because we're looking at some mature technology and not the bleeding edge, but if we look at the outliers, I think you could easily pick at least an innovator around each backend language.
• namelosw 8y ago
  Most of the languages are constantly changing but the JavaScript world is way faster than anybody else moves. Although might be over-hyped, I personally believe it's more a good thing which moves the community even the industry forward. React was kind of enlightened the functional and reactive patterns to the mainstream developer community. In contrast, most of the back-end communities still struggle with data synchronization between microservices, while all modern front-end frameworks are able to update all of the view or other read models almost magically. If anyone wants a more specific example, I think it's quite shocking to me that there are only very few back-end architectures knows clearly how to design a whole large scale architecture push WebSocket notification for a given user -- just like typical google suite stuff. WebSocket has been there for years, there are so few people know how to develop and operate a stateful service... unbelievable. I agree with that shipping business functionality is the most important value in technology. However, I feel most of the back-end communities worries about the problems they are encountering too much. And they don't really care about the art of the programming itself, yet advanced architectures indeed require language or platform level construct, for example, immutable data structures are much easier to be concurrent safe, or just the computation should be pure to be safely rescheduled on other core or machine, etc. In the front-end world, I think for example React and Mobx which I'm using are pretty much taking care of most of the accidental complexity of software development. In the back-end world, I can imagine something similar to a full-blown framework like Rails but built on top of something like Orleans or Lasplang would help us get rid of all the accidental complexity, and just expressing the domain itself instead. We're still too far from there. A quote from SICP lecture: https://youtu.be/2Op3QLzMgSY?list=PLE18841CABEA24090&t=81 https://youtu.be/2Op3QLzMgSY?list=PLE18841CABEA24090&t=81 "And the Egyptian who did that, geometry really was the use of surveying instruments. Now the reason that we think about computer science is about computers is pretty much the same reason that Egyptian thought geometry was about surveying instruments."
• dangerface 8y ago
  Front end javascript really hasn't changed. The newer native stuff is great but you cant really use it without dropping support for anything Microsoft, or writing a bunch of shims not good. SPA is an anti-pattern, don't buy into the whole craze to learn hottest new SPA framework which fixes all the problems with the last framework. They are all trying to make an anti-pattern work, it wont and no gimmick will fix that. Stop learning gimmicky front end frameworks and start learning front end design patterns.