5 ms·

>simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlciuhw >[...] >I had to install a package manager to install a package mana

>simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlciuhw >[...] >I had to install a package manager to install a package manager. And that's coming from a designer, not a programmer. A few years ago I had to take over a project that required installing something like 6 different package managers, 2 build systems, and a dozen different languages (counting things like jade and coffeescript), including dependencies that somehow required conflicting versions of the same libraries! (It took building pieces of it on 2 separate VMs and then merging them to get it to work.) All to build what turned out to be a simple little web site that in the end was basically 12 static pages and a simple form. That doesn't make things way easier. When I started programming, the key important things were to focus on getting the data model accurate, getting the business logic correct, validating input properly, and producing the desired output. Now that is maybe 5-10% of our workload, the other 90+% is dealing with dependencies, build tools, frameworks, 57 layers of generic abstraction, and all the fragile interconnections and leaky abstractions and compatibility issues between all of those things needed primarily just to simply display a page of content or handle a CRUD form. Sure, they're beautiful and interesting from an intellectual standpoint, and when they're working properly, they do make things that were once quite difficult a lot easier. But they also add a lot of complexity, require a lot of maintenance, and make the simple things much more complicated. Often, it's as if we're flying a squadron of helicopters down to the corner store to get milk (because isn't that cool and fun?!), and by the time the operation's completed and we've returned home and got all the helicopters repaired, we realize that we forgot the milk, or it's already spoiled, or we ended up with a potato instead. I do love playing with the new toys. React is really cool, a lot of the new stuff is interesting. But all those layers, all that indirection, all that distances us from the domain data and business logic can make it a lot harder to solve real problems and produce real value. Sometimes I just want to build something and not have to deal with all that mess.

RedneckBob 9y ago
Never though I'd have to run "make clean && config && autoconf && make && make install" to build a web page.
Donzo 9y ago
One of the best things about working for myself is that I write all my web stuff in vanilla JS. While I occasionally make errors, they are easy to identify, understand, and debug because the native features of JS are well-understood by modern browsers. Sometime in the last decade, modern web development moved on without me. I can no longer recognize what people are doing with all of these package managers and why they are doing it. I guess from a corporate stand point, it makes sense. You'd want your developers to be like widgets or sprockets, easily replaceable. Hot swappable. Otherwise these guys might build Daedalus-like spaghetti-code mazes and no one will ever be able to replace them. As a one-man operation, I'll stick with vanilla. It's easy to understand and it works forever.
- cc81 9y ago
  Sure that works, especially if you tend to write more web sites than advanced web applications. But that is true for back end as well, a one man operation can write Python or Java in a style and using libraries from 10 years ago and it would work perfectly fine. But depending on what they are doing they might not be as productive as they could be. If you want to try for example React it is incredibly easy to get started. Just if you want to check out what the fuzz is about. https://reactjs.org/tutorial/tutorial.html https://reactjs.org/tutorial/tutorial.html
  - user15672 9y ago
    This made me chuckle, since modern Python and Java styles are very, very similar, if not identical in places, to those of 10 years ago. Some of the libraries have changed, but many are the same as well. Shoot, I can still run Python code I wrote 10 years ago on the latest version (yep, that means something originally written for Python 2.3 can run fine on Python 3.6). And no, that doesn't make Python and Java old hat or redundant.
    - cc81 9y ago
      You can run 10 year old JavaScript as well, no problem. But Java written today is pretty different from Java written 10 years ago and the Java frameworks are very different. My point is that you can write code in the style from 10 years ago in any stack but for some reason people seem to take pride in it in the JavaScript world just because they cannot be bothered the actually learn modern development. Not to mention they tend to exaggerate the difficulty of getting started. Compare the tooling, build chain and language features of a JavaScript stack with for example Java. It is not like the JavaScript one is more complicated. You don't need something like React if you are doing a simple web page but a lot of people ARE building more advanced web applications these days and then it is probably best to just suck it up and learn a modern stack because the old ways of development is not really suited for it.
cc81 9y ago
That is because there was an explosion of possibilities with web development and a lot of different solutions where created at the same time. These days things have settled more and most technology stacks have one preferred package manager (almost always npm) and one build chain (webpack being the most popular). Yes, there have been confusion but there is a reason why and it has brought along web development that is so much better than it used to be and it is usually not very complicated these days. If you pick a stack you will usually have a cli that handles everything for you.
gjvc 9y ago
> Sure, they're beautiful and interesting from an intellectual standpoint constructing an application which consists of updating a table and persisting it in a database for business tomorrow should not be a high art. Most enterprise / business applications are not much more than glorified form fill-in, and the simple ones don't really deserve the multiple layers of abstraction. If you don't believe me, recall the relief of being able to "just edit the damn data" in the django admin tool when the regular application is misbehaving.

RedneckBob 9y ago

Never though I'd have to run "make clean && config && autoconf && make && make install" to build a web page.

Donzo 9y ago

One of the best things about working for myself is that I write all my web stuff in vanilla JS. While I occasionally make errors, they are easy to identify, understand, and debug because the native features of JS are well-understood by modern browsers. Sometime in the last decade, modern web development moved on without me. I can no longer recognize what people are doing with all of these package managers and why they are doing it. I guess from a corporate stand point, it makes sense. You'd want your developers to be like widgets or sprockets, easily replaceable. Hot swappable. Otherwise these guys might build Daedalus-like spaghetti-code mazes and no one will ever be able to replace them. As a one-man operation, I'll stick with vanilla. It's easy to understand and it works forever.

cc81 9y ago
Sure that works, especially if you tend to write more web sites than advanced web applications. But that is true for back end as well, a one man operation can write Python or Java in a style and using libraries from 10 years ago and it would work perfectly fine. But depending on what they are doing they might not be as productive as they could be. If you want to try for example React it is incredibly easy to get started. Just if you want to check out what the fuzz is about. https://reactjs.org/tutorial/tutorial.html https://reactjs.org/tutorial/tutorial.html
- user15672 9y ago
  This made me chuckle, since modern Python and Java styles are very, very similar, if not identical in places, to those of 10 years ago. Some of the libraries have changed, but many are the same as well. Shoot, I can still run Python code I wrote 10 years ago on the latest version (yep, that means something originally written for Python 2.3 can run fine on Python 3.6). And no, that doesn't make Python and Java old hat or redundant.
  - cc81 9y ago
    You can run 10 year old JavaScript as well, no problem. But Java written today is pretty different from Java written 10 years ago and the Java frameworks are very different. My point is that you can write code in the style from 10 years ago in any stack but for some reason people seem to take pride in it in the JavaScript world just because they cannot be bothered the actually learn modern development. Not to mention they tend to exaggerate the difficulty of getting started. Compare the tooling, build chain and language features of a JavaScript stack with for example Java. It is not like the JavaScript one is more complicated. You don't need something like React if you are doing a simple web page but a lot of people ARE building more advanced web applications these days and then it is probably best to just suck it up and learn a modern stack because the old ways of development is not really suited for it.

cc81 9y ago

That is because there was an explosion of possibilities with web development and a lot of different solutions where created at the same time. These days things have settled more and most technology stacks have one preferred package manager (almost always npm) and one build chain (webpack being the most popular). Yes, there have been confusion but there is a reason why and it has brought along web development that is so much better than it used to be and it is usually not very complicated these days. If you pick a stack you will usually have a cli that handles everything for you.

gjvc 9y ago

> Sure, they're beautiful and interesting from an intellectual standpoint constructing an application which consists of updating a table and persisting it in a database for business tomorrow should not be a high art. Most enterprise / business applications are not much more than glorified form fill-in, and the simple ones don't really deserve the multiple layers of abstraction. If you don't believe me, recall the relief of being able to "just edit the damn data" in the django admin tool when the regular application is misbehaving.