7 ms·
There's a bit of hyperbole in the article, but it strikes a nerve. I originally came from Java and was so fed up with the hulking class lib and the arcane buil
by iSnow 6y ago
There's a bit of hyperbole in the article, but it strikes a nerve.
I originally came from Java and was so fed up with the hulking class lib and the arcane build systems sprinkled with Ant snippets and XML galore, so JS felt like a fresh breeze.
AngularJS was a bit convoluted and the syntax was not nice. But OK, data binding was nice. Bit like dependency injection on the Java side made the code much harder to reason about but helped build certain classes of applications.
Angular 4 was just WTF. Somewhat cleaner module system but now with a clunky OOP language instead of the elegant functional expressions that JS had and Java finally adopted. For which reason exactly?
And I tried Vue which is a much lighter framework but like Angular, the build system is just retarded. Instead of many dozens of JARs with dozens of sub-dependencies, modern JS goes for the kill and literally imports several hundred of npm package with thousands of dependencies.
And in the end, I end up having to use "browserify" to have JS running in a browser. It's a clowns world in IT, but modern JS really takes the cake. I'm back in backend, solving real problems instead of wrangling my build chain.
- nickthemagicman 6y agoOn the bright side, with native web components and web assembly gaining traction things may be looking up in the future, as a lot of these ideas get rolled into the browser natively.
- overhero 6y agoyeah, web components gaining tractions since 2011...
- himujjal 6y agolol. web components are a waste of time unless someone wants to write a widget with ShadowDOM. Its clear. Svelte has won and is the last thing web can give us. Lets all go home
- nickthemagicman 6y agoWhat's wrong with the regular DOM? Shadow DOM having better performance is a myth. Google it.
- brainzap 6y agoYou can use Vue.js 2 without build system by just loading into the browser.
- nicbou 6y agoCan confirm. I built 2 VueJS apps that are 100% static, and it was not a problem at all.
- iFreilicht 6y agoA 100% static site doesn’t run any JS, right? What did you need Vue for, then?
- zimmund 6y agoA static site may use JS, but doesn't require server-side logic (PHP, databases, or any other type of dynamic content). In this case OP implies that it doesn't even require a build (because you may create a static site through a build process -like Jekyll does, for example-).
- nicbou 6y agoStatic from the server perspective. It only serves files in a directory without any parsing or processing.
- shrew 6y agoYou can still do this with Vue 3! The CodePen embeds they use in their "Getting Started" docs are all still just loading in an external library and making use of it with vanilla JS. https://codepen.io/team/Vue/pen/KKpRVvJ https://codepen.io/team/Vue/pen/KKpRVvJ
- franga2000 6y agoSure you can, but then the moment you want to use an external library with it, it's basically a coin flip whether they ship it in the correct format for that. If they don't, you have to import it - but you can only import from modules. So you modify your page to load your code as a module instead, but now you can't access the global state. So you refractor everything and realize, that your page takes a minute to load because each of those modules contains like a 100 dependencies and half of them overlap. TL;DR: it's there, but it's really only usable in like 5% of scenarios
- j-krieger 6y agoThere is no „wrangling the build-chain“ if you use the available clis all frameworks come with in advance.
- zdkl 6y agoWell since there's a plural in "CLIs", that goes into the "wrangling" category for me. If the dev/dep process involves more than one bespoke tool (looking at you js/Node monstrosities) and learning the arcana of their interactions, I'm out.
- j-krieger 6y agoWell, I guess you‘re out of programming as a whole then, no? Most languages and dev process involve a lot of configuration or „bespoke tools“ and learning the arcane of their interactions. Java? Gradle. JUnit. Maven. JavaDoc. etc. C/CPP? Make. CMake. Various dependency management tools. Maybe your OS native dependency manager Your OS? Brew / Yay / pacman / app-get / vim config / IDE configuration / environment tools / ... Deployment? Docker. Jenkins. Travis. Kubernetes. Coming back to „js monstrosities“, if you ever had the fun to poke around in the literal arcane magicks that are C++ dependency management systems and giant CMAKE files, you‘d love node. In fact, most cli tools are just for templating projects or generating boilerplate for components. They aren‘t arcane or complicated at all. Configuration is half of programming or dev ops. If you don‘t like it, maybe it just isn‘t for you.
- zdkl 6y agoI understand what you mean but disagree. I merely appreciate tools that make some effort to standardise their UX. Of course configuration is going to be a major part of the system; however that doesn't mean I must use fragmented tools to manage them. For instance, I avoid touching those Java tools you mention (or Javascript), preferring leiningen et al. from the Clojure ecosystem. If I don't want to deal with CMAKE or whatever the hell php or perl or erlang or go use, I can use my distro's package manager (coincidentally, yay) to abstract them away. If something goes wrong (which rarely happens these days!) it's even money that the problem comes from some Node/JS intermediate abomination which doesn't even show you the curtesy of being tractable in its scope or mode of operation. And your last line is uncalled for. I'm happy you like the current state of affairs, but my very subjective view is that I'm not affected by the JS-land Stockholm syndrome. Doesn't mean I don't enjoy dealing with the domain problems :)
- nicoburns 6y agoIf you like functional JS then you should be using React. This is exactly why it's still the most popular JS framework. If you want a simpler build system then you should try esbuild. It's a single Go binary.
- mercurysmessage 6y agoI don't understand why so many devs seem to want to use Functional programming. It's the exact same thing to me as what this article is complaining about. Everyone jumping on the latest and greatest bandwagon. Angular is easy, and OOP is very easy to work with for business needs.
- 5560675260 6y agoOOP is very easy to misuse where it hurts the most - on architectural level. It's very possible to write bad, unreadable FP code, but worst case isn't as bad or far reaching as with OOP.
- mercurysmessage 6y agoI suppose so, I've seen that myself. I always take the time to design anything I do thoroughly though so it's all clear and concise. Also the only time I used FP it was a seemingly awful implementation. Perhaps I'll mess around with F# or something some time to see how I feel about it more.
- JoeyJoJoJr 6y agoIn the case of React, I find functional programming excellent when it comes to mapping views from state. For state management, functional programming just seems like a massive time sink and a convoluted way of achieving the same things that OOP just gives you.
- mercurysmessage 6y agoRight, I don't know much about React myself, but that must be why Redux was created right?
- thecupisblue 6y ago> For state management, functional programming just seems like a massive time sink and a convoluted way of achieving the same things that OOP just gives you. Huh? function(state(A)) = state(B), always.