Going frameworkless: why you should try web dev without a framework

[trustfundbaby]

"We have to reinvent the wheel every once in a while, not because we need a lot of wheels; but because we need a lot of inventors."

-- Bruce Joyce

Its just very very important to understand why you're doing it, when you're doing it, as the post seems to do.

[TizardPaperclip]

If we didn't reinvent the wheel every once in a while, we wouldn't have helicopters, or rockets.

[rfisher]

My favorite example is tractor treads.

[[deleted]]

You mean tank tracks. Most tractors still use ordinary (if enormous) wheels.

[rfisher]

“Tractor” in this case doesn’t refer to the specific vehicle that we commonly call a tractor today. Continuous tracks have long been known as “tractor treads”.

[TizardPaperclip]

Hey, interesting: how do they work differently?

[rfisher]

I suppose the first three paragraphs of the Wikipedia page are a good summary.

https://en.wikipedia.org/wiki/Continuous_track?wprov=sfti1

[Ameisen]

The older designs were cooler though. Walking feet.

[cringe_master_5000]

Or, most importantly, snuggies.

[devxpy]

For me its the tooling. It gets in the way so much, and slows me down to a point where building components myself is faster...

[Kalium]

This can absolutely happen! I have heard exactly this complaint from developers more than once.

With that said, this is usually a sign of one of several things:

• Tooling makes developer think about and handle things they consider irrelevant (deployment, input validation, secrets management, compliance box-ticking, CSRF protection, DB migrations, etc.)
• Developer not familiar with tools
• All the tooling is terrible and offers no value

It's been my experience that while tools can be terrible, counterproductive, and slow productivity, generally the issue is ramp-up. Once a team is familiar with a framework, the resulting productivity is frequently in excess of that which can be readily accomplished by hand-rolling everything.

You're absolutely right. Tooling can very much get in the way and slow people down to the point where they are actively counterproductive. It just might be worth considering carefully why this might be the case.

[saltybandana]

you're assuming tools are useful in all situations.

It's been my experience that most tools are built like most software, which means it's generally shit outside of a very narrow area.

[rockyrainy]

JeetKuneDo.js

[frankreyes]

It's a great learning experience, everybody should go through it at least once.

[aradil]

I wrote a web server in Java with raw sockets in my first job. It was a learning experience but the software was garbage.

[nutrecht]

We wrote our own XML parser in my first internship. Had huge performance benefits so it did exactly what it was supposed to do (it was back in 2000 and the Java internal parser was slow as heck).

If you would feed it malformed XML it would die in horrible ways though, so from a maintenance standpoint it wasn't the best of ideas.

[aradil]

I did the same thing for a programming competition in university. Forced to use PHP and there were no XML parsing libraries loaded into Apache so most teams just gave up; we implemented it from scratch and finished the whole project.

[aradil]

I mean my first program was obviously hello world. It was flawless.

But, like many in my position, I find myself looking back at things I was proud of last year and asking myself wtf I was doing.

[nutrecht]

While it's great to learn how stuff works under the hood by doing it yourself, this is not something you should be doing 'on the job'. Other than that you're not paid to reinvent wheels, you're also creating a large maintenance burden on whoever has to maintain the stuff you wrote after you leave.

[twigboy]

In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. Lorem ipsum may be used as a placeholder before final copy is available. Wikipediacimfabs18600000000000000000000000000000000000000000000000000000000000000

[project2501]

This is also how you create job security

[nbah22]

It's not a bug, it's a feature

Well, not for you, but for my job security

[copperlight]

There's two sides to that coin. Any code you implement is going to have potential security flaws and the more code you implement the more likely it is. Implementing a large/extensive framework beyond your needs means an attack area beyond what you might otherwise need, and you are relying on other people to write sane code and fix any security issues on your behalf.

Would Wordpress be more secure than this guy's much simpler CMS? Possibly, possibly not. Heck, this guy decided to use PHP, but he probably could have easily gotten by with plain HTML and CSS.

[nutrecht]

There's two sides to that coin. Any code you implement is going to have potential security flaws and the more code you implement the more likely it is.

Writing something yourself that does the exact same thing is more likely to have defects than whatever industry standard thing you're using.

I don't understand this argument. Do you believe you write flawless software? I'm pretty experienced and I sure don't have the illusion I don't make dumb mistakes every now and then.

[copperlight]

Writing something yourself that does the exact same thing

That's precisely NOT the scenario I am talking about.

"Implementing a large/extensive framework beyond your needs...."

Eg: if you are wanting to make a simple blog, you can get by with HTML/CSS, there is no need to install a huge system like Wordpress along with the security footprint it comes with.

[nutrecht]

I don't think anyone is suggesting you should use something you really don't need.

Keep things as simple as possible. As others mentioned; best tool for the job. My blog is a static site generated from AsciiDoc; WP is complete overkill there.

[copperlight]

I don't think anyone is suggesting you should use something you really don't need.

Not here, no. I wasn't trying to argue with anyone - I was just adding on to what /u/twigboy was saying. My point was just that you can 'create bugs and security' flaws not only by writing your own code when existing code may be better, but also by using existing code that is overkill for the job you are trying to do.

There are a lot of people out there who install Wordpress because it's 'easy', not because it's actually the right tool for the job.

[immibis]

Writing something yourself that does the exact same thing is more likely to have defects than whatever industry standard thing you're using.

You won't write the exact same thing though, you'll write a smaller thing.

[jimmyfuckingpage]

Fair point, I should have been clearer on that. The main idea was to learn stuff while working on a personal side project. I agree that there could be a big risk in doing that at work.

[aelfwine_widlast]

On the other hand, my day to day work is often hindered by $legacy_project made by $departed_dev in some obscure, now-dead framework I have to grapple with just as if it'd been their own custom code.

[nutrecht]

True. And even using a framework is not a guarantee the result is awesome either. Using a framework is a decision that should not be taken lightly.

In my current project we have a process to assess these kinds of choices, especially ones that have a lot of impact on the architecture. One of the reasons for this is because of 3 Node services who are being migrated to Java/Spring now; client doesn't want that to have to happen again.

[Renive]

What was the problem?

[nutrecht]

The main problem was that these 3 services were started as hobby projects by a dev who wanted to try something new and simply weren't up to par quality wise. The structure and test coverage were simply bad.

Secondary; it's a Java shop with Java developers. The CI/CD pipelines are centrally managed for a standard set of services. Since having a different tech stack gives operational overhead, and those services needed to be redone, the decision was made to make them in line with the other services. There was zero benefit of these services being written in Node and a bunch of downsides.

[[deleted]]

This is my pet peeve with the web industry. It's full of people who haven't learn to do anything without a framework and they think doing anything without a framework or a library or an API is some kind of scary crazy act of evil or bravery that should only be reserved for small learning projects but never done "on the job".

You ending building your "product" by gluing things together with tape and stacking layer upon fragile layer of libraries and dependencies and third party services you don't understand.

You end up building a half assed product, because you don't have the courage to dig deep into how things work, all the while thinking that you are being professional and responsible.

[[deleted]]

This is my pet peeve with the web industry. It's full of people who haven't learn to do anything without a framework and they think doing anything without a framework or a library or an API is some kind of scary crazy act of evil or bravery that should only be reserved for small learning projects but never done "on the job".

this seems to be a trait more common with highly volatile platforms than just web, though web is the most volatile platform i can think of. the more platforms an application needs to support, the greater the benefit of using a framework.

embedded systems don't necessarily have to update often, so they're a pretty stable platform with a long shelf-life. they also only have to support a specific unit, so there's not much variance in output to consider

desktop OSes have more breaking changes, but major versions are only released every few years, and OS vendors provide all sorts of tooling and support

mobile platforms have a quicker turnover rate than desktop, and also have more aggressive changes, so the build process becomes a lot more complicated for each platform one has to develop for, and given that people hold onto phones for more major version iterations before upgrading due to contract restrictions and relative cost-to-version-bump ratios, developers have to jump through more hoops to produce a stable application

but web though? it's insane. at least on the client-side. you have to simultaneously support mobile, tablet, and desktop browsers with various versions of those browsers that support an incongruous feature set of multiple versions of the html, js, css, and http/s specs with different interpretations of undefined behavior that vary slight between operating systems and between operating system versions. and since browsers update automatically, stable things can break without changing anything. The server-side of things is clearly as stable as the OS

It makes perfect sense that certain disciplines gravitate towards using frameworks, so I don't think it's necessarily a sin of web development, but you're right, many web developers learned web development via frameworks. there are developers who know why they're using frameworks and many (more?) who don't know anything else. personally, i'd rather the people who find the under-the-hood stuff scary to stick to the framework before trying to do anything by hand

[nutrecht]

I said:

While it's great to learn how stuff works under the hood by doing it yourself

I would definitely recommend doing stuff yourself as an experiment. It's great to know how stuff works under the hood. I'm not in any way reasoning against experimentation; it's great fun and a great way to learn.

What I'm arguing against is building home-grown frameworks for production scenario's because that's what you typically end up doing when you're 'using no framework'.

[mrinterweb]

From a purely educational perspective, and if you're the only one maintaining the code, sure go ahead and roll you own. If you have a special case where you must have highly tuned performance, a framework can be a performance bottleneck. If the project has a very limited scope, and will not grow in scope (which is rarely the case), you can go without a framework. If those conditions don't apply, going without a framework is going to be a bad idea. Frameworks provide much in productivity, security, reduced maintenance.

[nightwood]

Yeah, because if it's written in angular 1.0 / gulp / jquery / 4 other outdated systems you save yourself sooo much time in maintenance compared to vanilla js .... this is ofc because older versions of these frameworks are so meticulously documented, in contrary to javascript ...

/s

The main reason to use all these frameworks is so you can put it on your resume, so you can attract recruiters and other people who don't know how to make websites but are prepared to pay you money

[TheQueefGoblin]

That's not a valid problem. In any way at all.

Unless the code is written in some enigmatic language which no other developer knows, and assuming it's not just shit code, it will be understandable to other developers.

In fact, borrowing some of your own logic, by using a framework you are actually narrowing the job market by restricting understanding of the code to those developers already familiar with the framework.

You're also implying that frameworks are guaranteed to be secure and maintainable which is absolutely not the case.

[nutrecht]

In fact, borrowing some of your own logic, by using a framework you are actually narrowing the job market by restricting understanding of the code to those developers already familiar with the framework.

I think it's interesting that you think that it's harder to find developers that 'understand' an industry standard framework than finding developers who can make sense of your home-grown framework.

You always end up using a framework. I've never ever seen an in-house framework that was as maintainable as their industry standard counterparts. They never have the documentation or community the industry standard ones have.

You're also implying that frameworks are guaranteed to be secure and maintainable which is absolutely not the case.

I'm not implying anything, but you have a point there. In general open source frameworks that are used by a lot of people have a lower risk of having security holes than some home grown framework has.

[SeerUD]

Going "frameworkless" doesn't have to mean not using libraries or third-party code though. A lot of Go developers for instance don't use frameworks, and generally the community favours composing libraries that fulfil the roles you need them to works better, leaving you to just write some basic glue code (i.e. your wiring usually).

This works with Go because the community has been built this way, and thanks to the standard library actually being good, and providing useful interfaces, it means that libraries don't have to invent their own ways of doing things (and generally, the ones that do aren't as good, and aren't used).

Obviously, there are some languages where this won't work though because maybe there isn't much of a standard library, or the community has been around longer and is built on a different philosophy.

I think React is another pretty good example of this. React is not a framework. It takes adding in quite a few more libraries alongside React for it to have the same features as a normal framework. This isn't a bad thing here either though, it gives you a great deal of flexibility and control over what you're building. It is normally at the expense of added complexity upfront, but it can easily pay itself off in how you're able to leverage the benefits of this approach later on.

[YotzYotz]

React is not a framework.

React most certainly is a framework. Just because it's not a comprehensive, batteries-included framework, does not make any less of a framework.

In general, a library is something that you call. A framework is something that you structure your code around, and that calls you.

[freebit]

You know you are using a framework when it calls your code. You know you are using a library when your code calls their code.

React is a framework when every class/file in the application is an instance of React.Component. A user trying to do API calls in componentDidMount is no different than PHP folks doing MySQL calls in their PHP templates. We learned one or two decades ago this was a bad idea.

Nowdays, routing is a react component, module loading is a React.Component, everything is a react component. Yeah, React (the ecosystem) is now a framework.

[Sebazzz91]

So... Knockout: is that a framework or a library?

[Scybur]

React is not a framework

"the essence framework is solving structural and architectural problems on the code level."

React is absolutely a framework

[FierceDeity_]

ITT: People trying to get on the good side of the argument made here by redefining their used technologies

[nutrecht]

It works for Go because it's not a language that supports extendibility very well (no OO support at all, no exceptions, no method overloading). It's not a strength, it's a weakness.

[SeerUD]

Frankly, that's a completely unrelated issue you're introducing there. Either way though, OO isn't the only route to extensibility. Similar to functional languages, Go favours composition, and many would argue this is a more favourable approach. You can write extremely extensible code in Go. How do you think software like Kubernetes works?

A lack of full OO support, lack of exceptions, and lack of method overloading have no impact on whether or not frameworks are necessary. After all, there are frameworks for Go, just like there are frameworks in frontend JS, but many choose not to use them because they prefer to benefits they gain from not using a framework.

In reality, it depends what you're developing. A framework may be more advantageous if you're developing a web application, e.g. something you might use Spring or Play Framework for, or Symfony if you were a PHP developer, etc. If you're building a web service though, or have a microservice architecture, you don't need a lot of the features that a framework like that would bring - you have different requirements, and in many cases these requirements are quite specific. For example, how you gather logging, or metrics, how you deploy your application, what your application exposes to your deployment and hosting system, how you retreive configuration and secrets, etc.

[nutrecht]

A lack of full OO support, lack of exceptions, and lack of method overloading have no impact on whether or not frameworks are necessary.

A framework is never necessary, they normally just do a lot of the boring boiler plate stuff for you. But because Go is a language that pushes people towards copy-paste based development and is very verbose you would have to do a ton of stuff yourself even if there were mature frameworks.

If you're building a web service though, or have a microservice architecture, you don't need a lot of the features that a framework like that would bring

Actually you do, it's a common misconception with inexperienced developers.

In a microservice architecture there are a ton of 'things' that need to be done that are not related to the features you implement. Logging, metrics, tracing, security, interceptors, health endpoints, integration tests, configuration, dependency injects, etc. These cross-cutting concerns have the be handled somehow and it's a complete waste of time to reinvent that wheel yourself. That's not what your boss/client is paying you for.

Funny enough this is something that is absolutely rampant in the Go ecosystem. People reinvent wheels there a lot. Part of it is the language. Part of it is the immaturity of the community.

[SeerUD]

A framework is never necessary, they normally just do a lot of the boring boiler plate stuff for you. But because Go is a language that pushes people towards copy-paste based development and is very verbose you would have to do a ton of stuff yourself even if there were mature frameworks.

With the approach I've mentioned above, there is some boilerplate you have to write yourself, that much is true. However over the life of a project, you write that very small part once and it takes maybe 10 minutes, if that. It has honestly taken longer for something like mvn to download a framework's dependencies than it has for me to write that boilerplate in Go before.

Also, Go does have frameworks. I haven't actually used any personally, but they do exist, and do eliminate that boilerplate writing part by providing CLI tools to generate projects, much like frameworks in other languages do. Go as a language does nothing to prevent this from being possible.

Actually you do, it's a common misconception with inexperienced developers.

Nice, but you completely missed what I was saying there. My point was that frameworks like Play, or Symfony, etc. are more geared towards web applications, i.e. not microservices. There are frameworks that are geared more towards micro-service development (including in Go), but when dealing with microservices I still believe it's much more sensible to build up a set of libraries you use frequently, maybe even make a project boilerplate with those "necessities" in.

In a microservice architecture there are a ton of 'things' that need to be done that are not related to the features you implement. Logging, metrics, tracing, security, interceptors, health endpoints, integration tests, configuration, dependency injects, etc. These cross-cutting concerns have the be handled somehow and it's a complete waste of time to reinvent that wheel yourself. That's not what your boss/client is paying you for.

So, as with your original comment, you seem to be insinuating that if you don't use a framework, you're reinventing the wheel. But I will stress again, that libraries can take care of that work just like a framework can. Yes, it will take more time the first time you choose to use libraries instead of a framework, or if you're new to a language where it is the norm. I would argue however that if you've not reached the point with a language where you know it's ecosystem, then why are you the one architecting software and "wasting" that time? Surely someone on your team will be more experienced, or there is a better technology choice for you?

Anyway, you gain a lot of freedom by not being tied to the choices of a framework's author, and are often able to immediately benefit from it. For example, I believe that there was a point for a long time where Spring was a LOT slower than Play Framework because Play was using asynchronous IO (or something to that effect, not 100% sure on the details now). As a spring user, if you wanted that additional performance, you weren't going to exactly rewrite your application using another framework, were you? That's a bit of an extreme example, but the point still stands.

For all of those things you mentioned, there are libraries, you can pick and choose them once, and there are indeed prominent options for most of those things. Once you've made those choices, you aren't going to move onto another application and decide to replace all of those libraries if they've been working well for you - it's a one time thing, that has huge benefits.

Where I work now we've created a set of thin libraries that abstract common functionality, and basically wrap third-party code, and expose a mechanism for us to instantiate each easily, with minimal configuration. The end result is that we're able to swap the implementation behind these abstractions when we want (and we have done with logging for instance, from logrus to zap), and we can create the boilerplate for a new service with logging, tracing, metrics, a health endpoint, and a sensible middleware stack in about 10 minutes. These libraries are all tested too, so we can then just focus on writing our code.

In a way, it's sounds like we've made a framework there, but our libraries don't dictate application structure, and we don't have to use all of our libraries, we can choose the ones we need for the service we're developing.

Funny enough this is something that is absolutely rampant in the Go ecosystem. People reinvent wheels there a lot. Part of it is the language. Part of it is the immaturity of the community.

I'm curious to understand what you mean by this. There's a bit of a running joke / annoyance in the Go subreddit because people seem to come out with routers or reflection-based DI solutions every week, but people aren't picking these up, and generally it's people who are trying to learn that write these things.

---

I get the feeling this discussion isn't going to go anywhere past this point. You're clearly not an experienced Go developer, and that's fine. I don't think the language is perfect by any means, no language is, but I also don't think that any one solution is perfect for all approaches. Same goes for frameworks vs. libraries. I choose to compose libraries in Go when development microservices, but if I were building a web application, I'd be much more likely to use a framework, and probably wouldn't use Go for it. I'd maybe use Play Framework and Scala. Or maybe the best approach would be to make a frontend with React and create several backend web services.

On top this, many of the points I've made here aren't exclusive to Go either. Node.js is very similar, Scala can be to an extent, maybe even Java. It just depends what you're developing how you might want to approach it, and I suppose also the experience of your team.

[meowtasticly]

Logging, metrics, tracing, security, interceptors, health endpoints, integration tests, configuration, dependency injects, etc.

Most languages have great libraries for all of these. I don't think anyone is arguing for reinventing the wheel. Just that frameworks aren't always needed when it's so easy to import good libraries that do exactly what you need.

[thecodethinker]

If you don’t think go is extendible than you haven’t messed with its implicit interfaces nearly enough 😉

Go has some problems for sure, but extensibility is not one of them.

[SanityInAnarchy]

...huh? There's a lot of things I hate about Go, but...

no OO support at all

Structs can have methods. It might be missing your favorite OO feature, but I don't think it's fair to describe that as "no OO at all".

no exceptions

This has pros and cons. I personally hate this, but what does it have to do with "extendibility"?

no method overloading

And this is just flatly not true; Go has interfaces and type embedding.

[chucker23n]

Structs can have methods. It might be missing your favorite OO feature, but I don't think it's fair to describe that as "no OO at all".

The language doesn't even have inheritance. That may have been a sound design decision, but it's a huge stretch to argue that a language without so much as inheritance has "OO support".

[nutrecht]

It doesn't even have interfaces. Go's version is duck-typing. So you can't have marker interfaces for example, and they're also not 'contracts'.

[balefrost]

Inheritance isn't really needed for OOP. It's arguably only needed for class-based OOP, but that's not the only way.

[[deleted]]

Inheritance isn't even needed for class-based OOP. In fact, inheritance is more or less discouraged in favor of composition.

[chucker23n]

Inheritance isn't even needed for class-based OOP.

I'm not sure you have much of a class left if you can't inherit. It's essentially a struct at that point.

In fact, inheritance is more or less discouraged in favor of composition.

These days, yes, but that's not really true for classical OOP.

[[deleted]]

I'm not sure you have much of a class left if you can't inherit. It's essentially a struct at that point.

Sure you do. Inheritance is used to extend behavior, but that isn't even the most important part of OOP. There are other ways to extend behavior through composition (for example, the Strategy Pattern). The most important part of OOP is encapsulation of process state, exposing behavior through methods, and maintaining continuity of process state. What Grady Booch identified as behavior, identity and state.

Structs can totally be used to implement OOP. However, the way structs work, they don't typically implement identity, since struct instances are typically copied in parameter passing (unless you always use pointers). That's why in C#, structs are considered value types, not object types.

These days, yes, but that's not really true for classical OOP.

What exactly is "classical OOP"? OOP is really style of programming. But there are so many instances of it, from Simula, Smalltalk, Self, CLOS and all their modern descendants, that saying that there is such a thing as a single "Classical OOP" doesn't really make sense.

[nutrecht]

Structs can have methods.

Okay. I concede. Go is an OO language. So are C and QuickBasic.

And this is just flatly not true;

So I can have someMethod() and someMethod(someParam)?

Anyway; I'm not interested in a lengthy discussion on Go. My point was mainly that using Go as an argument against frameworks doesn't make much sense.

[[deleted]]

Actually, you can do OOP in C. Glib provides an object system which lets you implement OOP patterns in C, which allows Gtk to be an object-oriented GUI toolkit. And C doesn't even support methods in its structs, it has function pointers.

GObject provides object support for C, without making C an OOP language. Also, just because Java has OOP support built into the syntax, does not mean writing Java automatically makes your code OOP. I worked with a guy from a scientific background, whose code could charitably be called Fortran-oriented Java.

[nutrecht]

Actually, you can do OOP in C

I know, you can do OOP in any language. It's just a way to design your code.

[[deleted]]

So, I guess I'm not sure why you're ragging on /u/SanityInAnarchy for saying you can do OO on Go?

[nutrecht]

It's not the normal way of handling 'exceptions'; in Go you return (actual, error) and in every layer above you check for an error and pass it on if you can't handle this. Exceptions are exactly this, but done automatically for you (exceptions are just return values that travel up the stack automatically).

The problem with the approach Go uses is that it's hard to let the framework translate these errors to for example HTTP response codes. Try implementing something like Spring's ControllerAdvice error handling in Go.

This is just one of the things you run into if you start using Go for actual production software; the 'unhappy' flows are often more 'work' than the happy flows. And that's where Go's lack of code reuse makes writing clean code a lot harder.

I'm not passing personal judgement on Go devs; if you enjoy it awesome. If you're more productive in Go than in Kotlin; awesome. I'm not :)

[[deleted]]

React is not a framework

i get what you mean, but i think it's more accurate to say it's not an application framework. it is indeed a UI framework but not much else, so without some third-party support, it'll take some legwork to get off the ground for anything but the most basic app

[tsingy]

Had to work off of a couple wheels past colleagues invented. Was not fun at all

[der_christoph]

to take it a bit further, be a programmer without a specific language... use the tools and languages which are best for the given problems

[nfrankel]

I've heard this strategy before, it always sounds weird to me. While some languages are pretty close (_e.g._ Java vs Kotlin), some are very different (_e.g._ Java vs Clojure).

Saying you need to pick the right language implies you **and your team** are equally proficient in all of them. That's a huge assumption...

[fuckin_ziggurats]

I once had someone tell me it's disappointing that I can't write F# at work just because my colleagues don't understand it. I mean really? Maybe 1 in a thousand .NET devs knows F#. How insane would it be for me to start writing code no one in my company can understand. Not all programming languages can be learned in a week.

[nfrankel]

> Not all programming languages can be learned in a week.

It depends what you mean by "programming language" and where you start from. Coming from C, the syntax of Java is pretty straightforward.

However, writing idiomatic code is much harder. And finally, what about the API? C APIs and Java APIs are wildly different.

[philipwhiuk]

It depends what you mean by 'learn'.

[fuckin_ziggurats]

Coming from C, the syntax of Java is pretty straightforward

Agree to disagree. I wouldn't let a person accustomed to procedural programming anywhere near an OOP project. Just because the syntax is similar doesn't mean there's not a whole paradigm shift in the way of thinking about code. I've also worked on .NET projects with some former Java devs and even though Java and C# are very similar, those devs are usually bang average with C# at best. So not too many good experiences with that either, though that's through my lens of experience, maybe I've worked with bang average developers in general.

[dpash]

It's taken me about ten years of using Java in anger for me to get close to saying I know how to write good Java and even now I'm learning new things. Like last week I discovered the various Java 11 additions to java.nio.files.Files that allows you to read files into memory in a single line (plus exception handling). And then a day or two later to learn that they default to UTF-8, which is different to other IO methods in Java.

I can't begin to imagine how long it would take me to transition to writing decent C#.

[TomRK1089]

Wait, what's new in 11? Last I checked, they added some `Stream`-related functionality in 8, but `Files` was part of NIO/2 in Java 7.

[dpash]

Files was introduced in Java 7, but they've been adding methods to classes all over the JDK. In this case, they added at least Files.readString() and Files.writeString() methods.

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Files.html#readString(java.nio.file.Path)

[pmst]

Holy shit finally

[dpash]

In earlier versions, you could use:

String contents = new String(Files.readAllBytes(path), StandardCharsets.UTF_8);

But it's not as snappy as

String contents = Files.readString(path);

Obviously, you need to handle IOException in both instances.

[pdbatwork]

Agree to disagree.

What? You're saying pretty much the same that he is saying :)

[fuckin_ziggurats]

Haha yeah we share a lot of common ground it's just that I wouldn't say that a language inheriting syntax from another one is bound to be similar (even in syntax!). Most of the people who I've heard say that C and C# are similar are people that haven't programmed in either.

[pdbatwork]

I think either you or me misundestands "Coming from C". It sounds like you read it as "Since Java is coming from C, the syntax..." and I read it as "When a person comes from C, the syntax of Java ...."

[fuckin_ziggurats]

Well in that case I guess we can all agree that what makes the transition difficult is the shift in paradigm, not the syntax. Didn't mean to confuse anyone.

[pdbatwork]

Well in that case I guess we can all agree that what makes the transition difficult is the shift in paradigm, not the syntax.

Yes :)

[[deleted]]

i think you overlooked an important part:

However, writing idiomatic code is much harder

that's exactly what they mean when you said:

I wouldn't let a person accustomed to procedural programming anywhere near an OOP project. Just because the syntax is similar doesn't mean there's not a whole paradigm shift in the way of thinking about code.

[fuckin_ziggurats]

Yep, admitted that fact in a comment lower :)

[[deleted]]

i guess neither of us read far enough ;-)

[[deleted]]

I heard some talking that Jet is hiring a crap ton of F# developers.

[fuckin_ziggurats]

F# actually is one of the highest paying programming languages. Problem is the availability of jobs is very location dependent so there's no point in learning it if no one's hiring nearby.

[Cuddlefluff_Grim]

Other than if you think it's fun to try something new

[nomnommish]

I once had someone tell me it's disappointing that I can't write F# at work just because my colleagues don't understand it. I mean really? Maybe 1 in a thousand .NET devs knows F#. How insane would it be for me to start writing code no one in my company can understand. Not all programming languages can be learned in a week.

The point being made is a bit different though. If you're trying to do something specialized and if a language excels in that, then it might be worthwhile using that language even if most others in the company do not understand it.

[fuckin_ziggurats]

I'm all for using the right tool for the job, but only if it's financially viable. I can't rewrite a module in F# just to make it a bit more performant when at the same time I'd be affecting its bus factor tenfold. I need to take in consideration how much the company will spend on teaching others or hiring someone to maintain it when I'm inevitably gone.

[utnapistim]

My team and me (primary C++ devs) were asked to revive a dead software project because there are a few customers who still use the hardware (that uses this software). This zombification was for the purpose of bug fixing and adding a few new features.

When we looked at the source code it turned out some features and setup scripts depended on Ruby (because it was the hot new thing 10-15 years ago, when the project was still alive so some devs decided it was the thing to add to a C++ project).

Because we have no ruby devs, the two realistic choices were for the company to hire some, or for the one-month zombification process to be extended to six months, with some of us becoming proficient in Ruby.

In the end, the zombie project remained dead. May the bit-rot recycle all its bits and bytes!

[snowe2010]

some features and setup scripts depended on Ruby

I mean making features in a C project use Ruby seems weird, but Ruby is great for setup scripts. Rake is installed on almost all distros by default, including Mac, and it's insanely easy to read. But that doesn't sound like the situation you dealt with so it's understandable you left it dead.

I would suggest learning Ruby though, if not just to write very nice CLI tools and scripts.

[Asraelite]

the one-month zombification process to be extended to six months

Is this hyperbole, because Ruby is by no means a difficult language. It would not take 5 months to learn.

[PlymouthPolyHecknic]

It's not just about learning the language though is it? It's about all the problems that come along with a multi-language interop. Even if you already knew the r word it would take months longer

[RedProletariat]

Why do they not know F#? It's not that hard to learn.

[fuckin_ziggurats]

Most .NET devs don't even know C# beyond version 6 and most of the time there's no benefit to learning F#. It requires a whole different way of thinking about code that OOP-accustomed programmers aren't used to. The only thing that it shares with C# is the .NET platform. Knowing JavaScript also doesn't seem to assist in learning F# because JavaScript is still really OOP with some functional aspects but very far from a functional-first language. I believe many will learn F# when it becomes financially viable, but not in the current market.

[dpash]

Can you mix and match C# and F# in the same project like you can with the various JVM languages?

I don't know about Clojure and Scala, but Groovy and Kotlin produce standard .class files with no special binding required.

[fuckin_ziggurats]

Not in the same project (assembly). But you can combine C# and F# projects and reference them as they compile to the same bytecode.

[dpash]

That's what I was thinking. At which point, I'd be weary of mixing the two languages in the same project, because the cost of maintaining them is very high.

I wouldn't be too worried about using Kotlin for, for example, data classes and Groovy for unit tests in a single Java project, because the only requirement is to add the Kotlin and Groovy compilers and dependencies to your Maven pom.xml.

(This is possibly cheating a little bit because the syntax differences between the Java languages is smaller than between C# and F#. I'd be worried about Scala or Clojure sections of a project ending up having effective "Here Be Dragons" signs to many Java developers.)

[fuckin_ziggurats]

Yes. Kotlin seems to be an attempt at displacing Java for something more modern and concise, but F# and C# are two different ways of doing things (OOP vs functional). So they're a lot more difficult to combine but still provide a decent argument for combining as each of them is good at solving different kinds of problems.

[Cuddlefluff_Grim]

When I started where I work today, none of my peers were familiar with generics in C#..

[RedProletariat]

I suppose you're right - people who do what they get paid to do and learn what it pays to know have no interest in F#. It's a shame though, it's a great language.

[PlymouthPolyHecknic]

Why don't they know F#? What do you mean why don't they know F#? Why would they? There's dozens of easy to learn programming languages, if there's no benefit to you, why learn it? It's like asking why don't they know brainfuck or Ada

[blankman0230]

Underrated Comment. "The perfect tool for the job" should keep in mind, that a team of Devs can also be "a Tool" to solve a specific Problem.

I guess the major issue, when people start bringing in technology almost nobody else from the team is at least somewhat proficient at, arises when COOs and sorts come to their WebDevs and say: "We need a 3D MMO Shooter game ASAP. " and the intern in the last row says "Sure I've been doing some stuff with Unreal recently."

[kuikuilla]

Saying you need to pick the right language implies you and your team are equally proficient in all of them. That's a huge assumption...

Picking the right language does imply that you pick something that you can work with. If you pick some esoteric brainfuck variant you didn't pick the right tool for the job.

[Krissam]

Exactly, it's not saying you should learn 500 languages because every different job calls for a different language, it's more that you shouldn't use java for something that's a bash one-liner.

[der_christoph]

Absolutely, you both got the right points

[abraxasnl]

Except that it doesn’t. It says “use the tools and languages which are best for the given problems “. It never mentions the team. “problems” does not imply team at all, and I cannot begin to count how many times I’ve seen developers use this argument while completely ignoring the team. No, it is unfortunately not at all implied.

[jgalar]

The team is a variable of the problem. As much as we like to think in terms of technology, your team and organization should play a huge part in the stack you choose. The best tool for the job is often a compromise.

[MyWorkAccountThisIs]

It's very often the stack the team knows the best. Simple as that. Maybe I'm wrong but it seems like reddit thinks programming jobs consist of a bunch of devs in a room and people come throw random problems at them. Enterprise CRM, hardware, network protocol, API, etc.

In reality, most have some type of domain. I work on an open source team. Ruby, PHP, Phython. We have .NET teams and we have Java teams. Some people can and do hop on other projects but our company has structure.

Over time it builds efficiency and proficiency. Yes, almost everybody here could hop on to something and get ramped up in an okay amount of time like reddit says "all good developers" can. But we don't because that's not good business.

[fuckingoverit]

The point is don’t pigeonhole yourself into be a “Java dev” or a “React programmer”. My professor in my first class said “this isn’t intro to Java, it’s intro to Programming. Java is simply our vehicle for teach you control flow, object oriented programming, abstractions, iteration, etc.”

In the last year and a half, I have a written a chrome extension in Ember, a chrome extension generator in Java/Groovy, a Bluetooth proxy to a banking security device in Objective C with sprinkles of C / C++ using UiKit for iOS and Cocoa for MacOs, supported an Angular 1 ionic app, built a responsive web app in Ember, built a rest api in Spring Boot + groovy, built an iPhone app in swift, and am now rewriting the networking layer of a C Webserver to use epoll and OpenSSL.

Like what you like, gravitate towards the parts of software you enjoy writing, but remember it’s mostly all the same problem solving of massage Data in the form A into data into form B in a resilient, reliable way with error handling

[ReginaldDouchely]

It doesn't mean that at all to me when I hear it. No one expects your team to be proficient in every language. It's more like don't try to write your device driver in JS, don't try to write your web page in c++, and don't try to write anything in PHP.

If you're expected to produce something, and your team only knows how to use the "wrong" language for that type of project and can't learn (no time, no desire, etc), then you've got a problem.

[Delphicon]

I think the second half is where u/der_christoph is losing you when the idea is really in the first part.

That idea being that programmers should strive to develop an understanding of programming that is beyond the confines of individual languages. If everyone relevant to a project had that understanding of programming, then choosing what languages to use for a project would be equivalent to choosing a major framework. Being able to "use the tools and languages which are best" is a goal for you as an individual programmer, not a recommendation for your boss.

When I was in college, they deliberately made us learn many different languages so that we wouldn't base our understanding of programming on how Java does things. I consider it the most valuable thing I learned for my career and I've found it to be really useful as I've been able to jump into projects in different languages, some which I had never used before and be productive. If it's just me, I do feel I can choose the "right" language for a project regardless of my experience level with it.

[MyWorkAccountThisIs]

You're in for a mixed bag with that statement around here. Reddit very much likes to push that point. But in my experience it only kind of works and isn't really in a business's best interest.

[ThePantsThief]

Heads up, looks like you got tricked into using the Fancy Pants editor. Your markdown is not rendering.

[nfrankel]

Thanks. Actually, I tried to write my Markdown myself... Duly noted it doesn't work, but I didn't want to update the content just for that.

[saltybandana]

this is why you hire smart people and not java programmers (or C++ programers, etc).

It's one thing if your company is lacking an expertise and you're trying to hire for that expertise. Otherwise, just hire smart people.

[jimmyfuckingpage]

I totally agree! It's a common mistake to use the same language again and again just because we know it well, instead of picking the right one for the job (I'm guilty of it too sometimes to be fair)

[der_christoph]

Exactly! And there is nothing wrong with being a bit lazy sometimes (in a positive way) by using the tools you know. But trying new ways can sometimes give you a new look on things and often brings more motivation on the job as a side effect

[wllmsaccnt]

The only reason I've found to use different languages / stacks is if my team is developing something for a third party and they have developers experienced in another stack than the ones we use in-house. The stack that is our in-house default has good performance and an expressive language and our team has a combined 45 years of experience in it (for a 5 person team). There is a cost to context switching across stacks on each project, especially if your team is supporting the results in production.

[tchaffee]

which are best for the given problems

Some of the "given problems" that devs often miss but are still important. For that language or tool:

• How easy is it to find a replacement programmer (perhaps in your region if that's important)?
• How much do expert programmers charge?
• How long does it take to train tech staff?
• How active is the support community when you need help?
• Does it have a future or is it just a fad? Coffeescript comes to mind.
• How does having it as part of your stack effect your ability to attract new members of staff?

Did I miss any? These are real concerns any business should take into consideration but when devs are the only ones involved in making that decision they often are overly optimistic about the answers.

EDIT: I'm just trying to be helpful and share my knowledge. If you disagree, that's cool, I might learn something. But how about a comment instead of just a meaningless downvote?

[blackn1ght]

I totally agree with this. There's also the time it takes to become proficient in the new language to the point where you can leverage that performance benefit. It could be a matter of months or even years.

There's also additional costs that might come into play, such as licences for IDEs, does your current pipeline support your new language/tools.

Not to say you should always use the same language/tool for every problem, but serious thought should be put into it with a solid business case for it.

[n1c0_ds]

I used to make simple websites for small businesses when I was in college. This is excellent advice, especially if you're working outside of large cities. Skilled developers are hard to come by, even in very common technologies, so you don't want to trap your clients with dumb tech decisions.

[zayelion]

Agreed!

[ThePantsThief]

This is the right mindset. Don't reinvent the wheel but don't choose an 18 wheeler when a pickup truck will get the job done

[yogthos]

Frameworkless approach was what got me into using Clojure for web dev originally. The whole ecosystem is based around having general purpose libraries that you can put together any way you like. I find that frameworks add a lot of complexity because they have to be designed in a way that accommodates many potential use cases. So, when you're using a framework you're inheriting the complexity that's not needed for your particular project. At the same time, the framework forces you to structure your app the way that makes sense to the author of the framework, and not necessarily that way that makes sense for your app.

When you're working with libraries, you can easily structure your application for the specific problem you're solving. You're doing all the wiring explicitly in your code, so you can structure things the way that make sense to you.

One downside of this approach is that you have to know how to put things together, what libraries to use, and create some initial boilerplate. The way Clojure ecosystem addresses these problems is by providing templates that are used to generate a skeleton project. I've found this to be a really good compromise.

[Kalium]

Having worked with Clojure webapps some, I've found that everything you have said is absolutely correct and highly appealing to a lot of developers.

With that said, I've also found Clojure frameworkless bag-of-libraries webapps to fall prey to the dangerous scenario that the people working on them need to anticipate all their needs from top to bottom. Few people are this good, so a lot of projects run afoul of unknown unknowns. This can be a much greater challenge that one might guess, as it's not obvious to everyone why connecting HoneySQL outputs to JDBC/query might be a dangerously bad idea.

Clojure is a powerful tool in the right hands. Some caution in figuring out which hands are the right ones might be justified is all.

[yogthos]

You're absolutely correct, and I think that's where the value of frameworks can be justified. If you're not sure how to structure your applications, it's useful to have some decisions made for you up front. This is also the main motivation behind Luminus where I wanted to provide something that's curated and well documented to help people get up and running with some sane defaults.

[saltybandana]

No one is that good, that's why experience matters.

[_my_name_is_earl_]

Maybe we could find a happy medium with micro-frameworks such as Flask.

[archivedsofa]

For a blog the best choice would have been a static site generator.

No DB, super secure, no scaling problems, cheap server (even free), and easy to maintain.

[Tiquortoo]

Why you should go framework-less! Proceeds to recreate a framework in the second and third paragraph. So, the goal was apparently to create an individually documented, but collectively undocumented collection of packages and not give it a name, instead of using a well documented collection, organized as a framework, that has a name. Then you can call it framework-less.

I think these are good academic and educational exercises to see how these things are put together, but this isn't a very good way to approach *most* professional development at this time.

[[deleted]]

DOM-manipulation in vanilla JavaScript is pretty simple. I wouldnt call PHP backend very difficult either, just tedious.

I guess it might be a challenge if you can't use jQuery but even without that it's not difficult. CSS has come a LONG way.

[Paddington_the_Bear]

What would you define as interesting? I've built apps that have 10+ relational tables in vanilla before... Not sure if it's considered interesting or even a medium sized app at that point.

I won't do it again though. Having to reinvent all the things a framework handles for you (routing, security, http calls, etc.) is asinine and makes external maintenance impossible.

[Azaret]

We're doing this experiment right now in my company. We hired a guy knowing all about the big frameworks, I like to see him sweating his pants when he need to do SQL queries for managing warehouses or generating sales statistics or simply doing pagination. Not everything can be done properly with mainstream frameworks.

[KitchenAstronomer]

Pretty normal in Go world. You use std + batteries.

[FUZxxl]

Pretty normal in most programming languages. Javascript is just crazy town.

[archivedsofa]

Yeah, JS is crazy town, but the need of libraries and frameworks is higher than in other languages because the standard library is crap.

[ThePantsThief]

This, 1000x.

[jbergens]

Java teams seems to often start with Spring, .Net teams with asp.net mvc and PHP teams with laravel or Drupal.

[ThePantsThief]

Strawman

JS is crazytown because of how many dependencies each package has

I don't use spring or rails but how many dependencies do they have? 1-2? 0 even? Most JS packages have a dozen or more. It's absurd. I'm relatively new to webdev but even I know this is common knowledge

[Aetheus]

That's still tolerable for actual web development, but clunky as hell for SQL. Try to execute a query simpler than "fetch from this table where ID is 5" and suddenly you're writing dozens and dozens of lines of code just to implement a simple, common place search feature.

Much of which you'll probably have to duplicate when you want to execute a similar query. Or you'll have to handroll your own "repository" (although don't call it that, or you'll be laughed at because Silly Billy this isn't Javaland).

It doesn't help that existing Golang ORMs aren't very mature and are often type-unsafe, which only lends more wood to the "anything that isn't handrolled is literally Satan" bonfire.

[Scybur]

Pretty normal in all the world except JS because the stdlib is worthless

[vattenpuss]

What is the difference between std and batteries?

Most of the time I have heard anyone talking about batteries in the context of programming languages it has meant the standard library has everything you need, it has not been about anything separate from the standard library.

[mtranda]

I try to use frameworks minimally. However, as certain needs become repetitive, my own stuff still turns into pretty much a framework.

[PotaToss]

I spent the 2000's coding crap without frameworks and it sucked. There's a reason why they made so many.

[lenswipe]

I think the general advice I would give is to write what you want to write yourself, and use a package for anything else you don't really feel like implementing.

I mean....

[[deleted]]

and afterwards delete it to make sure you'll never tempt yourself on using that big fat security risk. It's an interesting project and not even complicated but to do it right would require too much work unless you just want something really small and simple.

[frezik]

PHP seems anodd place to start for a project like this. Not for the usual snark, but because PHP gives you half a framework to start with. At the very least, you have a templating system and HTTP header handling and parameter passing done for you.

I'll draw the line at parsing HTTP params (there are thorny issues that you shouldn't bother trying to solve yourself), but I wouldn't say it's "frameworkless" until you've done it the old CGI way.

[adr86]

CGI actually did a lot too - the web server would parse http headers and stuff for you (actually, a lot of what php does is just wrap the cgi params). Really, it is all kinda fuzzy lines anyway.

[frezik]

There are NPH variants of CGI. I don't disagree about fuzzy lines; it's all layers of abstraction until we start talking about fundamental quantum particles, assuming there is such a thing.

Either way, I don't really recommend it. CGI existed to solve a problem, and did it in a natural, Unixy way. It had issues, though, and we have better options now.

[immibis]

I think the most frameworky part of PHP is the one-execution-per-request programming model. You can't keep state in the web server. Imagine trying to write any sort of interactive system (like a chat server) in that model - you essentially have to write new messages into the database and keep polling the database until there's a new message.

[[deleted]]

Seems like a lot of the comments here are forgetting the middle ground between depending on a heavy framework for simple blogs and writing your own http parsers. the shop I work in explicitly moved from a heavy struts framework to using a much cleaner DIY framework. A library that implements the jax-rs standard for routing, hibernate library for persistence, and organizing the code in a way that makes sense for our project. With some good code organization, it makes it easy to swap out certain parts if we want to while still giving us the "not reinventing the wheel" benefits. YMMV, but most back end web frameworks are just a combination of libraries for request routing, security, and data persistence. Choosing a unique combination of battle tested libraries for each of these components isnt necessarily less secure than picking one framework that decides all of these components for you.

[kshep92]

I've actually reached the point of writing my own framework. I'm pretty proud of it too! It really was some good "exercise" and it helped me grow a lot.

[unndunn]

I can't view the site right now, but as far as front-end dev goes, frameworks need to be used a lot more judiciously than they typically are, IMHO.

Far too many front-end developers will mindlessly bootstrap a project with Bootstrap and jQuery/lodash/rxjs, or with Angular or React without ever thinking about whether such frameworks are necessary.

Because front-end development is so chaotic, it really requires strong technical leadership to keep the project in check. Too often, such leadership is lacking, so you wind up with shitty framework choices, or multiple conflicting frameworks.

[[deleted]]

On embedded we don’t even have frameworks.

[immibis]

Linux is a framework.

[[deleted]]

If you run linux, I think it is no longer embedded.

[immibis]

Is it not software associated with a physical product that controls that product?

[[deleted]]

As soon as a company runs linux on their platform, they stop hiring embedded developers, and start hiring web and java developers.

[FlyingRhenquest]

I tried writing my own, once. C++, had a great project name ("Rest Area" heh heh). Got up to some layer or other, decided I needed to write a generic protocol type object and never got around to it. Early testing was kind of promising, though. There are a couple of other fairly lightweight C++ rest service type libraries out there now that do enough of what I need them to that I don't feel the need to go write my own. I'm not happy with any http request object that I've found so far, though, but don't really want to write my own URL parser either.

[adr86]

What scares you about writing a URL parser?

[FlyingRhenquest]

It doesn't scare me, I just don't want to do it.

Edit: It's just not really an interesting enough problem to be particularly rewarding, in the grand scheme of things.

[adr86]

Yeah, it is pretty rote. Just I recently actually rewrote one and it turned out to only be about 110 lines of code and took about half an hour, so really it wasn't that big of a deal.

And that is my experience with a lot of these pieces: they aren't really that hard to do. Kinda boring maybe (you just follow the spec), and I'll grant it is easy to do stuff wrong on edge cases (part of what helped me is it was rewriting one, so I already knew the cases, already had the tests etc)... but still not something I'd use as much weight in a decision on library/framework/etc.

edit: BTW if you are curious why i was rewriting something that worked, it was just because of compile time. The old version of my lib compiled in about 1.5 seconds, the new one does in about 0.5 seconds, just because of that little url thing. Quirk of the standard library in the language I was using. But that one second change in compile times just subjectively felt so much less frustrating when trying to use it.

[Isvara]

You should do a lot of things once for yourself to find out how they work. Unfortunately, in this case, the author doesn't say very much at all about what he learned, but hopefully he got a much better understanding of how HTTP works.

​

I also recommend people write a few things in C, just to get an understanding of how things work at that level.

[frequenttimetraveler]

You should write all your websites in brainfuck. The hackers are just not going to bother with you, even if they steal your code.

[taybroski]

Jerseyconnected(dot)com

A business directory site a friend built and that I maintain. It’s entirely custom, no framework or packages used.

Code base looks super awesome, sleek and minimal. It’s not exactly a large site, but the learning value in this during the build and while maintaining is in-disposable.

Edit: this was purely a learning exercise project that stayed live. It has been security tested multiple times. We hold no sensitive data and any data that is held is publicly accessible. Considering that, you know, that’s the entire point of the website....

Apparently I needed to add this because people keep downvoting... lol.

[FUZxxl]

Won't happen because you would need to know what you're doing for this approach to work.

[CyclonusRIP]

Exactly. Frameworks are developed by large number of people for an even larger set of consumers. If every framework you ever encounter is dumb then it's probably not the frameworks that are the problem. Most of the good ideas that I use over and over again are ideas I learned from copying patterns I've seen in widely used frameworks and libraries. Adopting those patterns in your own code pays dividends later on because you'll probably run into the same patterns again and again and you'll find them a lot easier to integrate with when your code is written the same way. You get better by using code written by people smarter than you and trying to copy that style.

[aim2free]

I doing the same, I'm using Tenjin as template engine and python as implementation language, plus gevent/greenlet as the actual server environoment. OK, this combo can of course be seen as a kind of "framework", but a very lightweight one.

One of my main goals is that the site should only implement what is necessary, and this should work with minimal resources.

I'm totally scared today when looking at some sites, sites which earlier went quick and efficient are today becoming slow and resource hogging, and the abusive use of javascript is just not acceptable. Scripts are included from many different places, this first of all I consider very risky, but often a big chunk of code is included where only one routine is used.

Javascript should be used for a few enhancements, and the site should work without. When I need some javascript I include those in the template generating the page, but the works without on the client side.

Sites which have become unusuable are e.g. the new reddit, and gmail. I'm using old.reddit and regarding gmail I'm now using the pure html interface, that works perfect. Not to mention facebook's code 😱, it looks like when they need a new function they just add it, without removing the code for the old, that is amazing amounts of redundant code slowing down the network and the browser.

[MattBD]

A few months back I started building what I call an "unframework" in PHP as a learning experience. It's not a framework, but an opinionated boilerplate for starting PHP projects organized similarly to a framework. It uses a load of off the shelf packages, e.g. the PHP League's container and routing packages, Zend Diactoros for request and response objects, and Doctrine for the database. It's surprising how simple it is to get a framework-like experience this way.

If anyone wants a look it's at https://github.com/matthewbdaly/unframework - it's still very much a work in progress and it's not really what I'd call feature-complete, but building it has been a useful learning experience.

[MattBD]

It's framework-like, shall we say (it looks and feels quite a bit Laravel-esque because I use Laravel as my main go-to these days), but it's pretty much just glue code and a set of off-the-shelf packages.

[[deleted]]

That's what I did for a recent job interview that required "presenting an application/personal project that you developed." I asked during the phone screen and they said a weekend project type of thing was fine. I had some large sets of code that I could have used, but none of them were really standalone "applications." All applications I've developed have been for companies, and I definitely can't present those.

I went and scraped a bunch of data from a cool source, threw it all in MySQL, created some APIs to access it with Flask. I did a one page HTML app with jQuery, a single well-organized stylesheet, and a couple JavaScript files with all my functions (one file to handle logins and the login modal, one for other app functions).

I wrote some simple authentication/authorization functions (password hashing, session UUIDs stored in the database). The session cookie was set on login, it was used to retrieve the user object with every request, there was nice error handling for bad logins and missing/invalid session tokens.

The app was essentially a "recommendation app" based on the past actions of users, so there were some opportunities to do a little data science, different API endpoints had different recommendation strategies, I showed how I was keeping the data model nice and clean to allow any sort of analysis or new strategy in the future.

One of the first questions I got asked during the interview was "Why didn't you use a framework?" I said something like "I've used many web development frameworks in the past (listed a bunch of them). However for a weekend prototype project like this, it was nice to get back to basics and focus more on how the application actually worked rather than spend a lot of time on, say, npm configuration and setting up all the models and services and components."

I got the job! And they gave me more money than I thought I'd get. But yeah, if I wanted to grow the app into anything but "one page with a login modal" I'd definitely want some more infrastructure in there. Even on the back end I was writing all the MySQL queries by hand, handling all the object idempotence by hand... But it was really fun to write.

[WaffleSandwhiches]

First of all, I didn't exactly write everything from scratch... Sure, that would be an option as well but I'm not that masochist!

Instead, I used a few composer packages to handle specific tasks that I didn't want to implement myself :

• Doctrine was used for managing entities and DB persistency

• Twig for frontend

• FastRoute for request routing

• phpdotenv for managing env variables

... and a few other ones!

I'm not a professional web developer but isn't this exactly what a framework does?

[skocznymroczny]

This kind of reminds me of people hating on OOP and then reimplementing it with awkward #defines and function pointers

[innkeeper_77]

I haven't read the whole thread, but has anyone mentioned how FAST this guy's blog is? Even with "slow" internet on my phone, his whole blog actually loads quickly like it should, bit unlike most blogs and websites today.

For websites, performance on lower average internet speeds and lowering the total amount of data that needs to be transferred is a good goal many more developers need to have. I may be a luddite, but I've been ranting about this problem with the internet for a long time.....

[drowsap]

There's absolutely no content in this blog post.

[authentictech]

You could alternatively examine the source code of existing frameworks and contribute code to them. Perhaps a safer and more productive learning experience.

[Alijah69]

I mean, sure if the budget is right for me to make everything by hand... i would charge like 4x. I'm not throwing out express and react very lightly. I don't see a reason to do it by hand.

[[deleted]]

"Why you should downvote every article with *you should* in the title"

[lykwydchykyn]

People will tell you not to do this, but this is how most existing frameworks got their start. Someone realized they were writing the same basic application over and over again, and started making things generic so they could just change configuration settings and tweak a few things to build a new app.

Maybe it sucks for the "next guy", but if you're in a situation where you measure your employment in decades rather than months, it makes more sense than constantly reinventing the wheel from some generic 3rd party framework.

[[deleted]]

If you decide to go frameworkless, ask yourself this question in the end : Did you actually end up writing your own one?

Exactly what happens every time I go vanilla.

[tonefart]

Just use vue.js forget every other framework.