5 ms·

I think your comment is touching on two different points, in my view. > Until something breaks, and you have to go through all the configs and try to fix it.

I think your comment is touching on two different points, in my view. > Until something breaks, and you have to go through all the configs and try to fix it. This is solved by understanding the language and the tools you are using. I see so many people screw up a react app because they don't know javascript. They take the same smorgasbord approach to languages and tools they have used in the past (like jQuery) and apply it to react. React is really a frontend framework for javascript developers, not a frontend framework for creative types (like Misko originally slated angular to be) If people would just take the time to learn the actual language they are using, it would make these other tools easier to grok. This is software development. It is suppose to be hard. Take the time to learn your tools. > I’ve seen https://kukuruku.co/post/hello-real-world-in-php-in-2017/ https://kukuruku.co/post/hello-real-world-in-php-in-2017/ far too often. I always wonder why people elect to use a heavy set of opinionated tools to solve simple problems. I understand the point the blog post is trying to make, but again, it's like taking a highly set of specialized tools and complaining when it is difficult to do the simple things, when all you needed was a hammer. React is a UI library first and foremost. You can take it, inject it into your page, and use it. You shouldn't add the bells and whistles until your complexity grows to the point where it makes sense to use it. I tell people to ask themselves this question all the time, "Are you sure you need flux?" Stop and ask that question. Can this be solved by just maintaining state on a top level component and passing down props? Do you need codesplitting and chunking and the advanced features of webpack? Or do you still operate in a traditional way where designers hand of their templates to coders to create the html and css and you are just tasked with writing the javascript? Then don't use webpack loaders. Use your coder's classnames on your components. This is people making things harder than they have to be. But again, all of this is really not that difficult if you take the time to fundamentally understand javascript.

kuschku 10y ago
One of the big issues I see with JS is a bit of an abstraction problem. See, in the Java world, lambdas were introduced, and I can write code with them using RetroLambda, and it will run on old JVMs, too. But Java 8 has them natively. And I can write a modern Java8 project with nano and javac. No transpilers, nothing. While in the JS world, even now that browsers are starting to support ES6, everyone just adds more and more steps to the build process, instead of trying to simplify them. Ideally, if I write code, I want it to be simple, without any such tools. I want to be able to write one file containing dependencies, my code in a few files, execute one command, maybe two, and have a fully working product. And have it work for years, even while dependencies update. One config, one command, and my code. Not any single LOC or invocation more. That’s doable with JS – you just need a dependency format where dependencies can define macros over the language, and they’re handled by a transpiler or compiler, and you can import them normally. And just like that, a lot of this stuff would go away. TypeScript would just use its own frontend to the transpiler, and in your config you’d just define a different plugin. In the gradle and java world, all that exists, with language-plugins, and annotation processors. Yet in the JS world, it’s not like that, you have dozens of abstractions on top of another. > This is solved by understanding the language and the tools you are using. The problem is that the JS world is simply more complex than the Java world. A helloworld JavaFX app is about 30LOC of config, and 20LOC of code and imports. And compared to a production JavaFX app, no more config will be added. It’s just that. That’s all you need. And easy to understand. For React, it’s an entirely different beast (see the mentioned link)
- treehau5 10y ago
  > While in the JS world, even now that browsers are starting to support ES6, everyone just adds more and more steps to the build process, instead of trying to simplify them. To build on your Java comparison -- this is would be akin to using a new feature that is still in the JSR approval process, and then downloading an edgey JVM platform (maybe OpenJDK nightly, or something like that) and then complaining when your app gets more complicated. The solution to that problem is to stick to the stable syntax until the new becomes fully supported. Admittedly, this is a problem with browsers where instead of 1 environment, there are 8 with some 1 offs, but again, there is IBM JDK, OpenJDK, Oracle JDK, Android Java (whatever that's called, Dalvik or something?) > The problem is that the JS world is simply more complex than the Java world. I strongly disagree. Have you seen "enterprise fizzbuzz"?* I don't mean disrespect but you are kidding yourself if you think Java isn't as complex (if not more) than the current JavaScript ecosystem. I spent 6 years programming in Java and never felt I scratched 10% of the surface. * https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
  - kuschku 10y ago
    > I strongly disagree. Have you seen "enterprise fizzbuzz"?* I don't mean disrespect but you are kidding yourself if you think Java isn't as complex (if not more) than the current JavaScript ecosystem. I spent 6 years programming in Java and never felt I scratched 10% of the surface. But that’s the point. That’s all just code. Just normal code. Not additional command line utilities. Even Enterprise FizzBuzz can be compiled simply with gradle or maven. No processors. No transpilers. > To build on your Java comparison -- this is would be akin to using a new feature that is still in the JSR approval process, and then downloading an edgey JVM platform (maybe OpenJDK nightly, or something like that) and then complaining when your app gets more complicated. But I can do that. And I just have to import one single plugin – https://github.com/evant/gradle-retrolambda https://github.com/evant/gradle-retrolambda, and never configure it! Nothing to configure, nothing else. One import, and I’m done. Look at that fizzbuzz enterprise build.gradle, it’s 29LOC! The problem of "good defaults" was never even considered in the JS world, it seems.

kuschku 10y ago

One of the big issues I see with JS is a bit of an abstraction problem. See, in the Java world, lambdas were introduced, and I can write code with them using RetroLambda, and it will run on old JVMs, too. But Java 8 has them natively. And I can write a modern Java8 project with nano and javac. No transpilers, nothing. While in the JS world, even now that browsers are starting to support ES6, everyone just adds more and more steps to the build process, instead of trying to simplify them. Ideally, if I write code, I want it to be simple, without any such tools. I want to be able to write one file containing dependencies, my code in a few files, execute one command, maybe two, and have a fully working product. And have it work for years, even while dependencies update. One config, one command, and my code. Not any single LOC or invocation more. That’s doable with JS – you just need a dependency format where dependencies can define macros over the language, and they’re handled by a transpiler or compiler, and you can import them normally. And just like that, a lot of this stuff would go away. TypeScript would just use its own frontend to the transpiler, and in your config you’d just define a different plugin. In the gradle and java world, all that exists, with language-plugins, and annotation processors. Yet in the JS world, it’s not like that, you have dozens of abstractions on top of another. > This is solved by understanding the language and the tools you are using. The problem is that the JS world is simply more complex than the Java world. A helloworld JavaFX app is about 30LOC of config, and 20LOC of code and imports. And compared to a production JavaFX app, no more config will be added. It’s just that. That’s all you need. And easy to understand. For React, it’s an entirely different beast (see the mentioned link)

treehau5 10y ago
> While in the JS world, even now that browsers are starting to support ES6, everyone just adds more and more steps to the build process, instead of trying to simplify them. To build on your Java comparison -- this is would be akin to using a new feature that is still in the JSR approval process, and then downloading an edgey JVM platform (maybe OpenJDK nightly, or something like that) and then complaining when your app gets more complicated. The solution to that problem is to stick to the stable syntax until the new becomes fully supported. Admittedly, this is a problem with browsers where instead of 1 environment, there are 8 with some 1 offs, but again, there is IBM JDK, OpenJDK, Oracle JDK, Android Java (whatever that's called, Dalvik or something?) > The problem is that the JS world is simply more complex than the Java world. I strongly disagree. Have you seen "enterprise fizzbuzz"?* I don't mean disrespect but you are kidding yourself if you think Java isn't as complex (if not more) than the current JavaScript ecosystem. I spent 6 years programming in Java and never felt I scratched 10% of the surface. * https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- kuschku 10y ago
  > I strongly disagree. Have you seen "enterprise fizzbuzz"?* I don't mean disrespect but you are kidding yourself if you think Java isn't as complex (if not more) than the current JavaScript ecosystem. I spent 6 years programming in Java and never felt I scratched 10% of the surface. But that’s the point. That’s all just code. Just normal code. Not additional command line utilities. Even Enterprise FizzBuzz can be compiled simply with gradle or maven. No processors. No transpilers. > To build on your Java comparison -- this is would be akin to using a new feature that is still in the JSR approval process, and then downloading an edgey JVM platform (maybe OpenJDK nightly, or something like that) and then complaining when your app gets more complicated. But I can do that. And I just have to import one single plugin – https://github.com/evant/gradle-retrolambda https://github.com/evant/gradle-retrolambda, and never configure it! Nothing to configure, nothing else. One import, and I’m done. Look at that fizzbuzz enterprise build.gradle, it’s 29LOC! The problem of "good defaults" was never even considered in the JS world, it seems.