If you use Phoenix, using types at the data model level using changesets and then trickling them down all the way to the UI is a very good compromise. As changesets provide type validations out of the box too.
Yeah, one of the worst practices. I've been working with Elixir professionally for 6 years now and I still see this sh*t everywhere. Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. List of memberships? Keep them as a list with the same fields as the junction table. Top-level APIs taking maps with string keys as "params" so they can very easily be cast for a changeset.
This was the only out of box solution when Elixir didn't support types. So, if you really did Elixir professionally for 6 years, you'd know that by now.
> Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape.
If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning and architecture overall as that is one of the very first things you do.
What you describe is an approach a lot of NoSQL fans use - use whatever works then, worry about datatypes later on. That's how you shoot yourself in the foot.
> List of memberships? Keep them as a list with the same fields
Again, using embeds_many or has_many works well too, using changesets - which is my point exactly. Not sure where the disagreement is here.
Your account is full of just ragebait comments at a quick glance, so I'm just going to leave it here.
> If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning
No it reflects the reality that requirements and applications evolve over time. You sound like someone who's never supported an application for more than 5 minutes.
> You sound like someone who's never supported an application for more than 5 minutes.
If your application requirements change every 5 minutes, then you prove my point - you suck at architecting and should honestly just give your job away to someone more competent.
The disagreement is on Ecto schemas used to represent databases tables from the persistence layer to the UI. Of course, use changesets to normalise user input but using the same schemas everywhere is a sign of immaturity as a developer. You really sound like someone who only does CRUD services. Real world is often more complex.
Which is why you architect before-hand with a paradigm of your choice, like DDD (Domain Driven Design) using proper contexts (which Phoenix supports) beforehand. That is the sign of a mature developer, not the other way around.
If your datatype for a column evolves over time to completely different types, it's just an excuse for poor planning and architecture. Eg. A string turning into an integer. That just sounds like someone junior would do with MongoDb.
> You really sound like someone who only does CRUD services.
You throw this like an insult, but in reality most applications can be simplified to just CRUD services. Chat interfaces? CRUD. Social Media? CRUD. Banking? CRUD.
I haven't used Elixer but tt's generally a good idea for the UI to have a different data model than the database (even if it means you initially type almost the same thing twice and have to write a tedious translation layer).
This lets you evolve each part independently and use the "native" types frontend vs backend, which happens surprisingly frequently as the app grows
> but tt's generally a good idea for the UI to have a different data model than the database
You're not wrong and most other comments are responding this from some sort of UI library perspective, like React / Svelte. However, if you're using even the barebones scaffolded UI using LiveViews from Phoenix, you don't have to do any of these. Phoenix will wire up the form to the changesets by default. Which is what I'm referring to.
I obviously don't know your specific use case, but in my experience having the database schema reflect throughout a project means its either very small or the design is going to run into problems.
It also sounds like a potential security nightmare. We have a policy of never sending domain objects across the wire so nothing accidentally gets sent. APIs must strictly whitelist data structures.
The way this can work in something like an Elixir or Clojure: you have gradual types in most of the core code, but you translate it just before you hit the view layer (e.g. templates).
The great thing about dynamically typed languages is you don't have to declare a new type for each view. You just select out the data you need and expose it for the view. In Clojure this is as simple as a select-keys.
Not sure what you mean here. Changesets are used to validate user input before interaction with business logic or your database; of course data validation has a runtime cost, in any language.
Please don't use changesets to enforce some kind of type system between system components. In case you do not trust your own code, Elixir is strongly typed (though not static typed), there are test cases, there's dialyxir and if still you cannot stop yourself from passing a number where a string will do, the process will crash, log a message for you to fix the bug, and get restarted by a supervisor.
I get why people are obsessed with static typing on "normal" languages, where bugs cause system downtime, but the Erlang platform gives you so many guarantees that even if you somehow make a mistake, it is never catastrophic. Gradual typing in Elixir is a nice cherry on top of the runtime, not the cornerstone to robust OTP software.
That's such a poor argument. What is the alternative here? Just let anyone fly with a dozen devices with the names BOMB and CRASH hoping that an actual bomb doesn't go off? Systems and processes exist for a reason.
Your example of 150ml liquids has no connection to this security measure nor incident either. That's just a straw man.
I think there’s a safety issue that isn’t necessarily reliant on ‘bomb’ being an explosive device: it’s the impact on other passengers.
Planes traditionally have avoided certain kinds of movies and such to avoid creating panic in the cabin. Here every passenger is looking at their phone, and if one guy makes the obvious “there’s a bomb on the plane” joke, the captain/crew could be in a situation.
Crowd management is essential to crew safety and crowd safety.
If my location dictates the type of employees your organisation needs / doesn't need, then yeah, you pretty much over-hired to begin with and just lack accountability. Hence trying to blame it on everyone and everything else except yourself. Respectfully.
I swear to God. I just want to go back to the 2000s where everything was just plain HTML and some basic CSS, if at all any, by default you got responsive design out of the box, readable text and super user friendly GUI from the browser's own default stylesheet.
Today you open any website. Everything is a fucking component. A simple dropdown with a finite list? Has its own loader and makes 10 fetch requests for no reason. Not even exaggerating - look at Instagram and Facebook on web.
Fuck all these specifications, just give me the raw HTML that isn't obfuscated by your shitty/shiny new JS framework that you swear will change the game (looking at you, React)
The 2000s, the golden age of web design, when people built inaccessible IE6-only mystery-meat navigation websites with Flash and HTML tables that dynamically loaded JS using iframes.
Can't upvote this enough. People have very selective memory of how the 2000s web worked. Every other website requires Flash just to show you a carousel of images. "Serious" business websites implemented in slow, buggy Java applets. iframes everywhere. Incredibly fucked up tables with no semantic meanings in your HTML just to do what modern flexbox now does in two lines. No one cared about accessibility of anything. Clicking on anything can get you pwned because you never updated your Flash player which has an RCE vulnerability. And yes, so many websites will tell you to use Internet Explorer for best experience.
I get being frustrated with some aspects of the modern web. But a lot of people are reminding of that Naomi Wolf tweet about how Belfast was calm and peaceful in the 1970s.
> Every other website requires Flash just to show you a carousel of images. "Serious" business websites implemented in slow, buggy Java applets. iframes everywhere.
Do you see the irony? This is a very selective example by itself. The table based minimal HTML + CSS websites existed throughout the decades (even so today) which is what I'm referring to specifically.
I'm not dunking on your whole argument, but as for this specific point: as someone who finds the mouse difficult to use and requires the keyboard a lot, the web definitely used to be a lot more accessible in this regard. There's no keyboard navigability anymore. And it would be so simple, just put an accesskey attribute on your buttons and textboxes. Nobody does it, anywhere.
> There's no keyboard navigability anymore. And it would be so simple, just put an accesskey attribute on your buttons and textboxes. Nobody does it, anywhere.
Nobody added those attributes in the 90s/2000s either, it's just that desktop apps (like browsers) all implemented keyboard navigation properly by default.
The real loss here isn't html authors being too lazy to add the attribute, it's that our modern desktop environments/apps stopped implementing keyboard navigation as a default
Table-based layouts that loaded faster and rendered better than anything you see today, and even read better on actually existing screenreaders (who never got the memo that tables are supposed to be less accessible than CSS and changing <b> into <strong> should make your site more disability-friendly).
You're referring to the mid-late 2000s. I'm talking about the early 2000s. You can hate Flash all you want, but for all the HTML5 hype we had back then, there isn't a single authoring tool today that's not even equivalent to the original Flash Studio (by Macromedia). It was the only tool in internet's entire history where both artists and programmers could work on together. Or sometimes even without each other.
What do you have now with all your fancy React and JS libraries that's pulled off something that Flash did?
Flash died because of the carcinogen that Adobe is. It could have been the future of HTML5 had they actually invested in it.
Look at the pathetic state of HTML5 today. What tool should a non-coder use to output something you could do with keyframes on Flash studio in 5 minutes in the 2000s? There's absolutely nothing quite the equivalent of Flash. You need to write 100+ lines of code to get something decent out of HTML5 that involves animation. There are paid niche tools, but nothing at the scale of what Flash pulled off.
You're not talking about the web, you're talking about authoring tools. There are (or were) plenty of modern Flash successors; it's just that most people don't use them when you can open a game engine and target the web that way.
> You're referring to the mid-late 2000s
Things like hidden iframe hacks to load JavaScript were a thing as far back as the late 90s, and table layouts have existed as long as HTML tables have.
Tangential but I remember Flash being killed by Steve Jobs and then smartphones in general. The iPhone’s battery couldn’t handle it or in any case he didn’t want to support it. I remember Flash being so prominent when iPhone 1 came out that the decision not to support it was shocking.
> The iPhone’s battery couldn’t handle it or in any case he didn’t want to support it
Very much the latter. Apple didn't want to give Adobe control of a big part of their new ecosystem - and they were already at loggerheads over Apple shipping native PDF capabilities in OSX
Every time is a beautiful time and a terrible time; it's just a matter of framing. I just don't think it's correct to point to the 2000s as some kind of golden age of amazing web design and tech.
That's funny because the argument against tables was always that they added extra markup a.k.a lines of code, only to replace them with dozens of nested divs, half assed CSS layout ideologies (floats and clear's, for example) and barely functional JS that all somehow needed to work in sync which was almost never. That's how NPM was born.
Tables worked with 100% of the browsers. The alternatives needed polyfills and shims and ironically the whole thing needed easily 2x the number of integration time and lines of code compared to just slapping tables.
There will always be a tension between those who want purely semantic documents and those who argue for a pragmatic allowance of layout to just be allowed in the document itself.
It’s indisputable though that the modern BS of frontend tech is approaching an asymptote of ridiculous complexity. The divs go so deep that it is often pointless to even try to determine what’s going on from a web inspector. And I think the documents themselves are now less semantic than they ever were. Sure, tables were abused (to the extent they weren’t anything close to tabular data). But today every element you see being a layer of 37 divs and spans that don’t even function or in some cases even render without JavaScript getting involved… the web is now just basically a responsive version of PDF.
View Source on any major modern website and many (most?) others is useless. You get 15 lines with some cryptic webpacked JS references.
It must be that we now have a new generation of devs that have no experience with the beauty of the original web where others’ pages were legible and you could as a human easily read and learn from their source. I’m not saying there are 0 tradeoffs but there’s definitely a loss there.
My first time wading into web development was hopping into the source of the MSN.com homepage circa 2000 to see how their DHTML menu rollovers worked, and then stealing it. It was mostly CSS, but to support some browsers they had JS assist with what's being moused over.
That kind of thing is utterly impossible to replicate with a modern frontend build -- all the classes are generated by styled components and all the behaviors are attached with React or Angular. Best you could hope for is to find some telltale attribute that points you toward an open-source library. Or, hope they left their sourcemaps on.
No, npm ultimately enabled the exact kind of accidental complexity I'm talking about where you need a massive node_modules folder and Babel just to generate client-side code
Did front-end dev (among other things) for half of the 2000s (and beyond) and heard plenty of arguments about semantic markup, flexible restyling, accessibility, separation of concerns, and more.
But not one about extra lines of code when it came to table layout.
And claiming non-table alternatives always needed polyfills and more code doesn’t sound like an accurate reflection of the time either. It sounds more like resentment of people who actually did invest in understanding of the domain because they might not just let you use the small toolset you knew without thinking about anything else.
And I say that as a person who did a lot of table-layout markup too.
Table designs were kinda brilliant though, both in how easy they were to create[1], but also how easy they were to parse programatically or with a text-based browser. Given context of the table in front of you, you can generally piece together where on the screen the information goes without rendering anything.
You can generally do a lot of the same things with CSS grid layouts, but it's 100x more complicated, and the layout information is generally in the CSS file rather than the document itself making parsing the layout a Hard problem demanding the implementation of a partial CSS engine (and a sometimes JS engine too).
[1] A totally viable workflow was to draw your website in something like photoshop, cut boxes where the content would go, and then export it to an HTML table.
Marketing email is still produced in this exact same way at some companies - ask me how I know!
(If anyone isn’t familiar with this, it’s because for security reasons we’ve all decided email should use an intentionally gimped de facto (non-)standard which only supports a few little dabs of CSS - 90% of email is formatted with strictly 90s technology.
And by “we” I mean that’s what Google and MS allow in their clients, so it’s very pointless to try to go beyond that given their combined usage share.
It became feasible to switch to CSS layouts for complex websites and apps in the early 00s. How early depended upon your target demographics and skill set. Lots of people who didn’t want to learn new ways of doing things carried on using table layouts long after browser support demanded it. I was using CSS sparingly from 1999 onwards and ditched table layouts in 2002, but I was ahead of the curve.
Same here, we resigned our site in early 2003 with CSS layout. Late adopters would snicker a bit back then, seeing it as chasing a fad or being too hipster.
Out of all similar situations, where I may have been an early adopter of a technology or method for reasons, using the web platform and following standards has probably been the one I least regret.
And today tailwindcss misuses the class attribute to add a gazillion classes that make your eyes bleed. By the time you reach the end of the list, you have grown a beard.
Yes and no. ie6 couldn’t render anything near the full specification so tables and other tricks were used where css couldn’t cut it. I’d still that that over JavaScript “apps”
I interviewed someone once for a fullstack role, gave him a mockup of a screen we had to build and asked how he would do it, in short some things on top of other things. The only thing he managed to say was how he would divide everything into components. I thought man, so many devs don't even know how to use html/css anymore, but who's laughing now, you just need to prompt a coding agent.
Ha, and I flunked a "Fullstack Developer" interview some years ago because I didn't reach for npm or React to build a page that had a simple form to make a request to the backend.
Quite. Or differences in the box-model, appending weird symbols to CSS to target specific browsers, adding zoom:1, praying you didn’t have to support IE6….
That doesn't seem relevant to responsive design? HTML and CSS are definitely responsive out of the box, but OTOH I remember how many designers of that era thought responsiveness was a bug and asked devs to add width:920px to body...
Right but how would you even display a vertical menu back then? `float: left` was rather bad, so you went back to using tables[0]. Good luck making these responsive.
[0]: and to using dozens of images sliced to fit your table cells, for that cool hover effect as well as round corners. :-)
> Why would documents have menus? Menus are for applications.
s/menu/navigation
> And there was nothing wrong with tables for layout, especially back then when the alternatives were very brittle.
I never said there was anything wrong with tables. OP said there was nothing preventing the design from being responsive, to which I responded yes, there was, at least in a lot of cases.
(Responsiveness was also mostly irrelevant back then because smartphones were not a thing yet.)
The idea that 00s websites were responsive is laughable. Websites used to tell you they are designed for resolutions 1024x768 and above, because they hardcoded the size and position and everything and the moment you sizes your browser window down a horizontal scroll bar appears, or worse. Say what you want about modern web practices but responsibility is only getting better, not worse.
Yeah I’m with you. If the web was still html-driven more than JS-driven, you wouldn’t need to make your site “agent-ready”.
On the same topic, it’s hilarious how much everybody suddenly cares about ergonomics of non-browser software. I have used SO many APIs that are just miserably documented, but now they have magical MCPs!! Which seem like they’re basically well-documented APIs? And suddenly everything needs to have a decent CLI tool because that’s what LLMs are suited for.
Like dang y’all didn’t care when the API was frustrating for me to use!!
IE6 was the most popular browser still during like 2006-2010. There was a point when Opera, Firefox, Chrome were already a thing, and they supported proper standard CSS and HTML, but 90%+ of users still used IE6 and you had to use tricks to support both standard and IE6 fuckery.
There is a company that makes a plurality of government software that still used VBScript-based HTML pages that required IE7 compatibility mode for their court management software when I left a few years ago.
But CSS can easily restyle every baseline HTML element. Making the web page look like the product is not only entirely possible without having to layer a framework on top, it's likely often easier and faster to implement than layering a framework on top.
First version of my website was pure HTML but that got unwieldly fast. I've been maintaining my own fork of the old pug/jade templating engine instead. It's essentially pure HTML but with no closing tags and with features to reduce repetition. I've been enjoying it a lot.
I too want to go back to that, but I fear most consumers/potential visitors to your website have been conditioned to expect flashy web by this point and so it's a self reinforcing paradigm.
I miss the days of Flash. Not because I want to actually use it, but because it being an extension forced most websites to offer a basic HTML4 version as well as a fancy, more opaque Flash one. After the advent of HTML5 almost all websites feel like Flash on steroids. Ditto for the IE6 holdovers.
> A simple dropdown with a finite list? Has its own loader and makes 10 fetch requests for no reason. Not even exaggerating - look at Instagram and Facebook on web.
I’ve seen an address form with search dropdowns that were absolutely bonkers. First it loads the list of countries. You start typing and the list disappears – it sends the text to backend, which returns... exactly the same list. The filtering is then done on the frontend. (After you select the country, you can select the region and then the city, which, of course, work exactly the same.)
Today you open any website. Everything is a fucking component.
We were doing the same things back then but with some nasty hacks to get things to work across different browsers. There's a reason why jQuery (released 2006) blew up, and plugin ecosystem was huge.
You literally can't make a website from the 2000's nowadays, because that means you want a 800px fixed width layout or something of sort.
If you do that, your website will look absolutely gorgeous since the 800px width + precise pointer + hover requirement allows you to get rid of all unnecessary whitespace, explain the UI with tooltips, and guarantees you always have enough width for one sidebar, but it won't be responsive.
The real solution to the modern web is to destroy all mobile devices on the planet.
The simple fix of the modern web is simple: no JavaScript. Enforce it as a security measure or whatever, but scripting is what is making the web worse.
yes. The moment when I see the interception of the scroll to show some overlay content. my brains either switching to admire the aesthetics or get's irritated by that. In the mean time I totally forgot the reason of this website visit.
Just because everyone builds it doesn't mean it will take off. Case in point: All the cloud serverless BS. Everyone in the industry are now switching back from server less because the math didn't work out.
I think it's just a fad and eventually you'll need to address the math no matter how much you sugar coat it - the 3x slower metric, eating of context window is all beneficial for LLM companies but not for the end user.
Ok, how many AI tools do you even use from 3 years ago? Funnily enough, I stopped paying for my chatGPT subscription a year ago.
Historically it has always been a bottom tier paying industry. Same like animation and VFX. On top of this, now you have AI and almost anyone can create some impressive games using stuff like Claude code. So, I foresee it will only get worse from here.
I mean, it was founded by the Nazi party, they single handedly destroyed diesels through the world's largest scam, what ethics can you really expect from them? I find it extremely funny when people boycott Teslas for being "Nazi" but won't boycott actual Volkswagens that was founded by the real Nazi party and to date - followed some of the most unethical practices in automative history :)
Just because the Nsdap party created something that doesn't mean you can automatically treat it is bad. That is prejudice. Something bad happening decades and decades after the party's dissolution is not going to be directly related. It is a reach to think unsupported third party apps breaking is related.
While I agree with you in principle, I don't think this is followed equally. Tesla's are still being vandalized to date, though. Selective outrage is a dangerous thing.
Well so the Nazis founded VW with confiscated union capital, and after the war control of the company was basically handed over to the union to make things right.
This is not an intelligent comment. the Nazi parry and modern-day Volkswagen have nothing in common, whereas Tesla is currently^ actively^ run by someone morally reprehensible to many.
If you had any actual understanding—:as opposed to just hearing this little factoid in passing and have been waiting for every opportunity to whip it out— you’d know that already.
It’s funny as a quip, but don’t for a a second act like it’s a legitimate point, which is exactly what you’re doing.
Stop pasting LLM replies through fake accounts. Dieselgate happened very recently (in this decade). Just research your stuff before you slap a prompt onto an LLM please.
I was talking to someone about a possible clutch issue on their car and they pinpointed to with a screenshot saying my diagnosis was wrong. I've been a car guy all my life and so I am not some amateur. I just wished them good luck and went about my business.
6 hours later guess who is stranded in the middle of the road? Not me.
It's an eye opener. Think about it - today, it was a mistake. But, what if it really happened? What if you really lost access to all your years of hard work? It's a wake up call. A blessing in disguise to store what matters to you the most locally, backed up offline. Never trust any single provider. Be it MS or Google or Apple. RAID is the way.
People should use something that keeps a local copy of their code and just copies it to Github and to other contributors with a sync process to push and pull changes. Some sort of 'distributed source control system' maybe. Then people would only need a 'hub' to connect to people, and it'd be easier to move somewhere else.
I'm looking at setting up rngit mirrors of all my repos on our boat NAS. Conceivably it also allows issue tracking and collaboration without centralized infra
What you just described is Fossil. It has an auto-sync feature that makes everything feel distributed.
Just set up a Kubernetes deployment and you’re set.
But as others mention, GitHub’s primary strength is collaboration. If you want decentralized, solve this by creating a decentralized collaboration tool on top of fossil and/or git.
For example, how to do pull requests and code reviews?
This gets tiresome. Github is a lot more than a host for Git repositories. If you want to suggest that people use something else, you need to suggest a replacement that has the features people use Github for.
yeah, #1, it is free private file storage, and #2, it's a download portal for free as in beer software replacing paid offerings. that's what it is for 99.99% of people.
being a host for git repositories has never been its core competency. neither has its groupware offering.
does it even serve OSS well? a very interesting criteria is, "Have mature or adopted end-user-facing OSS recently merged a large PR from an unallied contributor?" The answer is overwhelming no. This is why there is so much innovation in this space.
I think you missed the joke, which is that the parent poster you're replying to is suggesting a 'solution' to the problem which evolved in complexity until he was just describing Github again.
This happened to me as well—thankfully not my personal account that I use for work, but the organization associated with an open source project I worked on was suspended. It similarly took 2 months for GitHub to restore the organization.
> Our team is currently experiencing an unexpectedly high volume of tickets which has resulted in longer response times than we prefer. We acknowledge the long wait and apologize for the experience.
> Sometimes our abuse detecting systems highlight accounts that need to be manually reviewed. We've cleared the restrictions from your account…
Fully self-hosted IMO can be an overcorrection. The issue isn’t “relying on other people”—it’s relying on GitHub, when they’ve made it clear they don’t care about uptime and they don’t care about support turn-around-time.
Well yes, my git repositories sit on my laptop, that's the entire point. If github banned my country because its president has a tis, I can push my entire commit history to another company. Same with anyone else who's working on it.
It would be a pain as I'd have to set up a few integrations again, but github is far lower down the risk scale than the vast majority of SAAS providers
I've set up a local gitea now, and configured a few local runners as we test this setup out.
It's a few hours worth of work. Basic git operations and pull requests works fine for us already.
The interesting part will be how much maintenance this will need, and not the least how hard it'll be to port over github actions. We have trivial workflows, but I suspect this conversion will be the painful part.
I think they were intending to evoke the image of RAID rather than literally referring to a redundant array of inexpensive disks. You host your code on Github, Gitlab, and at home, then you survive a Github outage. It's a redundant array. Not sure it's inexpensive, though.
reply