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

301–310 of 328 posts

Re: Advice to Young Web Developers

#301

Post by tdeck »

davnicwil wrote: post #227
tdeck wrote: post #221

Earlier quoted context omitted.

By security I mean pretty basic things like "client should only be able to query objects the user account has access to" and "client should only be able to perform certain kinds of transactions and mutations". On the back end that's not too tedious - just make sure I only query for what I want. But with a SPA I can't just assume the client will make only the "right" queries, otherwise I could just expose a SQL query…

> "client should only be able to query objects the user account has access to" > "client should only be able to perform certain kinds of transactions and mutations" The solution to these is equal for server rendered HTML containing {data} or an API just getting {data} in raw form - the request contains an access token which identifies and authorises the user - same goes for mutations on {data}. The answer to the ques…

> The answer to the question 'how do you know who the user is when they request a server rendered page containing some sensitive data?' is literally the copy/paste solution to how to do authentication on your API - as in, it's basically the same code that must be implemented on the backend in either case :-)

100% agree. But that (authentication) is not what this thread is about.

> The point is it's the same data and mutations, just a different interface over them. There is no security tradeoff of using one over the other.

100% agree again. A properly written application makes no security trade-off here by using an API. But that's because a properly written SPA stack does the work of interpreting the data and it's relationships twice on both the frontend and backend.

Re: Advice to Young Web Developers

#302

Post by eyelidlessness »

collyw wrote: post #280
eyelidlessness wrote: post #122

Earlier quoted context omitted.

I like your list, but I’d suggest: 8) learn a statically typed language with a good type system Even if you end up preferring mainstream language X, learning a language that makes you think in expressions rather than operations, and a language that makes you think in contracts rather than knowing the runtime state in your head, is invaluable for learning how to design, structure and maintain a codebase

What you say sounds interesting but could you give an example of "think in contracts" compared to and example of "knowing the runtime state in your head". Personally I have never really seen the advantage of staticaly typed languages over say Python, but I do rely on the strict typing supplied by a database instead.

What I mean is that static typing makes interface boundaries (modules, function parameters and return types, data structures) explicit, and those boundaries are enforced automatically. Those boundaries become a contract, where a provided interface and its call sites must agree on in order to be run. This is like a million little unit tests you get almost for free (obviously you have to write the types, but they're usually declarative and very expressive).

But it also serves as documentation of how any part of your program's state is structured at any point. To the degree a type system is sound, and to the degree your types are appropriately detailed, you can be assured the documentation is correct and up to date as long as the program compiles. This allows you to eliminate the question of "what does this data look like?" when you're reading code, and focus more on things like whether the logic is implemented correctly.

Since you mention it, I'll add that Python does have (optional, gradual) static typing, and a lot of work has gone into the type system in recent versions. It's worth spending a little time adding some static types in a project and seeing some of these benefits. When I last worked in Python, you had to run `mypy` to actually fail on static type errors, I don't know if this is still the case. But you could also use an IDE (like PyCharm, surely there are others) which will at least surface static type errors while you work.

Re: Advice to Young Web Developers

#303

Post by eyelidlessness »

ridiculous_fish wrote: post #194
schrute wrote: post #134

Earlier quoted context omitted.

You must understand the point I am missing. Why learn a language in the LISP family as a young developer? Does it somehow improve you overall?

Clojure is indeed mind-expanding. Unfortunately its most compelling ideas don't translate to non-LISPs, so I must sadly disagree with the "learn Clojure" suggestion. It's wild fun, but it's hard to apply the ideas to DayJob. An example: threading macros. In a language like Haskell, partial application is optimized for left-to-right. `f a` substitutes the first argument; other orders are more awkward. Functions like `…

> Clojure is indeed mind-expanding. Unfortunately its most compelling ideas don't translate to non-LISPs, so I must sadly disagree with the "learn Clojure" suggestion. It's wild fun, but it's hard to apply the ideas to DayJob.

I must say, having learned Clojure (and ClojureScript) and used it in production in my day job (we even still have one ClojureScript project in production), I strongly disagree. I would probably not choose to use it again, mostly because I've come to prefer static typing, but quite a lot of what I learned from learning it (and learning its idioms) has greatly improved my work in other languages.

In particular, Clojure's approach to state is something you can (mostly) apply in most mainstream languages. Handling most runtime state as immutable values, with clear and explicit use of mutable state for the cases where it's either necessary or makes the code easier to understand/more maintainable, is a huge boon for developers working in imperative languages.

In my current job, I've seen the quality of projects improve drastically as I've lead by example with that approach, and as I've asked for changes like it in code review. I've seen the volume and severity of bugs decrease, developer productivity improve, and morale trend upward.

Re: Advice to Young Web Developers

#304

Post by ogre_codes »

imtringued wrote: post #218
paxys wrote: post #79

Earlier quoted context omitted.

Sure, but you also have to manually redownload the entire site whenever there is a change.

Documentation doesn't change in real time.

> Documentation doesn't change in real time.

If you are a javascript developer chasing the bleeding edge of web dev, it's pretty close to real time!

Re: Advice to Young Web Developers

#305

Post by Apofis »

stevage wrote: post #162

As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…

If any of your clients rely on "pay-per-click" advertising, your care-free attitude toward page load speed will simply cost them money. The difference between a subsecond load time and a 5-10 second load time is a lot of lost revenue. Not a lot of people will wait over 5 seconds for your fancy webapp SPA to load. They will click back or just exit.

It has nothing to do with standards, businesses don't care about standards in the long run, they care about making money.

Re: Advice to Young Web Developers

#306

Post by roryokane »

kall wrote: post #263
MrBuddyCasino wrote: post #233

> Infinite scrolls are inhumane. People need to be able to reach “the end.” There are forms of eternal torment described in religious texts that are less mean. If I had to pick just one, it would be this.

Why does infinite scroll have to suck on the web, yet you never see pagination in mobile and desktop software? It makes me think that it's not inherently bad, it's the technology that's lacking. If the file explorer would split a 1000 file listing into 10 files each it would drive anyone insane. The "Artists" list on my phone's music player can probably be meassured in meters yet it's a joy to use because momentum sc…

Your phone’s music player’s list of artists does not use infinite scroll, which explains why you like it. If you scroll to the bottom of your list of artists on your phone, you will see “ZZ Top” and nothing special will happen – you’ve reached the end. File explorers, which you mentioned, also do not use infinite scroll.

“Infinite scroll” means you can never reach the end, because every time you get close to the end, more content is downloaded and your scroll bar readjusts. There is theoretically some end to the content, but most users will never reach it. Examples are Twitter and Facebook feeds.

Re: Advice to Young Web Developers

#307

Post by runawaybottle »

timw4mail wrote: post #265
osrec wrote: post #241

Earlier quoted context omitted.

Yes, the UX on mobile leaves a lot to be desired in my opinion. The two things that are going for HN in its current form is the fact that it's lightweight and fast. A lot of people think that moving to an SPA would mean killing both those aspects. But the truth is, you CAN have an SPA that is both lightweight and fast - the developer just needs to know what they're doing.

I have yet to see this...

You can check out nodebb for example, tons of JavaScript and quite frankly it’s a better forum experience than reddit or HN:

https://community.nodebb.org/category/2/general-discussion

Re: Advice to Young Web Developers

#308

Post by realtalk_sp »

jkachmar wrote: post #199
realtalk_sp wrote: post #150

Earlier quoted context omitted.

The realization that this permits end-to-end fullstack type safety and allows some awesome things (like surfacing breakage at compile time in response to changes to the data model) is a quietly brewing revolution.

This is in constant tension with the point that GP is making though. If you’re not _very_ careful with your software architecture, you can inextricably tie your frontend and backend applications together. Depending on the size of your product, or why the growth plans are for that particular frontend/backend app end up being, this might not be a problem. If it becomes one, though, then every bad technical design decis…

When you really stop and unpack this, you can see that this is a non-issue. Adding an object or a field to the schema (the most common operations in a growing schema) never interfere with dependents and can be performed independently of client adoption.

The remaining coordination issues can be solved by documenting or using e.g. a '@Deprecated' decorator in Typescript. And, of course, you can always just remove a field to see where the code has dependencies on it (where code breaks during compilation).

The concerns about shared code may apply in some cases, but the global schema is not one of them, in my experience. I do agree it takes a bit of extra thinking to do this correctly but it's really not that difficult.

Re: Advice to Young Web Developers

#309

Post by freehunter »

osrec wrote: post #238
freehunter wrote: post #140

Earlier quoted context omitted.

"PHP is fine, it's just poor developers making bad sites". And then people stopped using PHP.

> And then people stopped using PHP. Evidence? In my experience, PHP seems to be more in use now than ever.

A quick HN search shows PHP’s unpopularity. Check the Stack Overflow survey if you need a second opinion.

Conversely, I’m gonna need evidence that PHP is more popular than ever because that absolutely is an extraordinary claim.

Re: Advice to Young Web Developers

#310

Post by freehunter »

ehutch79 wrote: post #290
freehunter wrote: post #140

Earlier quoted context omitted.

"PHP is fine, it's just poor developers making bad sites". And then people stopped using PHP.

PHP wasn't good, fine maybe, though I understand it's better now. it was kind of slow, and all the functions were inconsistent, and had a lot of foot-guns. It was easier to write more robust code and model-view-controller code in other languages. (not that it was impossible in php)

It’s hard to make the claim that PHP is a bad language and also claim that very similar complaints don’t also apply to Javascript. They’re both languages defined by their popularity in spite of how poor the language actually is.
Post reply on HN