12 ms·

JavaScript development is not fun for me anymore

106 points by jspekken 9y ago

rhapsodic 9y ago
>Plus, now I have to learn what Redux is, and how Vue is the next best thing that happened since Angular 2.0. How to use styled-components to make JavaScript in React do what CSS can do on it’s own. I'm glad I get to call the shots where I work, and I've steered my team clear of all of this stuff. If you have a deep knowledge of the core technologies -- HTML, JS, and CSS -- you can build a great front end with a reasonable amount of time and effort. If something breaks, it's likely going to be our own code, and much easier to diagnose and fix.
- deleted 9y ago
  [deleted]
- mfoy_ 9y ago
  Framework churn sucks. It's a shame you're being down-voted, I can totally understand where you're coming from.
  - topbanana 9y ago
    It does, but that doesn't mean you can't choose a decent stack and stick with it
    - deleted 9y ago
      [deleted]
    - scaryclam 9y ago
      Shouldn't we be looking at the task at hand and picking the best tool for the job though? Using a framework because it happened to work last time isn't a good criteria for selection. More and more I'm seeing over-engineered projects that took longer to build than they needed to and are currently harder to support than necessary, all because someone wanted to use their favorite tool.
- pavel_lishin 9y ago
  > If something breaks, it's likely going to be our own code, and much easier to diagnose and fix. But conversely, common problems and issues with frameworks are easy to find via Google and StackOverflow.
  - joshribakoff 9y ago
    Plus more people are familiar with a popular open source framework than OPs. There's 100s of thousands of react devs. But only OP knows OPs framework. Most people need to use an existing framework before they try to write their own, because a lot of people try to write frameworks not knowing what frameworks actually do or what is involved.
    - pavel_lishin 9y ago
      I wonder if OP doesn't have a framework at all.
      - joshribakoff 9y ago
        Either way, the code must follow some sort of conventions or use patterns -- and if you invent your own conventions other people are less likely to understand them. Although if no one ever invented their own conventions we'd never innovate. I just think people should at least try out a bunch of frameworks before deciding they want to make one.
- Klathmon 9y ago
  To me this kind of thinking sounds so strange. A framework is (like it's namesake) a frame that you can build around, it's a tool that enforces restrictions on you by design. Obviously there is some overhead to learning that framework, but the idea is that the framework is built by someone who spends their day-job building the framework. They are going to do a better job of designing a framework than you will in most cases. Yes, you can build something great without them, but for any moderately sized project, you will end up re-inventing a set of rules and restrictions to apply to your own internal code. You will in-essence create your own framework. And that's fine, I'm almost positive that your "framework" will do some things very well, probably better than most of the competition, but you need to ask yourself what your main goal is. Are you setting out to build a framework? And/Or are you trying to build a product? If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one. Doubly so if that framework isn't designed to be reusable at least in your organization. Not to mention the overhead of having all new devs have to learn it anyway. However if the answer is that you are setting out to build your own framework (because the current ones have a limitation that you can't deal with, or some problem that you need to solve yourself), then by all means go for it! But that can't be given as "general advice" as for many people (I'd guess most people), as they don't have those same goals as you do. Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases. (but not all cases!)
  - OtterCoder 9y ago
    Yes, frameworks are tools, but they're typically overspecialized and poorly designed. If vanilla JS is a cnc machine, Angular is an injection mold for a toy truck. If you're building a toy truck, that's awesome. If you're building anything else, say, a hand mixer, you're going to spend just as much time on the cnc machine trying to design toy truck whisk attachments as you would have spent just building a new mold with the incredibly powerful cnc you already have.
    - cormacrelf 9y ago
gtsteve 9y ago
I don't think there's that big a problem with how many front-end frameworks there are, and the pace of development. I think the problem is people who feel they have to use the latest and greatest feature and they have to know all the frameworks. At my company we picked a stack and stuck with it. That happened to be React and Redux. I hear Angular 2 and Vue are really great frameworks but I feel under no pressure to really investigate them because we're doing fine as it is. Two years later and we've barely changed aside from some package versions. We've got a very stable front-end with high code quality and component reuse. You don't have to listen to the hive-mind. Frameworks don't rust.
- ythn 9y ago
  > Frameworks don't rust Unless the framework is iron [1], of course [1] https://github.com/iron/iron https://github.com/iron/iron
- shados 9y ago
  Agreed. Honestly at this point I'll take boring. I'd welcome boring. People really need to stop upgrading 0.1 second after something comes out. Take the Java world. You can have a lot of criticism for the language or the platform, but the reality is people get shit done without upgrading right away. It's not even part of the culture. This allows people to master the platform and tools. In the JS world, there's no mastery. People just keep jumping to newest versions and spend all of their time fighting the new problems. Just. Stop. The company I work for almost standardized on react/redux. We're not done getting rid of our old stack that people are already looking at Relay Modern, Apollo, MobX, etc. If it wasn't for our investment in a massive home grown React component library, there would probably be VueJS all over the place. So we lose the ability to help each other. Every team is different, dealing with different problems. We can't build libraries since we don't have a platform to target. That to me makes us much weaker. So I welcome boring. I welcome the day when people are no longer interested in it so they stop spamming npm to check if a new version of their favorite library is out to upgrade to it when the existing one is working fine.
  - Prefinem 9y ago
everdev 9y ago
Breaking News: JavaScript sucks
tabeth 9y ago
Just pick one and stick with it. There's some serious FOMO going on in the JavaScript community. When you read articles talking about all the great benefits they see from switching frameworks, what you don't see are the gains they'd have if they just rewrote everything in the same language/framework, taking advantage of the increased experience since the original write.
sametmax 9y ago
But JS dev has never been fun. Web dev is fun because the browser is a freaking awesome plateform. However, it is _despite_ of JS. There's not a single characteristic of this language that makes it better than any other mainstream high level language out there. We use it because we have no reasonable alternative on the browser. It has always been a pain to use, requiring: - avoiding part of the language that is badly designed to escape traps. - recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc. - fight with the various implementations to find some code that will work for most of your customers. - use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS. The fact that the community is now shooting itself in the foot by providing so many incompatible, badly documented and breaking-compat-all-the-time tools is just icing on the rotten cake. P.S: since this comment is getting upvotes, I will say that having used in prod vanilla, jquery, react, angular and Vue, I will stick with Vue for the next years. I'm done. My quest is over. It takes 3 hours of reading to be productive with it. It requires no tooling and yet can be used with existing tooling. It's fast. It's well documented. I can now focus on writing software again.
- ballenf 9y ago
  > - avoiding part of the language that is badly designed to escape traps. This is universally true for any mainstream language where age > 10 years. > - fight with the various implementations to find some code that will work for most of your customers. That's an understandable tradeoff from the ability to write code that can run on thousands of different devices. It's very much preferable than writing native code for each platform and all the various implementations that would require. Basically agree with your other points.
- amiraliakbari 9y ago
  JS, and the web platform in general, is solving problems that are hard in nature. Considering the constraints imposed by these problems, quite a few features of JS are superior to many other languages. Consider the wide range of devices that a JS code must support. There is some pain in supporting all of them, but compared with Android development, the transpilers and shims available in JS seems like magic. Cross platform programming is hard, and JS seems wierd because any JS code must consider it, while many C programmers never need to think about it. Taking cross-platform into account, I prefer copying some shims from MDN to using IFDEF WIN32's. Or consider GUI development. The nice API for working with DOM, lots of available UI components, and specially the asynchronous programming model made possible by Promises is really nice by GUI-programming standards. Also the good parts/bad parts mindset belongs to the past. I can't remember the last time I even thought of using == vs ===, prototype hacks or similar "bad" parts. The usual post about strange behavior of ">=null" on HN is just amuzing, not problematic for my JS coding experience. As said in other comments, maybe everybody should just stick to using their prefered JS framework and master it.
robodale 9y ago
14 year .NET veteran here. For me Javascript (actually Typescript) using Vue as the front-end reinvigorated my joy of creating web applications again.
- sametmax 9y ago
  Vue is the only glimmer of hope a JS project gave me for the last 5 years. I actually sent a donation the very first afternoon I started to read their doc, because I decided that even if I would not end up using it, I wanted the author to be supported for just existing in the universe. Of course I ended up using it anyway.
  - ng12 9y ago
    Out of curiosity, what did Vue do for you that React didn't? I've been writing React for three years now and I can't find a compelling reason to even try Vue out.
    - sametmax 9y ago
      Nothing. For me the selling points of Vue are: - You don't need tooling to use it. You can use tooling, but you don't need any. It makes it freaking easy and fast to start a small project with Vue and increment on that. Webpack can wait. - Vue doesn't force components on you. Since most of my "widgets" are not reusable anyway, I really loves this. I write components only when I need to, usually a dozen per projects. - You don't have to pass state around using callbacks and props to make it works without a store. State is just an easy mutation away. I'm not facebook, most of my projects don't need a flux pattern, and having Russian dolls data passing shenanigans just so I can update my UI is a pain. - Vue documentation is stellar. It's wonderful. Like a walk in the parc with a friend. - Vue is so easy to start with. React took me a while to click. Vue took me 20 minutes. It's incredibly easy to train new people coming to your project. And as a professional trainer, the difference with students is just night and day. - Vue is very, very efficient. The lib is so small. But yet it's faster than react. - Vue has a lot of helpers that you can tell have been made by a pragmatic author. onclic.prevent and v-on:customevents are poetry to me. - After after hours and hours of react, I still have to look at the docs. I still have surprises. With Vue, the surprises stopped after day 3. - I hate JSX. Matter of taste of course. I like the Vue template language, but Vue can optionally use JSX if you prefer it. - Some very vocal people in the React community are dishonest. They will tell you you can use react without tooling or JSX because technically you could. But technically is not pragmatically. Nobody would. And you are on your own if you try. I hate fan boyism. Compare to Vue: the author even has a comparative page of most frameworks with Vue. He co-wrote the react part with react authors to get it fair. That, I like.
cc81 9y ago
React + (early flux and later mobx) made web development fun again for me. I was burned out at the end of the jquery era with all the different homemade structures and the limitations of browsers. Then I came back to React and babel/gulp (later webpack). Suddently there was structure in the front end that was easy to get into a project and contribute. Building components just felt right. Also js was almost a modern language now and I could use it even if the browsers did not actually support it yet.
- alexfl 9y ago
  I feel the same way... web development was hard, until I've learned about es6/babel, webpack, redux and react (I'm using morphdom as react replacement, but idea is the same). Now web dev is easy and fun. I have state, components, events and routes. That's it. Update the state and stay calm. The idea to concisely manage the state together with dom diffing, are my personal favorite game changers.
  - mring33621 9y ago
    Can you provide some guidance/links to a backend Java developer who wants to learn & use a quality long-term, front-end tech stack? Is there a kickstart example project for your preferred stack? Note that I prefer to avoid nodeJS for any back-end production use but am ok with it as part of the dev toolchain, if required. Thank you.
    - cnp 9y ago
      Stick to https://github.com/facebookincubator/create-react-app/ https://github.com/facebookincubator/create-react-app/ and you'll be golden. If you need more config later, you can "eject", but this is a one-command-and-go kind of thing that is well maintained and works great.
    - cc81 9y ago
      I would say just start with the React tutorial and use the react-create-app (uses webpack etc in the background and is a npm package) that they use in it. Then after the tutorial I would go into the docs and read through them and maybe test some. After that I would pick the state management tool I want. Either Redux or Mobx as both are popular and have their advantages and disadvantages. I think it is worth going through both their official tutorials as they are pretty good. https://facebook.github.io/react/tutorial/tutorial.html https://facebook.github.io/react/tutorial/tutorial.html http://redux.js.org http://redux.js.org https://mobx.js.org https://mobx.js.org There are of course tons of videos but I think the official tutorials are a great start and using react-create-app instead of trying to dig into webpack and all that is really good at the beginning.
abhisuri97 9y ago
I teach a course at upenn on intro to javascript. Perhaps the most useful advice I give to my students is that often the simplest tools will get the job done i.e. you don't need React, Redux frontend stack because for most cases jquery will get the job done much quicker. Only worry about the frontend libraries when you feel it's getting out of hand, otherwise, the simple, straightforward tools will suffice.
- rawrmaan 9y ago
  I guess it depends on how you define simple. To me, React is far simpler than jQuery because of its declarative nature. It’s simple to reason about and easy to maintain and change. I would say it’s a much more straightforward tool than jQuery. However, advising them to delay state management (Redux, MobX) until needed is definitely a good idea. (Also, hey neighbor—I live right off campus)
- amorphid 9y ago
  I haven't coded much JS since ES5. With the improvements to vanilla JS, are there still a lot of things that jQuery provides that vanilla JS does not?
  - abhisuri97 9y ago
    Yeah vanilla js still is a pain to access the Dom with.
gorpomon 9y ago
The desire to constantly switch JS frameworks is really confusing. I find each one different, exciting in their own way and fun to learn. However, and this is a big however, none of them radically change the work you'll create, so I'm happy with React, and not interested in learning just to learn. Maybe in a year or two, I'll try Vue, it won't be too hard to pick up. If you're at BigCo making internal apps, each one is basically dressing on a way to make various interactive UI states. How you get there is no big deal. How the data flows is no big deal. What test runner you use is no big deal. As a JS dev, my passion is to learn completely non-JS related things. Cryptography, Blockchain, CS Fundamentals I missed. These are much more interesting than the churn.
- deleted 9y ago
  [deleted]
Kiro 9y ago
> How to use styled-components to make JavaScript in React do what CSS can do on it’s own. Stopped reading right there. CSS-in-JS is one of the main reasons I'm even using React to begin with.
jroseattle 9y ago
Speaking as someone who has seen the ebb and flow of frameworks galore on the front-end and back-end, I've found many devs swing back and forth between love and loathing. It's just a natural evolution of how we use tools, and quite often the over/under application of those for the problems we're trying to solve with them. We've never had more options available to all of us to build complex systems, applications and services using highly-targeted tools. The new-framework-a-day pace at which these become available to us is fine, but honestly doesn't move the needle for most of us. A former leader of mine once said: you build things with tools, not popularity contests. I've found keeping such a perspective makes my stress level manageable.
pier25 9y ago
Well, that's what happens when you move the problems from the server to the browser (routing, dynamic data, auth, etc). instead of focusing only on UI you are working on a complete application. I like making SPAs, but there is really no need to do that. In many cases making an SPA is not even desirable.
adamc 9y ago
I think this is a good description of how front-end development has become a "tool zoo", where new versions of libraries and frameworks are often radically different, and new libraries/frameworks keep popping up. I compare this to Python, where most of the time learning a new library will keep paying off for years and years. It makes front-end development an expensive (educationally) place to work, and the maintenance costs of the code are substantial.
arstin 9y ago
I must admit having a hard time relating to all the complaints over js churn and the new world of...compiling code. I hated website dev in the past, hated using jQuery, hated being driven insane by the css cascade, hated wasting all my time on arbitrary and stupid browser incompatibility bugs with magic arcane solutions. I develop apps---not traditional websites---so I know this colors my experience. But every single tech change that I've made the past 4 years has been motivated by a real need. (Of course this assumes I have control over the tech: I'm grateful that I've only been forced to work on one Angular project for work!) I started using React in December 2013 after a shootout of the competing view libraries at the time because I didn't like having to be Sherlock Holmes to figure out how to change someone else's (or my own!) wild jQuery code, and I always inarticulately felt like I was fighting against a natural flow when using the old MVC frameworks. I now haven't churned my basic framework for almost 4 years. And don't expect to for many more! (I know that to an extent I got lucky: it's easy to forget now how much shit I got at the time for using dumb React lol compared to Angular). Ember is fascinating, I'm glad Preact, etc is around as a backup...but churning would solve no problem for me, and most jobs I'd get (for years now) require React, so why worry about changing? I've been a redux user for over 2 years now. I eagerly switched over the codebase I was working on because it solved a need I had: getting rid of a bug-prone, undocumented state solution of my own design which everyone else had to figure out for themselves. I expect I will switch out redux one of these years. But haven't seen anything to motivate it yet. Mobx-state-tree is very interesting, but until I see the benefits are worth the switch, why churn? I did really hate having to worry about babel, webpack, etc since it distracted from writing actual product code, though ES6 was just so obviously better than old JS that it was worth it. But now create-react-app and its siblings make the dev environment a matter of typing a single command. Contrary to this article, it points out errors that could easily have gone undetected in the the old world of wild web dev. No churn here. CRA all the way. Until I run into a need for something new. Styling solutions are something I have actually churned. But because I knew I wasn't committing, all css-in-js library code I write is in two or three "ui library" files. The app code itself only uses a jsx prop interface. So swapping these libraries on a mature app takes an afternoon at best. Though for the first time I now expect that I'll stick with Glamorous. I expect I'm going to stop churning here because I'm aware of no problem I personally have that Glamorous does not solve, unlike previous css-in-js libraries. I don't know, this guy's rant just put me in the mood for ranting lol. Anyway, I'm glad this guy found his real interest now might be as an animator and UX designer and I wish him the best! Those are important contributions too, possibly more important.
tjpnz 9y ago
Despite its flaws I tend to stick with Backbone whenever I need to do anything sufficiently complex on the frontend, and jQuery if it's any simpler. When writing software for money I've always found it pays to take a conservative approach.
- nrhk 9y ago
  I wouldn't jump too far ahead when writing software for money, it's always better to use something you know will work and have enough familiarity with to adjust around its deficiencies. But I think Angular 2, React and Vue are all getting to that point if not there already.
einrealist 9y ago
I totally agree with the sentiment. While others tend to use SPAs with their complex build system and lifecycle for everything, I follow principles of ROCA [1]. I don't understand why people think it is better and faster to make complex clients that include logic, that has to be verified on the server anyway. Everything I saw / see in the enterprise world is reinvented for client-side development again. [1] http://roca-style.org/ http://roca-style.org/
floor__ 9y ago
Honestly I love the Javascript Eco system. I love change and js is only getting better and better. Learning a new framework is fun. On top of that it keeps js development marketable. The wages for front end development have sky rocketed which imo is amazing.
madamelic 9y ago
It sounds like he doesn't dislike JS, he dislikes what web development has become. I dislike build tools and all the little doo-dads that we have to have now. Like, sometimes I just want to write some CSS and launch it with `npm start`
- buchanaf 9y ago
  Well create an index.html, inline a style tag in said file, write some CSS, npm init, npm install http-server -g, update package.json to with this script "start": "http-server", and profit. Fear not, we have the technology.
randallsquared 9y ago
> [Front-end is] looking more and more like the back-end This rings true to me. It's also partially why I don't really mind front-end development like I used to.
mattacular 9y ago
It's been fun again since I stopped worrying about keeping up with framework churn and all the tooling. I still feel bad when people ask what framework we use and I can rattle off a list of trendy new stuff but I quickly remind myself how asinine that is and go back to making perfectly fine, successful-in-production JS apps with stable boring things like ES5 and Backbone.
acty1 9y ago
Using Typescript with Angular2 + RXJS is like my second wind and a breathe of fresh air. It's like web development is "real" software development now.
moron4hire 9y ago
I think Framework-itis is a result of front-end developers—who are often junior developers who may not even have CS degrees—inculcating the false message that they are not "real" developers. As an industry, we have treated front-end development work as entry-level, occasionally even frivolous work, as it grew organically out of the left-over work that systems developers gave to the designers. Developing a framework doesn't look very much like doing front-end work; frameworks are generic, planned, and built from scratch, whereas the typical front-end developer is used to making highly-specific, ad-hoc changes to existing code (either because they've come in on a project started as a proof-of-concept by more senior developers, or they've used a boilerplate generating tool). Being more like so-called "real" software development, only "real" developers should be allowed to work on something ostensibly so important and complex as a "framework". The front-end developer has been indoctrinated into believing she (and it's very often a she, 'cuz design work is women's work, amiright?) has no business writing code, and that the code she does write is woefully "WRONG, WRONG, you're doing it wrong! What are you even trying to do?" by the karma-craving, bottom-feeders of StackOverflow. To avoid further public shaming—lest there be some hidden defects their inexperienced eyes cannot detect, no matter how trivial the bit of code may be—they avoid the actual act of writing code as much as possible and spend an inordinate amount of time searching for packages that may be imported from the gods. Thus left-pad, and the ensuing post-hoc rationalization in that debacle's aftermath that such trivial micro-packages are somehow a good development practice. I don't think there are a uniquely numerous quantity of framework projects in front-end land. Systems developers make custom tools all the time. But systems developers don't have a general fear, uncertainty, and doubt about their own work sewn into them, so it's more common for systems developers to jump into writing their own code than looking for pre-existing tools in whatever they might deem as trivial. Instead, I think a plethora of front-end tools reach a unique tipping-point level of popularity giving the perception of many more tools total, because of a general fear of falling behind. The front-end developer sees themselves as having no business criticizing their "betters" and must therefor accept what is handed down to them without question. If the front-end developer cannot prove they are a good little worker bee by keeping pace with any and all frameworks their benevolent employer or more-senior, more-"real" coworkers may spring on them, they risk having to go back to working as a barista. Something to think about while replying to a seemingly "simple" questions.
Kaotique 9y ago
$ ls node_modules | wc -l => 872 * Starts crying
moron4hire 9y ago
> After I was done with the front-end of a project, I hated that I had to do the back-end. I also was not good at it. After many, many years of tutoring students in a variety of subjects, there is definitely a connection between the last sentence and the first. People who work hard to get good at a particular subject often find themselves enjoying it a lot more. But humans don't care much for delayed gratification. If we have work that we could be doing that we enjoy more than some other work, than the hated work gets put off. Often indefinitely, as no skill in it ever gets developed, the more it is put off.
arrmn 9y ago
The last time I've really touched JavaScript is about a year ago, I'm just working with Python these days. Thinking back, I had 2/3 newsletters about JavaScript and whenever I've read them there was a headline "why X is better than Y", "Y has no chance against Z" "Good old X is better than Z,Y". I was always feeling, that I'm missing out on something and that I needed to learn new things. Switching to python actually made writing code enjoyable again.
saosebastiao 9y ago
I hate JavaScript with a passion, but 95% of that is fixed with TypeScript. But the thing that TypeScript can't fix isn't really related to JavaScript, but rather everything around it: 1) Build systems suck. Millions of plugins and adapters, opaque json configurations, silent errors, finicky and difficult optimizers, source maps upon source maps, shims everywhere, etc. 2) Browsers have unpredictable noncompliance with standards, HTML doesn't work well for user interfaces, CSS is obtuse, etc.
jancsika 9y ago
> So that’s why I’m now learning to be a Web Animator and UX Designer. Has anyone played around with the Web Animations API? I noticed that Chromium now lets you use elem.animate to animate SVG elements-- even properties like "width" which aren't technically presentation attributes in the 1.1 spec. Anyway, it's a very handy interface and easy to play around with inside about:blank to prototype things.
douche 9y ago
Was it ever fun? I lament the death of fat-client applications developed in real programming languages. Somehow we've decided that building our livelihoods on top of a scripting language that was whipped together in a week and branded to catch the tailwinds of another product is an acceptable way to do things.
Zelphyr 9y ago
To put a finer point on his argument; I'm working on an Angular project at the moment. Every time I refresh the page I have to wait 10 seconds before I see any of my changes while Angular compiles everything. I calculated that, given the number of times I have to refresh to test my changes, all of those 10 second compilations is costing my client tens of thousands of dollars every year in wasted productivity. So I can't help but wonder how Angular and their ilk are better?
alexasmyths 9y ago
Please try TypeScript. It's the only tech I will actively promote as 'not a fad' but a very useful thing. So useful, I stopped writing JS the first day I tried TS. For anyone with a background in classical software, it makes JS 'feel more real'. I can't imagine writing more than 50 lines of JS anymore.
vosper 9y ago
My biggest complaint about Javascript development is the config... OMG the config. So many modules, so many dependencies, so many build steps, so much half-baked documentation, so much assuming that you already know X, Y, and Z.
whipoodle 9y ago
JS moving in the direction of being compiled, statically typed, and adding lots of boilerplate for various reasons. When I started writing JS, it was partially to get away from these things in the .NET world. So, to be honest I don't enjoy these changes in isolation, but I understand why they are happening. I like that we're starting to think in a more systematic way about how to organize applications, and I think that bigger codebases and teams probably benefit from using static types. But god, sometimes when you open up these codebases they sometimes hardly look like JS anymore. Not to mention the tooling and build stuff, which still have a lot of maturing to do.
iamleppert 9y ago
Spend your time learning something that isn't subject to fads. In five or ten years, React will be a distant memory. Just like all the PHP frameworks are now. Focus on getting good at the web platform standards. I personally jump at any opportunity to learn new web platform APIs, graphics techniques, design patterns, data structures, and different business domains, and stay away from technologies that are fad-driven. Get good at a few basic tools and focus on application development. It's not about the code its what we make with the code.
bob1029 9y ago
I started to feel the same way as the author when 2016 rolled around. I found myself getting caught up in the paranoia of using the latest, greatest, most popular (i.e. supported) framework. Teammates would come to me with a bunch of proposals about how to use X over Y. We questioned continued use of Angular 1.x and had similar negative experiences with the build processes around the latest javascript frameworks. It really had gotten a bit out of hand considering our scope. I found the light at the end of the tunnel with Riotjs. It is close enough to the bare-metal JS runtime to keep you sharp in that regard, but also provides a lot of utility around building components without tying your hands in any particular way. For someone who is trying to build the best UX experience possible, I feel like riot or even vanilla JS provide a much better experience for expressing yourself. Front-end frameworks seem to me to be just a way to systemize the UX/UI problem into a thing that back-end engineers can reason with. Staring down a blank HTML/JS/CSS document without any constraints imposed on you can be a very daunting task until you truly get a feel for it. I strongly believe that one can be VERY productive on even the most complex web project without use of any frameworks, assuming they have the correct "artistic" mindset and the ability to balance that with systemizing the problem. My perspective is that the web is 3 languages (HTML/CSS/JS) and they need to be treated as equals. Any time you bring in a framework that does not consider all 3 with the same priority, I strongly feel like you are losing something. Since switching to riot/vanilla js, I have spent WAY more time thinking about how I want the UX to be than how I can force it into the various boxes some framework wants me to. In the Angular world, things like "it would be nice if that checkbox turned into a DDL when checked" would result in sweaty palms and much googling for phrases like "dynamic element swap directive" and an entire afternoon wasted. When you are used to working with DOM directly on a daily basis, this is a hilariously trivial activity requiring about 2 seconds of deep attention.
pendar747 9y ago
He wasn't a programmer since the beginning. He was a designer.

106 points by jspekken 9y ago

>Plus, now I have to learn what Redux is, and how Vue is the next best thing that happened since Angular 2.0. How to use styled-components to make JavaScript in React do what CSS can do on it’s own. I'm glad I get to call the shots where I work, and I've steered my team clear of all of this stuff. If you have a deep knowledge of the core technologies -- HTML, JS, and CSS -- you can build a great front end with a reasonable amount of time and effort. If something breaks, it's likely going to be our own code, and much easier to diagnose and fix.

deleted 9y ago
[deleted]
mfoy_ 9y ago
Framework churn sucks. It's a shame you're being down-voted, I can totally understand where you're coming from.
- topbanana 9y ago
  It does, but that doesn't mean you can't choose a decent stack and stick with it
  - deleted 9y ago
    [deleted]
  - scaryclam 9y ago
    Shouldn't we be looking at the task at hand and picking the best tool for the job though? Using a framework because it happened to work last time isn't a good criteria for selection. More and more I'm seeing over-engineered projects that took longer to build than they needed to and are currently harder to support than necessary, all because someone wanted to use their favorite tool.
pavel_lishin 9y ago
> If something breaks, it's likely going to be our own code, and much easier to diagnose and fix. But conversely, common problems and issues with frameworks are easy to find via Google and StackOverflow.
- joshribakoff 9y ago
  Plus more people are familiar with a popular open source framework than OPs. There's 100s of thousands of react devs. But only OP knows OPs framework. Most people need to use an existing framework before they try to write their own, because a lot of people try to write frameworks not knowing what frameworks actually do or what is involved.
  - pavel_lishin 9y ago
    I wonder if OP doesn't have a framework at all.
    - joshribakoff 9y ago
      Either way, the code must follow some sort of conventions or use patterns -- and if you invent your own conventions other people are less likely to understand them. Although if no one ever invented their own conventions we'd never innovate. I just think people should at least try out a bunch of frameworks before deciding they want to make one.
Klathmon 9y ago
To me this kind of thinking sounds so strange. A framework is (like it's namesake) a frame that you can build around, it's a tool that enforces restrictions on you by design. Obviously there is some overhead to learning that framework, but the idea is that the framework is built by someone who spends their day-job building the framework. They are going to do a better job of designing a framework than you will in most cases. Yes, you can build something great without them, but for any moderately sized project, you will end up re-inventing a set of rules and restrictions to apply to your own internal code. You will in-essence create your own framework. And that's fine, I'm almost positive that your "framework" will do some things very well, probably better than most of the competition, but you need to ask yourself what your main goal is. Are you setting out to build a framework? And/Or are you trying to build a product? If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one. Doubly so if that framework isn't designed to be reusable at least in your organization. Not to mention the overhead of having all new devs have to learn it anyway. However if the answer is that you are setting out to build your own framework (because the current ones have a limitation that you can't deal with, or some problem that you need to solve yourself), then by all means go for it! But that can't be given as "general advice" as for many people (I'd guess most people), as they don't have those same goals as you do. Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases. (but not all cases!)
- OtterCoder 9y ago
  Yes, frameworks are tools, but they're typically overspecialized and poorly designed. If vanilla JS is a cnc machine, Angular is an injection mold for a toy truck. If you're building a toy truck, that's awesome. If you're building anything else, say, a hand mixer, you're going to spend just as much time on the cnc machine trying to design toy truck whisk attachments as you would have spent just building a new mold with the incredibly powerful cnc you already have.
  - cormacrelf 9y ago

gtsteve 9y ago

I don't think there's that big a problem with how many front-end frameworks there are, and the pace of development. I think the problem is people who feel they have to use the latest and greatest feature and they have to know all the frameworks. At my company we picked a stack and stuck with it. That happened to be React and Redux. I hear Angular 2 and Vue are really great frameworks but I feel under no pressure to really investigate them because we're doing fine as it is. Two years later and we've barely changed aside from some package versions. We've got a very stable front-end with high code quality and component reuse. You don't have to listen to the hive-mind. Frameworks don't rust.

ythn 9y ago
> Frameworks don't rust Unless the framework is iron [1], of course [1] https://github.com/iron/iron https://github.com/iron/iron
shados 9y ago
Agreed. Honestly at this point I'll take boring. I'd welcome boring. People really need to stop upgrading 0.1 second after something comes out. Take the Java world. You can have a lot of criticism for the language or the platform, but the reality is people get shit done without upgrading right away. It's not even part of the culture. This allows people to master the platform and tools. In the JS world, there's no mastery. People just keep jumping to newest versions and spend all of their time fighting the new problems. Just. Stop. The company I work for almost standardized on react/redux. We're not done getting rid of our old stack that people are already looking at Relay Modern, Apollo, MobX, etc. If it wasn't for our investment in a massive home grown React component library, there would probably be VueJS all over the place. So we lose the ability to help each other. Every team is different, dealing with different problems. We can't build libraries since we don't have a platform to target. That to me makes us much weaker. So I welcome boring. I welcome the day when people are no longer interested in it so they stop spamming npm to check if a new version of their favorite library is out to upgrade to it when the existing one is working fine.
- Prefinem 9y ago

everdev 9y ago

Breaking News: JavaScript sucks

tabeth 9y ago

Just pick one and stick with it. There's some serious FOMO going on in the JavaScript community. When you read articles talking about all the great benefits they see from switching frameworks, what you don't see are the gains they'd have if they just rewrote everything in the same language/framework, taking advantage of the increased experience since the original write.

sametmax 9y ago

But JS dev has never been fun. Web dev is fun because the browser is a freaking awesome plateform. However, it is _despite_ of JS. There's not a single characteristic of this language that makes it better than any other mainstream high level language out there. We use it because we have no reasonable alternative on the browser. It has always been a pain to use, requiring: - avoiding part of the language that is badly designed to escape traps. - recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc. - fight with the various implementations to find some code that will work for most of your customers. - use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS. The fact that the community is now shooting itself in the foot by providing so many incompatible, badly documented and breaking-compat-all-the-time tools is just icing on the rotten cake. P.S: since this comment is getting upvotes, I will say that having used in prod vanilla, jquery, react, angular and Vue, I will stick with Vue for the next years. I'm done. My quest is over. It takes 3 hours of reading to be productive with it. It requires no tooling and yet can be used with existing tooling. It's fast. It's well documented. I can now focus on writing software again.

ballenf 9y ago
> - avoiding part of the language that is badly designed to escape traps. This is universally true for any mainstream language where age > 10 years. > - fight with the various implementations to find some code that will work for most of your customers. That's an understandable tradeoff from the ability to write code that can run on thousands of different devices. It's very much preferable than writing native code for each platform and all the various implementations that would require. Basically agree with your other points.
amiraliakbari 9y ago
JS, and the web platform in general, is solving problems that are hard in nature. Considering the constraints imposed by these problems, quite a few features of JS are superior to many other languages. Consider the wide range of devices that a JS code must support. There is some pain in supporting all of them, but compared with Android development, the transpilers and shims available in JS seems like magic. Cross platform programming is hard, and JS seems wierd because any JS code must consider it, while many C programmers never need to think about it. Taking cross-platform into account, I prefer copying some shims from MDN to using IFDEF WIN32's. Or consider GUI development. The nice API for working with DOM, lots of available UI components, and specially the asynchronous programming model made possible by Promises is really nice by GUI-programming standards. Also the good parts/bad parts mindset belongs to the past. I can't remember the last time I even thought of using == vs ===, prototype hacks or similar "bad" parts. The usual post about strange behavior of ">=null" on HN is just amuzing, not problematic for my JS coding experience. As said in other comments, maybe everybody should just stick to using their prefered JS framework and master it.

robodale 9y ago

14 year .NET veteran here. For me Javascript (actually Typescript) using Vue as the front-end reinvigorated my joy of creating web applications again.

sametmax 9y ago
Vue is the only glimmer of hope a JS project gave me for the last 5 years. I actually sent a donation the very first afternoon I started to read their doc, because I decided that even if I would not end up using it, I wanted the author to be supported for just existing in the universe. Of course I ended up using it anyway.
- ng12 9y ago
  Out of curiosity, what did Vue do for you that React didn't? I've been writing React for three years now and I can't find a compelling reason to even try Vue out.
  - sametmax 9y ago
    Nothing. For me the selling points of Vue are: - You don't need tooling to use it. You can use tooling, but you don't need any. It makes it freaking easy and fast to start a small project with Vue and increment on that. Webpack can wait. - Vue doesn't force components on you. Since most of my "widgets" are not reusable anyway, I really loves this. I write components only when I need to, usually a dozen per projects. - You don't have to pass state around using callbacks and props to make it works without a store. State is just an easy mutation away. I'm not facebook, most of my projects don't need a flux pattern, and having Russian dolls data passing shenanigans just so I can update my UI is a pain. - Vue documentation is stellar. It's wonderful. Like a walk in the parc with a friend. - Vue is so easy to start with. React took me a while to click. Vue took me 20 minutes. It's incredibly easy to train new people coming to your project. And as a professional trainer, the difference with students is just night and day. - Vue is very, very efficient. The lib is so small. But yet it's faster than react. - Vue has a lot of helpers that you can tell have been made by a pragmatic author. onclic.prevent and v-on:customevents are poetry to me. - After after hours and hours of react, I still have to look at the docs. I still have surprises. With Vue, the surprises stopped after day 3. - I hate JSX. Matter of taste of course. I like the Vue template language, but Vue can optionally use JSX if you prefer it. - Some very vocal people in the React community are dishonest. They will tell you you can use react without tooling or JSX because technically you could. But technically is not pragmatically. Nobody would. And you are on your own if you try. I hate fan boyism. Compare to Vue: the author even has a comparative page of most frameworks with Vue. He co-wrote the react part with react authors to get it fair. That, I like.

cc81 9y ago

React + (early flux and later mobx) made web development fun again for me. I was burned out at the end of the jquery era with all the different homemade structures and the limitations of browsers. Then I came back to React and babel/gulp (later webpack). Suddently there was structure in the front end that was easy to get into a project and contribute. Building components just felt right. Also js was almost a modern language now and I could use it even if the browsers did not actually support it yet.

alexfl 9y ago
I feel the same way... web development was hard, until I've learned about es6/babel, webpack, redux and react (I'm using morphdom as react replacement, but idea is the same). Now web dev is easy and fun. I have state, components, events and routes. That's it. Update the state and stay calm. The idea to concisely manage the state together with dom diffing, are my personal favorite game changers.
- mring33621 9y ago
  Can you provide some guidance/links to a backend Java developer who wants to learn & use a quality long-term, front-end tech stack? Is there a kickstart example project for your preferred stack? Note that I prefer to avoid nodeJS for any back-end production use but am ok with it as part of the dev toolchain, if required. Thank you.
  - cnp 9y ago
    Stick to https://github.com/facebookincubator/create-react-app/ https://github.com/facebookincubator/create-react-app/ and you'll be golden. If you need more config later, you can "eject", but this is a one-command-and-go kind of thing that is well maintained and works great.
  - cc81 9y ago
    I would say just start with the React tutorial and use the react-create-app (uses webpack etc in the background and is a npm package) that they use in it. Then after the tutorial I would go into the docs and read through them and maybe test some. After that I would pick the state management tool I want. Either Redux or Mobx as both are popular and have their advantages and disadvantages. I think it is worth going through both their official tutorials as they are pretty good. https://facebook.github.io/react/tutorial/tutorial.html https://facebook.github.io/react/tutorial/tutorial.html http://redux.js.org http://redux.js.org https://mobx.js.org https://mobx.js.org There are of course tons of videos but I think the official tutorials are a great start and using react-create-app instead of trying to dig into webpack and all that is really good at the beginning.

abhisuri97 9y ago

I teach a course at upenn on intro to javascript. Perhaps the most useful advice I give to my students is that often the simplest tools will get the job done i.e. you don't need React, Redux frontend stack because for most cases jquery will get the job done much quicker. Only worry about the frontend libraries when you feel it's getting out of hand, otherwise, the simple, straightforward tools will suffice.

rawrmaan 9y ago
I guess it depends on how you define simple. To me, React is far simpler than jQuery because of its declarative nature. It’s simple to reason about and easy to maintain and change. I would say it’s a much more straightforward tool than jQuery. However, advising them to delay state management (Redux, MobX) until needed is definitely a good idea. (Also, hey neighbor—I live right off campus)
amorphid 9y ago
I haven't coded much JS since ES5. With the improvements to vanilla JS, are there still a lot of things that jQuery provides that vanilla JS does not?
- abhisuri97 9y ago
  Yeah vanilla js still is a pain to access the Dom with.

gorpomon 9y ago

The desire to constantly switch JS frameworks is really confusing. I find each one different, exciting in their own way and fun to learn. However, and this is a big however, none of them radically change the work you'll create, so I'm happy with React, and not interested in learning just to learn. Maybe in a year or two, I'll try Vue, it won't be too hard to pick up. If you're at BigCo making internal apps, each one is basically dressing on a way to make various interactive UI states. How you get there is no big deal. How the data flows is no big deal. What test runner you use is no big deal. As a JS dev, my passion is to learn completely non-JS related things. Cryptography, Blockchain, CS Fundamentals I missed. These are much more interesting than the churn.

deleted 9y ago
[deleted]

Kiro 9y ago

> How to use styled-components to make JavaScript in React do what CSS can do on it’s own. Stopped reading right there. CSS-in-JS is one of the main reasons I'm even using React to begin with.

jroseattle 9y ago

Speaking as someone who has seen the ebb and flow of frameworks galore on the front-end and back-end, I've found many devs swing back and forth between love and loathing. It's just a natural evolution of how we use tools, and quite often the over/under application of those for the problems we're trying to solve with them. We've never had more options available to all of us to build complex systems, applications and services using highly-targeted tools. The new-framework-a-day pace at which these become available to us is fine, but honestly doesn't move the needle for most of us. A former leader of mine once said: you build things with tools, not popularity contests. I've found keeping such a perspective makes my stress level manageable.

pier25 9y ago

Well, that's what happens when you move the problems from the server to the browser (routing, dynamic data, auth, etc). instead of focusing only on UI you are working on a complete application. I like making SPAs, but there is really no need to do that. In many cases making an SPA is not even desirable.

adamc 9y ago

I think this is a good description of how front-end development has become a "tool zoo", where new versions of libraries and frameworks are often radically different, and new libraries/frameworks keep popping up. I compare this to Python, where most of the time learning a new library will keep paying off for years and years. It makes front-end development an expensive (educationally) place to work, and the maintenance costs of the code are substantial.

arstin 9y ago

I must admit having a hard time relating to all the complaints over js churn and the new world of...compiling code. I hated website dev in the past, hated using jQuery, hated being driven insane by the css cascade, hated wasting all my time on arbitrary and stupid browser incompatibility bugs with magic arcane solutions. I develop apps---not traditional websites---so I know this colors my experience. But every single tech change that I've made the past 4 years has been motivated by a real need. (Of course this assumes I have control over the tech: I'm grateful that I've only been forced to work on one Angular project for work!) I started using React in December 2013 after a shootout of the competing view libraries at the time because I didn't like having to be Sherlock Holmes to figure out how to change someone else's (or my own!) wild jQuery code, and I always inarticulately felt like I was fighting against a natural flow when using the old MVC frameworks. I now haven't churned my basic framework for almost 4 years. And don't expect to for many more! (I know that to an extent I got lucky: it's easy to forget now how much shit I got at the time for using dumb React lol compared to Angular). Ember is fascinating, I'm glad Preact, etc is around as a backup...but churning would solve no problem for me, and most jobs I'd get (for years now) require React, so why worry about changing? I've been a redux user for over 2 years now. I eagerly switched over the codebase I was working on because it solved a need I had: getting rid of a bug-prone, undocumented state solution of my own design which everyone else had to figure out for themselves. I expect I will switch out redux one of these years. But haven't seen anything to motivate it yet. Mobx-state-tree is very interesting, but until I see the benefits are worth the switch, why churn? I did really hate having to worry about babel, webpack, etc since it distracted from writing actual product code, though ES6 was just so obviously better than old JS that it was worth it. But now create-react-app and its siblings make the dev environment a matter of typing a single command. Contrary to this article, it points out errors that could easily have gone undetected in the the old world of wild web dev. No churn here. CRA all the way. Until I run into a need for something new. Styling solutions are something I have actually churned. But because I knew I wasn't committing, all css-in-js library code I write is in two or three "ui library" files. The app code itself only uses a jsx prop interface. So swapping these libraries on a mature app takes an afternoon at best. Though for the first time I now expect that I'll stick with Glamorous. I expect I'm going to stop churning here because I'm aware of no problem I personally have that Glamorous does not solve, unlike previous css-in-js libraries. I don't know, this guy's rant just put me in the mood for ranting lol. Anyway, I'm glad this guy found his real interest now might be as an animator and UX designer and I wish him the best! Those are important contributions too, possibly more important.

tjpnz 9y ago

Despite its flaws I tend to stick with Backbone whenever I need to do anything sufficiently complex on the frontend, and jQuery if it's any simpler. When writing software for money I've always found it pays to take a conservative approach.

nrhk 9y ago
I wouldn't jump too far ahead when writing software for money, it's always better to use something you know will work and have enough familiarity with to adjust around its deficiencies. But I think Angular 2, React and Vue are all getting to that point if not there already.

einrealist 9y ago

I totally agree with the sentiment. While others tend to use SPAs with their complex build system and lifecycle for everything, I follow principles of ROCA [1]. I don't understand why people think it is better and faster to make complex clients that include logic, that has to be verified on the server anyway. Everything I saw / see in the enterprise world is reinvented for client-side development again. [1] http://roca-style.org/ http://roca-style.org/

floor__ 9y ago

Honestly I love the Javascript Eco system. I love change and js is only getting better and better. Learning a new framework is fun. On top of that it keeps js development marketable. The wages for front end development have sky rocketed which imo is amazing.

madamelic 9y ago

It sounds like he doesn't dislike JS, he dislikes what web development has become. I dislike build tools and all the little doo-dads that we have to have now. Like, sometimes I just want to write some CSS and launch it with `npm start`

buchanaf 9y ago
Well create an index.html, inline a style tag in said file, write some CSS, npm init, npm install http-server -g, update package.json to with this script "start": "http-server", and profit. Fear not, we have the technology.

randallsquared 9y ago

> [Front-end is] looking more and more like the back-end This rings true to me. It's also partially why I don't really mind front-end development like I used to.

mattacular 9y ago

It's been fun again since I stopped worrying about keeping up with framework churn and all the tooling. I still feel bad when people ask what framework we use and I can rattle off a list of trendy new stuff but I quickly remind myself how asinine that is and go back to making perfectly fine, successful-in-production JS apps with stable boring things like ES5 and Backbone.

acty1 9y ago

Using Typescript with Angular2 + RXJS is like my second wind and a breathe of fresh air. It's like web development is "real" software development now.

moron4hire 9y ago

I think Framework-itis is a result of front-end developers—who are often junior developers who may not even have CS degrees—inculcating the false message that they are not "real" developers. As an industry, we have treated front-end development work as entry-level, occasionally even frivolous work, as it grew organically out of the left-over work that systems developers gave to the designers. Developing a framework doesn't look very much like doing front-end work; frameworks are generic, planned, and built from scratch, whereas the typical front-end developer is used to making highly-specific, ad-hoc changes to existing code (either because they've come in on a project started as a proof-of-concept by more senior developers, or they've used a boilerplate generating tool). Being more like so-called "real" software development, only "real" developers should be allowed to work on something ostensibly so important and complex as a "framework". The front-end developer has been indoctrinated into believing she (and it's very often a she, 'cuz design work is women's work, amiright?) has no business writing code, and that the code she does write is woefully "WRONG, WRONG, you're doing it wrong! What are you even trying to do?" by the karma-craving, bottom-feeders of StackOverflow. To avoid further public shaming—lest there be some hidden defects their inexperienced eyes cannot detect, no matter how trivial the bit of code may be—they avoid the actual act of writing code as much as possible and spend an inordinate amount of time searching for packages that may be imported from the gods. Thus left-pad, and the ensuing post-hoc rationalization in that debacle's aftermath that such trivial micro-packages are somehow a good development practice. I don't think there are a uniquely numerous quantity of framework projects in front-end land. Systems developers make custom tools all the time. But systems developers don't have a general fear, uncertainty, and doubt about their own work sewn into them, so it's more common for systems developers to jump into writing their own code than looking for pre-existing tools in whatever they might deem as trivial. Instead, I think a plethora of front-end tools reach a unique tipping-point level of popularity giving the perception of many more tools total, because of a general fear of falling behind. The front-end developer sees themselves as having no business criticizing their "betters" and must therefor accept what is handed down to them without question. If the front-end developer cannot prove they are a good little worker bee by keeping pace with any and all frameworks their benevolent employer or more-senior, more-"real" coworkers may spring on them, they risk having to go back to working as a barista. Something to think about while replying to a seemingly "simple" questions.

Kaotique 9y ago

$ ls node_modules | wc -l => 872 * Starts crying

moron4hire 9y ago

> After I was done with the front-end of a project, I hated that I had to do the back-end. I also was not good at it. After many, many years of tutoring students in a variety of subjects, there is definitely a connection between the last sentence and the first. People who work hard to get good at a particular subject often find themselves enjoying it a lot more. But humans don't care much for delayed gratification. If we have work that we could be doing that we enjoy more than some other work, than the hated work gets put off. Often indefinitely, as no skill in it ever gets developed, the more it is put off.

arrmn 9y ago

The last time I've really touched JavaScript is about a year ago, I'm just working with Python these days. Thinking back, I had 2/3 newsletters about JavaScript and whenever I've read them there was a headline "why X is better than Y", "Y has no chance against Z" "Good old X is better than Z,Y". I was always feeling, that I'm missing out on something and that I needed to learn new things. Switching to python actually made writing code enjoyable again.

saosebastiao 9y ago

I hate JavaScript with a passion, but 95% of that is fixed with TypeScript. But the thing that TypeScript can't fix isn't really related to JavaScript, but rather everything around it: 1) Build systems suck. Millions of plugins and adapters, opaque json configurations, silent errors, finicky and difficult optimizers, source maps upon source maps, shims everywhere, etc. 2) Browsers have unpredictable noncompliance with standards, HTML doesn't work well for user interfaces, CSS is obtuse, etc.

jancsika 9y ago

> So that’s why I’m now learning to be a Web Animator and UX Designer. Has anyone played around with the Web Animations API? I noticed that Chromium now lets you use elem.animate to animate SVG elements-- even properties like "width" which aren't technically presentation attributes in the 1.1 spec. Anyway, it's a very handy interface and easy to play around with inside about:blank to prototype things.

douche 9y ago

Was it ever fun? I lament the death of fat-client applications developed in real programming languages. Somehow we've decided that building our livelihoods on top of a scripting language that was whipped together in a week and branded to catch the tailwinds of another product is an acceptable way to do things.

Zelphyr 9y ago

To put a finer point on his argument; I'm working on an Angular project at the moment. Every time I refresh the page I have to wait 10 seconds before I see any of my changes while Angular compiles everything. I calculated that, given the number of times I have to refresh to test my changes, all of those 10 second compilations is costing my client tens of thousands of dollars every year in wasted productivity. So I can't help but wonder how Angular and their ilk are better?

alexasmyths 9y ago

Please try TypeScript. It's the only tech I will actively promote as 'not a fad' but a very useful thing. So useful, I stopped writing JS the first day I tried TS. For anyone with a background in classical software, it makes JS 'feel more real'. I can't imagine writing more than 50 lines of JS anymore.

vosper 9y ago

My biggest complaint about Javascript development is the config... OMG the config. So many modules, so many dependencies, so many build steps, so much half-baked documentation, so much assuming that you already know X, Y, and Z.

whipoodle 9y ago

JS moving in the direction of being compiled, statically typed, and adding lots of boilerplate for various reasons. When I started writing JS, it was partially to get away from these things in the .NET world. So, to be honest I don't enjoy these changes in isolation, but I understand why they are happening. I like that we're starting to think in a more systematic way about how to organize applications, and I think that bigger codebases and teams probably benefit from using static types. But god, sometimes when you open up these codebases they sometimes hardly look like JS anymore. Not to mention the tooling and build stuff, which still have a lot of maturing to do.

iamleppert 9y ago

Spend your time learning something that isn't subject to fads. In five or ten years, React will be a distant memory. Just like all the PHP frameworks are now. Focus on getting good at the web platform standards. I personally jump at any opportunity to learn new web platform APIs, graphics techniques, design patterns, data structures, and different business domains, and stay away from technologies that are fad-driven. Get good at a few basic tools and focus on application development. It's not about the code its what we make with the code.

bob1029 9y ago

I started to feel the same way as the author when 2016 rolled around. I found myself getting caught up in the paranoia of using the latest, greatest, most popular (i.e. supported) framework. Teammates would come to me with a bunch of proposals about how to use X over Y. We questioned continued use of Angular 1.x and had similar negative experiences with the build processes around the latest javascript frameworks. It really had gotten a bit out of hand considering our scope. I found the light at the end of the tunnel with Riotjs. It is close enough to the bare-metal JS runtime to keep you sharp in that regard, but also provides a lot of utility around building components without tying your hands in any particular way. For someone who is trying to build the best UX experience possible, I feel like riot or even vanilla JS provide a much better experience for expressing yourself. Front-end frameworks seem to me to be just a way to systemize the UX/UI problem into a thing that back-end engineers can reason with. Staring down a blank HTML/JS/CSS document without any constraints imposed on you can be a very daunting task until you truly get a feel for it. I strongly believe that one can be VERY productive on even the most complex web project without use of any frameworks, assuming they have the correct "artistic" mindset and the ability to balance that with systemizing the problem. My perspective is that the web is 3 languages (HTML/CSS/JS) and they need to be treated as equals. Any time you bring in a framework that does not consider all 3 with the same priority, I strongly feel like you are losing something. Since switching to riot/vanilla js, I have spent WAY more time thinking about how I want the UX to be than how I can force it into the various boxes some framework wants me to. In the Angular world, things like "it would be nice if that checkbox turned into a DDL when checked" would result in sweaty palms and much googling for phrases like "dynamic element swap directive" and an entire afternoon wasted. When you are used to working with DOM directly on a daily basis, this is a hilariously trivial activity requiring about 2 seconds of deep attention.

pendar747 9y ago

He wasn't a programmer since the beginning. He was a designer.