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

Advice to Young Web Developers

tumblr.beesbuzz.biz

Post reply on HN
Print view View original

291–300 of 328 posts

Re: Advice to Young Web Developers

#291

Post by pathseeker »

RNCTX wrote: post #156
realtalk_sp wrote: post #146

Earlier quoted context omitted.

Can you point to some worthy examples of this as proofs of existence? And I mean something truly novel, and not simply a different way to do something we already can do.

https://github.com/steve-chavez?tab=overview&from=2016-10-01... https://github.com/begriffs?tab=overview&from=2016-10-01&to=... How many projects are there to automatically API-ify a database with auth boilerplate today? At least a few well funded ones, one recently funded by YC even. They came up with it in 2015? 2016? and still have a thriving project going with it. Looks like less than 10 people have more than 10…

>How many projects are there to automatically API-ify a database with auth boilerplate today?

That's a really vague statement but you described phpmyadmin, django, wordpress with a plugin, etc. Most successful CRM companies essentially have some framework doing this underneath as well.

Re: Advice to Young Web Developers

#292

Post by jolmg »

anonytrary wrote: post #250
jjoonathan wrote: post #61

Earlier quoted context omitted.

It's so sad that it became "acceptable" to not test in Firefox (as estimated by the number of sites I randomly encounter that don't work in FF but do in Chrome) right around the time that Firefox Quantum happened and Firefox became good again :(

Some businesses are willing to (and sometimes should) take a 30% cut in traffic in order to ship a product more quickly. It's not a company/developer's fault that there are subtle differences between browsers.

Certainly not their fault. What's wrong is that it's possible to get the majority of traffic by developing for a single browser. They should not be sustainable doing that. It should be the case that in order to have sustainable levels of traffic they should develop for the standard. It should be the case that the cut is not 30% but rather 70% or more when compared to developing according to the standard.

Re: Advice to Young Web Developers

#293

Post by pathseeker »

dustingetz wrote: post #118

1) Nobody has any idea what they're doing 2) If you think you know more than your manager – you are absolutely right 3) HN is 3 years ahead of mainstream, but 10 years behind the edge 4) React was made by an OCaml programmer 5) if you want to be that good, learn emerging languages (all of them) 5) don't optimize for money too soon, if you follow these instructions you will quadruple soon enough 6) Whatever your probl…

>3) HN is 3 years ahead of mainstream, but 10 years behind the edge

I think you're using a weird definition of 'edge' here to mean "things that nobody else knows about" rather than the cutting edge of the industry/academia.

Academic publications occasionally float across the front page here that have only been public for a few days. That's pretty much the 'edge' of industry-wide knowledge.

If you want to include things that aren't public, that's super vague and sort of pointless.

Re: Advice to Young Web Developers

#294

Post by nepeckman »

austincheney wrote: post #284
nepeckman wrote: post #116

Earlier quoted context omitted.

I respect your experience, but that does not match up with what I've seen, and what I've seen by proxy networking with other developers in my area. I do personally think simplicity is a virtue. I always try to collaborate with our business team to deliver only what is needed, in the most straightforward way. But if the customer needs a 20 field form, with logical dependencies and validation between fields, as well as…

I doubt your customer specified dependencies as a business requirement.

I always enjoy a good faith discussion, but if you aren't going to respond to what I actually wrote there's no need to continue this. I _know_ the functionality I mentioned can be shipped without a framework. I _have_ shipped web apps without a framework. I've personally found the overhead of designing and enforcing an ad hoc framework to be not worth the effort.

Re: Advice to Young Web Developers

#295

Post by zbentley »

dustingetz wrote: post #118

1) Nobody has any idea what they're doing 2) If you think you know more than your manager – you are absolutely right 3) HN is 3 years ahead of mainstream, but 10 years behind the edge 4) React was made by an OCaml programmer 5) if you want to be that good, learn emerging languages (all of them) 5) don't optimize for money too soon, if you follow these instructions you will quadruple soon enough 6) Whatever your probl…

> Whatever your problem is that is holding you back – drinking, eating, whatever – fix it today

D'oh! Why didn't I think of that?

Re: Advice to Young Web Developers

#296

Post by ratww »

abjKT26nO8 wrote: post #58
non-entity wrote: post #17

Earlier quoted context omitted.

Nothing pisses me off like getting a message that some website only supports Chrome in 2020

At work we're forced to use a service for exchanging files where uploading a file is only possible in Chrome, but downloading a file is sometimes only possible in Firefox. Pinnacle of UX.

They're definitely doing their part to maintain diversity in the browser engine ecosystem.

Re: Advice to Young Web Developers

#297

Post by tdeck »

davnicwil wrote: post #234
beachy wrote: post #230

Earlier quoted context omitted.

> it's basically the same code that must be implemented on the backend in either case :-) No, it's not. If I expose an API e.g GET /widgets,I need to ensure that there is no combination of parameters that will ever return a widget that the user should not see (e.g because it belongs to some other department). Whereas when I render a web page server side, I just need to write a single, correct, SQL statement that pull…

I respectfully disagree: it's the same code, moved around a bit of course, but literally the same logic making whatever conditional statements or database calls necessary to do permissions :-) It's the same data, with the same auth needed. If it's accessible to anyone over the network you need auth for everyone in either model. The auth code is the same code in either model, only the interface changes. Looking at you…

I'm really struggling in this thread because it seems like folks are either missing one half of my point or the other half. The idea was that I have to either a) duplicate effort in both my frontend and backend (that's extra work), or b) have no security at all.

The goal of both applications is to display HTML. The duplicated work in an SPA is in the DB API -> JSON API and JSON API -> page steps. These steps involve telling my backend server about how my data are structured and how to interpret them, translating them to JSON (or something else), then telling my frontend the same things. Every SPA I have seen involves doing this work, although some (like Meteor) are designed to reduce it as much as possible. That's the standard work involved in an SPA.

The second half of my point is that you could remove this duplicate work but doing that gets rid of any security. Why is this? Let's look at my SQL API example again. In this example, I have effectively eliminated the duplicate work of making my app server aware of the data's schema. It just runs a query, serializes the blob that comes back, and returns it. So why not do that? Obviously because now I'm trusting the client too much. In a non-SPA world it's fine to trust the entity making queries (for the most part...let's not get derailed). In the SPA world it's not, so we inject the app server in between to do mediation, and we pay the cost.

Re: Advice to Young Web Developers

#298

Post by heavyset_go »

siquick wrote: post #164
heavyset_go wrote: post #51

Earlier quoted context omitted.

> They learn React/Vue/Angular/whatever, then seemingly decide everything they will ever build will use that framework, regardless of whether it's the right tool for the job. At least where I live, small businesses contract with agencies that develop React sites for them, and suddenly these non-IT companies are owners of expensive and hard to maintain websites that they don't, and shouldn't need to, know the first th…

> Meanwhile, WordPress on a managed host or a static site would suit those businesses just fine. Then, they wouldn't have trouble hiring to maintain it, or could even maintain it themselves. > If you work for an agency or you're freelancing, please stop burdening small businesses like this. There aren't many more soul-destroying experiences as a freelance developer than maintaining a neglected WordPress installation…

That's why I suggested a managed WordPress host, so that they can outsource maintenance of their instance to professionals.

These projects get completely rewritten because they aren't fun to work with for most developers. What is being ignored is that there is an immense pool of labor that specializes in WordPress et al, and they're relatively cheap to hire. Even if these companies don't have dedicated staff to run their sites, many people are capable of using WordPress as long as its maintenance is outsourced to a managed host.

Re: Advice to Young Web Developers

#299

Post by tdeck »

MaxBarraclough wrote: post #235
beachy wrote: post #230

Earlier quoted context omitted.

> it's basically the same code that must be implemented on the backend in either case :-) No, it's not. If I expose an API e.g GET /widgets,I need to ensure that there is no combination of parameters that will ever return a widget that the user should not see (e.g because it belongs to some other department). Whereas when I render a web page server side, I just need to write a single, correct, SQL statement that pull…

A web API doesn't have to be general and reusable. It could be tailored to specific pages, if that's what makes more sense.

Very true, but in an l evolving application you often pay the cost of that approach because any small change to the data displayed or the behavior of the application will require a change to both frontend and backend (e.g. wiring up a new API), so in practice I think people tend to build in a certain amount of generality. It's a kind of trade-off between the time to design a more general API vs. the time to churn the existing API when we tweak the application.

Re: Advice to Young Web Developers

#300

Post by mikorym »

non-entity wrote: post #17
mroche wrote: post #5

> Browsers change. Relying on browser-specific behavior means you’re relying on that one browser at that one point in time. Code to the standard, and test everywhere. I wish this was listed at the top of the list, in the middle, and at the end. It’s super annoying when a site or application isn’t “supported” because it wasn’t tested in a separate browser (i.e. non-Chrome browsers). I know it’s not always easy with a…

Nothing pisses me off like getting a message that some website only supports Chrome in 2020

This is completely irrelevant, but I get pissed off even when websites don't support Lynx.
Post reply on HN