Everything Easy is Hard Again (2018) • Hacker News Board

Re: Everything Easy is Hard Again (2018)

#241

Post by MereInterest » Sun, Apr 18, 2021, 12:48 PM UTC

nirui wrote: post #207

MereInterest wrote: post #11

Earlier quoted context omitted.

And this is exactly why any of my hobby projects that involve JS are done with plain JS, with as few libraries as possible. I might pull in specific libraries, but I don't want to pull in a giant framework that will be outdated the next time I decide to work on that particular project.

> ... are done with plain JS, with as few libraries as possible ... I was having the same opinion and practice. However, I'm kind regret it as well. Even if you done everything with plain JS, eventually, one day some idea will float into your head such as "Hey... I want to automatically compress the script file/snip", "Hey I wonder if I can polyfill all my script", "Automatically bundle assets?", "Compress assets ima…

I'd put that as a difference between hobby projects and work projects. For work projects, there is some amount of time that can be allocated to continual development. The project itself has value, and needs to stay up to date, and so sure, it may use the framework of the day.

For a hobby project, if I personally don't have fun with it, then nothing gets done on it. If I decide after a few years that I want to pick a project up again in order to add a new feature, the last thing I want is to find out that framework X needs to be replaced with framework Y, and so the two weekends I had expected becomes two months of weekends to rewrite the whole thing.

Re: Everything Easy is Hard Again (2018)

#242

Post by cglace » Sun, Apr 18, 2021, 1:29 PM UTC

dleslie wrote: post #193

runawaybottle wrote: post #191

Earlier quoted context omitted.

It’s non existent. It’s weird how people were obsessed with coal miners losing their jobs, but right here in tech we literally saw a profession vanish. There is no ‘website developer’ anymore, not really. It just ... went away. That group had to shift overnight (in relative terms) to app development. This might be more foreboding than people realize. Aside from those who need to write complex queries stitching big da…

App Development is the next to go; there's already a handful of competitive tools that will build an App, complete with cloud services, without any need for writing code. And yah, there's only so many ways to write CRUD, auth, profile, and presence; backend is already commodified as B2B products.

And yet I’ve never worked on a product that was just simple crud.

Re: Everything Easy is Hard Again (2018)

#243

Post by imbnwa » Sun, Apr 18, 2021, 1:30 PM UTC

xupybd wrote: post #231

runawaybottle wrote: post #202

Earlier quoted context omitted.

I’d pay close attention to it. We don’t talk about the death of website development as a career because app development was available for everyone to transition to, so it mostly got ignored. But it happened, and there was nothing anyone could do about it. It’s a dirty little secret that if we honestly told new people switching to web dev ‘hey, yeah, just so you know, our jobs as we knew it kind of vanished once’, the…

Air tables is a sign of this gs to come but we are not there yet. Our head of sales wants to use an air tables like product but upper management will not yield, we need a real CMS. I think this sort of thinking will delay the adoption of such tools.

Yeah, not just devs, but armies of designers, product people, managers all distinguish themselves with minute product differentiation, a large majority of the industry runs on _not_ standardizing data and UI. There's more inertia here than just whenever the accountants notice the cost difference. You'll see people retry outsourcing before you see standardization if I'm understanding this conversation correctly

Re: Everything Easy is Hard Again (2018)

#244

Post by filipo » Sun, Apr 18, 2021, 1:34 PM UTC

danShumway wrote: post #238

filipo wrote: post #221

Earlier quoted context omitted.

Not a node dev myself but why not simply reference dependencies with fixed version? According to semver (that is probably what most node projects use anyway), you are free to use latest minor and patch revisions and leave the major fixed. Shouldn‘t this prevent most compatibility problems?

> why not simply reference dependencies with fixed version? This is the second best strategy, but: - node makes it kind of annoying to do this, because unless you do a clean build every time (which is much slower) `package-lock.json` will get largely ignored. - I have seen multiple projects break with semver. Just because people are supposed to avoid breaking changes in minor releases doesn't mean they actually do. -…

Ok I see; thank your for the explanation. So out of interest, I did some research and found that approx. 30% of packages depend on native implementations further down... so this seems to be a huge problem...

Additionally I looked at the sqlite3 package and not too surprisingly it uses node-gyp as well. So even checking in node_modules might cause the problems you described.

Out of interest: which backend language do you recommend to reduce such problems...?

Re: Everything Easy is Hard Again (2018)

#245

Post by danShumway » Sun, Apr 18, 2021, 2:02 PM UTC

filipo wrote: post #244

danShumway wrote: post #238

Earlier quoted context omitted.

> why not simply reference dependencies with fixed version? This is the second best strategy, but: - node makes it kind of annoying to do this, because unless you do a clean build every time (which is much slower) `package-lock.json` will get largely ignored. - I have seen multiple projects break with semver. Just because people are supposed to avoid breaking changes in minor releases doesn't mean they actually do. -…

Ok I see; thank your for the explanation. So out of interest, I did some research and found that approx. 30% of packages depend on native implementations further down... so this seems to be a huge problem... Additionally I looked at the sqlite3 package and not too surprisingly it uses node-gyp as well. So even checking in node_modules might cause the problems you described. Out of interest: which backend language do…

I use Node. I don't think Node is wildly better than anything else, but I'm used to it and it's good enough, at least for now. I'm unaware of any back-end language that forces dependencies to stay in the same language, but something probably exists somewhere.

I agree that node-gyp is a problem. It's possible to avoid, but can take some work (particularly when you start dealing with databases that basically have to be in compiled languages). The one saving grace is that if you have a set hardware that you're running on, you can sometimes vendor node-gyp dependencies. Unfortunately, that comes with some weird edge cases, and sometimes your dependencies break because your OS changes. I don't recommend it, but I understand that sometimes it's unavoidable.

I am hopeful that native WASM will solve some of these problems, but I don't know how realistic that hope is.

Re: Everything Easy is Hard Again (2018)

#246

Post by nirui » Sun, Apr 18, 2021, 2:41 PM UTC

MereInterest wrote: post #241

nirui wrote: post #207

Earlier quoted context omitted.

> ... are done with plain JS, with as few libraries as possible ... I was having the same opinion and practice. However, I'm kind regret it as well. Even if you done everything with plain JS, eventually, one day some idea will float into your head such as "Hey... I want to automatically compress the script file/snip", "Hey I wonder if I can polyfill all my script", "Automatically bundle assets?", "Compress assets ima…

I'd put that as a difference between hobby projects and work projects. For work projects, there is some amount of time that can be allocated to continual development. The project itself has value, and needs to stay up to date, and so sure, it may use the framework of the day. For a hobby project, if I personally don't have fun with it, then nothing gets done on it. If I decide after a few years that I want to pick a…

I must say it's a valid point. After all it's a hobby project, having fun is the first priority :D

However, one could also say "Well, it's a hobby project, so I'll just slap this framework on to save my time..." or "What? I have to manually deploy this hobby thing every time I made a change? I'll just put it on a CI and let Webpack pack the thing for me"...

My method is this: I will start the project with all new tech/frameworks/lib/"display: grid", then I publish the project, if it turns out to be a success, I'll maintain it (including upgrade the framework, bug fix etc); if it's not, I'll just put it aside and start another one. This way, I can touch/learn many new stuffs that might later benefit me in my day job without any risk.

So, I believe it eventually boils down to personal preference (based on objective information on hand, of course) :D

Re: Everything Easy is Hard Again (2018)

#247

Post by tasuki » Sun, Apr 18, 2021, 3:29 PM UTC

inglor_cz wrote: post #121

jdkoeck wrote: post #114

Earlier quoted context omitted.

Hi, I'm really curious, what do you write exactly for a living? Do you write fiction books, non-fiction books, blog posts, technical documentation?

1. Political commentary for a local newspaper. They pay reasonably well. 2. Popularization of science and technology for a few web outlets. 3. Books about interesting historical events, these are by far the most popular and earn me majority of my writing income. 4. I dabbled a bit in fiction, but long forms like novels seem to be out of reach for me. My strength is in shorter texts that can be written in an afternoon…

Mind linking any of your work?

Re: Everything Easy is Hard Again (2018)

#248

Post by 5cott0 » Sun, Apr 18, 2021, 3:35 PM UTC

vbsteven wrote: post #137

5cott0 wrote: post #116

Earlier quoted context omitted.

I don't think you're smart enough to make any inference about when I started. But if you insist on this crusty bonafides peen measuring contest I got started serving php via cgi on apache deployed with scp.

I’m not insisting on anything, sorry if I might have offended you, that was definitely not the intent. I assumed that you might have started later than the author because you compared the current state to just a few years ago, while the article mainly talks about even further back in history. The tools I mentioned were not meant for bragging. I just wanted to indicate that back then it was all way simpler, which you…

I know I was being sarcastic because hn discussions around the history of JS always devolve into this silly flamebait and no one should take them seriously.

Re: Everything Easy is Hard Again (2018)

#249

Post by seanpquig » Sun, Apr 18, 2021, 4:40 PM UTC

As someone who only does a frontend/full-stack project once a year or so, I do feel like some of this tooling mess is getting better.

On previous projects I remember the frustration of futzing with Webpack and Redux. Now it seems like React has matured and simplified nicely and Next JS is a beautiful framework with a great balance of flexibility + power with some reliable guardrails to work within and boostrap a basic React project.

Re: Everything Easy is Hard Again (2018)

#250

Post by MereInterest » Sun, Apr 18, 2021, 4:43 PM UTC

nirui wrote: post #246

MereInterest wrote: post #241

Earlier quoted context omitted.

I'd put that as a difference between hobby projects and work projects. For work projects, there is some amount of time that can be allocated to continual development. The project itself has value, and needs to stay up to date, and so sure, it may use the framework of the day. For a hobby project, if I personally don't have fun with it, then nothing gets done on it. If I decide after a few years that I want to pick a…

I must say it's a valid point. After all it's a hobby project, having fun is the first priority :D However, one could also say "Well, it's a hobby project, so I'll just slap this framework on to save my time..." or "What? I have to manually deploy this hobby thing every time I made a change? I'll just put it on a CI and let Webpack pack the thing for me"... My method is this: I will start the project with all new tec…

Makes sense. For me, I like to get hobby projects for my own personal use. The "publishing" involves pushing it to github, then doing absolutely nothing additional with it. But because I use it on my own, I may want to add more features to it later.

For frameworks, I'm sure they save time once you are familiar with them, but that also requires evaluating which frameworks to use and how to go about using them. That ends up taking a lot more time than throwing something together with plain JS.

That definitely makes sense, especially if you're using the hobby projects to learn about frameworks that you'll later use elsewhere. I tend to do the same thing on the compiled side, trying out different libraries and languages. (For example, picking up Rust for last December's Advent of Code challenges, then porting some of my other projects over to make some performance comparisons.)

Part of this is also that my dayjob has very little interaction with JS. If/when I use JS in my dayjob, I'm usually picking something minimal so that it can be used/expanded on by others without framework-specific JS knowledge. My goal is to make sure that I leave behind a codebase that can be read/understood by as many people as possible, which may mean picking a software stack that has a bit worse usability, in exchange for ease of finding developers.