Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything Easy is Hard Again (2018)

frankchimero.com

Post reply on HN
Print view View original

231–240 of 269 posts

Re: Everything Easy is Hard Again (2018)

#231

Post by xupybd »

runawaybottle wrote: post #202
ReactiveJelly wrote: post #199

Earlier quoted context omitted.

I'm not a web developer, but at work I run a couple small app servers for internal tools. They have business logic specific to our product, and owned by the company, so although I'm doing a lot of pointless "plug together HTML" work for my learning, I'm also doing stuff that, AFAICT, has to be original code written by me. Did I manage to successfully duck out the entire web trend already? When I was a kid, the web ba…

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.

Re: Everything Easy is Hard Again (2018)

#232

Post by xupybd »

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.

I've been hunting for good low code CRUD tools. I'm not having a lot of luck finding any good ones.

Re: Everything Easy is Hard Again (2018)

#233

Post by varispeed »

There used to be a great system called Rancher where you could self-host quite complex applications across multiple servers. It was just perfect and very easy to use. Unfortunately they decided to embrace Kubernetes and it became too complex and not longer useful. I wish they continued to develop the old version.

Re: Everything Easy is Hard Again (2018)

#234

Post by xupybd »

runawaybottle wrote: post #196
papertokyo wrote: post #5

Frank is right, of course. Staying up to date with the tooling, best practices, and user expectations of the web requires an unreasonable amount of attention if making websites is only a small part of your service offering. One reason I prefer frontend libraries like Vue and Svelte is they feel closer to the grain of the web (HTMLesque templates with JS and CSS sprinkled in), and provide a reasonable level of abstrac…

Let’s not just pick on frontend. Has anyone seen what it takes to run something on AWS? Devops is nearing similar levels of insanity, and often for applications that won’t even have 50 users (seriously, all these companies that advertise for AWS experience for a tool that is going to be fucking internal with less than 50 users). It all builds up in me to be honest. You get the frontend complicated, then the deploy/in…

I recently got asked to consult for a project. I warned not to go with AWS that the tools they were wanting to put online were not well suited to AWS.

Then I got sent a 15 page deployment document outlining the AWS infrastructure they had gone with. They paid megabucks and got a rube goldberg machine. To run a zend based PHP site developed 15 years ago that has never had any significant maintenance.

Re: Everything Easy is Hard Again (2018)

#235

Post by arey_abhishek »

xupybd wrote: post #232
dleslie wrote: post #193

Earlier quoted context omitted.

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.

I've been hunting for good low code CRUD tools. I'm not having a lot of luck finding any good ones.

Try Appsmith, I'm a founder of it. Easy to build CRUD apps using pre-built UI components that talk to any database or API. Check out our repo here: https://github.com/appsmithorg/appsmith

Re: Everything Easy is Hard Again (2018)

#236

Post by majewsky »

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…

> Hey... I want to automatically compress the script file

The trick is to write so little JS that its bandwidth usage does not even register. I'm recently going as far as to include licensing headers and extensive comments in my website JS, see e.g. https://xyrillian.de/res/chapter-marks.js>.

Re: Everything Easy is Hard Again (2018)

#237

Post by danShumway »

WiseWeasel wrote: post #215
danShumway wrote: post #175

Earlier quoted context omitted.

There's a dirty secret that's fallen out of favor in the Node community, but that helps dramatically with this problem: it is usually a good idea to vendor dependencies for front-end projects (basically any project you're making that isn't being published to NPM). The trick with this is you have to avoid dependencies that compile C code or native binaries as part of their installation process, since those binaries mi…

By “vendoring” dependencies, I’m guessing you are talking about pulling them out of node_modules (into a js/vendor dir), and checking them into your repo, repeating the process every time you want to update. I will make an offering to Cthulhu if it’ll ensure we won't be using webpack and node 10 years from now in order to build those old snapshots without considerable effort.

> pulling them out of node_modules

No, even further. Just commit your node_modules folder.

There's this idea that vendoring has to be really complicated, but committing node_modules was actually official advice early on in Node's history. And what that means is that if you clone your repo, you just run `build`, you don't have to change or configure anything at all. The only dependency you have in your project becomes a node binary -- and honestly, you can vendor that someplace as well, node is reasonably portable.

There are a lot of advantages to this, not the least being that if you're demoing or working on a project someplace without an internet connection, having an up-to-date Git repo is all you need, you just have your entire project. If you switch branches, your project is ready to go.

Of course, if you have something like 1G of dependencies, checking them into Git starts becoming kind of cumbersome. But if possible, avoid that, for the same reasons you would avoid JS dependencies that compile native binaries. Having gigabytes of dependencies is going to be a nightmare for debugging and security, no matter what language you're in.

But I have built some pretty complicated projects where vendoring is fine. It doesn't balloon the size of my git repo, it doesn't make the project less portable, and it regularly saves my butt when I forget to check out the right branch before getting on a train without an Internet connection.

And all you need to do is not add node_modules to your gitignore.

Re: Everything Easy is Hard Again (2018)

#238

Post by danShumway »

filipo wrote: post #221
WiseWeasel wrote: post #215

Earlier quoted context omitted.

By “vendoring” dependencies, I’m guessing you are talking about pulling them out of node_modules (into a js/vendor dir), and checking them into your repo, repeating the process every time you want to update. I will make an offering to Cthulhu if it’ll ensure we won't be using webpack and node 10 years from now in order to build those old snapshots without considerable effort.

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.

- Even if you're downloading the same version, there are scenarios where natively compiled binaries can bite you. I've run into issues where node-gyp just wouldn't work unless I downloaded a completely separate compile toolchain onto Windows and restarted the computer. If you can avoid that and have all of your dependencies be pure Javascript, you will eventually save yourself a lot of horrible dev-ops work when the "quick" install on a new VM turns into an hour long process of watching Visual Studio tools download (tools that to GP's point may not be available or compatible 10 years from now).

- And finally, sometimes you want to do work across multiple branches without an internet connection, and vendoring your dependencies allows you to check out a branch and know you have the correct dependencies even if you don't have a connection to run `npm install` with.

Re: Everything Easy is Hard Again (2018)

#239

Post by ZephyrBlu »

grishka wrote: post #147
austincheney wrote: post #140

Earlier quoted context omitted.

> If you want to make a complex web app today, that's easier than it was 20 years ago. The tools are infinitely better. That’s true if the web app is a SPA and uses React and doesn’t require much accessibility and uses Redux or doesn’t manage state and, and, and... Most web developers are limited to those conditions and most currently posted front end jobs are limited to those requirements. Technically what you said…

I'm able to make what people call a "web app", yet I honestly have no idea what React and Redux are, besides buzzwords, and what they are supposed to solve. But then there's also the problem of people relying on JavaScript at all for websites that would've been fine as a bunch of fully static HTML pages. It's as if these days you can't do software development without overengineering everything into oblivion.

What do you classify as a web app?

React and other frameworks help you manage the state of your UI without having to worry (As much) about efficiently re-rendering the UI.

Redux and other state libraries help you manage the global state of your JS app so your entire app can easily access and update common data.

Re: Everything Easy is Hard Again (2018)

#240

Post by infensus »

elias94 wrote: post #171

What I found frustrating is how fast a front-end project is getting old. Taking a NPM+Framework project of 9 months old I often have a low change of install-run at the first time. Always there's an update, an incompatibility, or something that brakes the build process and I need a couple of hours to fix it again. Is not possible to work like this in the long run. Front-end projects are investments of time and money a…

Are you using packgage-lock.json/yarn.lock?
Post reply on HN