The last one I looked at, had an npm dependency tree like crab grass. No less than 9 copies of the same module, all different versions between 0.x and 6.x - and all that module does is parse query strings.
The best part was when the developer of said module release v6 changing all `var`s into `let`s and `const`s and then basically responded to people who filed bugs along the lines of "fuck you not my problem".
The last few years have seen both JavaScript and PHP gain community powered package management tools that actively encourage this type of behaviour, and until cool-kid developers understand that they need to actually be aware of the code they're relying on, nothing will change.
Really, it's just so simple- Write the code that does the stuff. That's it. Everything else is bullshit. Pick a framework at random. Don't write tests. Use vanilla javascript. Don't bother with a build tool. That's really all there is to it. Every other decision is premature- you likely do not know your requirements yet, much less understand the costs and benefits of gulp vs grunt. Don't even try. Just start writing. When the problem becomes apparent, then cross that bridge. Yes, you will re-write a lot of code. Pull up your pants and get it done. Re-writing code is always better than never-writing code.
You don't need to collect all your tools before you begin. Just start your work.
Errr, not really.
Let's pick a platform/language: Java
Build => maven (majority)
Unit-Test => JUnit (majority), Mockito (helper) Version => don't care, anything from Java 5 and above are good enough
Framework => Spring Framework or JEE (all batteries included)
Keep in mind either Spring Framework or JEE do component libraries so one does not have to use everything in there and they can mix-and-match.
spring-tests component provides stub objects for a few important JEE/Spring objects in case if you need them.
Ok, let's try one more time with: Ruby
Build => gems + rake + bundler
Unit-Test => Test::Unit or Rspec
Version => 1.8.7 or above, not a big issue, (having said that Rails do influence the version uptake)
Framework => Rails, Sinatra
I like what I'm seeing from these two ecosystems: high-quality tools that help me be more productive without spending too much time in either selecting or setting things up.
Build => npm + Gulp (optional) + Webpack
Unit-Test => Karma + Jasmine or Karma + Mocha + Sinon
Framework => React+Redux+Data (modular) or Angular (all batteries included)
Same deal. High quality tools. You are pretending that there aren't hundreds of frameworks for Ruby (Cuba, Brooklyn, Scorched, Hobbit). The only people overwhelmed by choices are people afraid to make one.
But that's far from what I usually want from my code.
I want the code that is easy to change, code that I understand, code that is reliable, code that works well with garbage data, code that will still be maintainable after I extend it. Having reasonable performance (notice, I'm not saying the best performance, just reasonable) is a must, too.
And in most other cases, when I move to a new tech, I get most of it pretty quickly. Of course, there's some learning involved, but I never aim just for code that "does the stuff". Just "doing the stuff" is so abysmally insufficient for good software that I don't expect any programmer to be satisfied with this single requirement.
Easy to change? Reliable?! Maintainable?!?
Bah humbug! Who needs it? Not me. I'll probably trash this version anyways! If I can get the thing to do one thing reasonable well, it's a winner. The code quality is always secondary to actually getting something done. Once you have a product and some customers and you've proven that it won't explode, then we can talk about performance. But I've seen too many projects strangled under the high-minded ideals of better programmers than I.
Complex dependencies that add up-front development burden should be added only if, and only when, there is an expected benefit justifying the cost.
I have 'app update fatigue' and often after I update an app I end up preferring previous versions I can no longer install or use again once they're 'updated away' and no longer current. My wants for what my phone or tablet can do are really simple, but I just don't want to have to wait to update anything I've already taken time to save to be sure I'd have when I needed it.
So I wrote the following apps and they all have manifests and icons. I have plenty more pages I use that aren't as polished (like http://staticresource.com/base64.html) but this whole exercise has made me feel like I have some control back over my phone.
Doesn't matter iOS or Android, I can always run my crappy little apps equally as crappy everywhere, and I know they'll never need updating, needlessly waste my battery, include malware that's tracking me or spying on me, and they do much of what I would use the device for anyway! If I've learned anything it's that building your own tools is VERY worth it, and I should invest more time in learning how to do this and doing it :)
Sketch
- View: http://staticresource.com/sketch.html
- Source: http://staticresource.com/inspect?/sketch.html
Sketch is a browser-based sketchbook! Draw with the mouse or your finger and export SVG by email or download.
---
SpeedTest
- View: http://staticresource.com/speedtest.html
- Source: http://staticresource.com/inspect?/speedtest.html
SpeedTest is for responsive web testing. Load a URL into the input and press Go or hit 'enter' to load a page into the window below. Pressing the buttons (or keyboard keys 1-0) will resize the window allowing you to quickly test sites at a variety of widths on desktop, and allow you to test sites at widths other than your device width on mobile.
---
Reminders
- View: http://staticresource.com/reminders.html
- Source: http://staticresource.com/inspect?/reminders.html
Reminders is a lightweight reminders app that uses localStorage. Helpful for grocery lists or to-do items.
---
Encode/Decode
- View: http://staticresource.com/encode.html
- Source: http://staticresource.com/inspect?/encode.html
Encode text by shifting its unicode character range. Decode by reverting the text back to the regular character range.
---
Clock
- View: http://staticresource.com/clock.html
- Source: http://staticresource.com/inspect?/clock.html
Analog clock made from JavaScript and CSS
---
Snake
- View: http://staticresource.com/snake.html
- Source: http://staticresource.com/inspect?/snake.html
Move the mouse or touch the screen to draw a rainbow snake on the screen
---
Shuffle
- View: http://staticresource.com/shuffle.html
- Source: http://staticresource.com/inspect?/shuffle.html
Tap the page to draw a new random card and roll a die (unlimited decks)
Virtual Deck of Cards
- View: http://staticresource.com/deck.html
- Source: http://staticresource.com/inspect?/deck.html
1 deck of cards, shuffled,flippable, no rules, no dealing. You can play solitaire, it's just like a real deck of cards you have to deal it yourself :)
---
Calc
- View: http://staticresource.com/calc.html
- Source: http://staticresource.com/inspect?/calc.html
Calc is a very basic calculator to demonstrate how JavaScript can think about strings
---
Piano
- View: http://staticresource.com/piano.html
- Source: http://staticresource.com/inspect?/piano.html
Piano is a small synth with a piano keyboard, capable of generating square waves on the piano scale to make noise for tuning things, or sketch out a melody, or just to jam around when bored.
I also have my own personal web-based 'command line interface' called JOE that end up being my most-used website and app on whatever device I'm using. I use this to check the weather and USD at least once daily, plus many more times for other things: http://staticresource.com/
...
> Javascript mixed with HTML seems ugly after having tried React
I think these highlight the real problem. Because we are constantly bombarded by such cool tech, it is easy to notice that some aspect of something could be done in a better way. The key to success is to ignore those minor papercuts and just focus persisting on your own project.
> Don’t try to know everything – it’s impossible in modern web development.
When I started web development. There already was a bunch of different stuff and no one tried to learn it all.
Pearl, PHP, .Net, ColdFusion, Java and what not...
As a result, there's a lot of people who started web development at a time when it may have seemed, if not simpler, less diverse in terms of strongly-supported options -- and trending toward greater consolidation, rather than greater diversity. For those people, the current state of web development could legitimately be a surprising array of more-complicated-than-they-would-have-expected decisions, with lots of opportunities for analysis paralysis.
Which combination of tools should you use? Ember if you have no idea where to start - otherwise thing about the problem you have with other tools and find tools that solve those problems.
I do agree that with the semi-recent "resurgence" of Javascript there's an abundance of frameworks and tools out there both for the client and server side making the selection of the "ecosystem" that would fit your needs challenging.
My take on this is stick to the basics until you realize that you need to look into something new. Client-side technology upgrades are reasonably simple as long as the client-server contract is defined up front (we doing old school gets/posts or ajax or wss etc?).
Server-side decisions are a little more tricky than that but once you commit to a definite decision on the server side tech, the specifics can be worked out down the road without affecting the client.
Granted the analysis paralysis wasn't so bad as react was much newer when I started, so I didn't even look at redux (though looking at it now, I'm still not sure what problem I was supposed to have that it solves).
As far as packing everything into a single file, I used make which would pipe cat through a minifier (or not minified with "make debug").
So ironically, I suppose all these new tools have made it harder to get started on React, which is perhaps the point of the article.
How many more of these comments do you have to read?
> The core of the problem is choice and the overwhelming abundance of tools to choose from.
Excuse me, did you want to try out a few new things, refresh web-dev tools, have some fun or start coding immediately?
Because, it looks like: I am chief-cooker and i can't cook simple meal. There are so much vegetables, juices, it looks like a game.
> I want a bread for my meal.
Leavened, Rye, Flatbread?
Uhhh, ohhh, it's too haaard, i wanted to try new things, but I'm seeking for best, standard choice.
These two things don't have to be mutually exclusive. In any other area of programming that I've tried recently, they're not — except for JS-based web development.
I remember I was trying to replace maven with gradle in Java -- it was fail because I wasn't able to add new repository to gradle. I'm still not sure how to it.
=> Redux
> this Gulp configuration file...
=> Webpack
This might be opinionated but for a personal SPA pet project without any legacy a good up to date stack has ES6/Babel, React, Redux, Webpack included. Curious what others prefer.
It doesn't matter what he uses, he just wants to write code and everyone telling him to use some other marginally different tool is just contributing to the paralysis.
I meant React + Redux, Redux or Flux is the missing piece for React. He used just React wondering how to manage the models, if he got a bit deeper in the React ecosystem he would have seen Redux or other Flux based frameworks. Besides, the React team and site explicitely states that some architecture such as Flux is required, so guess he just dipped just into React before he wrote his JS fatigue post.
> ...marginally different tool
Wouldn't agree with this. Tools/libs/frameworks are quite different and you can decide by comparing and having personal preferences. And the more choice the better tools. I don't know of any other ecosystem where such strong competition leads to so many innovations. Eg: Webpack, Redux and all the new kids on the block have significant learning curves but do this investment and you learn new stuff every minute and afterwards you are enlightened (if you like tech) because you find always something which works 10x better/faster/easier/more elegant than existing solutions. If you just want to get a job done, then learning new stuff might be perceived as too time-consuming and sticking to learned stuff allegedly seems easier.
Good, then he can stop reaching for new libraries and frameworks every time he gets "confused" or "intimidated". Invest the effort to learn one of them in-depth and the knowledge will still be applicable to new tools that come along. After all, they're just "marginally" different.
The main benefit is that you get something that already has the whole development/test/build workflow set up, with your framework of choice. Then you can tweak things as necessary.
Since all of the processes should be able to be run through a small set of CLI commands, there isn't much mental overhead switching between projects.
Really? I used to work with Java. I sometimes miss type checking, but I don't miss the Java type system - is C# a lot better?
