241–250 of 366 posts
Earlier quoted context omitted.
Likewise, Ember holds the record on that list at 6.5 years, it was forked from SproutCore which goes back even further.
Wasn't it just renamed from SproutCore?
“Forking” vs “renaming a project and creating a new repo” sounds an awful lot like the same thing to me anyways.
Earlier quoted context omitted.
All of this is why, in the end, more and more... I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for, if I understand enough to write an SQL command, and use a library for that DB that does parameterized queries? On the front end, I tend to lean towards abstractions that work together... I really like React and the material-ui library's switch to JSS. It's relatively clean, and useful…
> I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for I think it's mostly premature optimization. People think writing DTOs is challenging, so they want an ORM. But since you end up needing DTOs anwyays, removing SQL capabilities from the app means writing SQL in not SQL, and things like joins suddenly become slow and problematic and result in really heavy systems that are harder to c…
To this day, I haven't found anything (including ORMs, Spring support, etc.) easier to use, more flexible, or more sensible.
(1) The closer you get to the front end (especially GUIs), the further you get from algorithms and other mathematical certainties and the closer you get to something that's more a matter of design and fashion. People get tired of GUIs looking and feeling a certain way and they change, and that often requires a code re-work because changes in GUI look and feel can break previous abstractions.
(2) Form factors and display technologies change. Mobile completely annihilated 30 years of GUI work for example. To a lesser extent high-DPI screens have done a number on some older GUI systems. The stuff under the hood changes too but more slowly and in less fundamental ways e.g. an SSD is mostly a "disk" from an abstraction point of view even though the tech is wildly different. Command lines are fundamentally unchanged since the 1970s. VT emulations have become more advanced but the basic paradigm is incredibly stable.
(3) GUIs look deceptively easy but in reality they're incredibly hard. A modern GUI layer is at the same level of complexity as a modern game engine like Unreal. The list of edge cases and layouts and modes and languages and interaction metaphors and input devices and so on and so on you have to support is very long. Software engineers routinely underestimate this difficulty and try to re-invent GUIs and GUI abstractions in a quest to be clean and small and simple. They're then forced to shoehorn everything a modern GUI requires into these clean and simple abstractions, breaking them and turning them into overloaded monstrosities. Simple clean systems get ugly when you try to extend them too far. A more elegant design could be achieved by starting with the premise that the problem is big and hairy and developing heavier and more flexible abstractions accordingly.
Is there a difference between "Medium" and "Self Promotion"?
I tried barking up that tree a year or 2 ago when Medium took over HN.
Earlier quoted context omitted.
All of this is why, in the end, more and more... I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for, if I understand enough to write an SQL command, and use a library for that DB that does parameterized queries? On the front end, I tend to lean towards abstractions that work together... I really like React and the material-ui library's switch to JSS. It's relatively clean, and useful…
> I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for I think it's mostly premature optimization. People think writing DTOs is challenging, so they want an ORM. But since you end up needing DTOs anwyays, removing SQL capabilities from the app means writing SQL in not SQL, and things like joins suddenly become slow and problematic and result in really heavy systems that are harder to c…
This part puzzles me: > "Put yourself in the shoes of a junior-to-mid-level JavaScript developer, writing a new application for the first time. > "It starts innocently enough. You have a completely clean slate and want to keep things simple. You are a devout Agilist and YAGNI is your watchword. So you begin with a ‘simple, barbones framework’. That sounds good, doesn’t it? (Even if it did not, that’s often the only c…
Because job postings don't say "Wanted: Junior developer with standard stuff JavaScript experience."
Sorry but I find font-end development pretty stable. Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal? In my career I also had to learn Java, PHP, C#, Node.js, bash, batch, Python… Build apps with Spring, CakePHP, Symfony 1 & 2, ASP.NET MVC 3 & 4… Query database with Hibernate, Entity Framework, Linq SQL… Handle dependencies with Maven, Nugget… Store data in Post…
Otherwise you are horribly screwed if you try to buy in into the current HTML-based fronted development.
Web frameworks are churn-y because they are incredibly leaky abstractions covering really awkward impedance mismatches. This means that they are never quite satisfactory - and that just to use one, you need to be capable of building a new one yourself. Think of a typical web app. Your data exists: 1. As rows in a database, accessed via SQL 2. As model objects on the server, accessed via method calls and attributes 3.…
Web frameworks are churn-y because they are incredibly leaky abstractions covering really awkward impedance mismatches. This means that they are never quite satisfactory - and that just to use one, you need to be capable of building a new one yourself. Think of a typical web app. Your data exists: 1. As rows in a database, accessed via SQL 2. As model objects on the server, accessed via method calls and attributes 3.…
All of this is why, in the end, more and more... I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for, if I understand enough to write an SQL command, and use a library for that DB that does parameterized queries? On the front end, I tend to lean towards abstractions that work together... I really like React and the material-ui library's switch to JSS. It's relatively clean, and useful…
Earlier quoted context omitted.
That's good, in each cycle, sooner or later you get improvement: webpack over grunt, react over jQuery and npm over vendoring your jQuery plugins. OP forgot how life looked when your web app project was handcrafted HTML page with manually inserted scripts tags. When your form submission was multi-level backend API in PHP. jQuery plugins with 20+ options published randomly on the internet.
I feel like this is a false dichotomy. The choice doesn't have to be roasting squirrels over an open flame/handcrafting PHP pages vs. shiny futurism/Node+React. I have been getting along just fine with Rails, HTML, and a sprinkling of JS for over 10 years.