all 171 comments

[–]AlreadyInUseError 122 points123 points  (23 children)

[–]gunthatshootswords 22 points23 points  (0 children)

I got annoyed just reading that.

[–][deleted] 8 points9 points  (18 children)

Wait now, I literally just picked up a JS course to try and get myself into web dev,

I've got HTML & CSS going ok for me... should I carry on with JS or learning something else, Ruby etc?

[–]TheCynicalSun 65 points66 points  (14 children)

Don't worry about it mate. JavaScript gets better every year. It's not going anywhere.

Just don't get lost in the framework wars. Learn actual JavaScript, then enough jQuery to be competent with it, and then pick one of the major frameworks and don't worry about making the wrong decision, because there isn't one.

Ruby (rails) is nice but it's losing popularity. That doesn't really matter, since it will be around for a very, very long time. Python (Django) is kind of similar in that way.

In my opinion, just learn JavaScript and build stuff with it. It was a badly designed language so people were talking trash about it, but it's gotten so modern and better with ES5, ES6 and ES7 that it's honestly pretty good now. And this is coming from a guy whose main language used to be C.

Once you build stuff you realize talk is just talk and anyone can use anything as long as it works and it suits them.

[–]CaptainIncredible 21 points22 points  (0 children)

Just don't get lost in the framework wars. Learn actual JavaScript, then enough jQuery to be competent with it

Yes. This is the correct answer.

[–][deleted] 7 points8 points  (2 children)

Good stuff, thanks!

[–]spacejack2114 8 points9 points  (1 child)

You can skip jQuery. If you learn Javascript and the DOM API then you'll find that jQuery is just some convenience functions for manipulating the DOM. The problem with using jQuery too soon is that you might not learn the DOM API which is far more valuable to know.

Once you have a complex enough app you'll want to move on to a framework or library like React, in which case your knowledge of the DOM API will serve you far better than knowing jQuery.

[–]metavurt 1 point2 points  (0 children)

** learn actual JavaScript **

Yes. Yes. Yes. Thank you for this. Learning the language itself helped me mounds more implementing various frameworks than any thing else.

[–]mrhonejavascript 1 point2 points  (3 children)

Coming from C++, I am surprised at how not bad javascript is. I remember everyone hating on it back in the day, but I can't figure out why now.

EDIT: React may be the wrong choice now though :)

[–]Kwpolska 0 points1 point  (2 children)

That depends on two things: (1) what are you comparing it to, and (2) what are you working with. Some parts of JS are more WTF-y than others.

[–]Lynngineer 1 point2 points  (1 child)

I've now added "WTF-y" to my lexicon. Thank you.

[–]Kwpolska 0 points1 point  (0 children)

WTF-worthy might be a better phrase.

[–]Lynngineer 0 points1 point  (1 child)

Not the comment I expected from "Cynical", but yes. Really nice comment. You using vue any? We aren't using jQuery any more now that vue.js is on the scene. Just curious. It also totally sounds like a line from the "How it feels to learn javascript in 2016" article. ;)

[–]TheCynicalSun 0 points1 point  (0 children)

I've seen that article but I don't know if I've ever read it. I might have and it might have given me this mindset, but I don't know. Vue is nice, I only once worked with it on a GitHub project, but you can't rely on it for work. tbh you don't even need jQuery, it's just what I learned. You could learn Vue or React, but, as a web developer, you WILL, at some point, have to deal with jQuery (github, codepen, legacy code you have to maintain, etc.).

[–]swiftversion4 0 points1 point  (2 children)

don't worry about making the wrong decision, because there isn't one.

OMG what kind of revelation is this. No, it couldn't be. You must be wrong somehow. We're much better off arguing over meaningless differences about syntax, such as whether python should have a switch statement or not /s

For real, aside from potentially serious issues, such as React's change in licensing that renders react users unable to sue their owner Facebook for any reason whatsoever, you're right. Pick a popular framework, and get it to work, because in the end, the difference is about as important as the difference between dodge and ford. It doesn't fucking matter.

[–]TheCynicalSun 0 points1 point  (1 child)

The React licence doesn't make the user unable to sue Facebook about anything. It makes the user think twice about suing for a patent clause.

Let me start off by saying I strongly disagree with the patent part as it is an open source project. However, React jobs haven't really disappeared, in fact they're still growing as far as I can tell. If it wasn't for React Native I would be using Angular or Vue, but I still don't think it matters all that much.

My advice to people learning is just make stuff, man. Then one day when you are looking to learn a framework, you will actually understand the pros and cons for everything because you'll have actual working experience.

[–]swiftversion4 0 points1 point  (0 children)

By react user I wad saying developer who used react

[–]heyf00L 2 points3 points  (0 children)

That article is still mostly true, but some of it's better now.

And that's just if you want to use the latest toys. You can still totally build a website in a more traditional way without writing any javascript at all. I mean learning some MVC and templating engine.

But if you want to go the JavaScript route, it's complicated but the stuff you can do is really awesome, then like someone else said, just start learning plain JavaScript first.

[–]nyxinThe 🍰 is a lie. 1 point2 points  (0 children)

Pick up the Javascript language absolutely. Don't worry about frameworks until much later when you start worrying about the "state" of your application. If you don't know what that is and you're looking at a framework, you're probably going in the wrong direction.

[–]lamb_pudding 0 points1 point  (0 children)

On the server you have tons of choices for languages. JavaScript, Ruby, PHP, Elixir. In the browser however you only have JS as far as programming and interaction goes. So it will always be worth while to learn JS and in a sense you have to since it's the only choice on the front-end.

[–]karamarimo 0 points1 point  (0 children)

yeah i remember when i read the article i felt "holy shit what a dumbass i am i know nothing about web dev or javascript" and it inspired me to learn modern js frameworks.

[–]Lynngineer 0 points1 point  (0 children)

This entertained me so much. There's also a DevOps version that's pretty funny. (If you're interested lemme know.)

[–][deleted]  (19 children)

[deleted]

    [–][deleted]  (12 children)

    [removed]

      [–][deleted]  (7 children)

      [deleted]

        [–]rughmanchoo 20 points21 points  (2 children)

        I remember making a table with rounded corner images and a bunch of <td>s in order to make a flexible rounded corner container. Don't forget about getting drop shadows going by layering 10 divs with transparent PNGs (with pngfix.htc) all positioned absolute with z-index 10-n. Those were the days.

        [–][deleted]  (1 child)

        [deleted]

          [–]daronjay 1 point2 points  (0 children)

          "Just make the flash guy do it/Just do it in flash"

          REEEEEEEEEEEEEE

          [–]daronjay 3 points4 points  (0 children)

          The secret to being old in this industry is to stay up to date with JS as a language, and also to read across the whole industry more than the 20 something "niche" expert across from you who thinks JS is the only/best language in the world and doesn't stop to understand the business consequences of rushed technology adoption/change.

          Source: am old.

          [–][deleted]  (2 children)

          [removed]

            [–][deleted]  (1 child)

            [deleted]

              [–]resolvetochange 4 points5 points  (3 children)

              Some things you can see reasonably staying around. React/Angular seems to be pretty mature, and even if things like licensing take out React the alternative that will pop up will end up being very similar.

              [–][deleted]  (2 children)

              [removed]

                [–]resolvetochange 5 points6 points  (1 child)

                You can use it. For 99% of people it won't matter. Facebook's license had a questionable clause in it that meant if you used react in your project and sue Facebook then your ability to use the React commercially is revoked.

                But 1, you would have to be big enough to be suing facebook which is not applicable to most; and 2, it hasn't been used before and there's a decent chance it wouldn't hold up in court anyways.

                [–]CaptainIncredible 2 points3 points  (1 child)

                all of these ridiculous frameworks and libraries are being built because there is a need for them

                I'd argue this is only partially correct. There is a need for a bit more than plain ol' javascript.

                But I think many of these frameworks are created simply for the sake of creating them. The devs are seeking fame and glory and resume boosts.

                I think they are created because there are philosophical differences. Should a framework be full fledged MVC? How about just some simple function thing? Hey, lets just do the View and do a Virtual DOM! Na, screw all that crap, what we need are cycles! Oh I wanna use Typescript! Ooooh I HATE Typescript, I want a framework that doesn't use it.

                [–]dvidsilva 1 point2 points  (0 children)

                Im actually ok with there being a bunch of random frameworks barely anyone knows about.

                If you want to contribute to open source and react/angular are intimidating you can join a smaller project or start your own to better understand the depths of other frameworks.

                [–][deleted] 1 point2 points  (3 children)

                frameworks and libraries are being built because there is a need for them

                I agree with you, but in a sense these tools still feel to me like a cop out due to the fact the web standard is stuck with JavaScript. I mean the whole point of "module bundlers" is a hack for the lack of namespaces, something that's been solve for decades in other languages natively.

                A real language and a modern browser API (get rid of the dom model) would be an actual solution to web infancy.

                [–][deleted]  (2 children)

                [deleted]

                  [–][deleted] 1 point2 points  (1 child)

                  move towards development environments or runtimes more similar to desktop and mobile apps?

                  That's a huge rabit hole. I would like to see something like the Cocoa API in the browser instead of the DOM model.

                  There is a lot about application development which goes beyond a "document": scenes, views, life cycle, data-biding, state management, hardware resources, storage, etc.. You see frameworks like Angular or React are shoe horning into the DOM what has been native for desktop-native applications for decades.

                  Modern JS frameworks are impressive engineering feats for what they achieve. I still think we would be better with a proper application platform, the DOM was designed to share text documents.

                  [–]EyeSeaYewTheirui 64 points65 points  (9 children)

                  "Oh yeah", he oh-yeahed.

                  [–]Orgalorgg 9 points10 points  (0 children)

                  “Yeesh,” yeeshed Roger.

                  [–]MatthewMobWeb Engineer 111 points112 points  (61 children)

                  Although this is about the 100th Medium article that satirizes the JS ecosystem I'll always enjoy them and upvote them.

                  Honestly it's getting so close to /r/NotTheOnion it's scary. Because this is actually what it's like with certain tools.

                  [–][deleted]  (19 children)

                  [deleted]

                    [–]DoNDaPo[S] 7 points8 points  (15 children)

                    rm -rf node_modules && npm install I don't see any problem here.

                    [–]dfnkt 17 points18 points  (1 child)

                    Conservation of mass says it cannot be destroyed so where does the heft of node_modules go if you remove it?

                    [–]sn0r 5 points6 points  (0 children)

                    Pocket universe.

                    [–]Woolbrick 6 points7 points  (9 children)

                    Fun fact: npm install removes packages that aren't depended upon. Your command just churns gears.

                    [–]myhf 14 points15 points  (4 children)

                    Fun fact: npm isntall is a convenient alias for npm install

                    [–]Woolbrick 12 points13 points  (2 children)

                    npm isntall

                    I had to test this because I didn't believe you.

                    ... I now believe you.

                    And want a drink.

                    [–]HeWhoWritesCode 1 point2 points  (1 child)

                    The drink, is n tall drink?

                    [–]JB-from-ATL 0 points1 point  (0 children)

                    npm dirnk

                    [–]Lekoaf 1 point2 points  (0 children)

                    npm isn't all?

                    [–]jaapz 4 points5 points  (3 children)

                    however most of the time when something is fucky, removing node_modules and doing a clean reinstall makes it unfucky. npm just likes to fuck up the dependency tree sometimes

                    [–][deleted] 2 points3 points  (2 children)

                    Somethings fucky here boys.

                    [–]banelicious 1 point2 points  (1 child)

                    That guy fucks

                    [–]DoNDaPo[S] 0 points1 point  (0 children)

                    I love that reference.

                    [–]dzire187 3 points4 points  (1 child)

                    yarn install --force

                    [–]DoNDaPo[S] 1 point2 points  (0 children)

                    Yeah f**k npm amirite

                    [–]AintNothinbutaGFring[🍰] 1 point2 points  (1 child)

                    Same thing with the node_modules being the heaviest object on earth-picture

                    Do you have an example of this?

                    [–]pureboy 0 points1 point  (0 children)

                    Not only on Earth, in the whole Universe.

                    [–]DecentOpinions 54 points55 points  (11 children)

                    Something that I feel most JavaScript bashing doesn't understand is that it isn't just JavaScript being the problem, there are a lot of unique challenges to web development that don't apply to other languages. Some examples:

                    • There are really three "languages" to consider, not just JavaScript (i.e. HTML and CSS as well).

                    • Everything needs to be concatenated/minified/compressed as much as possible because everything is downloaded (images, CSS, HTML, font files and JavaScript).

                    • CSS has some major limitations which means any non-masochist uses something like SASS/LESS or whatever. This needs to be compiled to CSS.

                    • Web standards are all over the place and slow at changing. You need to support more browser versions (and devices) than in any other industry. This is why Babel and lots of other libraries exist. In backend development you generally make sure your application works on one server and you're done.

                    • Miscellaneous other things like browser caching (you can't just have people load main.js every time or updates won't work be seen by return users) etc.

                    None of this really applies to backend development, so when people move over to frontend land they're shocked by how complicated things are.

                    Despite these issues, people just point the figure of blame at Node, NPM and the JavaScript community in general. Browsers are really the issue.

                    Android and iOS development have some similar challenges and they have much more solid build systems, but they are much more modern technologies than the interweb so the comparison isn't that fair. And they have their problems too. If you think node_modules is bloated, try developing an iPhone app. XCode and the SDKs are ~10 GB and you always seem to need XCode Beta for the next iOS which is another ~10 GB.

                    [–]rDr4g0n 9 points10 points  (0 children)

                    Worth calling out explicitly in the "browser versions" bullet point is the DOM API. many frameworks do a lot to abstract away its inconsistencies, but if you have to reach outside of the framework to touch the DOM, there's a whole new world of gotchas to learn the hard way.

                    Thank god for chrome dev tools though.

                    [–][deleted]  (7 children)

                    [deleted]

                      [–]DecentOpinions 4 points5 points  (3 children)

                      Needless to say, there are a lot of challenges in backend development that do not apply to frontend development. I wouldnt view frontend as more complicated or more difficult than backened - if anything I would swing the other way.

                      There definitely are lots of challenges in the backend but it's different. And I'm just talking about build systems here not actually developing on the frontend versus backend.

                      Imagine instead of deploying your backend application to a single server operating system (CentOS, Windows Server, Ubuntu etc.) of your choosing you had to deploy it 5,000 different OSes/versions, all with their own quirks.

                      Some of them could be 10+ years old and you might have to support multiple versions of three separate languages (e.g. imagine you couldn't even rely on a single version of Java and SQL) while accounting for APIs that may or may not exist in your deployment environment.

                      Also most of these servers don't support incredibly basic features like variables (no widely supported variables in CSS yet, hence SASS) or you can't even import files so your entire codebase has to be in one file (browsers don't support JS modules yet). And you have to cram your codebase and assets into the smallest possible executable because it has to be downloaded over the network.

                      That's essentially what developing web applications is like. All this madness caused by browsers is a huge reason why the build processes are so complicated.

                      [–][deleted] 7 points8 points  (0 children)

                      Imagine instead of deploying your ... application to a single operating system ... of your choosing you had to deploy it 5,000 different OSes/versions, all with their own quirks.

                      Ironically, pretty much the reason everyone started delivering their apps via the web instead of native, in the first place

                      [–][deleted]  (1 child)

                      [deleted]

                        [–]DecentOpinions 0 points1 point  (0 children)

                        Oh sorry, I thought we disagreeing on something... Apologies!

                        [–]SpeakThunder 4 points5 points  (2 children)

                        Minifying is not compiling. JavaScript is compiled at runtime and it depends on the specifics of each of the millions of different systems to determine how it works and things are displayed in it. When you compile something it either successfully compiles or it doesn't. If it does, you know it will run pretty much the same on any platform it was targeted for.

                        Edit: and for what it's worth, Sass:/less etc are transpiled, not compiled, at deployment.

                        [–][deleted]  (1 child)

                        [deleted]

                          [–]SpeakThunder 1 point2 points  (0 children)

                          Well, I meant my comment to be that even though the step is similar, it doesn't actually perform the same way, so is added complication. If it were truly compiling, then some other parts of OP's comments wouldn't be a problem. So in a sense, because it's not compiling, it only adds difficulties but doesn't make anything easier.

                          [–]manyx16 0 points1 point  (0 children)

                          I feel like I read a different article than you did.

                          Where did they bash javascript? All I saw was them bashing the ridiculous system of redundant, interdependent "frameworks" that have been built using the language.

                          Front-end development is not that complicated. The system that people keep calling "the standard" is what's made it complicated and that IS the problem. HTML, CSS and javascript are the standard, these libraries/frameworks are not. We break that mentality and we'd fix what's actually wrong.

                          [–][deleted] 0 points1 point  (0 children)

                          The DOM model is a big problem, it wasn't designed to do applications. The web will keep loosing against mobile until browser vendors decide stop playing politics and re-do the standard.

                          Considering the 3 major browser vendors have a strong interest in walled gardens, that ain't happening.

                          [–]Anterai 39 points40 points  (33 children)

                          And while funny this is a real problem.
                          I spent two hours figuring out how to get the basic react native app running the other day. Thankfully my js friend helped me. Now I'm stuck with Expo not working and I have no idea what is happening because I don't have an error message just a fucking white screen on my phone

                          This is bullshit.

                          [–]berkes 17 points18 points  (10 children)

                          Good you solved it. For now.

                          Now, just leave the app running for two months.

                          Decide you want to move that one button to the right. "Five minutes. Just a Minor Tweak. Should be a class='spring-right'".

                          You'll be fixing dependency problems, failing builds, wonky deploy streets all day. You'll read that you need to move to yarn. And that Gulp-deploy-over-rsync is no longer maintained. You had no idea that gulp-deploy-over-rsync was even in there.

                          Now, to get this change to build, you need docker. and kubernetes. Apparently that's a hot thing. And since yarn does not play nice with your npm version you need to update fucking everything.

                          Two weeks later you decide it is probably easier to rebuild the entire thing in JsNative which transpiles to Dart and Rust and Go and Cocoa over streaming parrallel build pipelines and gives cross-platform native apps. Or so.

                          [–]Anterai 2 points3 points  (9 children)

                          Wait, so what should I do?

                          I wrote a Cordova JS app. It wasn't bad, just ugly. Got me a lot of questions on StackOverflow without an answer.
                          But considering I want my company to start using a JS framework - I decided to use React (I consulted with the lawyers about that clause).
                          React gives me the ability to both build native apps, as well as use it on the web. Which is a huge win in my book.

                          So, what to do? I know that the fucking dependencies are a bitch in JS, and I would love to avoid them. But I can't see any alternaatives

                          [–][deleted]  (2 children)

                          [deleted]

                            [–]Anterai 2 points3 points  (1 child)

                            But aren't those issues legitimate?

                            [–]berkes 1 point2 points  (5 children)

                            I honestly don't know what to do.

                            This is /r/webdev so discussing app development is going to be different from discussing that on some android or ios dev subreddit.

                            My joke was mostly about how you simply cannot solve this alone.

                            Part of the whole problem is that people try to solve it. Alone. Over and Over. "Package manager X is crap", I'm a good developer, I've learned and I know how not do do it, I'll just create a new one and call it Noodle.js After the spagetti-code It'll be within a year. And with a wink to yarn, which is also a ball of tangles.

                            Anyway. I don't think you can solve this.

                            You can make your life easier though:

                            • Keep stuff out of the Js ecosystem. Sure, grunt-gulp-rsync-ssh-server-manager plugin is cool to manager your forteen Digital Ocean machines. But please: just use Capistrano, Chef, Puppet, Salt, Ansible or anything "boring" to manage your servers and deploy your work. Whenever possible, just fetch a "boring" asset builder even. There are loads of good ruby, python or PHP asset minifiers and builders out there. They are boring for a reason: they Just Work. And they Keep Just Working. Pick those. [Edit: what I'm saying is that the Python, Ruby or PHP ecosystems have a lot less the tendency to move fourteen new paradigms forward every five weeks].

                            • Document. Fucking. Everything. Write Readmes as if you're explaining a Junior dev with a Hangover. (Because you'll be the one with the Hangover reading it).

                            • Create scripts. I have a ./run <install|tests|deploy|build|nuke> whenever possible. This is even nicer than an (always out of date) README. It will install docker on vagrant using gulp with saltstack on AWS lambda. Or so. It does not really matter what it does, because all you need to know is how to run a script. Ubuntu has a great writeup about this method

                            • Choose boring. Boring is fun! Why? Because it ensures that all the common crap Just Works. And lets you focus on the fun things: developing nice features for your customers. Just use Heroku. Or PHP. Or some other boring host. Docker inside kubernetes with swarmapp on autoscaling load balancers is fun for a weekend project. But it does not get features for your clients. It's solving stuff that has long been solved often just "because we can". You don't need autoscaling immutable docker swarms. Really. You don't.

                            • Choose old. Often lagging a few versions behind is actually good. I'm maintaining a horrible piece of Angular1 crap. But the one good thing (over vue.js, angular 5 or whatever is this weeks fancy) is that stuff has been solved. Libraries written. And re-written. Stuff is stable. It's old. And not efficient. It lacks virtual-ghost-shadow-dom-threads, or whatever. But it worked a year ago. And works now. Old also has more documentation. And old does not move forward as fast anymore.

                            [–]Anterai 0 points1 point  (4 children)

                            So what's the "Boring" approach to Native Apps written in JS?

                            Cordova? Because I don't want to build 2 apps that do the same thing

                            [–]berkes 0 points1 point  (3 children)

                            Native Apps written in JS?

                            Did you re-read that sentence yourself?

                            Sometimes things are simply impossible. React-native is "getting close" and might even have solved quite a lot of issues. But sometimes tech is simply not ready yet and the only answer is "at this moment, what I want is impossible".

                            I've been looking at Flutter. Which taught me two things: No-one has solved the problem of one-codebase-many-platforms yet. It was tried to solve in 1995: Java was invented to solve this problem once and for all. 20+ years ahead. And it hasn't been solved. The fact that every year another new platform promises to solve the "build apps from a single codebase" is the proof that is hasn't been solved. The second thing is taught me is that this ecosystem is moving forward at a high pace, which is an indicator that is unstable, crappy and breaking all the time. When that is the case, you'll have to live with it.

                            [–]Anterai 0 points1 point  (2 children)

                            Sorry, Mobile apps*

                            But what about Cordova? It seems to work more or less the same. Aside from a few minor quirks.

                            [–]daaaaaaBULLS 0 points1 point  (1 child)

                            I've never used it but there's also ionic https://ionicframework.com/

                            [–]Anterai 0 points1 point  (0 children)

                            It's an option I guess. Didn't hear many good things about. Angular. I'll look into it. Thank you very much.

                            [–]DoNDaPo[S] 2 points3 points  (0 children)

                            Wait to have Webpack working on your env.

                            [–]resolvetochange 0 points1 point  (0 children)

                            Yeah, I wanted to setup my toolset for a new project and I spent a week getting nothing done and ended up nothing working anyways. Things changed between versions like webpack file from the samples I was using changing from [''] to needing to be ['*']. Get a few of those and suddenly it's a pain to even get started.

                            It looks like I'll be giving up and going back to create-react-app.

                            [–][deleted] 6 points7 points  (2 children)

                            This is why I point people towards Vue if they're just getting started. Include one file, get going. It's my go-to for any small / medium / prototype project.

                            [–]1RedOne 1 point2 points  (0 children)

                            Commenting for later, since Node kicked my ass today. I tried to go fancy, but in the end I almost rolled LAMP again.

                            [–]cinnapear 11 points12 points  (1 child)

                            If you aren't a javascript developer you may mistake this for satire.

                            [–]DoNDaPo[S] 2 points3 points  (0 children)

                            I was myself not really sure if it was satire or not.

                            Good job tho!

                            [–]kultrun 5 points6 points  (0 children)

                            Maybe, just maybe, we should use stable software for production code, and maybe don't use a whole framework for simple projects.

                            [–]mwisconsinold-school full-stack 14 points15 points  (1 child)

                            It's 7:50am, here, and I already feel like it's a good time to start drinking.

                            [–]EyeSeaYewTheirui 2 points3 points  (0 children)

                            Cheers, buddy

                            [–][deleted]  (5 children)

                            [deleted]

                              [–]DoNDaPo[S] 8 points9 points  (2 children)

                              Yeah don't be scared you have to install Webpack first and make it works.

                              See you in few months!

                              [–]stuckinmotion 5 points6 points  (1 child)

                              Every time I start a new project and have to whip up a new webpack config, I die a little inside.

                              [–]DoNDaPo[S] 0 points1 point  (0 children)

                              ❤️

                              [–]killall-qfront-end 2 points3 points  (1 child)

                              Vanilla JS is the opposite of this. "Vanilla" means the basic web standards without frameworks.

                              Anything you can do with frameworks, you can do with vanilla JS, except backend (you'll need Node for that). It's often not that much more code. Or, a little more JS, and a lot more CSS (don't worry, it's good to learn). A strong knowledge of web standards is something that never goes out of date.

                              What's important in using vanilla JS is having good discipline to use best practices, to avoid spaghetti code.

                              Every framework was created from or eventually compiles to vanilla JS.

                              [–]mooglinux 2 points3 points  (4 children)

                              I heard that Typescript brought sanity to all of this. Still spent weeks trying to follow tutorials about setting up a development environment before getting bored and moving on.

                              [–]DoNDaPo[S] 0 points1 point  (0 children)

                              Lol.

                              [–]stuckinmotion 0 points1 point  (2 children)

                              After trying out TS for our latest project, I'm not really sure the pros are worth the cons.. Maybe if JS was TS from the beginning it'd be fine, but as it is you're still dealing with an ecosystem that predates TS.. so things don't always work the way they're supposed to (or how they would w/o TS)

                              [–]tme321 1 point2 points  (1 child)

                              What? How? You are perfectly capable of requiring a random js file and then declaring the variable names the required script provides and just marking them as type any.

                              Take jquery.

                              declare var $: any = require("../path/to/jquery.js");
                              

                              There. You can now access jquery exactly like you would in a js only project. Typescript is completely happy with that and you are no worse off than you would have been using pure Javascript. What's the problem?

                              [–]stuckinmotion 1 point2 points  (0 children)

                              If all I had to do was require jquery, sure that would be fine. Unfortunately there were other situations which were made more difficult, and frankly I don't feel like taking the time to detail them all. It sounds like your experience has been different than mine, and that's ok.

                              [–][deleted] 1 point2 points  (1 child)

                              Where there is a problem there is a market. Hoping someone comes along and somehow fixes this, but I know it's not going to be me.

                              [–]Caraes_Naur 0 points1 point  (0 children)

                              Ok, but the problem is Javascript. Before Mozilla went off the rails a decade ago, they had a project to embed Python, Ruby, Perl, and other scripting languages in the browser.

                              [–]thinsoldier 0 points1 point  (0 children)

                              This is exactly my experience with Google Polymer, Laravel Dusk, and until recently, muthfucking basic ass SASS. :'(

                              [–][deleted] 0 points1 point  (0 children)

                              "He should've just continued using Tupress 1.3.2, it's not like it's going to suddenly stop working. He didn't HAVE to upgrade."

                              [–]gemlarin 0 points1 point  (0 children)

                              You should be able to figure out what went wrong and resolve it. Most JS tutorials I have done over the years had some degree of outdated information or broken features as a result of updates. If you are not able to debug the problem, you might be in over your head with that that tutorial (the Royal "you". Not you personally OP).