Live data from Hacker News

What to expect from your framework

johan.hal.se

41–50 of 87 posts

Re: What to expect from your framework

#41

Earlier quoted context omitted.

> Modelling your frontend as a bunch of reusable components is a big benefit of frameworks. I think it's hard to go half and half with frontend component and backend templating though. I've heard this before, and just don't get it. I have, can, and do create view "components" in both Django and Jinja2. They're just templates. Templates that get included in other templates. I've never ( never ) got to a point where I…

If you think templates are a substitute for components there is very little to discuss. Templates hide hierarchy, are not easily composable, are not easily shareable (Can you publish a set of templates on NPM?) and cannot easily have complex self-contained logic. Another big upside of JS components which does not exist in templates is typechecking. Templates are good if you don't have complex hierarchies and have rel…

> The backend does not own UI state.

It does with Phoenix LiveView. And for stuff that shouldn't need to talk to the backend I find Alpine.JS to be a comfortable option that's very lightweight and several orders of magnitude less complex than React.

Re: What to expect from your framework

#42

I was interviewed for a job a few days back and I was told that these heavy JavaScript libraries are the future of the web. I'm still confused. Either my country is just behind or what you read on hackernews is not reflective of the real world.

> hackernews is not reflective of the real world.

Say it isn’t so! :-D Just as an example: When was the last time you read about Angular on the HN frontpage? Basically last decade. Does that mean nobody uses Angular? Hell no. It is extremly widely used by big-ass corps. It’s just that their devs generally aren’t in the HN crowd.

What companies do, what their support cycles are and how conservative their tech leaders are is an extremely heavy influence on the programming languages, frameworks and libraries they will use. You can research in advance and adapt your expectations.

Re: What to expect from your framework

#43

This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million ye…

There's a lot of programming propaganda that floats around and gets amplified that talk up the advantages of some approach. Often the advantages being discussed aren't even the outcome of the technology, they're just the goals of the technology. Said propaganda will also completely fail to include the disadvantages of the approach. The result is a whole bunch of people who will flock to the new tech, and only 2 or 3 years later will the real story start to come out. The tech usually does have legitimate uses, it's just those uses were niche rather than "everyone should do it this way".

A big recent non-web example of this is NoSQL databases. Endless hype about their advantages. Virtually no discussion about their disadvatages. (In relative terms. It was actually there in absolute terms, I know because I picked up on it. But it was buried for a couple of years in the hype.) Endless hordes of developers switching to them, and confirmation-biasing their way past the first few red flags. Do they have a niche? Yes. Were they massively, massively overused? Absolutely. I've seen projects killed by the choice to use them, and many others switch away from them in a tearing hurry because their systems were coming down around their ears. Would a lot more discussion of their disadvantages been helpful? Who knows. In the midst of a hype cycle sober engineering discussions become a form of betrayal or personal attack for a whole bunch of engineers who too-quickly incorporate the new tech into their personal engineering identity.

SPAs are the same way, and more generally, heavily REST-based backends. Is there a time and a place for them? Absolutely! Are they always the best default organization? Heck no. Do they come with a lot of costs that need to be accounted for with the benefits? Yes.

Stepping up to a stratospheric level of abstraction, outright philosophical astronautics here, I think one of the biggest mistake programmers make is to sit down at some technology decision in which one must weight the costs or the benefits, and implicitly without thinking about it, assign a flat ZERO to some tech's costs or benefits. Most often costs, though the latter can happen. Especially in their earlier years, though even older programmers can get caught up in a hype cycle if they're not careful. Costs are never zero. Benefits are effectively never zero because nobody talks about techs with no benefits at all.

Re: What to expect from your framework

#44

This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million ye…

I believe this is best explained with the saying “if all you have is a hammer, everything looks like a nail”. Say you came into tech after jQuery and the like. You know your SPA frameworks/libraries. Maybe you are somewhat lazy at sniffing around for new trends/tech.

You are presented with a new challenge. What will you chose? The stuff you know you can do it with or something else entirely?

Re: What to expect from your framework

#45

This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million ye…

How do you implement editable list of items where requirements are that:

- editing/creating new has to be in a popup - people don't want full page reload because they lose context (and have "feel" it beeing slow even if it is not) - edit-table is not a solution because amount of settings will fit popup - some things like item name in a list has to be updated in the list after saving in popip which requires two way data binding, because cannot do page reload - pagination and filtering is required and for same reason as above cannot be full page reload

I don't see how you implement that in a way that is maintainable with "sprinkling jQuery" on it. I would like to build it with full page reloads which would be fast and would take away complexity but every business analyst or product owner I saw was saying that "users feel" it is slow and they lose context even if list has stable sort and filtering was kept between reloads.

Re: What to expect from your framework

#46

I dislike frameworks for the same reason most of their proponents like frameworks, you can not expect to out-compete all the smart people working together on a common goal. Frameworks are bad at cultivating off-colour ideas, they tend to have a well curated API but are often stuck with a singular architecture. Sometimes the solution is to be found in some lateral dimension. One such example is PostREST, it does away…

Mediocrity enshrined as a process that gets elevated to best practice. And then you get yelled at if you try to improve on it, because it is a best practice. :)

You just described my last employer to a T, and all because of ego. They kept solving problems that the framework they used already had solutions for. You were actively discouraged from coming up with any different solutions, because the VP of development was stupid and didn’t want anybody changing the patterns he used when they started the company. This included things like “using base classes or modules”, any third party libraries, code linters, database views, and many others.

It was a huge waste of YC money, but the money kept pouring in.

Re: What to expect from your framework

#47

This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million ye…

Side note, but just wondering what you think Rails's flaws are? What did you got sick of?

Great question! I'm actually writing a lengthy blog post on this topic, but it's not published yet. Until then, I think Piotr Solnica has written some really good takes:

https://solnic.codes/2016/05/22/my-time-with-rails-is-up/

https://solnic.codes/2016/05/30/abstractions-and-the-role-of...

https://solnic.codes/2015/06/06/cutting-corners-or-why-rails...

(See also this old HN discussion about the first link: https://news.ycombinator.com/item?id=11749203)

And please pardon the self-promotion, but if you're a Rails guy and I can convince you to give Phoenix a try, I hope I can also convince you to try my course on the topic: https://phoenixonrails.com/

Re: What to expect from your framework

#48

Rails is probably the best framework still. But it still feels too low-level. I don’t want to care about the mountains of Web gunk there are: JSON serialization, HTTP methods, cookies, etc. Lack of static typing really hurts the maintenance story, too. I really just want to write business logic, wire that up to endpoints in a nice DSL, and move on. Most web frameworks seem to be obsessed with the web platform to the…

Cough phoenixframework.org cough

It is definitely closest to what I want. I need to give it an honest try.

Re: What to expect from your framework

#50

Earlier quoted context omitted.

Companies are already used to hiring frontend and backend separately, it is much easier to find an expert in either than an expert in both. It is also one of the few opportunities where you can meaningfully split up work. How much of an upside that really brings, is secondary. It already happened. I do not buy into the YAGNI or in-most-cases arguments. Most cases are interactive applications, not the overengineered l…

> Companies are already used to hiring frontend and backend separately, it is much easier to find an expert in either than an expert in both. I think this gets cause and effect the wrong way around. If companies stopped unnecessarily dividing their stack in two, we wouldn't have so many FE developers who don't know how to do anything on the BE and visa versa. I've worked with frontend "experts" who barely know how to…

Yes, frontend developers often barely know how to query a database, whereas backend developers often create terrible user interfaces, whereas fullstack developers are not particularly good at either. It is a tradeoff.
Post reply on HN