by hn3333 on 2/28/20, 4:24 PM with 18 comments
I mean I get it, it's web, it's sandboxed, it's safe, it's run-everywhere, but it also makes me want to quit my current job.
HN: What am I missing? Can you cheer me up?
(Btw. I usually love programming. C, C+=, ObjC, Ruby, ..)
by austincheney on 2/28/20, 6:56 PM
* All the unnecessary nonsense: frameworks, template foolishness, tooling, thousands of dependencies, and so forth
* Bad advise. Be critical of all advice, including this advise, especially since you are already an experienced developer. Be extremely critical of any advise that attempts to make the technologies or languages easier. Simple is not easy.
What makes JavaScript a fun experience:
* Expressiveness. Functions are first-class citizens which means they can be used and executed anywhere a primitive type can be used. This is a feature, not an accident. Since ES6 the language has lexical block scope, which is great for writing structured code without a bunch of syntax decoration.
* Rapid experimentation. JavaScript compiles fast enough that you won't ever know there is a compile step. This allows you to write code and test it instantly. The biggest limitation in this process is you.
* Appreciate the data structures provided for you. Treat the DOM like a data structure, which it is, by using the standard methods and your code will be more expressive, smaller, and execute several orders of magnitude faster. Being comfortable with how the technologies work allow you to write logic that is more fun to test and more interactive to use.
Here is a fun personal project that I recently worked on. The GUI only took a bit more than 2 weeks to write and fully test: http://mailmarkup.org/sharefile/demo1.mp4
by elviejo on 2/28/20, 4:35 PM
Maybe I'm just old like you. But I remember that it was easy to make graphical user interfaces, connected to a database in simple tools such as TK or visual basic ver 2.5
But somehow around 1995 we lost our way...
by m0ther on 2/29/20, 12:52 AM
It's a lot of fun to work on, it fits my specific (unusual) needs, it's fully predictable, and it's fast as hell.
There is no chance I could have convinced someone to pay me to build this. I'm a solo founder with 20 years of r&d programming and high complexity, high traffic, application architecture experience.
As crazy as this stack may sound to some; the chances that this system will continue to run and be usable without modification in 10 years is pretty high.
by LarryMade2 on 2/29/20, 3:52 AM
Then again I sometimes see a well crafted thin website, usually this is one that's been around a while (which after a few re-boots learned that just getting anyone to re-make it again is not going to fix the problem.) Look around, they are out there.
So what can I say, there is a lot of technical debt in web development lately (i.e. WordPress), and at some point these will come due. The script kiddies will not be the choice to fix the problem, but folks who care about the long term will - and with that there will be a chance to go through the cruft and refactor a more optimised web.
by brailsafe on 2/28/20, 8:23 PM
by npinsker on 2/28/20, 7:38 PM
I do enjoy JavaScript, and I've found much more happiness sticking to the absolute minimum for personal projects: vanilla JS or sometimes React + JSX without NPM.
by krapp on 2/28/20, 10:34 PM
by cordaciu on 2/28/20, 4:39 PM
by jamil7 on 2/29/20, 11:13 AM
by lukaszkups on 3/2/20, 11:23 PM
by viraptor on 2/28/20, 10:27 PM
If you're doing something internal and tiny with Vue for example, you could just import it like any other script and not use anything else, not even npm.
by buboard on 2/28/20, 10:49 PM
by sbjdigital on 2/29/20, 8:10 AM
by alexmingoia on 2/29/20, 5:11 AM
by matijash on 3/4/20, 12:32 PM
Why is it so? I believe because everything started switching to web lately so it gained a lot of focus. Being open-source in nature it attracted a lot of new ideas and this is what lead us to the influx of new frameworks we have today.
It is a good thing because innovation->improvement, but also a bad thing because a huge mess and choice paralysis :D. I also feel overwhelmed with all the transpiler and compilation steps, pretty much gave up on understanding everything.
How to hate it less? What @valand suggested below makes sense to me, by focusing less on the technology and its brokeness, but rather on the product, best practices and the end-goal. Also, even if the build system is a mess we can still write clean, high-quality and tested code which can be reused. This is what we did, propagated this culture through the team and that helped me hate things less. We were reading engineering books, having clean code dojos, best practice presentations etc. My takeaway from that was choose your victories when you can have them and enjoy them.
Another approach would be to join the madness by creating your own solution - which is what I also did. I know it is a https://xkcd.com/927/ case, but it was too fun and interesting so I couldn't help it :)
We basically built a DSL that compiles to the underlying stack of choice. If somebody wants to give it a look it is here: https://github.com/wasp-lang/wasp
Good luck and hope you find peace with whatever you choose!
by valand on 3/2/20, 1:47 PM
I found that the most comfortable place to look at software development is at the architecture level and I suggest you try too.
You'll be able to see the roles of each component in a system. It's magnificent.
Tips:
1. In the end, you'll only need to know the fundamentals
2. Docker builder pattern really helps with the build scripts thingy if you're developing a web app, either for the frontend and backend side. It really helps with fragility because fragility is often caused by leftover states and Docker container really helps you with that.
3. Rewrite instead of reuse parts that are not essentials / easily breaks. Pass-by-value and copy-paste was invented for something ;D
4. If you're using javascript, consider using TypeScript. It saves you a lot of time debugging for type-related bugs.
5. For browser/browser-like apps, use declarative language frontend libraries such as React, but don't rely much on other libs that come with React's popularity (such as redux, react-bootstrap, etc). They usually don't help as much and could be a hindrance in the future. All you need to understand are the fundamentals: html, css, and javascript.
6. For backends, don't feel forced to follow some architecture pattern such as (MVC, MVVM, etc). They often only apply well on certain tech-stacks, but not the other (e.g. expressjs is more popular than the MVC oriented sails.js, actor system is more comfortable in elm than redux due to the former having static typing). It'll help with flexibility later on.
7. Optimize the most valuable and reused component of the software/system. Over DRYing could lead you into premature optimization/abstraction where it would lead to unnecessary complexity.
8. If possible, only make assumptions if it is commonly done or it is guaranteed to not change frequently in the future. Otherwise, do not reuse. This is where YAGNI applies.
9. Don't feel rushed by the overwhelming amount of new frameworks, those things rarely survive. Choose the most flexible, helpful, and do the least (and most starred). Resist hype-based development because new programmers tend to be excited to learn new things and will inadvertently put what's new in the stack because it is cool.
10. Make it a constant if it can. Give it default if it cannot. If there's no possible default, don't run if not provided, write documentation for it. Do the same when running something. It'll reduce the amount of config in your codebase from now on.
Optimize at the architecture level, because you'll find the moving cogs over there are the most valuable for the business. Do touch the codebase at the lower level to understand what problem resides there.
Any framework you choose doesn't matter much as long as it fulfills the purpose of that very component.
You'll find that some tools and frameworks are better than the other for a particular problem, but usually, the choice of tech stack matters more despite the framework. And the choice of structure, contract, and architecture is the real deal, applicable everywhere.
Example: React feels better than Angular in electron. Nevertheless, electron app done right is almost always slower than native apps done right (not hating electron, I code electron almost every day in 2018). But ultimately you'll need to have a desktop app over publishing game in only-browsers, if you've got to run a game publishing and download management business because requirements and other things.
After a while, you'll realize that the technical decisions that matter the most are which you have to balance between development speed/productivity, performance, and maintainability. To me, it sounds like a pretty decent challenge, and I'm sure it does to you too.
If you're dealing with multi-layered architecture that needs maintaining, press your team or yourself to make each layer as simple as possible, do one thing and do it well, this also applies for frontend apps. Sometimes it takes more line of codes to do less, but it'll be worth it.
These have made my life easier and I hope they help you love programming more too.
(I love programming too, Game programming, Functional Programming, Fullstack, TypeScript, Rust, JavaScript)